LDraw.org Discussion Forums

Full Version: Adding normals to the library
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Roland Melkert Wrote:The things I like about the LDraw format: it's very clean (in it's initial state) and the recursive nature of it makes it very efficient.

So I can't help having mixed feelings adding normals to the library files for a couple of reasons:

  1. Not all end user software needs it (e.g. POVRay)
  2. Normals are trivial to calculate when doing flat shading, so adding one normal per triangle/quad is very wasteful.
  3. Adding normals for smooth meshes will break the recursive / reusable nature of LDraw like you noted yourself.
  4. Smoothing isn't that hard when using modern bfc-ed parts (I agree with your notes on fixing the library itself). And if slow or something software is free to pre calculate/cache them.

Given the above I feel it's unfair to burden the part authors (often working with little more then notepad etc) with the normal issue, while it's only a couple of days work to implement a decent smoothing algorithm in software (done once).

Maybe we could improve things for the view/edit software programmers by adding a reference smoothing algorithm to the LDraw documentation in pseudo code.

Thanks for your answer, here's my considerations:

  1. Povray is a special type of renderer, it uses raytracing, which is a different way to render things than the usual (that's why it takes 10 hours to build a frame). The standard rendering tecnique in the 3d world is using normals.
  2. Of course the flat surfaces are easy Smile the problem are the curved ones. As i said, optimizations can be made for flat surfaces to make the thing less verbose, and we can discuss on how wasteful it is to fill a couple more MB today.
  3. You are right, but this is not an universal rule, it's only becouse of how we decided to subdivide things into subparts/primitives.
  4. First off, it may be impossible to cache them, if the software doesn't know in advance what he has to render. And yes, they're expensive to calculate for a big model. Given that MLCad, LDView etc still have bugs on their renderer, i guess it's not that easy to implement either.


Have you ever stopped for a minute to consider WHY our part authors are working with notepad? Do you think there is another branch in the whole 3d world, say videogames, industrial design, movie effect, 3d printing, ANY field where authors are using notepad to design? No, there is not.
Why can't our part authors just fire up Blender, Maya or whatever, design the part with modern tools, autocalculate most of it and export it in a minute? Just like the rest of the world does? Becouse they're stuck with invertnexts, condlines, and a bunch of other "technology" that are unheard of in the rest of the world. And they're unheard becouse they're not necessary.

I don't want to be rude, but they looks like medioeval meticulous miniaturist in a world where everybody else uses electronic printers. And then you guys complain that there are less and less active part authors? Of course there are. But ask yourselves what you are requiring them to do. Time is a precious resource for everybody.

Sorry for the polemic tone, but reading about authors using notepad really made it evident to me how dramatically off the road we are. As i said elsewhere, alternatives exists and are coming out. LDraw already lost a lot of users to LDD. It's easy to imagine how things will go when a serious alternative will be available.
Quote:it may be impossible to cache them
You could cache them per part it's no different from when the source files where per part meshes.

Quote:Have you ever stopped for a minute to consider WHY our part authors are working with notepad?
I know full well how different things are with LDraw compared to the rest of the 3D world, but have you considered some people actually prefer working with the text based format.

If the majority of the currently active part authors want normals, and less recursion I'm all for it but I'm not willing to change the format if they don't want/need it.

So in the end, imho, it's up to the part authors to choose (maybe a poll?) and not the software engineers.
To the best of my knowledge, the people who have implemented smooth shading recently have done so using color 24 type 2 lines ("edge lines") to indicate creases, and have smoothed geometry that wasn't separated by edge lines. LDView's standard view does something different, which is to use the presense of color 24 type 5 lines ("conditional line") to indicate non-creases.

I came to the conclusion that LDView's way of doing things was the wrong way to go, and when I implemented my POV exporter, I went with the "new" way, and that's what I have advised others to do. I've never gotten around to implementing the other algorithm for LDView's 3D view, and since it is in fact useful for detecting missing conditional lines, I would never get rid of it entirely, simply make it the non-default smoothing option.

The "Smooth Shading and Edge Split" algorithm from Nicola's post is relatively straightforward. The problem is that it works rather poorly with some LDraw geometry. It relies on a threshold angle to decide if things should be smooth shaded or not, and LDraw files have situations where a relatively sharp angle is supposed to be smooth along with other situations where a relatively shallow angle is supposed to have a crease. The edge line-aware algorithm I mentioned above will probably also include a threshold angle, but the threshold will be set to a fairly sharp angle (far sharper than such algorithms normally use) to accomodate LDraw.

Unfortunately, it's not easy to figure out if the place where two arbitrary polygons join has a co-linear edge line. So the edge line-based algorithm is relatively complicated, and also relatively slow.
So Ive been seriously wondering if we're all clinging to a sinking ship out of nostalgia and maybe we should convert the library and move on...
Quote:I know full well how different things are with LDraw compared to the rest of the 3D world, but have you considered some people actually prefer working with the text based format.
Maybe it's the other way round... I weakly tried working with Blender but gave up in front of the relatively steep learning curve, since the result didn't fit well the (efficient but complex) structure of LDraw files. Making the square Blender peg fit round (primitive Wink ) LDraw hole seemed more work than going on with MLCad/text/special tools.

And we might possibly loose some seasoned LDraw parts authors but attract young SPAM CONTENT accustomed to modern modeling tools...
Travis Cobbs Wrote:The "Smooth Shading and Edge Split" algorithm from Nicola's post is relatively straightforward. The problem is that it works rather poorly with some LDraw geometry.

You're right, but i was just talking about normals in general, i was not not suggesting to use this tecnique to mass-add normals to the ldraw library. To do that i think one of the two methods you mentioned are the way to go.
For what little it worth, I completely agree with this! I think this is a necessary step to advance LDraw into more realistic graphics (and help slow all of the other programs / libraries from passing us by).
Pages: 1 2