 | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | | | | | |
> 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.
>
> 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, 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!
| | | | | | |
