I'm facing a problem with the ocgkml Writer. When I route 3D surface geometry of building models to the writer, I'm getting flipped surfaces for my facade features. Unfortunately this behaviour doesn't remain constant for all facade triangales, some of them are oriented correctly and some are not.
The input features look correct to me and exports to collada prove this to be wright.
An export with FME 2015 also shows a correct export with all walls oriented correctly. So this has to be an issue with FME 2016 and 2017.
Has anybody else encountered this behaviour and found some workaround for this?
Find attached the sample data together with a snipped of the workspace and the exported KML files
Thanks in advance to everybody who can help me!
Best answer by geosander
Hi @whkarto,
One of the major differences between the 2017 and 2015 output that I noticed, is the fact that each building in the 2017 version is a MultiSurface that contains a lot more Mesh parts than the 2015 one. I guess your Building.ffs file contains the original data, right? In that case, the 2015 output seems to be correct (as you expected) and the 2017 one converts the CompositeSurface parts of the MultiSurfaces into more Mesh parts than it originally contained. My guess is that the Collada writer (which the KML writer calls) is to blame here and something goes wrong with the triangulation.
As a workaround, you could try to take care of the triangulation yourself (so the Collada writer doesn't screw up) and deaggregate each building one level so you end up with all CompositeSurface geometries, pull them through a Triangulator (which outputs Meshes) and then reassemble them into MultiSurfaces (e.g. grouped by UUID) using an Aggregator. Then write out to KML again. I'm using 2017 and for me, this worked!
Nevertheless, this feels like a bug, so I would report this to @support (e.g. @DaveAtSafe).
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
One of the major differences between the 2017 and 2015 output that I noticed, is the fact that each building in the 2017 version is a MultiSurface that contains a lot more Mesh parts than the 2015 one. I guess your Building.ffs file contains the original data, right? In that case, the 2015 output seems to be correct (as you expected) and the 2017 one converts the CompositeSurface parts of the MultiSurfaces into more Mesh parts than it originally contained. My guess is that the Collada writer (which the KML writer calls) is to blame here and something goes wrong with the triangulation.
As a workaround, you could try to take care of the triangulation yourself (so the Collada writer doesn't screw up) and deaggregate each building one level so you end up with all CompositeSurface geometries, pull them through a Triangulator (which outputs Meshes) and then reassemble them into MultiSurfaces (e.g. grouped by UUID) using an Aggregator. Then write out to KML again. I'm using 2017 and for me, this worked!
Nevertheless, this feels like a bug, so I would report this to @support (e.g. @DaveAtSafe).
One of the major differences between the 2017 and 2015 output that I noticed, is the fact that each building in the 2017 version is a MultiSurface that contains a lot more Mesh parts than the 2015 one. I guess your Building.ffs file contains the original data, right? In that case, the 2015 output seems to be correct (as you expected) and the 2017 one converts the CompositeSurface parts of the MultiSurfaces into more Mesh parts than it originally contained. My guess is that the Collada writer (which the KML writer calls) is to blame here and something goes wrong with the triangulation.
As a workaround, you could try to take care of the triangulation yourself (so the Collada writer doesn't screw up) and deaggregate each building one level so you end up with all CompositeSurface geometries, pull them through a Triangulator (which outputs Meshes) and then reassemble them into MultiSurfaces (e.g. grouped by UUID) using an Aggregator. Then write out to KML again. I'm using 2017 and for me, this worked!
Nevertheless, this feels like a bug, so I would report this to @support (e.g. @DaveAtSafe).
Thanks, sander_s that approach worked perfectly! The result now looks as expected and changes in workflow are not worth mentioning! So you're getting two thumbs up from me!
Thanks, sander_s that approach worked perfectly! The result now looks as expected and changes in workflow are not worth mentioning! So you're getting two thumbs up from me!
