Re: [Gnuplot-info] maxima + gnupolot: 3D rendering bug?

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

Ethan Merritt wrote:
> On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote:
> 
>>Hello,
>>
>>On Tue, 2010-12-07 at 15:42 +0000, Stanislav Maslovski wrote:
>>
>>>On Tue, 2010-12-07 at 11:51 +0000, Stanislav Maslovski wrote:
>>>
>>>>Hello,
>>>>
>>>>Can anyone advise me on how can I workaround the problem with 3D
>>>>rendering in the plot [1]? The problem is that the surfaces that must be
>>>>hidden are seen in this plot (to clearly see them,
>>>>load "maxout.gnuplot" and try rotating the plot).
>>>>
>>>>The plot was generated in maxima, using the draw3d command. Any help
>>>>will be very much appreciated!
>>>>
>>>>[1] http://zalil.ru/30094104 (wait 10 secs, and download will start)
>>>
>>>Replying to myself: actually, after reading some docs (and the code) I
>>>realized that it was a limitation of the rendering algorithm used by the
>>>gnuplot (a variant of painter's algorithm). So, I solved this issue by
>>>patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles
>>>was done based on the average depth of 4 corners.
> 
> 
> I don't think this is the best way to approach the problem.
> As Hans-Bernhard pointed out, _any_ simple-minded sorting on a 
> single Z value is going to fail for some configuration of triangles.
> The bigger the triangle, the more likely that any single Z value is not
> right for the whole thing.
> 
> I suggest that a better approach would be to add a pass that splits large
> triangles into smaller pieces before sorting and rendering.
> The only tricky part is how to define "large".   
> [OK, there's potentially another tricky part if you are coloring by
> something other than Z since you have to decide how to assign colors
> to the newly created vertices.]
> 
> You can probably find sample code for this kind of divide-and-conquer
> approach in a textbook or article, but it should be simple enough to
> work it out from scratch.

The rendering of the 3D surfaces doesn't cut it.  I tried very hard myself to come up with a good compromise, but it seemed there was no good approach for the general case.  (Some examples would look good, others not.)  What Ethan is suggesting might help (or not, depending on the example perhaps), but that still isn't the answer.

I had reached the conclusion that implementing the rendering by determining intersections of surfaces pretty much as defined might be the best place to put effort.  It was just after I had looked at the 2D mesh code that had some boundary issues.  The 2D code looks for intersections of lines and then breaks those lines up.  If one thinks in terms of vectors and matrices (i.e., linear algebra formulas), keeping things straight is not too difficult.  The same would apply for 3D surfaces.  Look for intersecting surfaces and then break those up--being 3D there are a lot of cases and the result will be a growth in code, but one just has to be organized about it.

The "painter algorithm" works for a first pass, i.e., if there is not intersection along the depth, (or width or height) for two particular triangles, then there is no way there can be intersections and no need to check.  That will speed processing significantly.

Actual 3D rendering would be a nice addition.  Might make for a good little project one of these days.

Dan