| |
There is somewhat of a disagreeance going on over at the PT about mirrored parts
and I thought I'd bring it to the whole community to discuss.
Here's a little background for the non initiated:
In order to same time and DAT code if a part has a mirrored brother then one
part reference the other and applies a mirrored matrix. For example, the
Technic Panel #1 just references Technic Panel #2 and applies the matrix
-1 0 0 0 1 0 0 0 1
This is the preferred way to represent a mirrored part pair. There is no
disagreement about this methed of coding parts. The problem comes in when you
add studs.
If you have stud the the part and apply a mirror matrix, most of the time
nothing is wrong. Along comes L3P or LDView that, based on user preference, add
the LEGO logo to the top of the studs. If the part is a mirror part then the
added logos also show up mirrored. Here's where we get 2 dissenting opinons:
1.) Nothing is wrong with the part. The stud logos are added by an external
program and are not part of the DAT code. This is, therefore, a limitation of
the external program and not of the part itself.
2.) The part itself is flawed in that the studs are mirrored. We should redo
all the mirrored parts with stud in such a way that the studs are not mirrored.
My question to the reader of this post is:
What do you prefer?
I'm axious to get a resolution on this since many otherwise good part are being
held up because of this issue.
-Orion
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> There is somewhat of a disagreeance going on over at the PT about mirrored parts
> and I thought I'd bring it to the whole community to discuss.
>
> Here's a little background for the non initiated:
>
> In order to same time and DAT code if a part has a mirrored brother then one
> part reference the other and applies a mirrored matrix. For example, the
> Technic Panel #1 just references Technic Panel #2 and applies the matrix
>
> -1 0 0 0 1 0 0 0 1
>
> This is the preferred way to represent a mirrored part pair. There is no
> disagreement about this methed of coding parts. The problem comes in when you
> add studs.
>
> If you have stud the the part and apply a mirror matrix, most of the time
> nothing is wrong. Along comes L3P or LDView that, based on user preference, add
> the LEGO logo to the top of the studs. If the part is a mirror part then the
> added logos also show up mirrored. Here's where we get 2 dissenting opinons:
>
> 1.) Nothing is wrong with the part. The stud logos are added by an external
> program and are not part of the DAT code. This is, therefore, a limitation of
> the external program and not of the part itself.
>
> 2.) The part itself is flawed in that the studs are mirrored. We should redo
> all the mirrored parts with stud in such a way that the studs are not mirrored.
>
> My question to the reader of this post is:
>
> What do you prefer?
>
> I'm axious to get a resolution on this since many otherwise good part are being
> held up because of this issue.
>
> -Orion
I favour the following scenario - put the part detail in a subpart, but the
studs themselves in the main part files.
s\xxxxs01.dat
bulk of part excluding decorated surfaces and studs (handedness of lowest
numbered part)
xxxx.dat
1 0 0 0 1 0 0 0 1 0 0 0 1 s\xxxxs01.dat
4s and 3s for decoration
x y z 1 0 0 0 1 0 0 0 1 stud.dat (correctly orientated for LEGO logo)
xxxy.dat
1 0 0 0 -1 0 0 0 1 0 0 0 1 s\xxxxs01.dat
4s and 3s for decoration
x y z 1 0 0 0 1 0 0 0 1 stud.dat (correctly orientated for LEGO logo)
Chris
|
|
| |
I am generally against new meta-commands, but inspired by "0 BFD INVERTNEXT",
how about something like "0 MIRRORING KEEPPOSITIVENEXT". The more accurate
syntax, I leave to the gurus...
/Tore
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> If you have stud the the part and apply a mirror matrix, most of the time
> nothing is wrong. Along comes L3P or LDView that, based on user preference, add
> the LEGO logo to the top of the studs. If the part is a mirror part then the
> added logos also show up mirrored. Here's where we get 2 dissenting opinons:
I'm not going to comment on the actual question, but I want to make it clear
that LDView should NOT display the logo mirrored, ever. It automatically
detects that the stud has been mirrored, and mirrors the logo back to its
correct orientation. For this reason, you cannot use LDView to detect the
mirroring if you want to proof a part and verify that there aren't any mirrored
studs. (If some part author wants an option to turn off this auto-unmirroring,
please let me know; it should be trivial to add.)
LDView can do this because it fully parses and processes the model tree. On the
other hand, my understanding is that L3P essentially converts the model tree to
POV format one .dat file at a time, without any concept of the orientation of
the final rendering. This produces much smaller POV files and takes less time
to process.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Chris Dee wrote:
> In lugnet.cad.dev, Orion Pobursky wrote:
> > There is somewhat of a disagreeance going on over at the PT about mirrored parts
> > and I thought I'd bring it to the whole community to discuss.
> >
> > Here's a little background for the non initiated:
> >
> > In order to same time and DAT code if a part has a mirrored brother then one
> > part reference the other and applies a mirrored matrix. For example, the
> > Technic Panel #1 just references Technic Panel #2 and applies the matrix
> >
> > -1 0 0 0 1 0 0 0 1
> >
> > This is the preferred way to represent a mirrored part pair. There is no
> > disagreement about this methed of coding parts. The problem comes in when you
> > add studs.
> >
> > If you have stud the the part and apply a mirror matrix, most of the time
> > nothing is wrong. Along comes L3P or LDView that, based on user preference, add
> > the LEGO logo to the top of the studs. If the part is a mirror part then the
> > added logos also show up mirrored. Here's where we get 2 dissenting opinons:
> >
> > 1.) Nothing is wrong with the part. The stud logos are added by an external
> > program and are not part of the DAT code. This is, therefore, a limitation of
> > the external program and not of the part itself.
> >
> > 2.) The part itself is flawed in that the studs are mirrored. We should redo
> > all the mirrored parts with stud in such a way that the studs are not mirrored.
> >
> > My question to the reader of this post is:
> >
> > What do you prefer?
> >
> > I'm axious to get a resolution on this since many otherwise good part are being
> > held up because of this issue.
> >
> > -Orion
>
> I favour the following scenario - put the part detail in a subpart, but the
> studs themselves in the main part files.
Thats what i did with the re-upload of some files from the 2865.dat & 32087.dat
parts (9V straight track, 9V track cross ) and the recently posted 2867.dat (9V
Curved track). I moved the studs from the subparts to the main file. With the
original release i got the same problem with the stud logos. Studs where placed
in the subfiles, so when rotating them 180 degrees they wheren't correctly
aligned. I will use this scenario for the 9V points too (left & right handed
point are mirrored parts). When certifying those files, read the remark i placed
on the parts tracker, because some parts use the same subfiles and need
therefore released at the same time, otherwise you'll get double studs (2 studs
on top of eachother - 1 from the subpart file and 1 from the main part file). I
didn't need to do it, but i did it anyhow, just, if rendered in hight quality
level that it looks good. It took also some extra time, because i wasn't aware
of this problem (i check my parts with L3LAB V1.2 20000616 and it doesn't have a
Quality level3 rendering setting). I suppose that this issue can be added to
http://www.ldraw.org/reference/faq/ or
http://www.ldraw.org/library/tracker/ref/
>
> s\xxxxs01.dat
> bulk of part excluding decorated surfaces and studs (handedness of lowest
> numbered part)
>
> xxxx.dat
> 1 0 0 0 1 0 0 0 1 0 0 0 1 s\xxxxs01.dat
> 4s and 3s for decoration
> x y z 1 0 0 0 1 0 0 0 1 stud.dat (correctly orientated for LEGO logo)
>
> xxxy.dat
> 1 0 0 0 -1 0 0 0 1 0 0 0 1 s\xxxxs01.dat
> 4s and 3s for decoration
> x y z 1 0 0 0 1 0 0 0 1 stud.dat (correctly orientated for LEGO logo)
> Chris
Ludo
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> There is somewhat of a disagreeance going on over at the PT about mirrored parts
> and I thought I'd bring it to the whole community to discuss.
>
> Here's a little background for the non initiated:
>
> In order to same time and DAT code if a part has a mirrored brother then one
> part reference the other and applies a mirrored matrix. For example, the
> Technic Panel #1 just references Technic Panel #2 and applies the matrix
>
> -1 0 0 0 1 0 0 0 1
>
> This is the preferred way to represent a mirrored part pair. There is no
> disagreement about this methed of coding parts. The problem comes in when you
> add studs.
>
> If you have stud the the part and apply a mirror matrix, most of the time
> nothing is wrong. Along comes L3P or LDView that, based on user preference, add
> the LEGO logo to the top of the studs. If the part is a mirror part then the
> added logos also show up mirrored. Here's where we get 2 dissenting opinons:
>
> 1.) Nothing is wrong with the part. The stud logos are added by an external
> program and are not part of the DAT code. This is, therefore, a limitation of
> the external program and not of the part itself.
>
> 2.) The part itself is flawed in that the studs are mirrored. We should redo
> all the mirrored parts with stud in such a way that the studs are not mirrored.
>
> My question to the reader of this post is:
>
> What do you prefer?
Good summation. My preference is 1... a sufficiently clever convertor could
perhaps detect this rotation and use rotated versions of the studs that it
substitutes somehow in a preprocess step???
If there is a way to do 2 (perhaps with a comment or keyword similar to BFC to
denote that there is an extra mirroring somewhere??? but no other change to the
part...) that might work but it would require a lot of parts to change. I would
be opposed to the parts being completely recreated.
Thanks for bringing this up. My opinion is easily swayed, BTW...
Also I have another issue to surface/resurface which I iwll do in a separate
post
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> If you have stud the the part and apply a mirror matrix, most of the time
> nothing is wrong. Along comes L3P or LDView that, based on user preference, add
> the LEGO logo to the top of the studs. If the part is a mirror part then the
> added logos also show up mirrored. Here's where we get 2 dissenting opinons:
LDView does not have a problem with mirrored studs.
> 1.) Nothing is wrong with the part. The stud logos are added by an external
> program and are not part of the DAT code. This is, therefore, a limitation of
> the external program and not of the part itself.
Right!
See my posting http://news.lugnet.com/cad/dat/parts/?n=3956
Travis Cobbs also explains it well in http://news.lugnet.com/cad/ray/?n=1454
> 2.) The part itself is flawed in that the studs are mirrored. We should redo
> all the mirrored parts with stud in such a way that the studs are not mirrored.
Though I acknowledge that L3P should deal with the problem
I also appreciate this initiative, because the solution is not easy,
as explained above.
/Lars ;-)
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> There is somewhat of a disagreeance going on over at the PT about mirrored parts
> and I thought I'd bring it to the whole community to discuss.
**snip**
> Here's where we get 2 dissenting opinons:
>
> 1.) Nothing is wrong with the part. The stud logos are added by an external
> program and are not part of the DAT code. This is, therefore, a limitation of
> the external program and not of the part itself.
>
> 2.) The part itself is flawed in that the studs are mirrored. We should redo
> all the mirrored parts with stud in such a way that the studs are not mirrored.
>
> My question to the reader of this post is:
>
> What do you prefer?
Ah, the perennial question. During a past discussion of this very topic I
offered what I thought to be a semi-workable option similar to #2 above, which I
reiterate in the interest of further stirring the pot:
We could redo the mirrored parts so that the basic file without studs is
treated as a sub-part, and this in turn is used as the foundation for both the
"primary" part and the "mirrored" part. As an example, consider the 4x8 wing:
The "base" part would be the wing itself without any of the stud.dat
primitives included (let's call it wing.dat just to be generic). The
"right-hand" version of the wing would be written this way:
0 Wing, 4 x 8, right
0 Part Name: Wing-R
1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\wing.dat
1 16 -10 16 0 1 0 0 0 1 0 0 0 1 stud.dat
1 16 -10 16 -20 1 0 0 0 1 0 0 0 1 stud.dat
1 16 -10 16 -40 1 0 0 0 1 0 0 0 1 stud.dat
0
and so on, until all the studs are added. The "left-hand" version of the wing
would then be written:
0 Wing, 4 x 8, left
0 Part Name: Wing-L
1 16 0 0 0 -1 0 0 0 1 0 0 0 1 s\wing.dat
1 16 10 16 0 1 0 0 0 1 0 0 0 1 stud.dat
1 16 10 16 -20 1 0 0 0 1 0 0 0 1 stud.dat
1 16 10 16 -40 1 0 0 0 1 0 0 0 1 stud.dat
0
and so on, until all the studs are added. This way, the base "s\wing.dat"
subpart will be mirrored right-to-left, but the stud.dat primitives will not be,
and the part will render just fine in L3P even at q=3. I am 100% certain that
this works, because I've written a number of mirrored clone parts this way.
When I offered this suggestion previously, Steve Bliss (that stinker) pointed
out that this potentially generates a bunch of new subparts (which may in itself
be undesirable) as well as creating somewhat more work for parts authors. YMMV,
but his concerns are worth considering. In any case, it's still quicker than
generating a whole new left-hand wing element from scratch.
Dave!
|
|
| |
Orion Pobursky wrote:
> 1.) Nothing is wrong with the part. The stud logos are added by an external
> program and are not part of the DAT code. This is, therefore, a limitation of
> the external program and not of the part itself.
>
> 2.) The part itself is flawed in that the studs are mirrored. We should redo
> all the mirrored parts with stud in such a way that the studs are not mirrored.
My view is that there is nothing _serious_ wrong, but that a fix should
be welcome.
Anyway. Since we are only talking about studs, the rendering programs
_could_ simply remember to fix any mirrored studs (can be done by
multiplying the rotation matrix of the object with the sign of its
determinant).
Play well,
Jacob
--
Horse (building instructions):
http://jacob.sparre.dk/LEGO/Dyr/Hest/
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> 1.) Nothing is wrong with the part. The stud logos are added by an external
> program and are not part of the DAT code. This is, therefore, a limitation of
> the external program and not of the part itself.
That is my opinion. The programs should be changed, rather than the
parts.
One thing to consider: even if we 'fix' all the part files so that all
studs render non-mirrored logos, mirrored logos can still occur. For
example, if someone created a left-hand wing for an airplane, they might
make the right-hand counterpart via a mirrored reference to the left
wing:
1 7 0 0 0 1 0 0 0 1 0 0 0 1 leftwing.ldr
1 7 0 0 0 -1 0 0 0 1 0 0 0 1 leftwing.ldr
In this scenario, L3P will render mirrored logos on the right wing's
studs.
However, I'm willing to go with the idea outlined by Chris and Dave! I
think that is a reasonable compromise, despite what I said in the past
about extra work and extra subfiles.
Also, if we're going to add any meta-statement (as Tore suggested), how
about adding a single statement for the file header:
0 STUDSGOTHISWAY 0 0 1
where the three parameters give a vector, indicating the 'up' direction
for stud-logos. That way, rendering programs could fix mis-rotated
studs, as well as fixing mirrored studs.
> I'm axious to get a resolution on this since many otherwise good part are being
> held up because of this issue.
I definitely would not hold a part because the studs aren't all lined
up!
Steve
|
|
| |
Just for kicks and grins.(not!) I'll throw in my $1.25
In lugnet.cad.dev, Orion Pobursky wrote:
> There is somewhat of a disagreeance going on over at the PT about mirrored parts
> and I thought I'd bring it to the whole community to discuss.
This may have resurfaced because of the studs with logo files on my webpage. It
was a quick thought I came up with a couple years ago.
I guess I should remove them and any references to them. They have seemed to
cause more trouble than they are worth.
How many people actually review parts down to the orientation of the studs? Very
few in my opinion. If a part is new and has several errors, I will make mention
that the stud should be oriented like "1 16 ........dat" However, I rarely check
stud orientation.
> Here's a little background for the non initiated:
>
> In order to same time and DAT code if a part has a mirrored brother then one
> part reference the other and applies a mirrored matrix. For example, the
> Technic Panel #1 just references Technic Panel #2 and applies the matrix
>
> -1 0 0 0 1 0 0 0 1
>
> This is the preferred way to represent a mirrored part pair. There is no
> disagreement about this methed of coding parts. The problem comes in when
> you add studs.
>
> If you have stud the the part and apply a mirror matrix, most of the time
> nothing is wrong. Along comes L3P or LDView that, based on user preference,
> add the LEGO logo to the top of the studs. If the part is a mirror part
> then the added logos also show up mirrored. Here's where we get 2 dissenting
> opinons:
>
> 1.) Nothing is wrong with the part. The stud logos are added by an external
> program and are not part of the DAT code. This is, therefore, a limitation
> of the external program and not of the part itself.
I'm not inclined to think this way. Programs have to make up for too many
exceptions as it is. (Don't they?)
> 2.) The part itself is flawed in that the studs are mirrored. We should
> redo all the mirrored parts with stud in such a way that the studs are not
> mirrored.
My opinion would be #2. Time consuming for someone to do, Has anyone checked to
see how many parts are affected? This should help make a decision.
> My question to the reader of this post is:
>
> What do you prefer?
>
> I'm axious to get a resolution on this since many otherwise good part are
> being held up because of this issue.
>
> -Orion
If checking parts also needs to include checking stud orientation, Reviews will
have a longer review time and orientation errors will be treated as a nuisance
and not get fixed.
Like I said above, I do not "hold" parts for this and rarely even check for it.
Paul
|
|
| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Orion Pobursky wrote:
>
> > 1.) Nothing is wrong with the part. The stud logos are added by an external
> > program and are not part of the DAT code. This is, therefore, a limitation of
> > the external program and not of the part itself.
>
> That is my opinion. The programs should be changed, rather than the
> parts.
And mine as well. If LDView can correct for this then so can any other program.
The stud logos are a bonus feature offered by many programs but are not
officailly supported by the LDraw spec.
> One thing to consider: even if we 'fix' all the part files so that all
> studs render non-mirrored logos, mirrored logos can still occur. For
> example, if someone created a left-hand wing for an airplane, they might
> make the right-hand counterpart via a mirrored reference to the left
> wing:
> 1 7 0 0 0 1 0 0 0 1 0 0 0 1 leftwing.ldr
> 1 7 0 0 0 -1 0 0 0 1 0 0 0 1 leftwing.ldr
> In this scenario, L3P will render mirrored logos on the right wing's
> studs.
This further supports my position on this matter
> However, I'm willing to go with the idea outlined by Chris and Dave! I
> think that is a reasonable compromise, despite what I said in the past
> about extra work and extra subfiles.
My problem with the studless subpart is that we'll set a precident that may be deterimental. What if we have 2 32x32 baseplates that are mirror images? would we have two files with 100+ stud that are exactly the same with the exception of the part being mirrored? This will only serve to increase render time since we mow have to parse and extra subfile.
<snip>
> I definitely would not hold a part because the studs aren't all lined
> up!
I agree that this is a pretty petty reason for a hold vote
To sum up:
If LDView can correct for this, any program can. The extra work and subfile
clutter are just not worth it for a nice-to-have-but-not-required bonus feature.
--Orion
|
|
| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Orion Pobursky wrote:
>
> > 1.) Nothing is wrong with the part. The stud logos are added by an external
> > program and are not part of the DAT code. This is, therefore, a limitation of
> > the external program and not of the part itself.
>
> That is my opinion. The programs should be changed, rather than the
> parts.
>
> One thing to consider: even if we 'fix' all the part files so that all
> studs render non-mirrored logos, mirrored logos can still occur. For
> example, if someone created a left-hand wing for an airplane, they might
> make the right-hand counterpart via a mirrored reference to the left
> wing:
> 1 7 0 0 0 1 0 0 0 1 0 0 0 1 leftwing.ldr
> 1 7 0 0 0 -1 0 0 0 1 0 0 0 1 leftwing.ldr
> In this scenario, L3P will render mirrored logos on the right wing's
> studs.
>
> However, I'm willing to go with the idea outlined by Chris and Dave! I
> think that is a reasonable compromise, despite what I said in the past
> about extra work and extra subfiles.
>
> Also, if we're going to add any meta-statement (as Tore suggested), how
> about adding a single statement for the file header:
> 0 STUDSGOTHISWAY 0 0 1
> where the three parameters give a vector, indicating the 'up' direction
> for stud-logos. That way, rendering programs could fix mis-rotated
> studs, as well as fixing mirrored studs.
>
> > I'm axious to get a resolution on this since many otherwise good part are being
> > held up because of this issue.
>
> I definitely would not hold a part because the studs aren't all lined
> up!
>
> Steve
My only concern about letting the rendering programs do this is "how they know
which way to orientate the logo". Coding this within the .dat file (either with
a correctly orientated stud.dat or with metadata) is preferable to storing this
information in some other place and dispersing "Lego part" information in
several repositories.
I rarely (if ever) include a check for stud orientation in my parts review.
IIRC the 16x32 baseplates exist in two forms - with the Logo either aligned with
the long side or with short side. I would NOT be keen to have a part variant
just for this (non-functional) feature.
Chris
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Orion Pobursky wrote:
> > If you have stud the the part and apply a mirror matrix, most of
> > the time nothing is wrong. Along comes L3P or LDView that, based on
> > user preference, add the LEGO logo to the top of the studs. If the
> > part is a mirror part then the added logos also show up
> > mirrored. Here's where we get 2 dissenting opinons:
> >
> > 1.) Nothing is wrong with the part. The stud logos are added by an
> > external program and are not part of the DAT code. This is,
> > therefore, a limitation of the external program and not of the part
> > itself.
>
> Right!
> See my posting http://news.lugnet.com/cad/dat/parts/?n=3956
> Travis Cobbs also explains it well in http://news.lugnet.com/cad/ray/?n=1454
>
> > 2.) The part itself is flawed in that the studs are mirrored. We
> > should redo all the mirrored parts with stud in such a way that the
> > studs are not mirrored.
>
> Though I acknowledge that L3P should deal with the problem
> I also appreciate this initiative, because the solution is not easy,
> as explained above.
Wait a minute. Doesn't L3Input.cpp build a threaded tree structure
before outputting a single POV part? I would think you could traverse
the array Parts[0...nParts] and look for toplevel parts from the PARTS
directory. Then for each toplevel part, if it has mirrored studs,
make a duplicate of each subpart (and it's subparts) with mirrored
studs. In the duplicate subparts, use a different stud with a
mirrored logo. You don't really have to "flatten" the whole tree to
do this, just the branches with mirrored studs. And you're not really
flattening them, you're just duplicating them, which is similar to
what you'd end up with anyhow if we manually unmirror the studs in the
mirrored parts files.
Hmmm, maybe I should fiddle with this using Paul Easter's stud parts
in ldglite to see what I might have missed. Paul, don't delete those
logo enhanced stud files! If anything, just slap a larger disclaimer
on them.
Don
PS. In case I was unclear there, I think this should be fixed in
software, not in the part files. Keep the part files simple. They're
meant for building.
|
|
| |
In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> Anyway. Since we are only talking about studs, the rendering programs
> _could_ simply remember to fix any mirrored studs (can be done by
> multiplying the rotation matrix of the object with the sign of its
> determinant).
Umm, my math is really rusty. Can the sign of the determinant also
be used to detect mirroring? That could be handy.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> > Anyway. Since we are only talking about studs, the rendering programs
> > _could_ simply remember to fix any mirrored studs (can be done by
> > multiplying the rotation matrix of the object with the sign of its
> > determinant).
>
> Umm, my math is really rusty. Can the sign of the determinant also
> be used to detect mirroring? That could be handy.
Yes. That's what LDView does.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Tore Eriksson wrote:
> I am generally against new meta-commands, but inspired by "0 BFD INVERTNEXT",
> how about something like "0 MIRRORING KEEPPOSITIVENEXT". The more accurate
> syntax, I leave to the gurus...
We definitely don't want to do this. It's unnecessary, because the sign of the
determinant in the matrix specifying the sub-part tells you whether the sub-part
is mirrored. The above might allow the program to do less math, but that's not
an acceptable reason for introducing a meta-command that is susceptible to human
error. (Plus, in many cases the program will have calculated the determinant
for other reasons anyway.)
--Travis Cobbs
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Jacob Sparre Andersen wrote:
> > > Anyway. Since we are only talking about studs, the rendering programs
> > > _could_ simply remember to fix any mirrored studs (can be done by
> > > multiplying the rotation matrix of the object with the sign of its
> > > determinant).
> >
> > Umm, my math is really rusty. Can the sign of the determinant also
> > be used to detect mirroring? That could be handy.
>
> Yes. That's what LDView does.
Yeah, I did a search for determinant and found your note. I tried
the on-the-fly fix in ldglite with the L3 structs and it seems to work,
although I'm not sure I'm applying the fix correctly. Is it really
as simple as multiplying some matrix by -1? I must have been applying
the -1 to the wrong matrix, so I went with mirror around the Z axis
transform instead. Can you point me to the ldview code that does this?
I'm feeling rather lazy today, asking for help before looking for
myself...
Thanks,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Yeah, I did a search for determinant and found your note. I tried
> the on-the-fly fix in ldglite with the L3 structs and it seems to work,
> although I'm not sure I'm applying the fix correctly. Is it really
> as simple as multiplying some matrix by -1? I must have been applying
> the -1 to the wrong matrix, so I went with mirror around the Z axis
> transform instead. Can you point me to the ldview code that does this?
> I'm feeling rather lazy today, asking for help before looking for
> myself...
I don't actually do any transformations in LDView to get the logos right. I
just detect the mirroring (by tracking negative determinants and flipping the
mirrored bit every time I see one) and modify my texture coordinates to
un-mirror (horizontally) if the stud has been mirrored. You can take a look at
the genTextureCoords method in TGLStudLogo.cpp if your interested, but I don't
think it will really help you.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> I don't actually do any transformations in LDView to get the logos
> right. I just detect the mirroring (by tracking negative
> determinants and flipping the mirrored bit every time I see one) and
> modify my texture coordinates to un-mirror (horizontally) if the
> stud has been mirrored. You can take a look at the genTextureCoords
> method in TGLStudLogo.cpp if your interested, but I don't think it
> will really help you.
Actually that does help a bit. It looks like you aren't concerned
with whether the logo faces the same direction as on the actual part,
you're just ensuring that it's readable. That makes me feel better
about my solution.
By the way, why do you bother to track all the mirroring steps? Can't
you just look at the final matrix?
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Actually that does help a bit. It looks like you aren't concerned
> with whether the logo faces the same direction as on the actual part,
> you're just ensuring that it's readable. That makes me feel better
> about my solution.
Correct. There's no way to know if they actually face the right direction, so I
just figured that horizontal mirroring was more likely to be correct than
vertical (although I could be wrong).
> By the way, why do you bother to track all the mirroring steps? Can't
> you just look at the final matrix?
You can, but my code that decides which texture coordinates to use doesn't have
access to the final matrix. Also, I flatten the geometry of all parts in
LDView, and the flattening process can result in a mirror transformation being
aplied to the stud geometry. (By flatten, I mean that I apply the
transformations for sub-parts, and copy the geometry into the parent part.) I
have to track when this happens.
--Travis
|
|
| |
> The stud logos are a bonus feature offered by many programs but are not
> officailly supported by the LDraw spec.
> The extra work and subfile
> clutter are just not worth it for a nice-to-have-but-not-required bonus
> feature.
>
> --Orion
After thinking about it for a while, I totally agree. If anyone wants to make
perfect rendering with stud logos lined up correctly (how often does this
occur?), I assume this person must have the knowledge to inline that part
locally at his/her PC and rotate the stud(s) at will. The extra time spent for
this operation is neglectable compared to all fiddling with light settings and
camera positions/angles and so on.
I too have local, unofficial variants of part files on my PC. Anybody is of
course free to hack. :)
And if he publishes the POV-file based on his local hack, it will have the studs
correctly aligned there, too.
/Tore
|
|
| |
In lugnet.cad.dev, Orion Pobursky wrote:
> My problem with the studless subpart is that we'll set a precident that may
> be deterimental. What if we have 2 32x32 baseplates that are mirror
> images? would we have two files with 100+ stud that are exactly the same
> with the exception of the part being mirrored?
A fair point, but how often would that happen, realistically? Enough to be a
problem? Even if one or two parts eventually turn up like that, why would the
whole system have to be jettisoned for those few exceptions?
> This will only serve to increase render time since we mow have to parse and
> extra subfile.
I'm not sure that this is a persuasive argument. Until not long ago I used a
super-sluggish Pentium 120 CPU, and I never had a discernable problem with
parsing delays of this sort. Even the slowest CPUs on the market today are
much, much faster, so delays of a few nanoseconds don't give me much pause, so
to speak.
> <snip>
>
> > I definitely would not hold a part because the studs aren't all lined
> > up!
>
> I agree that this is a pretty petty reason for a hold vote
Absolutely agreed!
Conversely, if a pair of mirrored parts were submitted as a subfile + two
distinct stud layouts, would the parts be accepted in that form?
> If LDView can correct for this, any program can. The extra work and subfile
> clutter are just not worth it for a nice-to-have-but-not-required bonus feature.
Well that's definitely true. If a fix can be generated without radically
restructuring the way mirrored parts are created, then by all means that's the
way to go.
By the way, why is subfile clutter a problem? There are a zillion minifig
torsos that I never use, but I don't delete them because they don't cause me any
real trouble. I almost never look in my s\ directory, so anything that goes on
in tehre is basically irrelevant to me.
Dave!
|
|
| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Orion Pobursky wrote:
>
> > 1.) Nothing is wrong with the part. The stud logos are added by an external
> > program and are not part of the DAT code. This is, therefore, a limitation of
> > the external program and not of the part itself.
>
> That is my opinion. The programs should be changed, rather than the
> parts.
Yes. But I'm not as willing as you are to see files changed, I guess
> One thing to consider: even if we 'fix' all the part files so that all
> studs render non-mirrored logos, mirrored logos can still occur. For
> example, if someone created a left-hand wing for an airplane, they might
> make the right-hand counterpart via a mirrored reference to the left
> wing:
> 1 7 0 0 0 1 0 0 0 1 0 0 0 1 leftwing.ldr
> 1 7 0 0 0 -1 0 0 0 1 0 0 0 1 leftwing.ldr
> In this scenario, L3P will render mirrored logos on the right wing's
> studs.
>
> However, I'm willing to go with the idea outlined by Chris and Dave! I
> think that is a reasonable compromise, despite what I said in the past
> about extra work and extra subfiles.
>
> Also, if we're going to add any meta-statement (as Tore suggested), how
> about adding a single statement for the file header:
> 0 STUDSGOTHISWAY 0 0 1
> where the three parameters give a vector, indicating the 'up' direction
> for stud-logos. That way, rendering programs could fix mis-rotated
> studs, as well as fixing mirrored studs.
I think mirrored is more of a concern than misrotated, but that's just me.
Would this meta work though? In other words, are there any parts that have studs
*with logos* in different, non parallel planes? We have lots of parts that have
studs in different planes, but IIRC, all of them tend to use the technic/stud
with missing center for non coplanar (or at least non parallel) studs. (for
example, all the brackets http://guide.lugnet.com/partsref/bracket/ share this
behaviour, as do all the bricks with side studs that I checked...)
> > I'm axious to get a resolution on this since many otherwise good part are being
> > held up because of this issue.
>
> I definitely would not hold a part because the studs aren't all lined
> up!
Me either! I'll reiterate, I don't like the solution proposed by Dave! I say
programattically or not at all would be the preferred approach.
|
|
| |
In lugnet.cad.dev, Larry Pieniazek wrote:
> Me either! I'll reiterate, I don't like the solution proposed by Dave!
Ouch--painful use of Dave!
Oh, well. I knew my solution wasn't perfect, but it solved the immediate
problem (while admittedly creating others).
I'll still probably use it in my blasphemous clone.dats, if it's all the same
to you folks.
> I say programattically or not at all would be the preferred approach.
I'll likewise reiterate that it would definitely be nice to have a program
take care of it. I think the studlogo is a sufficiently nice little confection
to keep, even if it's not part of the original LDraw canon.
Dave!
|
|
|
