Adding normals to the library


Re: Adding normals to the library
#11
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.
Reply
« Next Oldest | Next Newest »



Messages In This Thread
Adding normals to the library - by Nicola - 2014-11-04, 13:31
Re: Adding normals to the library - by Nicola - 2014-11-04, 14:17
Re: Adding normals to the library - by Nicola - 2014-11-04, 16:12
Re: Adding normals to the library - by Nicola - 2014-11-04, 22:07
Re: Adding normals to the library - by Nicola - 2015-01-16, 16:07
Re: Adding normals to the library - by Nicola - 2014-11-04, 22:54

Forum Jump:


Users browsing this thread: 1 Guest(s)