New feature request: Add "primitive substitution" feature about ldr-importer HOT 19 OPEN

Here are screenshots of the tool LDView with the primitives replacement enabled and disabled.
You can see that one picture shows a plain, boring polygon mesh,
and the second picture shows a native OpenGL 3D object, which is much more detailed.

from ldr-importer.

Assigned to later date milestone, as this would only happen after the rewrite (v1.2).

from ldr-importer.

is fine for me.
adding this feature will make the LDR Importer a heartbreaker.
This substitution is a killer feature.
Without it, you have to stick with boring polygon meshes forever.
With it, your 3D scenes can be rendered smoothly.

from ldr-importer.

Again, /cc @rioforce

from ldr-importer.

FYI, here is a list of all LDRAW primitives. You can see the systematics in there
to see how to substitute the primitives:
http://ldraw.org/library/primref/

You could also contact Travis Cobbs, the author of LDView.
That tool already contains a primitives substitution list.
Maybe you can re-use his list instead of re-inventing it:
http://ldview.sourceforge.net/

from ldr-importer.

You have quite a few good ideas, almost too many to keep up with.

;)

from ldr-importer.

Whiled this idea may be good for LDView, it's not right for the LDraw importer. Reconstructing certain primitives would be pointless, because this is an LDraw importer, not something that imports coordinates and reconstructs bricks. If we were going to reconstruct certain bricks, we could just reconstruct all the bricks and then wouldn't have to worry about using the LDraw parts! But that's not logical, because this is an LDraw importer, not a brick constructor. LDraw has different qualities of bricks for a reason, and with a simple function, we could toggle between hi-res, lo-res, and normal-res bricks. :)

from ldr-importer.

you misunderstood me.
i was not talking of "reconstruction" of bricks. i think you think of something like LGEO or something,
where whole brick geometry is replaced.

this request only talked about primitives.
that's a small handful of ldraw files, like cylinders, discs, tori.

i was talking about how they are imported.
currently, they get imported as a mesh.
but they could also be imported as a native 3D object (cylinder, disc, torus etc).

this is not at all about "guessing" geometry, or "reconstructing" it from the mesh.
would I have suggested that, then I would have objected the same way you did.
the importer is no math algebra suite which can reconstruct cylinders etc from given meshes.

the task I talk about here is much, much more trivial:
when an ldraw file says "please put a half cylinder of radius 20 here",
the importer currently simply puts the cylinder mesh from ldraw file p/2-4cyli there.
it would be easy, if not trivial, to put a real 3D cyli there.

from ldr-importer.

Ah, I understand what you mean now. I think that it's harder than it sounds though. Not sure how that would work with our parser...

from ldr-importer.

still very simple. you just need a small table which tells you:
"ah, you want a 2-4cyli scaled by factors x/y/z at location p? fine. i'll put a primitive for you there."

this is not an issue about the file parser.
parsing the file already works well.
this issue is about what to do with the information from the file.
currently always the mesh is used.
the request is, if the option for that is enabled, to replace SOME (just few!) specific meshes
(ie., the primitives) by native 3d objects.
it's something that comes after parsing.

from ldr-importer.

parsing the file already works well.

Um, nope. Take a look at the code and see what I mean. :P

from ldr-importer.

what I wanted to say is that you need to separate parsing a file from working with the parsed data.

to mix these 2 steps usually leads immediately to spaghetti code.
the usual implementation in compiler construction is

1. parse the input
2. operate on the parsed stuff
   If you start modifying things already during the load, things quickly get messy.
   http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811

from ldr-importer.

Yes, we are aware of the "spaghetti code". David Pluntze wrote it that way, and fixing it is one of the (if not the) main goal of the rewrite. 😉 Thanks for the resource, though too bad I most likely will not get the chance to read it.

from ldr-importer.

if you're studying computer science, you will :)

from ldr-importer.

One Question: Does LDraw already have the primitive models as DAT files in the LDraw directory, or is this an optional thing? If re-building them is just to increase quality, subsurf (or a similar method) would help from within Blender.

from ldr-importer.

Your question makes no sense. You are asking if LDRAW contains DAT files for those primitives.
Yes, it does.
But this issue is about REPLACING them by native 3D objects of the renderer,
i.e., using a PERFECT 3D cone instead of the polygonized one from the DAT.

from ldr-importer.

We added the high and low-quality primitives from LDraw for this reason. Instead of reconstructing meshes, why not just use the new LDraw primitives? This importer is supposed to import LDraw bricks as they are, with maybe some minor cleanup. I don't see a reason to re-construct the bricks when LDraw already has 3 qualities of primitives built in.

If you can show us some code, we may consider it. But until then, I don't think this will get into the script.

from ldr-importer.

You again misunderstood me.
DAT files ONLY can contain meshes. NO native cones etc.

This request asks for SUBSTITUTING the mesh DATs with native 3D primitives.

So it makes no sense that you again point me back to DATs.

This request is something totally different.

The feature is available in LDView, and rendering quality dramatically increases
when using it.

I wanted to have the same feature in Blender.

from ldr-importer.

Depending on your pictures above, ( #44 (comment) ), it makes the mesh more high-poly. "Native cones" are meshes in Blender. So are LDraw models. They all turn into faces and vertices. I don't see the point of replacing them. I thought that's why we added the hi-res primitives, so people could have higher quality bricks. I understand what you want, but the feature just doesn't have a high demand. Maybe this could go into the script re-write.

from ldr-importer.