POV-Ray : Newsgroups : povray.programming : Which code evaluate Math functions (ie: isosurfaces) ? : Re: Which code evaluate Math functions (ie: isosurfaces) ? Server Time
27 Apr 2024 02:44:15 EDT (-0400)
  Re: Which code evaluate Math functions (ie: isosurfaces) ?  
From: virtualmeet
Date: 16 Feb 2007 18:55:00
Message: <web.45d642fef1edfe3ee9d7399f0@news.povray.org>
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> I still doubt that this would really benefit POV-Ray, because I doubt
> that the various functions such as sqrt or cos are called very often
> with the same exact input.  And if it isn't called with the same input,
> you'd still have to evaluate the function.
Hi,
You're right about the reuse for predefined fcts values : This process is
not garanted like with a voxel grid. Also, we have a few informations about
points to evaluate : there number and exact locations aren't known (we know
"only" that they are in the same line), so it needs more work than with the
grid.
However, I belive that we can improve the raytracing process in many ways by
using a grid of voxels:
I think that surfaces sampling by the marching cube and the raytrce can have
the same first process which consist on locating the isosurface in 3D space.
The divergence came after that process: I'm using the marching cube to
generate triangles of the surface but we can easily imagine using the
raytrace technic to do the job "inside" every voxel...
What I mean is that we can use a grid of voxels to minimise the 3D space and
after that use the raytrace technic to finish the job: mainly the grid will
reduice the cube to a "tick" isosurface.
I don't know if someone else have done this before but the closest idea I
found is here : http://www.imagico.de/fast_iso/patch.html (Christoph's
page).
Where Christoph use an octree, I'll use a predefined grid and push the
resolution to height level to reduice the final use of the raytrace.
I have one question thought: is there a reference to something like that in
the net? if not, then i think that something is preventing such use because
it's more easy to imagine that process than the octree process...

> why don't you branch the 3.6 codebase, try it out, and let us
> know if it works?
I already started to look at the code but I have to say that it will took
time before I start to be familliar with the entire code: hopefully I'll
find an easy way to prevent all that process.
Cheers,
Taha


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.