Hi,
I am trying to create a .3sm in Microstation Connect Edition with Descartes. When I select the dgn level for the shape to clip with, the resulting .3sm ignores the shape and appears to triangulate across the clip boundary. I am getting the same result in ConceptStation if I do data import with a .dtm and an SID to create the .3sm, where the .dtm has an exterior feature but is ignored in .3sm creation.
The yellow in the image below is the clip shape the .3sm should be honoring.
There are lot of issues with 3sm which were not problem with stm. I have logged like 5 issues with generated terrain 3sm.
Main issue is that it doesn't seem to correctly work with GeoCS. Also grouping and feature order doesn't seem to work correclty.
Hi David,
When you add a dgn level as a clip boundary in Descartes only the vertices will be filtered, not triangle edges. Which means that during the generation process triangle edges might cross the boundary of the clip in the dgn level, in order to create a convex hull. This is the same behavior as with the old STM technology.
If you want to clip the triangle edges as well you'll need to apply a non-destructive clip using the Reality Mesh Attachments dialog's clip functionality.
To do the same with OpenRoads ConceptStation you need to define your region of interest as a polygon when creating your .dgndb file.
That being said in your screenshot I am seeing some vertices that are outside your clip boundary, which seems a bug. Could you send us your dataset for further investigations?
As for the external feature of your DTM I know that recent version of OpenRoads ConceptStation is supporting DTM boundary features, which can be use to enforce some kind of hull that is not convex. Is your feature a boundary?
Thanks,
Mathieu
Hi Oto,
What do you mean by "doesn't seem to correctly work with GeoCS"? Georeferencing?
If so 3SM should be handling geo-referencing and reprojection in a similar fashion as the STM is doing.
Also what do you mean by grouping and feature order? Import process?
The 3SM and STM import process is practically identical (i.e. : in fact the import code is almost the same for both technologies).
The big difference between the 3SM and the STM is the mesh generation process, which allows 3SM much better display performance and scalable analysis.
That being said the STM terrain generation is currently resulting in terrain that are likely to be more similar to what the Terrain Model element will create, though we are working hard to make the 3SM terrain technology to handle all the edge cases that the Terrain Model technology do.
I mean the defects 7000807200,7000810425,7000807049,7000810983, 7000805472 and Enhancement 923268
3SM terrain production is not stable enough. Best would have to have STM to 3SM converter.
I just reviewed your defects and here is a quick update: - 7000807200 : A fix has been pushed a few months ago.
-7000810425 : The ticket was close by our technical support group (TSG). Someone from TSG should contact you about this one.
- 7000807049 : We have this item for this one : Enhancement 926927:[DC][CCE] Disable some feature sources. Not sure I completely understand what the request is though. You want to automatically deactivate source data but keep the source data on? Is that something that is supported by the STM technology?
- 7000810983 : TSG is currently reviewing this one, a defect might be filled.
- 7000805472 : We have this item for this one : Enhancement 926957:[DC][CCE] Generate Scalable mesh(3sm). Probably a bug though, something we broke when modifying the STM import code to suit the new 3SM technology. Not yet fix.
- Enhancement 923268:[DC] Add display quality setting like the one available for STM : Not yet started.