Crash saving geomstream with auxChannel data #6583
Comments
|
Show your code please. |
|
The polyface creation is in the attached file. Then just create the geomstream and assign this to a geometric element's elementGeometryBuilderParams property. It works fine without the auxChannel data. |
|
I might be reading it wrong, but if the test just stores the geomstream into the database and no other services are running than I expect it won't show the problem. The actual update of the element is not what crashes. While I can't be sure, I believe it is either the tile generation based on this new geomstream, or somehow rendering the tile. |
|
Gonna need actual repro steps. |
|
Alternatively, consider using the debugging, logging, and crash reporting capabilities built into Studio to capture a native stack trace. |
|
Either generating and saving that geomstream in an application, or opening that imodel in an application should reproduce it. I checked for logs in %TEMP%\iTwinStudio\Logs but I don't see anything from native. |
|
No crash when opening the view, whether I open the .bim with none of the other files present, nor with all the other files present. Tiles finish loading and I see a green polyface and below it the outline of a blue rectangle. Several seconds after I zoom out a bit, it crashes. Element geometry stream reported in display-test-app does not include the aux channels, but otherwise looks reasonable. (I assume the green polyface is the element that's supposed to contain aux channels). |
|
Yes the green mesh is the one with the aux data. Although if it shows no aux data then I wonder if it actually got the last transaction or not? Since it crashed after that change. But I would have thought it would be in the journal file and applied even in that case; assuming the display app has that logic? |
|
Index out of bounds.
|
|
@Rock2000 your mesh has the same number of aux data indices as it does vertices. It is expected to have the same number of aux data indices as it does point indices. |
|
The aux data indices is not the same as the point indices? I'm passing in the polyface pointIndex as the aux data indices. |
If you're talking about this sample, the flat mesh has 58806 point indices, 58806 aux data indices, and 10,000 points. The cantilever has 5688 point+aux indices, and 1424 points. If you look at my previous screenshot (from your polyface), you've got 4124 point indices, 3093 aux data indices, and 3093 points. The documentation is sparse and unclear, but the code appears to assume that aux data index count == point index count. |
|
Yeah I had misread your first explanation. I thought you said aux data needed to be the same length as pointIndex. But now that I read it correctly, it is very weird because I literally pass the pointIndex as the auxIndex, so I'm not sure how it would end up as point count. polyface.data.auxData = new PolyfaceAuxData(auxChannels, polyface.data.pointIndex); Let me poke around a bit more. See if I can step in and see anything. |
In addition, the Polyface visitor code assumes the indices for aux data are parallel in structure to the other Polyface index arrays. In other words, the indices for a given facet are found in the same range of every index array in the Polyface. I'll try to make this clearer in the documentation. |
|
The platform is changing the polyface data somewhere. In my sample data from aux.txt, there are 723 points and 723 pointIndex and 723 auxIndices. I save that geomStream to an element and then read that element back. The geom that is read now has 723 points, 723 auxIndices, but 964 pointIndices. I'm surprised it touched my polyface at all, but maybe that's legit? If so, it feels like there is code that tinkers with the pointIndices but doesn't adjust the auxIndices similarly. Maybe related, I will want to compress our polyfaces as all the facet vertices are their own points right now (none shared). I was curious if the compress also correctly updated the auxIndices during this process. |
|
Looks like iTwinjs transfers AuxData indices verbatim to flatbuffer bytes, without transforming them into 1-based, 0-terminated format like it does for the Polyface point/normal/param/color indices. I believe this was a mistake. When that polyface flatbuffer is deserialized into an imodel-native polyface, it's probably missing the zero after each face loop that the other polyface index arrays have. This is what causes PolyfaceQuery::ClusteredVertexDecimate to crash. I propose changing the Polyface AuxData index array FB format to be 1-based 0-terminated, exactly how we persist the other polyface index arrays. In native/iTwinjs FB deserialization logic, it should be possible to come up with heuristics to detect invalid AuxData index blocking in existing flatbuffers, and to use the point indices to recover the correct blocking. Serialization would be changed to always write the correct blocking. As for compress, |
|
Here's a file containing a polyface with aux data that was created using the existing TypeScript API AnalysisExample.zip, to test against any changes you make to the persistence/serialization layer. |
Actually, it looks like the native API must have written the flatbuffer bits stored in this bim file, as the mesh in this file has valid aux data. (It's the TypeScript API that has the AuxData serialization error.) I am creating other test cases, though, and using the sandbox aux data for one of them. |
FYI @Rock2000 if you plan on compressing a mesh that has |
|
TypeScript and imodel-native PRs are merged. Keeping this issue open to track:
|
We are creating geometric elements that represent a 3d surface. We tried to add auxChannel data in order to use the Scientific Visualization feature, but after saving the element with the auxChannel data the platform crashes.
To Reproduce
Attached is the mesh with aux data that was used. The aux data in this test is Scalar data that is simply zeros. Save this polyface to a geomstream. The element update call will succeed, but afterwards the platform will disappear. I presume when the tiles are being regenerated.
aux.txt
Desktop (please complete the applicable information):
The text was updated successfully, but these errors were encountered: