Baseplate underdetailing was Re: LDView Bug

[Chris Dee]

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.

[Jean-Philippe Ouellet]

It just seems like a ton of extra pollies to me, slowing down rendering without any functional gain. AFAIK all baseplates have those dents underneath, so it's not an issue of this part vs that part, just an issue of the level of detail. If you really want it to look that good, you're probably going to be rendering in POV-Ray or something where you're probably already substituting more-detailed versions of parts anyway so one more detail-related substitution isn't a big deal, especially when its on a part of the model you'll probably never see (I've never seen baseplates not on the ground in any real-life model).

IMO: Visually satisfying thing to have around for the very rare case you want to actually see the bottom of a baseplate, but not practical for the official library.

On the other hand, I have noticed a widespread trend towards including more underside detail regardless of its functionality, and perhaps this is something we want to pursue given the increase in computer power seen since the detail-level precedent was set.

As an illustration of my point, consider the following parts:

Philo has just done an outstanding job authoring a great deal of detail inside the bottom of 88293:

In any practical application, that detail will never be visible, and thus isn't necessary and only hurts rendering time. (Please don't take this personally Philo, I'm sure you spent a considerable amount of time authoring that detail, and it is quite admirable, I'm just pointing it out to support both sides of the debate.)

Now look at the underside of 3001:

And compare it to the real thing:


First off, detail A (the underside stud dimples) are not present in the model of any bricks, so why should they be present in baseplates? I believe this makes a strong case against the "h" baseplate variants because, in order for the entire library to be consistent, almost every single brick would need to be revised, and because these are round, the number of polygons that would be added is astronomical.

Secondly, James Jessiman hadn't modeled details B and C (which are present in 88293), be it for the low authoring-time to usefulness ratio, or rendering efficiency, I do not know, but it wasn't there. Recently, there has been a trend towards including these details. Although they are just as (un)important to LDraw models and renders as detail A, I believe these should be considered separately, because they are only boxes, not inset round things.

Another thing to consider is the fact that rendering a few more polygons today is much less of a relative burden on your hardware than it was 10 years ago.

I believe this trend towards increased levels of detail should be examined by the LSC, and we should standardize how detailed parts should be (something more clear-cut than the current "if it's less than 1 LDU, ignore it" suggestion).

Just my two cents, take it or leave it.

[Tim Gould]

Perhaps this is a good topic to raise with the community at large? Some open debate about the pros and cons of various options might help you to come up with a decision.

NB. And I mean see what the community thinks, but decide unilaterally. Or ship it off to the LSC.

Tim

[Tim Gould]

