Subject:
|
Re: Change to existing policy on embedding POV-Ray code in Official Files
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 2 Jul 2007 04:27:05 GMT
|
Viewed:
|
5000 times
|
| |
|
|
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.
>
> Our main reasoning behind this conclusion is outlined below is that the
> inclusion of POV-Ray code locks the Official Library into a standard beyond the
> control of the LSC. The intermixing of language formats creates backwards
> compatiblity issues that are too large to ignore.
>
> Note that this restriction would only apply to Official Parts Library Files and
> not to the LDraw File Format as a whole. We are discussing the official
> recognition of seperate libraries that define LDraw parts in various 3D formats.
> These libraries would not be distributed with the LDraw base package but would
> be offered as a downloadable add-on.
>
> 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.
Since I've contributed exactly two official parts to the LDraw library (neither
of them with inlined POV-Ray code), I'm sure that my opinion carries more weight
than anyone's on the subject... :)
For some time it has been argued that the use of inlined POV-Ray code would
expose the relevant part to possible obsolescence in the wake of future
revisions to POV-Ray itself, but honestly I find this argument unconvincing, at
least as it applies to the parts themselves. Inlined POV-Ray code serves to
improve complex curved surfaces, whereas almost all revisions to the ray-tracer
involve the particulars of lighting and radiosity, rather than the structure of
basic objects. AFAIK The code for a torus in POV-Ray 1.0 is the same as in 3.5,
for example. Thus the threat of non-backwards-compatibility seems small. And
certain curved surfaces simply turn out much better using POV-Ray code.
Nevertheless, the "not under LSC control" argument is IMO sufficient to end the
discussion all by itself. Any other issues aside, this is the one point on
which there really can't be any debate, and it's a basically insurmountable
obstacle. It's as unfortunate as it is unavoidable.
My vote, as an interested bystander, is to bar inlined POV-Ray code from the
official LDraw library. But I think the idea of officially recognizing other
parts formats is a great idea.
Dave!
|
|
Message is in Reply To:
27 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
