The cross-references between the poly and its holes are not properly updated if any of them move within the files. For example, if an unrelated poly occuring earlier in the file than the poly with holes is deleted or moved to, say, the bottom of the file, the poly "loses track of" the holes and the holes no longer "point" to the poly.
The results can be quirte "unusual".
Don
Polys with Holes
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm
Hi Don.
If you change the drawing order of a polygon, it's holes may not be drawn properly. The drawing order is found under the General tab of the polygon properties. A hole must have it's order later than the polygon it is cut from.
For example, if your poly is #34, the hole must be at least #35. Assuming the hole is #35, and you change the drawing order of the parent to #75, the hole will no longer be cut in the parent.
The resulting BGL of a "lost" hole does produce some odd things when viewed from TMFViewer, and may produce oddities in the sim.
Rearranging the draw order of polys that contain holes is not a good idea. The drawing order in the sim is controlled by the terrain.cfg file. The order within the BGL, of polys with identical draw priorities ( as per the terrain.cfg ), is considered random, according to the Aces.
So changing priorities in the SBuilderX file isn't needed.
========================
Deleting an unrelated poly might change the relative ordering of the hole, or it may not... regardless, the hole needs to be reassigned as a hole to the correct poly if it does not display as a hole in the SBX display.
The lesson here is to use holes sparingly in SBX, and perhaps to draw them last in the project.
Dick
If you change the drawing order of a polygon, it's holes may not be drawn properly. The drawing order is found under the General tab of the polygon properties. A hole must have it's order later than the polygon it is cut from.
For example, if your poly is #34, the hole must be at least #35. Assuming the hole is #35, and you change the drawing order of the parent to #75, the hole will no longer be cut in the parent.
The resulting BGL of a "lost" hole does produce some odd things when viewed from TMFViewer, and may produce oddities in the sim.
Rearranging the draw order of polys that contain holes is not a good idea. The drawing order in the sim is controlled by the terrain.cfg file. The order within the BGL, of polys with identical draw priorities ( as per the terrain.cfg ), is considered random, according to the Aces.
So changing priorities in the SBuilderX file isn't needed.
========================
Deleting an unrelated poly might change the relative ordering of the hole, or it may not... regardless, the hole needs to be reassigned as a hole to the correct poly if it does not display as a hole in the SBX display.
The lesson here is to use holes sparingly in SBX, and perhaps to draw them last in the project.
Dick
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm
Thanks for the info Dick. I wasn't aware of this restriction.
However, as explained in my first post, the poly that was moved - to the "top of the stack" (i.e., to the highest numbered poly) so I could see others - was unrelated to the one with the holdes. The relative positions of the probelm poly and its holes was unchanged, but all the cross-references were corrupted when SBuilderX attempted to renumber the polys to account for the move.
Don
However, as explained in my first post, the poly that was moved - to the "top of the stack" (i.e., to the highest numbered poly) so I could see others - was unrelated to the one with the holdes. The relative positions of the probelm poly and its holes was unchanged, but all the cross-references were corrupted when SBuilderX attempted to renumber the polys to account for the move.
Don
-
rhumbaflappy
- Posts: 420
- Joined: Sat Oct 16, 2004 10:11 pm
Hello,
Holes were added to SBuilder when the internal data structure for polys was already defined. If you create simple polygons with and without holes and export them as a SBX file, you can understand how child polygons (holes) were implemented.
During the testing of the programme there were many more errors. For example, deleting a parent polygon caused an error.
BUT AND FOR THE PROBLEM of this thread, the ordering of polygons was added at a later stage and no "handling of the holes" was carried out. The reason is that it is extremely dificult to handle that. A solution was indeed to modify the internal structure of polygon data but that would mean to rewrite most of the code related to polygons.
I am sorry for this problem,
Regards, Luis
Holes were added to SBuilder when the internal data structure for polys was already defined. If you create simple polygons with and without holes and export them as a SBX file, you can understand how child polygons (holes) were implemented.
During the testing of the programme there were many more errors. For example, deleting a parent polygon caused an error.
BUT AND FOR THE PROBLEM of this thread, the ordering of polygons was added at a later stage and no "handling of the holes" was carried out. The reason is that it is extremely dificult to handle that. A solution was indeed to modify the internal structure of polygon data but that would mean to rewrite most of the code related to polygons.
I am sorry for this problem,
Regards, Luis
Luis, all the data needed to manage this problem is available. The polys records the indices of the holes, and the holes record the index of the poly. It should be a fairly simple algorithm to maintain these relationships.
But, if you can't, I suggest you at least provide a warning when holes are present that the relationship may(will) be corrupted and must be repaired using the .sbx.
Don
But, if you can't, I suggest you at least provide a warning when holes are present that the relationship may(will) be corrupted and must be repaired using the .sbx.
Don