Re: Hidden3d Bug Fix

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

Daniel J Sebald wrote:

> [5]  The sort_edges_by_z() shouldn't be necessary in the quad-tree 
> version of the code since there isn't a speed-up test hinged on the 
> order of edges. However, it doesn't hurt things and in fact it helps.  I 
> tried without it and got pretty much the same results but in some 
> circumstances a line will show through.  The reason is described in [6], 
> but in any case, I've left the sort as is.

Actually, the sorting of edges doesn't appear to be critical in the quad-tree 
compilation.  With that edge sort removed there seems to be a small speedup for 
bigger meshes, but not significant.

What I am seeing was actually always there in the glass.dat example, which is 
the seam at the start and end of a scan line that shows through.  I entered that 
as a bug in SourceForge but I'm not sure what can be done with that.  Maybe add 
something that if V_EQUAL() on two vertices tests true replace the vertex with 
the previous?

What might be worth a change in terms of speed up is to make the quad tree 
granularity dynamic and have it be on the order of the isosamples setting in 
both x and y directions.  I have a Gaussian 2D plot in which I set the 
isosamples to 60.  By changing the granularity from 10 to 50 there is a speed 
improvement of about 40%.

Also, I'm still wondering if for larger meshes, say iso_x * iso_y > 500, we 
should have the mouse 3D rotation turn off hidden lines until the user lets go 
of the mouse button at which point the hidden line version is drawn again. 
Otherwise panning is so choppy.

Dan