virtualmeet wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> Well, that's the problem: You are tesselating the isosurface, POV-Ray
>> doesn't. POV-Ray wouldn't benefit from your optimizations because they
>> can be used only when tesselating the isosurface.
> Hi,
> I know that the 3 steps in generating images by PovRay doesn't have clear
> frontiers like in thoses used in K3DSurf. However, it seems to me that
> everything can be splitted that way: If we don't see it, that's because we
> aren't used to it.
> How about changing the raytracing technique to make it able to treat 64 rays
> at the time? Is it really impossible to imagine that process ? I don't think
> so...

Your code does *NOT* render an isosurface!!! It is a simple voxel algorithm,
something not even closely related to an isosurface defined by a function.
As i told you very early on, you can already do exactly that in POV-ray with
the density file/function feature. The fact remains it is a *different*
algorithm that is *not* related to isosurfaces. As I have also explained
multiple times now, it does *not* make sense to implement isosurfaces based
on a voxel array. If you trace 64 or one ray is completely irrelevant, as
you voxel array will not be faster to traverse if you use one ray or 64 at a
time.

Warp and I have now multiple times explained things, and you keep repeating
the same incorrect statements. What you say just has neither head nor tail
when applied to ray tracing. In fact the algorithm you describe isn't even
the best scan-line rendering algorithm for voxels.

Please, first understand how ray tracing works in general, what isosurfaces
actually are, how intersection with isosurfaces are computed, and after all
that you will realise your misconceptions. Please!

	Thorsten

Post a reply to this message