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