LDraw.org Discussion Forums
Decreasing poly count on models - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: Rendering Techniques (https://forums.ldraw.org/forum-20.html)
+--- Thread: Decreasing poly count on models (/thread-8263.html)

Pages: 1 2 3


Re: Decreasing poly count on models - Nicola - 2013-04-11

Tim Gould Wrote:I'd like, one day, to make a program that can "auto BFC" a part by this method by tracing a ray and flipping surfaces as needed. But it's slow and thus not a routine you'd like to do every load. Do it once and prepackage a BFCd library.

Tim

I think it would be much better to have normals included directly in the quad/tri data, precalculated by the part author, just like any 3d format. All that stuff about BFC, invertnetx, matrix flipping etc is insane, i've never seen in any 3d framework, and i've seen some Smile


Re: Decreasing poly count on models - Tim Gould - 2013-04-11

With ldraw 'better' depends a lot on perspective. The file format and large parts library maintains backwards compatibility to the 90s. It's also hand editable. It's also highly portable.

Where it does fall over in matching with modern 3D standards. But to change that in the way you'd like we'd need to alter the entire parts library, all the techniques and technology written for part design, and entirely break backwards compatibility.

Or to put it another way, what is good for a renderer is not necessarily good for any of the other tasks of the file format.

Tim


Re: Decreasing poly count on models - Nicola - 2013-04-12

Tim Gould Wrote:With ldraw 'better' depends a lot on perspective. The file format and large parts library maintains backwards compatibility to the 90s. It's also hand editable. It's also highly portable.

Where it does fall over in matching with modern 3D standards. But to change that in the way you'd like we'd need to alter the entire parts library, all the techniques and technology written for part design, and entirely break backwards compatibility.

Or to put it another way, what is good for a renderer is not necessarily good for any of the other tasks of the file format.

Tim

Yes i understand the motivations. Still i think something should be made in that direction. It doesn't have to break compatibility, just like BFC extension didn't. A good normal support extension would make many ldraw quirks obsolete and solve many current "bugs" such as mismatching half curves, weird minifig heads and such.

Btw, while backward compatibility is important, there is a moment when you have to draw a line and drop all 20 years old legacy that holds back, all softwares do that. I'm not suggesting to do that now, after all i'm just the last arrived here, i don't want to look arrogant Smile

Also we are going off topic, eventually we can discuss this on another thread Smile


Re: Decreasing poly count on models - Ben Supnik - 2013-04-12

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.

Cheers
Ben

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).


Re: Decreasing poly count on models - Paul Griffin - 2013-04-13

BFC is easy...well, compared to bowtied quads. I could not believe how many ways you could bowtie a quad.

Now if only there was a simple algo for conditional lines...


Re: Decreasing poly count on models - Nicola - 2013-04-24

i finally got around and tested this thing, with a slightly different algorithm.
I tested it on one of my models (this one) and the results are that i was able to go from 71k triangles to 32k. While this is substantial (more than 50% off), i was expecting something better. Stacking parts should hide both top studs and bottom "female studs" cylinders and internal boxes, greatly reducing face count. But probably rounded parts and wheels (that have a lot of insets) still make a huge face count.
Performances were quite slow, requiring tens of minutes to get around a model (of course it was a completely un-optimized test).


Re: Decreasing poly count on models - Ben Supnik - 2013-04-25

Hrm - are you saying that your model was slope in the rendering engine with 32k triangles? If so, can the engine be made faster? Pretty much any desktop hardware you run on should be able to plow through that sized mesh.

(It might be easier to make the rendering faster than to further remove detail...)

cheres
Ben


Re: Decreasing poly count on models - Nicola - 2013-04-25

no no the rendering was fast, it was the preprocessing that took ages


Re: Decreasing poly count on models - Michael Horvath - 2013-10-22

Any progress? I am very interested in this as well.


Re: Decreasing poly count on models - Antonio Cort├ęs Carrillo - 2013-11-23

A very very long time ago (2004), i implemented a similiar algorithm that detects and removes the inner parts of the model.

If you are interesting, can find it here:

http://buf3d.cimplus.es/download/pfedit2.zip

Is not the buf3d, is much older and for that reason:
* Does not properly read all 3D Ldraw models.
* Do not use GPU (but works very fast ... )
* Well .... sure there are many bugs that buf3d already solved Smile

For use, these are the steps to follow:
- Import->Ldraw Model (I will ask the library directory)
- Optimize-> Select Objects Ocludded
- They will leave many options without touching it will be fine (9/16 iterations)
- After the process, the internals parts appear selected
- Selected-> Show Selection Only (Optional)
- Selected-> Remove Selected

Removes over 50% triangles, easily Smile