LDraw.org Discussion Forums
Baseplate underdetailing was Re: LDView Bug - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Baseplate underdetailing was Re: LDView Bug (/thread-3095.html)

Pages: 1 2 3


Baseplate underdetailing was Re: LDView Bug - Chris Dee - 2012-01-16

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.


Re: LDView Bug - Jean-Philippe Ouellet - 2012-01-16

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:
[Image: WRD30.png]
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:
[Image: 0DLR3.png]
And compare it to the real thing:
[Image: IxKEq.jpg]

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.


Baseplates with underdetails was Re: LDView Bug - Tim Gould - 2012-01-16

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


Re: LDView Bug - Tim Gould - 2012-01-16

Jean-Philippe Ouellet Wrote:(I've never seen baseplates not on the ground in any real-life model).

[Image: metro2.jpg]

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

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


Re: LDView Bug - Jean-Philippe Ouellet - 2012-01-16

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 Tongue


Re: Baseplates with underdetails was Re: LDView Bug - Steffen - 2012-01-17

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.)


Re: Baseplates with underdetails was Re: LDView Bug - Jean-Philippe Ouellet - 2012-01-17

Steffen Wrote:(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:
[Image: pvs8Z.jpg]
everywhere there is a stud, there is one of those bottom things.

Steffen Wrote:parsing time increase
Just as with stud groups, this is negligible.

Steffen Wrote: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.


Re: LDView Bug - Tim Gould - 2012-01-17

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

Tim


Re: Baseplates with underdetails was Re: LDView Bug - Tim Gould - 2012-01-17

Steffen Wrote:(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


Re: LDView Bug - Philippe Hurbain - 2012-01-17

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