When you see that "holey" effect- it appears that there are steps or holes
in the isosurface and you have to increase the max_trace value to help eliminate
them.  I have had a few do that and curing it steps up the render time a lot.
What is the source of that anyway?  You may be the right person to tell me.

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

light_source{0#macro k(_)sphere{13*z+i*_.5pigment{agate}finish{phong.3}}#end
1}#macro _(s,i,g)#if(s)k(1)k(-1)_(s-1i+g,g)#end#end _(3x+3*y<2,-2>)_(2x,y)_(
2x-y,x)_(4x*3,-y)_(4<3,1>x)_(2x*6,-y)

Post a reply to this message

On Thu, 11 Apr 2002 17:22:27 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> I have never seen anything like this when working with isosurfaces, could
> you give an example?

perhaps he means something like http://www.abx.art.pl/pov/nonlinear/twist.jpg
but it of course is my fault becouse object pattern in megapov was used

ABX

Post a reply to this message

Slime wrote:
> 
> Sure, you can go ahead and store the information that "a ray from this point
> hit the isosurface at this point", but the chances of another ray ever
> hitting that same point from the same direction are extremely tiny. Even if
> you did encounter another ray that passed through that point, you'd still
> have to test if it hits the isosurface before it reaches that point.
> 
> Remember, we're not dealing with pixels, we're dealing with an infinite
> number of points in three dimensional space.

It's not that hopeless, you could store all function values evaluated and
use them later for new rays, together with the known max_gradient you can
reduce the number of necessary new function evaluations this way, but you
would have to design efficient methods and data structures for accessing
the stored values and the memory requirements can be enormous.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 18 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Sir Charles W. Shults III" wrote:
> 
>     When you see that "holey" effect- it appears that there are steps or holes
> in the isosurface and you have to increase the max_trace value to help eliminate
> them.  I have had a few do that and curing it steps up the render time a lot.
> What is the source of that anyway?  You may be the right person to tell me.

I can only assume you are having problems with max_gradient and accuracy,
apart from that i don't know about any general problems with the
appearance of isosurface objects.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 18 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Hugo" <hua### [at] post3teledk> wrote in message
news:3cb5791a@news.povray.org...
> Well I'm not into the source code, but what about to precalculate just the
> bit of isosurface, that is currently rendering? I mean, POV-Ray renders
> pixel by pixel, line by line. For each pixel, many things has to be done,
> but it shouldn't be necessary to calculate the surface, for that pixel,
more
> than once.. I wonder if it's calculated many times, since some objects
like
> iso's takes much longer.
>
> (I know this idea wouldn't provide a cache for transparant or reflected
> objects. Those would have to be recalculated.)

A mosaic preview using something like adaptive sampling could speed up an
isosurface ;)
This would only be effective if the isosurface took only a small portion of
it's contained_by object.  Test all four corners of a box, and use those for
ray tests within a certain distance of the box(es).
This could be adapted to allow reflection/transparency.
--
__________________
 RAY

Post a reply to this message

> It's not that hopeless, you could store all function values evaluated and
> use them later for new rays, together with the known max_gradient you can
> reduce the number of necessary new function evaluations this way, but you
> would have to design efficient methods and data structures for accessing
> the stored values and the memory requirements can be enormous.

True.

Chances are, unfortunately, that using these remembered sample points would
only make the render time longer.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

Wow, I didn't expect this much response!  Thank you to everyone who 
has responded.  OK, so basically the problem is that an Isosurface 
requires more time to calculate the effects of a ray, and radiosity 
shoots many rays, so the combination of Isosurface and Radiosity = SLOW.  
<smile>
    	Maybe I need to optimize my Isosurfaces?  I'm not sure they can be 
though, they're fairly simple; I've shown one at the end of this message.  
The other six Isosurfaces in the scene are identacle except for the 
scaling in the two functions.  Can this be optimized for speed at all?
    	Or maybe a better question; can objects be excluded from the 
radiosity calculations??  I could group these with a shadowless fill 
light if I can get them to be ignored by radiosity.
    	These rocks are part of a reef tank picture I'm trying to put 
together...  an example of the WIP is attached.


#declare Rough = function { pigment { wrinkles scale 0.75 } }
#declare Rock = function { x*x + y*y + z*z - 1 }

isosurface {
   function { Rock(x/3,y,z/2) + Rough(x+1,y+0.2,z+3.2).gray*.75 }
   contained_by{sphere{0,2}}
   threshold 0
   accuracy 0.001
   max_gradient 5.884
   texture { rockTex }
   scale 4 
   translate <0,2,-16>
} 


Thanks again for all of the responses!

-- 
Rich Allen
(Remove SPAM from my address to reply by e-mail)

Post a reply to this message

Attachments:
Download 'Tank.jpg' (36 KB)

Preview of image 'Tank.jpg'

Rich wrote:
> 
> [...]
> 
> #declare Rough = function { pigment { wrinkles scale 0.75 } }
> #declare Rock = function { x*x + y*y + z*z - 1 }
> 

For 'Rock' you should use the internal 'f_sphere' function from
functions.inc because it's faster and has a constant gradient (like when
using 'sqrt(x*x + y*y + z*z) -1')

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 11 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Understood

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

light_source{0#macro k(_)sphere{13*z+i*_.5pigment{agate}finish{phong.3}}#end
1}#macro _(s,i,g)#if(s)k(1)k(-1)_(s-1i+g,g)#end#end _(3x+3*y<2,-2>)_(2x,y)_(
2x-y,x)_(4x*3,-y)_(4<3,1>x)_(2x*6,-y)

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in 
news:3CB69939.DA52425D@gmx.de:

> For 'Rock' you should use the internal 'f_sphere' function from
> functions.inc because it's faster and has a constant gradient (like when
> using 'sqrt(x*x + y*y + z*z) -1')

  Cool, I'll try that tonight.  Thanks!

-- 
Rich Allen
(Remove SPAM from my address to reply by e-mail)

Post a reply to this message