Closed mzwaal closed 10 months ago
can you provide a sample ldraw scene for this problem? some level of winding changes are expected to be handled by the renderer / outside the library to allow instancing of the data.
https://github.com/pixeljetstream/ldrawloader_viewer I made this debugging tool public now and it does handle some winding changes through openGL at rendertime / testing matrix determinant.
Thanks, I will test the issues first with this viewer and let you know how it goes.
There were some other official parts that rendered in a sub optimal way and some that triggered the asserts. It might be useful to have a test application that tries to load each part of a given official library and logs the exceptions to see which parts fail.
I also had build such a loader btw, but yours has some nice surface optimizations so I decided to switch
I have checked my implementation and managed to fix it. Thanks!
I originally had implemented it like yours, but I thought it was wrong because of another issue and started to modify the ldrawloader which solved my issue for most cases but was kind of a hack.
In other words, my issue is solved and your reference implementation helped me and will help others in the future.
In the official ldraw library, people mirror parts that they have already written via a matrix transformation. In those cases the winding is not flipped by ldrawloader.
Parts can refer to other parts a few levels deep, so this probably need to be fixed recursively.
A good example would be minifig arms
Great library by the way!