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

[Stanislav M. <sta...@gm...>]

Hello,

On Thu, 2010-12-09 at 12:11 -0800, Ethan Merritt wrote:
> On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote:
> > > 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.

Yes, I agree. That was just the first thing I tried and it worked for my
task. However, until a better rendering algorithm is available, I still
suggest including my patch because it makes the depth sorting
configurable which certainly helps in some cases (while keeping the same
default behavior). The reasoning behind this is purely practical: 1)
configurability of depth sorting can be useful with sparse datasets; 2)
all the infrastructure that my patch relies upon is already in the code
(in the realization of corners2color option).

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

I was thinking about exactly the same thing, but then realized that
there is already the "interpolate" option that does (almost) the same.
But sometimes we want to look at a dataset _without_ smoothing it,
right?

--
Stanislav