Subject:
|
Re: Change to existing policy on embedding POV-Ray code in Official Files
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 1 Jul 2007 22:54:53 GMT
|
Viewed:
|
5489 times
|
| |
|
|
In lugnet.cad.dev, Orion Pobursky wrote:
> In lugnet.cad.dev, Tore Eriksson wrote:
> > In lugnet.cad.dev, Orion Pobursky wrote:
> > > In lugnet.cad.dev, Tore Eriksson wrote:
> > > > In lugnet.cad.dev, Orion Pobursky wrote:
> > > > > The LDraw.org Standards Committee (LSC) has recently discussed the issue of
> > > > > embedded POV-Ray code in Official Parts Library files. After careful
> > > > > consideration and with inputs from leading non-LSC members, most notably Lars
> > > > > Hassing and Chris Dee, we have agreed that the inclusion of this code is
> > > > > undesirable.
> > > >
> > > >
> > > > > Before we make a final decision regarding this matter, we would like to open
> > > > > this discussion up to the LDraw community as a whole. Please be constructive
> > > > > with your comments.
> > > > >
> > > > > - The LSC
> > > >
> > > > Too sad. If I got that complicated language correcly, this means that the
> > > > problem presented at http://www.hassings.dk/l3/l3p.html#primsubst and was solved
> > > > by embedded POV-code has now regressed to be un-solved again.
> > > >
> > > > /Tore
> > >
> > > Actually, the only Official Library parts that have embedded P-R SDL are some of
> > > Paul Easter torus primitives. Since nothing was ever done in the first place,
> > > nothing is being undone now. If you're like me and frustrated that LGEO is
> > > incomplete and not actively being updated, please join onto the LDrawPOV
> > > project:
> > >
> > > http://sourceforge.net/projects/ldrawpov
> > >
> > > Lars is already implementing support for this project in L3P 1.4
> > >
> > > -Orion
> >
> > Lars has already been implementing that support since... what year? 2004?
> > Probably even longer.
> >
> > I may would have joined it, but it didn't work then and I still can't get it to
> > work now, 3½ years later. (tried testdoc.pov) And, like I said, inline POV works
> > instantly without the frustrating, endless search for up-to-date include files
> > and trying to find an approriate folder to place them in.
> >
> > /Tore
>
> At the risk of reigniting this argument, I still hold to the original reasons
> for disallowing EmPOV:
> - The POV-RAY SDL is not under the control of the LSC. This means that if the
> POV-Ray Team decides to depreciate a command (which they have done in the past)
> we're up a creek and would potentially have to update 1000s of parts
> - Why POV-Ray code? POV-Ray isn't the only renderer that ever was or will be.
> A better renderer will eventually come along that will supplant POV-Ray. What
> to we do then, continue to support dinosaur code in the library? Also, I could
> see someone in the future making a stink that their favorite renderer's code
> isn't supported
> - It would slow the part review process even further. Some are already
> complaining that the review process is too slow, adding EmPOV would only
> exacerbate the problem.
>
> I understand your desire for ease of use but I feel the above reasons outweigh
> the convenience of EmPOV. For what it's worth, I've tired of waiting for L3P
> 1.4 and have restarted development of my L3P post processor.
>
> -Orion
I'd _like_ to see a meta-language for basic shapes defined in their primitives
(the current naming system would be fine if it was consistent) as that could be
used in converter software of all hues.
I also realise this isn't likely to happen and will just continue to use
unofficial inline pov and making my own parts in POVray and hope that the LDraw
POVray repository in the wiki
(http://ldraw.org/wiki/index.php/POVray_Parts_Repository) is kept up to date
when other people do the same.
Tim
|
|
Message is in Reply To:
27 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
