Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Monday 15 January 2007 00:01, Daniel J Sebald wrote:
> 
>>Anything wrong with the following approach?
> 
> 
> Please go back and read the 2005 discussion.

In 1077726 patch?  I read it.


> As I understood the argument, the whole point of the "pm3d hidden3d" option
> was the cleverness of doing the border tracing at the same time as the pm3d
> fill. This gives you the [admittedly imperfect] hidden-surface removal
> essentialy for free.

Well, it really isn't hidden3d.  I'd prefer the name "tileline" or something like that.  And then use the name "hidden3d" to mean exactly what appears in the documentation.


> Yes, you could do a better job on the lines by handling them in the true
> hidden3d code instead (I had a patch to do that, but I cannot recall if I
> circulated it).  But it's much slower.

Actually, I'm not sure it is much slower.  As implemented right now, hidden line removal on Kuen is pretty fast, whereas the pm3d variant is noticably slower.  Granted, one may have an order complexity greater than the other for increasing N.  Something about pm3d is slow right now.

Even still, a nice, correct plot for the user is the end goal.  If they want to use a mode (say "depthorder" plus "tileline") for a quick rough idea, and then generate a correct, but slow plot (i.e., "hidden3d" turned on) for publication or presentation, that would be very nice.

What you suggest is the correct approach to take and road to follow.  Hidden 3D has it's level of complexity:  surface element covering point (fairly easy), surface element covering line (difficult), surface covering surface (very difficult).  But the mathematical constructs between methods are related I would think.  I suspect good estimates would result from augmenting line removal.  That is, as one goes along and makes decisions about surfaces in conjunction with line removal there is more info available than the current depth order scheme.  Relationship to neighboring elements is information that can be used whereas if all you have are list of surface elements and faced with the problem of correctly ordering them options are limited.

I would probably take an object oriented approach.  Ultimately one would like a list of points, lines and surfaces intermingled in the proper plotting order.  Also, tag each element as hidden or not.  (In the case of lines, I think hidden3d breaks them up, so there is no idea of a "partially hidden" line.  In the case of surfaces, "hidden" would not include the class of partially hidden.  I don't think we want to go to the complexity of breaking up surfaces.  It's consequences are minimal for the same reason depth ordering works OK.)  That way, one can toss out hidden lines for the effect as seen in so many demos.  Or the hidden lines can be retained for the purposes of the transparent solids feature.

>  Given the difference in speed, and
> the fact that the pm3d rectangles themselves still cannot be ordered
> perfectly, it was judged a net loss rather than a gain.

Had I been paying more attention at the time, I probably would have argued that slowness isn't an issue.  Again, having both options fast/guesstimate and slow/estimate is fine in my opinion so long as it is made clear to the user what the distinction is.


 It doesn't do
> much good to get the bounding line occlusions right if the rectangles
> themselves stick out where they shouldn't.

This Kuen example is one where colors of incorrect ordered quadrangles is so close to the ones it is interchanged with that it would hardly be noticable.  If the colors of the quadrangles were that drastically different, then they probably would not have been mis-ordered.

> 
> On the other hand, I was disappointed at the time that we didn't pursue 
> the complementary option of allowing inclusion of pm3d rectangles in the
> true "set hidden3d" code path.  For all the reasons that Hans-Bernhard
> enumerated, rectangle-rectangle occlusions still would not be handled
> correctly in the general case.  Certainly it is not going to help the
> Kuen's surface rendering much.

Actually, I think it might.  The first example of Kuen I sent showed an improvment when I used a "surface cover point" approach; still some flaws.  But "surface cover line" is more robust in terms of correctly estimating overlap.  And the second example of Kuen I sent showed that in fact appears to have corrected the flaws that still remained in my "surface cover point" approach.  (Note the couple comments I made about hidden line removal in the previous post.)

Dan