Subject:
|
Re: Inline POV code in official parts?
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 2 May 2007 00:46:09 GMT
|
Viewed:
|
4213 times
|
| |
| |
> In lugnet.cad.dev, James Reynolds wrote:
> > Why not make official POV-Ray Lego bricks and skip the whole LDraw to
> > POV-Ray conversion? Use the same names, scale, and coordinates and
> > all you need is a small script to convert the LDraw lines into POV-
> > Ray lines using the same translations. Or you could use a converter
> > and use an existing POV-Ray library of bricks that converts the LDraw
> > names, coordinates, and scales into POV-Ray, like Anton Raves'.
>
> It doesn't really gain you much if you are just converting the
> LDraw parts
> directly - l3p does that just fine, and fairly fast. The only
> advantage of a
> POV-ray library is when you start adding POV-ray specific stuff,
> eg: replace the
> curve approximations with smooth surfaces.
Well, maybe others don't care about visible polys when it should be
smooth, but it makes all the difference in the world to me.
> And once you start doing that, you need someone to maintain the POV-
> ray library
> - when an LDraw part changes, the corresponding POV-ray part needs
> to be checked
> to make sure it still corresponds.
>
> I think it's something that's worth investigating, but you need
> someone like
> Anton (or a team) prepared to keep it up to date, or it will just
> end up like
> the LGEO library.
Well, yeah. But that is better than everyone inventing their own POV-
Ray code to make their own parts. How many head or hair parts should
each of us make before it is finally integrated with the core library?
As far as Tore's request, I would really like to be using Maya or
Blender. Why can't I embed MEL or Python in the LDraw files? This
is my point. LDraw is LDraw. POV-Ray is POV-Ray. Converters should
do the work of moving from one format to another and it would be
great if the converters understood what part is what and added extra
code for that part. I think rather than extending the LDraw format,
Tore should look into modifying the output of L3P or submit for L3P
feature requests to support what he is trying to do.
If anything is going to be added to LDraw files it should be generic
for all formats, not specific to POV-Ray. For example, in addition
to having a polygon mesh for LDraw, it could have NURB or Subdivision
points to indicate what it should look like in some other format. I
would SOOOOO be using Maya or Lightwave if it were possible to get
smooth parts from LDraw. I choose to use POV-Ray and not Maya or
Lightwave because, as I indicated above, smooth is more important to
me than having easy to use tools (compared to scripting everything
with POV-Ray, Maya IS way easier...). I've even put in some work to
making my own Maya library but it was so much work I had to give up
and decided to tackle it in a few years or so when I am a better
modeler and not so burned out on it...
Now that I say all this, the reason I'm so against adding to the
LDraw spec for animation is because I'm thinking Tore is eventually
going to want logic added to the LDraw format to handle the logic
required for animation, and that just seems so wrong to me. Why
invent Yet Another scripting language? And built around the LDraw
language? Can you imagine every script line having to start with "0
SCRIPT"? What a nightmare.
I offer my apologies to you Tore if this isn't what you is thinking
at all. I'm just trying to think what it means. And I'm trying to
steer you AWAY from adding any POV-Ray code to LDraw when it should
be in a POV-Ray library that is sharable just like Anton's library.
For that matter, I have my own library files I'm sharing to do things
like create and animate minifigs, and several utilities making it
easier to work in POV-Ray with Legos, and I'm going to add more for
creating scenes, using keyframes, and using inverse kinetics once I
finish my current project. Many other POV-Ray users share libraries
too and I've used many of them to add things like planets, stars,
lens flare, splines, functions making the clock easier to use, etc.,.
James
|
|
Message is in Reply To:
| | Re: Inline POV code in official parts?
|
| (...) It doesn't really gain you much if you are just converting the LDraw parts directly - l3p does that just fine, and fairly fast. The only advantage of a POV-ray library is when you start adding POV-ray specific stuff, eg: replace the curve (...) (18 years ago, 1-May-07, to lugnet.cad.dev)
|
18 Messages in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|