POST
|
Hi, I've already informed our local support about this issue but I'd like to show it here, too, in case someone else is running into this problem. We're (maybe ever since) struggling for a long time with missing blocks generated by our export process (we're exporting cities into our realtime engine). That results in ugly black holes when viewing the city in our engine. Now this has always puzzled me but I haven't had the time to investigate the issue further. At least, the blocks appeared to be totally fine in CE itself so I thought it was probably a stupid bug in my CE export scripts or engine import tool. Now, as we're nearing the end of our current project, this becomes a rather hot issue because you really won't drive through a city which has such blatant faults, so I instrumented our export processes to gather metadata about how the export data flows through our pipeline. I've been very baffled when I discovered that apparently, shapes from a single block seem to be exported twice! I'm assigning new IDs to exported models based on the running block index when I'm iterating through all blocks in the scene in our export script. So the models have been exported twice, but with different block indices! That made me wonder why this could happen and I traced the final exported model files back to their original shapes/blocks in our CE scene. That is where I discovered that apparently there are shapes in the scene with equal UUIDs! Individually, they seem to be generated by different blocks but get assigned the same UUIDs so that, when I iterate through all blocks, I visit two blocks but when exporting the shapes of these blocks, they're equal! So what happes that, although I export two different blocks, I only get the shapes from ONE of the blocks. That perfectly explains the observed twin models in our final export data. I made some screenshots showing different shapes from different blocks which have the same UUIDs (OIDs). Also, both shapes seem to have the same set of parameters assigned (as you can see in the inspector). Which explains another issue our designer reports to me from time to time, that she was modifying shapes (assigning new rules, changing attributes etc.) but after a save/load, the block looked "destroyed". Which probably results from "copying over" attributes from a different block. I haven't yet found a way to re-assign UUIDs or any other way to force twin shapes/blocks to separate from each other. Regards, Oliver === Quick Update === I've fooled around with our city and I discovered two important things: a) Apparently all twin blocks are separated by a street and are facing each other. b) By removing this "divider" street and re-adding it, it is possible to make the resulting two blocks unique Yet, I can't tell why this happens in the first place. Maybe it is some rare side-effect when splitting up blocks with additional streets, although I wasn't able to reproduce the observed results.
... View more
03-22-2013
06:57 AM
|
0
|
1
|
801
|
POST
|
Hi, I've tried it and have to say it works very well, the mesh now looks right! Unfortunately this approach seems to make the u coordinates discontinuous along the u axis. We're strongly relying on continuous UV-Coordinates for detecting driving lanes later on so this fix only works half for us. I'll look if we can maybe circumvent this by treating roundabouts differently when figuring out the exact street layout. Many thanks for this fix!
... View more
02-28-2013
10:47 PM
|
0
|
0
|
1058
|
POST
|
I'm sorry, didn't knew that - I've contacted our local distributor's support now, too. Hopefully they can sort this out. In the meantime I'll look if it is possible to pre-model the geometry I need - we're doing some post-export mesh analysis to get precise street data but the current approach isn't working on roundabouts because of this bug. Regards, Oliver
... View more
02-27-2013
07:50 AM
|
0
|
0
|
1058
|