Subject:
|
Re: Change to existing policy on embedding POV-Ray code in Official Files
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 1 Jul 2007 22:43:18 GMT
|
Viewed:
|
10928 times
|
| |
|
|
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
|
|
Message has 1 Reply:
Message is in Reply To:
27 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
