Re: ***[Possible UCE]*** Re: surface elements for transparent_solids.dem

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

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
> 
>>Hmm, might there be a slight alteration of this that would work
>>"better"? 
> 
> 
> No.  The whole idea of "depth sorting" is fundamentally flawed.  No 
> slight alteration can make it work correctly.  The only real effect a 
> slight alteration will have is to move the errors to a different region 
> of parameter space, i.e. replace a known-bad guess by an unknown one.

Depth sorting with something like qsort() is fundamentally flawed.  The assumption of equality is a problem in a sort like that.  If "does not overlap" is assigned to the equality class, a = b (a and b don't overlap) and b = c (b and c don't overlap) does not imply a = c (a and c might overlap).


>>Rather than carrying out a bubble sort on depthorder, couldn't we
>>carry out a bubble sort on "covered by"?
> 
> 
> No --- because "covered by" isn't a proper ordering criterion.  Cyclic 
> obstruction from view is possible with as little as three triangles in 
> the scene.  And surface patch can intersect each other, share edges or 
> vertices, and do various other kinds of "special case" things that are 
> hard to think of before-hand.

Well, what you are saying is generally true.  However, such an approach might (repeat might, I'm trying it out right now) work for samplings which do not have the property you mention, and this could be a broad class.  If every element only covers elements that do not lead back to cover the original element, I can imagine a valid sorting method (but again, sorts based upon a notion of equality won't do it).

What I'm saying is that even though we are using an approximation to "ray tracing" (for lack of phrase, i.e., the correct solution) we might be able to improve the current approximation and get good results in a high number of cases.

I have some ideas.  More later.


>>Anyway, it shouldn't be too difficult to write a routine, given two
>>elements that establishes draw order for the scenarios above.
> 
> 
> Oh, it _is_ difficult.  If you don't believe my words, believe the code 
> I wrote to implement hidden3d, or get yourself a textbook on 3D computer 
> graphics.

Yes.  I've been trying out a few things and then came to the conclusion that the problem of determinining if two general convex surfaces in 3-space overlap is deceptively difficult.  I then started looking to some research-oriented stuff on the topic and learned a bit about this.

Dan