LDraw.org Discussion Forums

Full Version: Baseplate underdetailing was Re: LDView Bug
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Chris Dee Wrote:I don't like the idea of unofficial libraries, since we could inadvertently break them with changes to the official library.


Comments welcome.

Ok, I revise my suggestion.
Why not make the /D library official but optional?
Chris, I like your idea a lot.
If at all we should decide to put energy in this issue, we should solve it in a way similar to what you suggest.
May I just ask for the introduction of not just 1, but 2 new levels of stud detail:
(a) officialize the LEGO logoed studs, which I use everyday, and without which I cannot live anymore (see attachments)
(b) another level for addition of baseplate undersides

The counterargument that current baseplate implementations just use 1 big underside quad,
and, after the introduction of Chris' suggestion would have to be modeled differently,
i.e., refererencing n instances of underside baseplate studs, which depending on their rendering
could be a simple quad or a detailed stud, is valid. For example, a 32x32 baseplate would have 1024 underside
quads in the simplest case, compared to currently just 1 quad.

However, Chris' suggestion of providing stug* files for the underside quads can solve this problem.
Would the 32x32 baseplate for its underside simply reference the "32x32 underside baseplate stug" file,
then that file could be 1 single quad in its simple incarnation, and 32x32 underside studs in its detailed incarnation.
Problem solved. NICE!!!!
Edited 64 to 48 in the original post (my bad!).

I'm not suggesting that we use the technique of the current ****h baseplates on the Parts Tracker which combine top AND bottom surfaces into the stud. Rather we should revert to the current technique for the top surface (a single rectangle with superimposed studs) and, for example, a stug19-16x16.dat for the underside. In the ldraw/p folder this primitive would be a single rectangle, but in the ldraw/p/48 folder it would be a matrix of 48\stud19.dat references.
Chris wrote:
> - a zero-res (superfast-draw) primitive - p/studline.dat (although I'm not sure if any tool since ldraw.exe has supported this)

MLCad does!
You can turn on that stud usage in its preferences.
When you do, it even correctly uses studline.dat, and does no "own" stud line drawing.
You can proof that by putting something else into that file - it will have the expected effect.

LDView currently only allows to toggle between fast-draw and normal studs, but adding a third option
for studline.dat should be nearly trivial.
Did you have some further thoughts?
(2012-01-16, 22:31)Chris Dee Wrote: [ -> ]Only on the Parts Tracker - e.g. her. I'm not yet convinced this is a good idea, or sure how we should implement it in the Parts Library.

We should simply get rid of them - too much detail.

Pages: 1 2 3