Cleaning the PT

[Willy Tschager]

Guys,

the PT currently has some HOLD parts which should be addressed instead of sitting on the PT for the rest of their days. Just one example:

http://www.ldraw.org/cgi-bin/ptdetail.cg...s/879h.dat

Please discuss.

w.

[Willy Tschager]

Since the underside studs do not add any functionality but add a lot of triangles which have to be calculated I would delete it.

w.

[Max Martin Richter]

I really like these files - they allow a realistic project rendering. I know AFOLs that use baseplates even for sides or roofs.
I would suggest to make them available as an high res version or something else.

/Max

[Philippe Hurbain]

Agree with Max... different people, different usages, different needs! I personnally have no use for those baseplates (as of now!) but I understand that people may need them. This actually raises question of various trade-off points between rendering quality and rendering speed.

[Max Martin Richter]

Basically I could agree with the following solution:
In editors the baseplates don't need the underside holes, in viewer or rendering programs the user should make a decision, if he wants it or not.
Mmh, the more I think of these holes, the more I think, that this question could be solved by a new hi res library or by using the LGEO library for photorealistic rendering...
And this brings us directly to the other topic about the new file format and/or parallel library...

/Max

[Willy Tschager]

If we are going this way I agree with Steffen:

This part creates a precedence case which needs to be resolved:

The XXXXh.dat file models a different virtual version of XXXX.dat,
but in reality only ONE such part existed AFAIK.

I don't think that it is a Good Idea ™ to have to virtual
representations of the same part in our library.
Either XXXX.dat or XXXXh.dat has to be deleted.
The remaining part then has to get the normal file number XXXX.dat
again. The "h" suffix does not make much sense to me.

The reason for creating the two variants probably was
to leave the decision to the user if he wants a detailed baseplate
underside or not. But I think that that issue should be resolved
not by this special "h" suffix, but instead the same way
as the "coarse" studs had been implemented:
all baseplates should be modeled with detailed underside,
and the underside negative stud could be present in two versions,
a detailed one, and a simplified one - i.e., one that isn't present
at all and models the underside as flat as previously.

w.

[Chris Dee]

I think we had a technical solution to this involving hi-res primitives, but I'd need to check back through the forum.

[Willy Tschager]

Browsing the list of the HOLDs at random I came across this:

http://www.ldraw.org/cgi-bin/ptdetail.cg.../85543.dat

Rubber Belts should be described more detailed like
<cutshape f.e. [round]><Inner diameter><thickness>

which needs to be addressed since there is nothing wrong with the part itself.

w.

[Steffen]

I also like the files a lot.
I also want to have the possibility to render baseplates in "very high res" with a fully modeled underside.
That's really something very nice.
However, to repeat my argument,
I think that they should not be modeled as separate parts,
but instead the existing mechanism of using finer or not-so-fine studs
should be used also for the underside. I.e., the underside should be modeled
referencing a yet-to-be-created "baseplate underside stud" primitive.
Of that primitive, we should create 2 variants.
First, the "default" one, in the \P folder, modeling a baseplate underside stud as a simple flat surface.
The hi-res variant of this could be put into the \P\48 folder, where the baseplate underside stud really is modeled as a concave surface.
The only thing missing would be a mechanism to switch between the two implementations.
Currently, e.g. MLCad offers to switch between different stud implementations already.
However, doing so it does not use our various folders, but instead simply replaces them by a single line,
or doesn't render them at all.

[Max Martin Richter]

The underside stud prim is already done:
p/studbp1.dat
p/studbp2.dat
p/studbp3.dat

Maybe it needs a better name...and we need to create the low-res version of it.

/Max

[Willy Tschager]

More politics required:

http://www.ldraw.org/cgi-bin/ptdetail.cg...s/3496.dat

Personally I'm fine with a new origin.

w.

[Magnus Forsberg]

Either origin is OK with me, but the shape is in need of a workover.
red/yellow is current design. blue/green is LDD data

   

[Willy Tschager]

The LDD data of the top looks more accurate. The angle of the bottom has to be remeasured while the inner stud-cavity of the green part is surely wrong.

w.