| |
Steve wrote:
> It's probably easier to make high-quality parts in LGEO, but it should
> be possible to make them in LDraw, run them through L3P, and get
> equivalent results.
I agree.
> What'd be *really* great is if the substitution wasn't hard-coded in
> L3P, but was stored in an external file. That way, LGEO (or even
> L3G0) parts could be easily substituted in for LDraw parts, if the user
> was willing to go through the work of editing the translation file.
It's not that simple. Together with the POV substitution string I also
have other data like the BoundingBox of the primitive, which is used
e.g. in the automatic camera positioning. I think it is troublesome
to have this kind of info in the external file too.
> > Should we have more primitives, or should L3P have a list of
> > exceptions in order to convert a zero height cone to a ring?
>
> Seems kind of hacky to me to hard-code exceptions. Especially since
> this won't be the only place this approach is/was used, I think.
You are completely right.
> Let's see: L3P reports four other part files with singular matrices:
> 352.dat, 6043.dat, 4285.dat, and 3741.dat. I think these may be
> mistakes -- in each case, the singular matrix is flattening either a
> N-Mcyli.dat or stud4.dat. Even if they aren't mistakes, there are
> other ways to write those codes.
I think they are mistakes too.
Actually there are lots of singular matrices! So many that I decided
not to burden the innocent user. L3P has a list over xz-primitives
(like 4-4disc.dat) and silently fixes singular matrices for these
primitives. You can see warnings for this if you run "l3p -check -w3"
"WARNING \"%s\" Line %d: Row %d all zeros: %s"
"WARNING \"%s\" Line %d: Y column all zeros: %s"
I don't like having this list (and having to keeping it up-to-date),
but it seems that many part authors are lazy or ignorant and write
lines like "1 16 x y z 10 0 0 0 0 0 0 0 10 4-4disc.dat"
If L3P didn't fix these lines, you would just have a lot of warnings
from POV, which would only confuse the ordinary user. The goal of
L3P is to not have POV issue any warnings at all.
Please let me know if you experience any.
> So I guess I was wrong--so far, no one has needed to flatten
> a primitive on purpose, except 6267.dat.
>
> Since POV-Ray doesn't like flattened primitives, we should rethink the
> proposed strategy of (in the future) using flattened conics to make
> rings, and not creating new ring primitives. Too bad -- I hate
> cluttering up the primitives directory. But if we must, we must.
Maybe OpenGL and DirectDraw don't like them either? Leonardo?
I think that it serves us best to use normal transformations.
/Lars
|
|
Message has 4 Replies:
 | | Re: Flattened Primitives (was Re: 1x1 and 2x2 chess sets)
|
| (...) (I didn't claim it would be easy) Of course, the more information stored in a translation, the harder it is to customize. And load into a program to use the information. (...) (BTW, I meant 'mistake' as in a typo or a sub-optimal approach to (...) (25 years ago, 3-Mar-99, to lugnet.cad.dev)
|
5 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
