Subject:
|
Re: Inline POV code in official parts?
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 29 Jul 2003 20:54:13 GMT
|
Viewed:
|
1375 times
|
| |
|
|
In lugnet.cad.dev, Tony Hafner wrote:
> What's the current plan for POV-Ray code in official parts? I have been out of
> the loop for a while, but my last understanding was that parts with inline
> POV-Ray code don't have any chance of getting certified on the parts tracker.
> Is this still the case?
>
> I am specifically referring to cases where primitive substitution causes gaps
> around curved surfaces. The ldraw code looks fine in the usual tools (ldraw,
> MLCAD, L3Lab), and the extra code makes the parts render without gaps in
> POV-Ray.
>
> --
> Tony Hafner
> www.hafhead.com
I agree with Steve on this issue: no POV code in offical parts with the possible
exception of primitves. I feel this way for a few reasons:
- It could be construed the POV is the Official rendering program of the
LDraw.org library. This can not and will not be the case. While POV might be
the most widely used, it is not the only high quality rendering program in use
(Bryce, Rhino/Flamingo, 3D Studio Max, Blender to name a few) .
- It locks the offical library into a standard beyond the control of LDraw.org
and the LSC. What happens if the POV team depreciates a command used in the
parts files? This could potentially affect hundrends of parts in the library.
- What version of the POV standard would we use? We have enough issues with
backward compatibility in the Official library right now, adding POV code would
only complicated the matter further.
- How would we review such code? It's is much harder to rotate and scale POV
code to an arbitrary position than it is DAT code.
- Why not just ditch the DAT code and have the the library be POV only? The
great thing about DAT code is it text based and easily visualizable. Some POV
code isn't as intuitive.
- What if another program that's bigger and better than POV come into wide use?
Would we add the code for that program into the library? Would we remove the
POV code?
Adding POV code sounds like a quick fix to problems such as primitive
substitution gaps but as I think about more I can see the list growing quite
large. Since we don't even have an Official standard for DAT code, I don't
think adding another standard would be beneficial.
-Orion
|
|
Message has 2 Replies:
 | | Re: Inline POV code in official parts?
|
| This is just my opinion since I started all this by suggesting to Lars to add POV support into L3P in the first place. By adding a few .dat primitives (not POV primitives) to the .dat definition, then you don't have to tie yourself to any renderer. (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
| | | Re: Inline POV code in official parts?
|
| (...) That's a very heavy argument against EmbPOV. It would be a great thing if we could just have a very few basic features, say clipped by, pattern wrap and maybe one or two other and make it a generic syntax for alternative code. (...) Despite (...) (20 years ago, 13-Jan-04, to lugnet.cad.dev)
|
Message is in Reply To:
| | Inline POV code in official parts?
|
| What's the current plan for POV-Ray code in official parts? I have been out of the loop for a while, but my last understanding was that parts with inline POV-Ray code don't have any chance of getting certified on the parts tracker. Is this still the (...) (21 years ago, 28-Jul-03, to lugnet.cad.dev)
|
18 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
|
|
|
|