(I've never seen baseplates not on the ground in any real-life model).

I will use any part of any part if it suits my purpose

Although I'm inclined to agree that the main version of the part can ignore this. There are other, better ways around it for the few cases the underdetails are needed.

Tim

[Jean-Philippe Ouellet]

Haha, nice. I knew it was only a matter of time until somebody posted pics proving otherwise... Bonus points if they're from BrickFair yesterday

[Steffen]

my opinion:
yes, I like realism, and the underside of baseplates is really worth considering being remodeled this way.
but: I think we should (currently) refrain from doing so, because:

(a) doing it will require to adjust nearly _all_ baseplates,
which will be tons of work, and we can need the energy currently IMHO
better in fighting down the PT backlog further

(b) the visual gain will be there only in very special usecases,
but the work will be gigantic, and the memory impact will be big,
as well as parsing time increase, polygon count etc.
thus, to support the underside studs in those rare usecases,
an interested (most probably experienced) builder can easily take
care of adding the underside negative studs locally, when really needed,
to his files.

summing it up: generally a good idea, really worth considering,
but currently IMHO too time consuming for too small gain.

in the future we should find an analogous way to turn on and off that feature
like we currently can toggle the stud representation (detailed, rough, primitive-substituted, none, as just a line, etc.)

[Jean-Philippe Ouellet]

(a) doing it will require to adjust nearly _all_ baseplates,
which will be tons of work, and we can need the energy currently IMHO
better in fighting down the PT backlog further

Not just baseplates. If we are going to start modeling these things at all, I believe we should model them everywhere, and (as far as I can tell) EVERY PART WITH A STUD would need to be remodeled. Because this requires too much scenario-specific attention to be able to be done programmatically, EVERY PART WITH A STUD would need to be edited by a human. Such an undertaking is absolutely insane.

See these parts:

everywhere there is a stud, there is one of those bottom things.

parsing time increase

Just as with stud groups, this is negligible.

in the future we should find an analogous way to turn on and off that feature
like we currently can toggle the stud representation (detailed, rough, primitive-substituted, none, as just a line, etc.)

Substituting studs themselves is easy because it's just one dat file that you can directly substitute. In this case, many (most) surfaces on which these stud-underside-bumps appear are just one giant poly for the underside of the piece, so an LDraw viewer would need to calculate (based on where studs are on the top of the brick) how to subdivide that polygon (and avoid creating T junctions while doing so) and then place the inset studs appropriately. This is a somewhat overwhelming undertaking for a very very small gain. If anyone really wants to do this, more power to them, but I certainly don't see why anyone would.

[Tim Gould]

That same picture started a discussion about this very topic many years ago

Tim

[Tim Gould]

(b) the visual gain will be there only in very special usecases,
but the work will be gigantic, and the memory impact will be big,
as well as parsing time increase, polygon count etc.
thus, to support the underside studs in those rare usecases,
an interested (most probably experienced) builder can easily take
care of adding the underside negative studs locally, when really needed,
to his files.

This gets to my preference: I'd rather see the Parts Library remain as it is but see a special library of parts with the details there made available for special occassions only. Advanced builders may not be able to make such a baseplate themself, but they could download it if they wanted.

Having the underside details is simply too much computation for too little gain IMO.

Tim

[Philippe Hurbain]

One point of reference might be how LEGO modelled parts for LDD, generally it's a good compromise between accuracy and number of polygons (I said generally because some LDD parts are really off!). Bottom of parts is generally detailed, but... not baseplates! This can be easily explained because stud-intensive parts are very heavy! Cavity below brick studs is not modelled either in LDD.

Just to throw in some figures in the discussion, here is the top-5 of the most heavy LDD parts, after a raw conversion to LDraw:
Part / Name / Filesize
4186 / Baseplate 48 x 48 / 14.921 Mb
3811 / Baseplate 32 x 32 / 6.606 Mb
91405 / Plate 16 x 16 / 4.190 Mb
30072 / Brick 12 x 24 / 3.987 Mb
54779 / Boat Hull Unitary 51 x 12 x 6, Top (more or less equiv. ref.) / 3.825 Mb
To compare, a big sculptured baseplate (but studless!) is "only" 1.301 Mb (53588). And 88293 dome part, that has reinforcements (but no side ribs) is a mere 0.115 Mb.

In the light of this, I definitely don't think that increasing stud structure complexity (especially for baseplates) is a good idea...

[Tore Eriksson]

My opinion is that this calls for a special, unofficial library, just like my "Boxed" versions with simplified versions of basic parts, stored in the unofficial path <LDRAWDIR>\Parts\B
Let's say <LDRAWDIR>\Parts\G, where G stands for Geek.
This will even make it possible to have both "standard LDraw" parts and extremly detailed in the same model:

0 Example
0 // Yellow Normal part
1 14 0 0 0 0 0 -1 0 1 0 1 0 0 3001.dat
0 // Red Geek part
1 4 0 -24 20 1 0 0 0 0 1 0 -1 0 G\3001.dat
0


I haven't read this thread, so pardon me if I repeat what may already be written, but I don't think basepates are exactly 4 LDU thick, so at least those extremely detailed Geek versions of baseplates should also IMO have corrected thickness.

/Tore

[Tore Eriksson]

Let's say <LDRAWDIR>\Parts\G, where G stands for Geek.
This will even make it possible to have both "standard LDraw" parts and extremly detailed in the same model:

0 Example
0 // Yellow Normal part
1 14 0 0 0 0 0 -1 0 1 0 1 0 0 3001.dat
0 // Red Geek part
1 4 0 -24 20 1 0 0 0 0 1 0 -1 0 G\3001.dat
0

/Tore

Or maybe:
<LDRAWDIR>\Parts\H, where I believe H stands for Holes, as this seems to be what has been discussed so far.

Or, even better:
<LDRAWDIR>\Parts\D, where D stands for Details.

/Tore

[Tim Gould]

I like the solution in general and I like /D best since it can be used most generically.

Tim

[Steffen]

I strongly disagree with these "geeky" "special letter folders" named
G
H
D
or whatever.
The times of DOS 8.3 are long gone, and there's no need to be so brief and cryptic here.
I also disagree with this special folder.
Instead I would favor the same technique as used currently for studs, i.e., meaning
that the baseplates refer to some special underside primitives,
and those will either be instantiated as "fully detailed" or "simplified".

Nevertheless, I would much more prefer to interrupt this discussion here
and instead devour our precious energy to the review process of the existing parts pile on the PT,
instead of making that pile explode again by adding all those refurbished baseplates to it.
The amount of work to get all that done simply frightens me currently,
and I fear that my parts, sitting for over 8 years now on the PT will _never_ make it off it :-((((

[Orion Pobursky]

I fear that my parts, sitting for over 8 years now on the PT will _never_ make it off it :-((((

Don't worry, my oldest part from 2002! was just released last update.

[Tore Eriksson]

I mildly disagree with you, but at the same time agree.

I agree with you that these files shouldn't burden the PT. Like I already said, my general opinion is that they should be unofficial, just like my Boxed parts. But if the LDraw community decides that they should be official, I won't stand in the way - but OTOH I won't be very active to push them through the PT either. Maybe I'll supply an LDS file to help them being produced automatically if anyone asks me to. And of course I agree that it would be better to work on the already existing pile.

And no, it's not a matter of DOS 8.3. (Well, maybe 5% or less it is. At least for me.) It's about trying to keep those LDraw lines to one line when printing out the code. It's about not having to make wider and wider columns in file lists (like parts.lst for example).

[Willy Tschager]

the visual gain will be there only in very special usecases,
but the work will be gigantic, and the memory impact will be big,
as well as parsing time increase, polygon count etc.

Nod.

w.

[Chris Dee]

I don't like the idea of unofficial libraries, since we could inadvertently break them with changes to the official library.

Currently we have three "officially supported" levels of rendering, which are only applied to studs (a high polygon count component of large models/scenes):
- regular 16-agonal stud primitives - p/stud.dat, p/studn.dat and studnn.dat
- low-res (fast-draw) octagonal stud primitives - p/stu2.dat, p/stu2n.dat and stu2nn.dat
- a zero-res (superfast-draw) primitive - p/studline.dat (although I'm not sure if any tool since ldraw.exe has supported this)

The p/4864 folder also gives LDView (at least) the ability to provide on-the-fly hi-res substitution of primitives that it recognises. This folder also serves as a primitive resource for large parts that benefit from the additional polygon count.

We could extend the "official support" for stud rendition to four levels and use this to incorporate the baseplate underside details:

- Create hi-res stud*.dat primitives in ldraw/p/4864 - these could be an official sanction of the "LEGO" logo studs.

- Define a new "studNN" for the baseplate underside dimple. In ldraw/p this would just be a 20LDu x 20LDu quad, but in ldraw/p/4864 it would be a complete modelling of the dimple. The increased polygon count of rectangles could be overcome by defining "stud groups" for the common multiples. These would just be large quads (rather than a matrix of studNN.dat) and would thus have minimal impact on polygon count at regular resolution.

This proposal does depend on implementation support in the rendering tools. So LDView, for example, would need to used stud primitives from the ldraw/p/4864, if found, rather than substituting at the 4-4cyli, 4-4disc level.

At the same time, it might be wise to straighten out the anomoly of low-res studs being identified by a naming convention by creating a ldraw/p/8 folder and moving existing stu2*.dat primitives to ldraw/p/8/stud*.dat .

Comments welcome.

[Orion Pobursky]

I like this idea lot. I have a few comments that I'll post later when I'm not at work but I thought it important to throw my hat into the ring now.

[Travis Cobbs]

I have a few comments. First of all, it's p/48, not p/64 (very minor point). A bigger point is that the baseplates with underside studs are completely differently modeled from the others since they use big polygons for their entire top and bottom surfaces (minus the rounded corners), and then just stick the studs on top of the top one. So baseplates have to have completely different versions in order for this to work. Splitting the existing baseplates over to using the updated baseplate stud dimple would introduce a huge amount of extra geometry.

[Tore Eriksson]

I don't like the idea of unofficial libraries, since we could inadvertently break them with changes to the official library.

8<---

Comments welcome.

Ok, I revise my suggestion.
Why not make the /D library official but optional?

[Steffen]

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

[Chris Dee]

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.

[Steffen]

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.

[Chris Dee]

Did you have some further thoughts?

[Willy Tschager]

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.

w.