Orphaned Polys

#1 This error is a bit of a misnomer. Just ignore it and carry on, I'm not sure whether map2dif just removes the polys but it doesn't seem to affect the model in game. The number randomly seems to jump about as well.

#2 Orphaned polys as it was explained to me are faces on brushes that will be sent to the video card, but will never be seen on screen because they are completely occludded by an adjacent brush surface. As long as you're not getting thousands of these you should be ok.

I'm also starting to believe that some of them are due to vars in map2dif that are not initialized properly. I'll investigate it more next week.

#3 Thanks for the responses, I won't worry too much about it now :)

#4 @ Tom

Out of interest, what is meant by an ambiguous brush?

I have noticed that the Orphaned Poly count varies quite a bit between exports but the ambiguous brush count is fairly reliable (not that I have seen problems in a dif that has either or both).

#5 I have been having major problems with orphans. It seem like there are just as many orphans as there're surfaces. For example, below I render a hollowed out box and the surfaces equaled the orphans. Will this be a problem, because I finished a structure will over a 1000 surfaces and the orphans were around 900, there wasn't a problem rendering in Torque, I'm just concerned if I should continue using this product if there will be problem as the structures count increases.

//Example "Hollow Box //

Temporary crash file: 'test_crashed.csm'
Reading CSM v5.
Performing fixups on CSM geometry.
Converting CSM to MAP.
Texture smartcopy.
256-256
Parsing map.
Creating BSP.
Marking active zones.
Creating surfaces.
Processing lightmaps.
Grabbing surfaces.
Processing surfaces.
Creating shadow volumes.
Processing emitter BSPs.
Lighting 18 surfaces...
5.56%
11.11%
16.67%
22.22%
27.78%
33.33%
38.89%
44.44%
50.00%
55.56%
61.11%
66.67%
72.22%
77.78%
83.33%
88.89%
94.44%
Processing alarm lighting.
Sorting and packing lightmaps.

Statistics:
- Brushes
+ total: 6
+ structural: 6
+ detail: 0
+ portal: 0
- Number of zones: 2
- Number of surfaces: 18
- Ambiguous brushes: 0
- Orphaned polygons: 18

Exporting to runtime.
Writing 'D:\test\test.dif'.
Done!

#6 @David - Sorry i hadn't responded earlier... i lost track of this thread. So far i can't find anyone that knows exactly what those are and if they are really safe.... but people do say they can be ignored. I will go thru the code and find out once and for all.

@Brian - I'm not at my machine today, so bear with me. You have 36 total surfaces (6 brushes * 6 faces). Only 18 are lit because only 18 are visible... the other 18 are not. In theory they should not be a problem, but i don't think it would normally report these 18 as orphaned. I'll check this out tomorrow when i'm back at my desk.

#7 Where the faces touch each other and are not visible. then these would be orphaned polygons..

the exporter culls these out as they are never seen anyways.. so I would not be concerned at all..
just roll with it.. :)

#8 @Tom - Yea that's basically it, but i didn't think that those were reported as "orphaned"... so that conserns me. I need to revisit the issue and write the definative information into the Pipeline docs.

#9 The surfaces at the point of intersection could be interpreted as orphans, which make sense.

Thanks,

Brian

P.S. Great tool, beats the h*ll out QUARK

#10 @Brian - Maybe... i'll let you know for sure tomorrow.

Quote:P.S. Great tool, beats the h*ll out QUARK

Thanks. Visit our dev screenshot and testify... we're trying to win over some converts! =)

#11 @Tom - I had forgotten I had asked that!

I read (somewhere) that an ambiguous brush is a brush face where there are 2 different textures (such as where two differently textured brushes are in contact and the contact faces are the same size). Having religiously applied the null texture to all shared faces my ambiguous brush count is now zero so it would appear that the definition is correct. The null texturing seems to do nothing for the orphaned count though.

#12 Posting my research into the code that i've now added into the Torque Pipeline FAQ for the next minor version release. First ambiguous brushes:

Quote:Q: What are ambiguous brushes?

A: Ambiguous brushes (do not confuse this message with "ambiguous planes" explained below) are brushes which have one or more surface planes which are the same, but the texturing parameters differ. Think of a cylinder where one side is vertex manipulated to be flat and you change the textures on one or more of the faces on the flat side. Only the first surface plane is kept and the rest are thrown out. It does not effect performance in any way, but your texturing on that brush will not reflect what you see in Cartshop. To fix this identify the brush and split it into two separate brushes.

Please post if you think any of this information is wrong or could be explained better.

#13 Ok... next... ambiguous planes:

Quote:Q: I get a warning that says "Dropped N ambiguous plane(s)". What does this mean?

A: The ambiguous plane warning (do not confuse this message with "ambiguous brushes" explained above) is generated during creation of the shadow volumes when lighting the interior. When the shadow volume is generated an odd sliver of a polygon can be created which cannot be classified as fully inside, outside, or split by the volume. These are just tossed out and can be safely ignored.

#14 FYI. Using the setInteriorRenderMode(3); command in the Torque console will highlight ambiguous brushes in your interiors. setInteriorRenderMode(4); will highlight orphaned polys. setInteriorRenderMode(0); restores the rendering mode to normal. These commands only work on a debug or internal release build of Torque.

#15 Ok... i think that most of the orphaned polygon warnings are bogus. See my bug report. I'll wait to get verification of this before i decide what the orphaned polygons warning really means.