Baseplate underdetailing was Re: LDView Bug

Re: LDView Bug
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.
« Next Oldest | Next Newest »

Messages In This Thread
Re: LDView Bug - by Jean-Philippe Ouellet - 2012-01-16, 22:46
Re: LDView Bug - by Tim Gould - 2012-01-16, 22:50
Re: LDView Bug - by Jean-Philippe Ouellet - 2012-01-16, 23:56
Re: LDView Bug - by Tim Gould - 2012-01-17, 2:13
Re: LDView Bug - by Philippe Hurbain - 2012-01-17, 8:16

Forum Jump:

Users browsing this thread: 1 Guest(s)