Subject:
|
Re: LDraw File Format Spec 1.0 DRAFT - Call for Public Comments
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 23 Aug 2007 10:12:31 GMT
|
Viewed:
|
5456 times
|
| |
|
|
In lugnet.cad, Timothy Gould wrote:
> --snip--
>
> > > > Neither. It's just a question of wording. As long as you put the X, Y, and Z
> > > > in the appropriate place (and the 0s in the other appropriate spots), and as
> > > > long as you do your transformations correctly, both ways produce the same
> > > > results.
> > > >
> > > > --Travis
> > >
> > > I think a full worked through example would do the specs a lot of good. If I
> > > understand right the line
> > >
> > > 1 c x y z a b c d e f g h i part.dat
> > >
> > > transforms any point by the operation
> > >
> > > (u, v, w)->(x+a*u+b*v+c*w, y+d*u+e*v+f*w, z+g*u+h*v+i*w)
> > >
> > > With it spelled out explicitly like that a programmer can use whatever internal
> > > format they like.
> > >
> > > Tim
> >
> > If I were new to 3D graphics (and I am ) I would be confused by this, I would
> > have to ask someone else how to interpret the spec. I think Travis' proposal to
> > show the two different matrices that can be built from the line of values is
> > more clear than the equation. Like they say, a picture is worth a thousand
> > words, or in this case, a big equation ;)
> >
> > Rob
>
> I'm not new to matrices and Travis' example is still a little unrigorous which
> is why I propose the mathematically sound form above. Note the amount of
> discussion already here because of what people consider 'standard' or 'given'
> forms of the matrices. The form I give is totally unambiguous.
>
> Of course I'd like both ultimately.
>
> Tim
I think we need to draw this particular discussion to a close.
From all the comments around matrix manipulation it is clear that this part
of the specification is ambiguous and so needs further consideration.
Unfortunately, whatever method we finally come up with to explain the spec,
it will always be unclear to some, on the basis that you "can't please all
of the people all of the time". However, provided that it is mathetically
correct, this is not a major obstacle to the final ratification of the spec.
While it may also, from the view point of some, be best if the LDraw spec
followed some other spec (eg OpenGL), again this is not a requirement, and
indeed, there are very good reasons why the LDraw spec should not slavishly
follow other specs (see the reasons for not embedding POV-RAY code into
parts for a very good argument) - they may happen to coincide at some
points, but that's very different from following.
So, the LSC will carefully consider all the points made in this thread in
due course, and come up with something that works for LDraw.
William
|
|
Message is in Reply To:
55 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
