POV-Ray : Newsgroups : povray.advanced-users : Isosurface speed : Isosurface speed Server Time
6 Oct 2024 13:18:00 EDT (-0400)
  Isosurface speed  
From: Orchid XP v3
Date: 28 Aug 2006 10:05:15
Message: <44f2f81b$1@news.povray.org>
I have an isosurface that's making my 2.2 GHz Athlon64 cry. Currently 
averaging just 40 pixels/second - and that's just for the *black* 
pixels! I hate to think what it will slow down to if it ever gets to the 
part with some surface in it...

The real killer is that it's actually a very simple (I might even say 
"boring") shape I'm trying to trace. It's essentially a Z-shaped oval 
pipe. That's it.

However, since it's the isosurface of a 18th degree polynomial, I've had 
to set max_gradient=exp(18) to get it to render correctly.

In layman's terms, the problem is simple. Because the *maximum* gradient 
of the function is extremely high, POV-Ray is densely sampling all of 
space (even the completely empty parts) just in case there's some 
surface there. In fact, it just so happens that the edges of the 
bounding box are where the function is steepest; where the surface is, 
the function is fairly shallow.

And so, I've been sitting here thinking about all the ways POV-Ray could 
arrive at its result faster. The trouble is, I can think of quite a few 
that would work for *this* shape, but would fail in special cases. It 
just so happens that the shape I'm trying to trace has a huge max 
gradient, but is actually a very simple shape.


One idea is if POV-Ray were to cache the locations of previously 
discovered surface points. Then instead of densely sampling the entire 
length of a ray, you would only need to sample "around" where the last 
surface was found.

This instantly fails when you reach a nearer edge that should occlude 
the previously-found surface. POV-Ray would *still* need to densely 
sample all the way back towards the camera to check it's found the 
*nearest* surface point. (Also, a cache lookup would have to end up 
being quicker than just calculating samples...)


Another idea is to do a little prepass stage where POV-Ray builds up a 
low-res 3D map of the surface, so it has some idea where to start 
looking when tracing a ray. You start by finding a surface point - ANY 
surface point - and then finding other surface points near to it, until 
you have covered the entire surface with a loose grid of points. Doing 
it this way avoids the edge problem, because you "follow" the surface 
round before you even start tracing.

This instantly fails if the surface is not completely connected. It also 
fails if the grid points are too far apart to pick up small details. 
(You would need something like a max_complexity number telling POV-Ray 
how "messy" the surface is, and hence how fine a grid to use.)


Yet another idea (similar to the previous one) is to split all of space 
into a grid of cubic volumes, and attempt to figure out which cubes 
actually contain some surface, and which ones are completely empty.

Once again, this doesn't work well for disconnected surfaces. How will 
you tell if a cube contains anything? POV-Ray would need to know the 
minimum possible size of a feature to look for... And then how would you 
actually look for it? We could end up doing more work here then what we 
do currently!


In short, lots of ideas that would work for the shape I'm trying to 
trace, but none that would work for every possible shape one could try 
to trace.

Anybody have any further thoughts?


Post a reply to this message

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