Decreasing poly count on models

Re: Decreasing poly count on models
Hi Nicola,

I had a very similar reaction when I first looked at the LDraw file format - coming from a 3-d rendering background, my immediate reaction was "why isn't texturing UV-mapped? Why aren't normals per vertex?" Allen gave me some background into the LDraw format, process, etc. that was helpful.

I think you have to view LDraw as a _source_ format, not a _rendering_ format. X-Plane's objects have per vertex normals and UV-mapped textures, but our artists don't use that format to create things. They use a 3-d program with all sorts of complex, tweaky stuff - automatic subdivision, NURBs, deformers, etc. The 3-d program and an export script then 'bake' the work down into the simple, boring, basically fully-precomputed format the renderer wants.

You could totally define an "LDraw processed" part format that was designed for ease-of-render, and not at all meant for editing. You could have UV maps (instead of projections from the tex spec) and per vertex normals (instead of crazy algorithms to 'guess' normals), you could subdivide all quads into tris, you could pre-compute vertex sharing, you could even pre-compute LOD info.

The advantage of such a format would be that usage of it would be trivial for rendering programs - a lot of the hard work of drawing LDraw is in getting from raw LDraw to that "pile of triangles" state the hardware wants. With a pre-baked format, the analysis code could be written once and saved to disk to be used by everyone.

But that doesn't imply that the needs of a 'baked' format necessarily apply to the source format. I would even say that one of the nice things about pre-processing is that you can afford to do algorithmic transformations that would be too expensive/complicated to put in the renderer itself.

I think it would still be useful to have some idea of a long term road map for .ldr files -- as a source format. This is one reason why I've been skeptical of proposed normals to fix normal smoothing issues: I think we should have an idea of what a comprehensive solution looks like before we accept parts of the solution into the library.


PS, I agree that BFC is really quite complicated. :-) But I think the -derived- results of a 'baked' part with BFC are pretty tame - a pile of CCW quads with some marked as two-sided (or doubled to form the back faces).
« Next Oldest | Next Newest »

Messages In This Thread
Decreasing poly count on models - by Nicola - 2013-02-14, 16:17
Re: Decreasing poly count on models - by Ben Supnik - 2013-04-12, 17:38

Forum Jump:

Users browsing this thread: 1 Guest(s)