|
|
|
|
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: (simple?) Isosurface patch request
Date: 14 Aug 2004 09:58:52
Message: <411e1a9b@news.povray.org>
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>> [...]
>>
>>>which will work
>>>well in cases like these where the accuracy is much smaller than the
>>>features of the isosurface function anyway
>>>
>>
>> This is correct. If you really want the _isosurface_ of a function to get
>> plottet in a numerically usable way, you need to have
>> "accuracy" < "characteristic surface feature grain size".
>
> Your numbers what factor you can reduce the accuracy settings are quite
> wild guesses. It depends on how well the linear interpolation
> approximates the real change of the function in the final interval.
>
This is certainly correct. That's why I put the "well-behaved" in there :)
It turns out that the "wild guesses" are fulfilled quite good for smooth
if one is rendering the Mars topography since the function in question
is a linearly interpolated image map itself.
> If
> it does this badly you won't have such a gain (factor 10 would already
> be extremely good).
>
Yes. But OTOH it is _very_ unlikely to get below factor 2.
(And actually no reason not to use it.)
> Also note the normal vector calculation uses the
> accuracy value as well so by increasing the accuracy setting you also
> influence the calculation of the normal vector.
>
Yes, I saw that because my initial guess for the reson of the black dots
was problems in the numerical differentiaion. And actually, numerical
diff is one of the most critical things. There simply isn't a perfect
solution for the problem -- especially no cheap one.
> Sure, some time.
>
Well... "some time"...
Do you mean I need to code it myself if I want functionality like that
this year?
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
>
>>Sure, some time.
>>
>
> Well... "some time"...
> Do you mean I need to code it myself if I want functionality like that
> this year?
I don't know but don't conclude from the fact that the technique can be
explained in a few paragraphs that it is simply to implement.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
<snip>
> What Christoph said here and in the previous posting is certainly correct.
> Once a isosurface root is found, the linear interpolation step gives us
> a better guess of the true postion of the root (expect one or two orders
> of magnitude for well-behaved functions).
> This means:
> (1) It is not meant as a way to generate bevel edges.
I understand this. But if we *can* get bevelled edges using higher
accuracy values, why not let people use it that way? My preliminary
tests (without the patch) indicate that a simple min(..) of two
functions can be bevelled, saving lots of csg-coding time. Incidentally,
it would render faster, too, because of the high accuracy values.
> (2) It cannot make black regions disappear which occur because of
> not found roots (such as missed roots due to incorrect max_gradient).
I don't have this problem. Some people might, but I seem to always be
able to find the right max_gradient early on.
> (3) It does greatly improve the actual surface accuracy. While the current
> code will have the real root depth within the specified accuracy, the
> patched code will have it within 1/10 to 1/100 (typ.) of the accuracy.
> This in turn means, that one can render equally-well images with smaller
> accuracy and hece faster. See below, too.
This is what's really frustrating me.... I know the patch is better when
it comes to accuracy. With the 'official' isosurface, we have to use
accuracy values which are MUCH SMALLER than the needed 'grain size', or
resolution of the isosurface to rid ourselves of the black dots.
> (4) The black dots on my images are IMO due to the shadow rays (i.e. the
> ones from the light source to the object) come _really_ flat above
> the surface. I did no detailed investigation on why exactly the black dots
> disappear with my patch. However, a linear interpolation after a bisection
> algorithm is the most common way to go numerically and there is no reason
> why we should not do that here.
Can I give you an example isosurface statement, to test my theory on
this? I've seen the problems; I believe your patch fixes them. If we
break even on render time, so be it. A fix is a fix.
>>but this can't be
>>generalized. A two times speedup in all isosurface renders because of
>>this change is illusory.
>>
>>
> Not for "all" but for "a lot of real-life relevant" isosurfaces.
> And after all, I cannot see major disadvantages from using it.
I can only see advantages.
> BTW, talking about isosurface speed, I very much like the idea of your
> patch presented here:
> http://www-public.tu-bs.de:8080/~y0013390/fast_iso/patch.html
>
> Will this patch be made available sometimes somewhere (such as in
> the next megapov version)?
>
> Wolfgang
*Sigh* I wish I knew how to compile POV's source code... :c/
-Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge wrote:
>
> This is what's really frustrating me.... I know the patch is better when
> it comes to accuracy. With the 'official' isosurface, we have to use
> accuracy values which are MUCH SMALLER than the needed 'grain size', or
> resolution of the isosurface to rid ourselves of the black dots.
>
You should really better show an example. Black dots are nearly always
an indication of unsuccessful root finding and then this patch would not
help as explained.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: (simple?) Isosurface patch request
Date: 14 Aug 2004 14:23:29
Message: <411e58a0@news.povray.org>
|
|
|
| |
| |
|
|
Samuel Benge wrote:
> I understand this. But if we *can* get bevelled edges using higher
> accuracy values, why not let people use it that way?
>
Well... it would (again) be some sort of "art produced by numerical
errors in the solver".
I certainly won't keep you from doing such things and it's great if
it works for you.
However, don't yell at us if things break in the next version. Numerical
algorithms typically give results which are only exact up to some certain
error (i.e. accuracy). And it is no good idea to rely on a special behaviour
of the numerical error.
>> (3) It does greatly improve the actual surface accuracy. While the current
>> code will have the real root depth within the specified accuracy, the
>> patched code will have it within 1/10 to 1/100 (typ.) of the accuracy.
>> This in turn means, that one can render equally-well images with smaller
>> accuracy and hece faster. See below, too.
>
> This is what's really frustrating me.... I know the patch is better when
> it comes to accuracy. With the 'official' isosurface, we have to use
> accuracy values which are MUCH SMALLER than the needed 'grain size', or
> resolution of the isosurface to rid ourselves of the black dots.
>
The actual accuracy improvement depends on the function used.
It seems you did not completely understand the grain size argument.
If you look at the isosurface (mathematically!) of a function, this can be
very smooth (like a billard ball) strongly grainy (like a sponge).
In order to get a useful representation of the isosurface, you normally
need an accuracy value which is smaller than the characteristic grain
size. This is necessary to make sure that the first root along the
light ray is actually found (and not any root). This is independent of
my patch.
landscape), are very smooth and hence the "grain size" is large and
you could use a fairly large accuracy value. So, here we find the correct
(i.e. first) root easily but the result for the ray depth of the root may
be displaced from the real location by the amount of accuracy. And here
comes the patch: By linearly interpolating, this guess for the actual
location of the root between the last two evaluation points can be
"greatly" improved.
How much depends on the function used. For very smooth functions
(especially the mars topo which is itself a linearly interpolated function),
you can gain the mentiones factor 10 to 100. For other less smooth
functions it will be less and for really rough ones we won't win anything
but also not lose anything.
> Can I give you an example isosurface statement, to test my theory on
> this? I've seen the problems; I believe your patch fixes them. If we
> break even on render time, so be it. A fix is a fix.
>
Well, feel free to post or send me the SDL code in question. I'll give it a
run (unless it takes ages :).
> *Sigh* I wish I knew how to compile POV's source code... :c/
>
tar xfj povray-3.6.1.tar.bz2
./configure COMPILED_BY=your_name
make
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Samuel Benge wrote:
>
>>
>> This is what's really frustrating me.... I know the patch is better
>> when it comes to accuracy. With the 'official' isosurface, we have to
>> use accuracy values which are MUCH SMALLER than the needed 'grain
>> size', or resolution of the isosurface to rid ourselves of the black
>> dots.
>>
>
> You should really better show an example. Black dots are nearly always
> an indication of unsuccessful root finding and then this patch would not
> help as explained.
>
> Christoph
Okay, the example image has been uploaded to p.b.i. I gave three
examples in png format, each one having a different accuracy value.
Also, the isosurface has smooth and rough surfaces combined for obvious
reasons. The code for the example is below. You might want to uncomment
the max_gradient and use very high values, to conclude the artifacts
shown are not related to max_gradient. Also, I encourage both you and
Wolgang to try this in the patched version. I'd like to see the results.
-Sam
// Begin Code
global_settings{
assumed_gamma 1
}
#default{ finish{ ambient 0 } }
camera{
fisheye
right x*.5 up y*.5
//right x*.5*1.33 up y*.5
location< 0, 20, -30 >
look_at 0
angle 14
}
background{ rgb<.3 .4 .5> }
light_source{<1,2,-.95>*100000,<1 1 .8>*2 }
#declare tex=
function{
pattern{
granite
}
}
isosurface {
function{
min(
max( // cube
abs(x),
abs(y),
abs(z)
)-1,
max(
sqrt(y*y+z*z)-.75, // cylinder
abs(x)-2
)+tex(x,y,z)/10 // rough surface
)
}
accuracy .05 // .01 // .001
//max_gradient 100
evaluate 0.6, 1.8, 0.95
contained_by{
box{
<-2.1,-1.1,-1.1>,
<2.1,1.1,1.1>
}
}
pigment{ rgb 1 }
rotate y*35
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge wrote:
>
> Okay, the example image has been uploaded to p.b.i. I gave three
> examples in png format, each one having a different accuracy value.
> Also, the isosurface has smooth and rough surfaces combined for obvious
> reasons. The code for the example is below. You might want to uncomment
> the max_gradient and use very high values, to conclude the artifacts
> shown are not related to max_gradient. Also, I encourage both you and
> Wolgang to try this in the patched version. I'd like to see the results.
>
What you see on the front face of the box are exactly the explained
shadow ray noise effects you also see on Wolfgang's samples caused by
tangential lighting. The surface is always found reliably, just if it
is in shadow or not varies. Since these surfaces result from a
precisely linear function the linear interpolation leads to perfect
results here for arbitrary accuracy values (on the faces, not near the
edges and only within the accuracy of floating point numbers of course).
Since you usually won't use tangential lighting in real scenes for such
flat surfaces i moved the light source a bit. I also changed
max_gradient to 4 (the real maximum gradient of the function seems just
above 3). Here are the results:
no interpolation:
http://www.tu-bs.de/~y0013390/files/sam_test1_o05.png
http://www.tu-bs.de/~y0013390/files/sam_test1_o01.png
http://www.tu-bs.de/~y0013390/files/sam_test1_o001.png
with Wolfgang's patch:
http://www.tu-bs.de/~y0013390/files/sam_test1_i05.png
http://www.tu-bs.de/~y0013390/files/sam_test1_i01.png
http://www.tu-bs.de/~y0013390/files/sam_test1_i001.png
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>What you see on the front face of the box are exactly the explained
>shadow ray noise effects you also see on Wolfgang's samples caused by
>tangential lighting. The surface is always found reliably, just if it
>is in shadow or not varies. Since these surfaces result from a
>precisely linear function the linear interpolation leads to perfect
>results here for arbitrary accuracy values (on the faces, not near the
>edges and only within the accuracy of floating point numbers of >course).
>Since you usually won't use tangential lighting in real scenes for
such >flat surfaces i moved the light source a bit.
Umm, I see this a lot, actually. The more complex a shape becomes, the
more these 'tangental lighting' artifacts appear. They happen on curved
surfaces, too, but with less obvious striation. I hate having to move my
light_source so often, but at least it's a fix for the flat surfaces...
>I also changed max_gradient to 4 (the real maximum gradient of the
>function seems just above 3). Here are the results:
>no interpolation:
>http://www.tu-bs.de/~y0013390/files/sam_test1_o05.png
>http://www.tu-bs.de/~y0013390/files/sam_test1_o01.png
>http://www.tu-bs.de/~y0013390/files/sam_test1_o001.png
>with Wolfgang's patch:
>http://www.tu-bs.de/~y0013390/files/sam_test1_i05.png
>http://www.tu-bs.de/~y0013390/files/sam_test1_i01.png
>http://www.tu-bs.de/~y0013390/files/sam_test1_i001.png
>Christoph
Wow. Those results look encouraging. It's much like I suspected: edges
no longer have that jagged look. The chopped-up surface is now smooth.
Some spots still appear, though. I'm sure in time all such artifacts
will be resolved.
Have you tried both patches (yours and Wolfgang's) combined yet? With AA?
-Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge wrote:
>
> Wow. Those results look encouraging. It's much like I suspected: edges
> no longer have that jagged look. The chopped-up surface is now smooth.
> Some spots still appear, though. I'm sure in time all such artifacts
> will be resolved.
???
To me the difference seems very minor, not even close to 10x the
accuracy value leading to the same result quality.
Just in case this was not clear: the 'i' samples are with the patch, the
'o' ones without (like with official POV-Ray 3.6).
> Have you tried both patches (yours and Wolfgang's) combined yet? With AA?
What patch of mine are you referring to? The isosurface bounding tree
patch has nothing to do with this.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Samuel Benge wrote:
>
>>
>> Wow. Those results look encouraging. It's much like I suspected: edges
>> no longer have that jagged look. The chopped-up surface is now smooth.
>> Some spots still appear, though. I'm sure in time all such artifacts
>> will be resolved.
>
>
> ???
>
> To me the difference seems very minor, not even close to 10x the
> accuracy value leading to the same result quality.
That's because you seem to be bent on using really low accuracy
settings, or something. All I'm implying is that it's not necessary to
use such low accuracy values all the time... it actually seems 'safe'
not to now, with the new patch.
> Just in case this was not clear: the 'i' samples are with the patch, the
> 'o' ones without (like with official POV-Ray 3.6).
It was clear, thanks.
>> Have you tried both patches (yours and Wolfgang's) combined yet? With AA?
>
>
> What patch of mine are you referring to? The isosurface bounding tree
> patch has nothing to do with this.
>
> Christoph
I guess if you believe linear interpolation patch won't help speed up
isosurface rendering significantly, you might say that.
-Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|