Problem with normals when building my own LDraw interpreter.


RE: Problem with normals when building my own LDraw interpreter.
#6
(2019-03-12, 23:51)Travis Cobbs Wrote: I strongly suspect that this is the cause of his problems.

Having said that, BFC as a whole is fairly complex, and requires quite a bit of work to implement properly. You have to deal with the fact that every file specifies winding separately, the fact that BFC isn't in fact required, and can only be enabled if all the files above the current file in the hierarchy are also BFC certified (up to the part level), the fact that matrices with negative determinants flip the winding, the fact that the winding can be flipped in the parent part before referencing a child part (INVERTNEXT), the fact that NOCLIP can turn of BFC for arbitrary polygons in any file, and possibly other complications. (The INVERTNEXT and the negative matrix determinants also mean that a single file can have both windings.) And in addition to being difficult to make all that work, you still have to support non-BFC geometry (for transparent parts, for non-BFC certified parts, and for sections of BFC certified parts that are in a NOCLIP section.)

I believe that an alternative is to draw every face twice (with opposite windings). This would obviously be slower, but not by as much as you might think. Bear in mind that it is likely that things from the first winding will still be mostly already calculated by the graphics card when it does the second winding, and since only one of the windings will face the camera, only one will actually get drawn. Furthermore, generally speaking, the vertex data won't have to be duplicated, since faces are usually drawn with indexes. (However, the actual surface normals for each winding would be in opposite directions, so depending on how the vertices are specified, it might mean that they have to be fully specified twice.)

If things look good after doing that, then taking the time to properly and fully support BFC would probably be good, but I wouldn't bother to even try in the initial stages of a new project.

Yea you're right, BFC is very very complicated, I might be better off just drawing two faces like you said. Unity indeed uses indeces to store the actual triangles (also does not support quads to make things even more difficult) so besides the normals taking up some space it will be efficient enough for now, and I'll see if I can fix the integration later. Thanks for all the help.
Reply
« Next Oldest | Next Newest »



Messages In This Thread
RE: Problem with normals when building my own LDraw interpreter. - by Lasse Boijens - 2019-03-13, 6:28

Forum Jump:


Users browsing this thread: 1 Guest(s)