Need for BFC INVERTNEXT / primitives?

[Philippe Hurbain]

About CCW/CW/Invertnext/double sided poly: for all i can see, this is completely superfluous. No other file format i know (and i know some), has things like this. This is not a big issue, but again is an arbitrary and useless thing we have on top, it's a mix of legacy and solutions from a time where saving a single triangle was a big gain. Now video card can pump out gazillion triangles with ease. Just stick with a direction, and convert the library.

What do you propose for BFC? It wouldn't be a big deal to convert all library to one or the other orientation, but what about 3D primitives turned inside out? Remove completely the notion of primitive (why not...)? Provide two sets of primitives, one seen from inside, the other from outside?

[Orion Pobursky]

I see his point on CW vs. CCW for non-primitive parts. Pick one for the library (CCW is the de-facto standard I think). I still think INVERTNEXT is needed for legacy purposes but modern programs can simply do primitive substitution.

[Nicola]

What do you propose for BFC? It wouldn't be a big deal to convert all library to one or the other orientation, but what about 3D primitives turned inside out? Remove completely the notion of primitive (why not...)? Provide two sets of primitives, one seen from inside, the other from outside?

Well, i'm not a big fan of primitives (or even the hierarchical structure of subparts for that matter), but i think we can make some improvements even with them.
Having two separated standard for CCW and CW is useless. It still needs the code to check which is the current one to consider and to flip. Ideally, only one of the two should be there so you can blindly go in one direction and be sure it's ok. Now i don't remember but i think there's a per-file directive, and a per-part/face directive, or am i wrong? All of this could be removed and made implicit with some automatic sanitization.

About invertnext, it must be kept if we want to also keep inside out primitives. Or as you said, duplicate the primitive keeping one inside and one outside, which would be even better in my opinion. Why do we need to keep all the invertnext mechanism up, only to define an inside out box, that can be defined simply with (up to) 6 faces? Sure with curves ist's a little worst but still..

But just removing the CCW/CW will remove one layer of useless dust from the format and relative softwares, and it comes quite cheap. If we tackle the cheap issues we'll end with a cleaner library that will make a better starting point for anything else.

[Philippe Hurbain]

Totally agree that the library should have been completely converted to CCW from the beginning... All primitives were already converted this way some time ago. And indeed, boxes are of very limited benefit except to keep file size down (itself of limited benefit...)!

[Santeri Piippo]

I vouch 100% for unifying winding in the library. It's being very VERY frustrating to deal with when coding BFC stuff (which is pretty much why ldforge still doesn't have properly working BFC support). Having a mere toggle for knowing what is BFC-compliant or not would be so much easier to deal with than trying various gross hacks to try keep track of CW/CCW winding... give me the go and I'll convert everything by hand if need be.

[Travis Cobbs]

I agree that having everything be CCW makes sense, but I don't agree that this makes things much easier for coding a renderer. Supporting INVERTNEXT requires supporting switching the order of points. Given that constraint, it's pretty trivial to also support CW/CCW.

[Roland Melkert]

I also agree with making everything CCW header wise, but unless we are willing to break backwards compatibly we can't just drop everything but invertnext from the BFC extension definitions.

We could however minimize it in that way for use in official parts, so newly build parses just looking to read official files will have less problems getting started.

[Roland Melkert]

YFI

I don't understand what things are you keeping track of? You only need to track the header status recursively.

In LDCad I force everything to CCW on the part top level, so the recursive function only keeps track of the needed mutation on the current file to get it to CCW at toplevel. This is done in a single line:

Code:

const TLDWindingMutation wo=mainRenderData->getUseBFC() ? (doInverse xor (curMatrix.determinant()<0) ? LDWM_Inverse : LDWM_Normal) : LDWM_DontCare;

Where doInverse and curMatrix are the recursive function parameters. And for any type 1 line you pass (doInverse xor "invertnext meta present") and the new matrix to the next recursion level.

Maybe this helps you