Hello, all who frequent this group, and greetings to Wolfgang Weiser. 
I'm sorry if this request has been made by someone else; I made a real 
effort to avoid asking an already-answered question. It doesn't appear 
this is available for Windows.

My request is simple. It involves having somebody compile the POV-Ray 
3.6 for Windows executable, and for a certain piece of the code to be 
altered.

The patchwork is already done. On his webpage,
http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/patches/isoacc-patch/ 

Wolfgang describes what seems to be a perfect fix for a common problem 
with rendered isosurfaces: black spots and 'chopped up' surfaces. He 
shows which piece of POV source must be altered to allow "linear 
interpolation after the final bisection step." The results are astounding.

Normally, we are forced to lower the accuracy to make such artifacts 
disappear. This leads to longer render times and sharper edges. 
Sometimes we don't want sharp edges at all. This new patch presents us 
with a two-in-one improvement for isosurface rendering. I believe his 
code will allow us to turn an ordinary isosurface cube into a bevelled 
isosurface cube.... simply by raising the accuracy. A bevelled cube 
which renders (theoretically) faster than a sharp-edged cube!

Now, if somebody were to compile this patch, I have a kind of 
compensation planned. I will test techniques (using the patch) and 
create an HTML documenting my efforts. It will be conclusive no matter 
what: either we have another technique for bevelling iso objects, or it 
didn't work, because artifacts still appear. I doubt the artifacts will 
be too noticable, though. The page will be published either by me, or 
somebody with a more stable webspace.

I don't want to tear anybody away from 'POVComp time', but if the 
isosurface improvement is as good as I think it is, it will make POV 
look a LOT better when all the entries come streaming in. Faster 
isosurfaces :)

-Sam

Post a reply to this message

Samuel Benge wrote:
> 
> The patchwork is already done. On his webpage,
> http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/patches/isoacc-patch/ 
> 
> Wolfgang describes what seems to be a perfect fix for a common problem 
> with rendered isosurfaces: black spots and 'chopped up' surfaces.

That is not true.  Black spots on isosurfaces can have multiple reasons, 
the most common being an insufficient max_gradient.  The idea of using 
interpolation for the final root position is good but it is not a 
panacea for all kind of isosurface problems.  In other words it will 
only improve the results if the isosurface root finder has already 
successfully found the root.

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:
> 
>>
>> The patchwork is already done. On his webpage,
>> http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/patches/isoacc-patch/ 
>>
>> Wolfgang describes what seems to be a perfect fix for a common problem 
>> with rendered isosurfaces: black spots and 'chopped up' surfaces.
> 
> 
> That is not true.  Black spots on isosurfaces can have multiple reasons, 
> the most common being an insufficient max_gradient.  The idea of using 
> interpolation for the final root position is good but it is not a 
> panacea for all kind of isosurface problems.  In other words it will 
> only improve the results if the isosurface root finder has already 
> successfully found the root.
> 
> Christoph


I understand this, but did you look at the comparison images? 
Interpolation after the last step 'glues' the isosurface together, so it 
doesn't have holes that really shouldn't be there in the first place. 
The isosurface renders up to (and more than) two_times_faster. His patch 
sure seems like a bug fix to me.

Max_gradient issues are, IMO, easy to fix. You raise the max_gradient. 
Done. No amount of that, however, can fix problems not related to 
insufficient max_gradient values....

-Sam

Post a reply to this message

Samuel Benge wrote:
>>
>> That is not true.  Black spots on isosurfaces can have multiple 
>> reasons, the most common being an insufficient max_gradient.  The idea 
>> of using interpolation for the final root position is good but it is 
>> not a panacea for all kind of isosurface problems.  In other words it 
>> will only improve the results if the isosurface root finder has 
>> already successfully found the root.
> 
> I understand this, but did you look at the comparison images? 
> Interpolation after the last step 'glues' the isosurface together, so it 
> doesn't have holes that really shouldn't be there in the first place. 
> The isosurface renders up to (and more than) two_times_faster. His patch 
> sure seems like a bug fix to me.

No, the examples Wolfgang shows on his page show the patch improving the 
results in cases of self shadowing and intersecting surfaces.  None of 
the samples shows a case where the root is not found reliably (no holes 
in any of the images).

There is no speedup either but a slight slowdown in fact, the faster 
results are due to the use of a higher accuracy value which will work 
well in cases like these where the accuracy is much smaller than the 
features of the isosurface function anyway but this can't be 
generalized.  A two times speedup in all isosurface renders because of 
this change is illusory.

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:
>>>
>>> That is not true.  Black spots on isosurfaces can have multiple
>>> reasons, the most common being an insufficient max_gradient.  The idea
>>> of using interpolation for the final root position is good but it is
>>> not a panacea for all kind of isosurface problems.  In other words it
>>> will only improve the results if the isosurface root finder has
>>> already successfully found the root.
>> 
>> I understand this, but did you look at the comparison images?
>> Interpolation after the last step 'glues' the isosurface together, so it
>> doesn't have holes that really shouldn't be there in the first place.
>> The isosurface renders up to (and more than) two_times_faster. His patch
>> sure seems like a bug fix to me.
> 
> No, the examples Wolfgang shows on his page show the patch improving the
> results in cases of self shadowing and intersecting surfaces.  None of
> the samples shows a case where the root is not found reliably (no holes
> in any of the images).
> 
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. 
(2) It cannot make black regions disappear which occur because of 
   not found roots (such as missed roots due to incorrect max_gradient). 
(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. 
(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. 

> There is no speedup either but a slight slowdown in fact, 
>
Well, the overhead can really be neglected. 

> the faster results are due to the use of a higher accuracy value
>
("higher value" = "less accuracy", i.e. 1e-3 instead of 1e-5)
>
> 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". 

It seems that you are/were using hyper fine structure in some landscape/... 
renderings with structure size about as large as accuracy (?). 
But from the numerical point of view, this does not make much sense. 
It's more like "art produced by numerical errors from the solver" in case 
it is visible at all. 

> 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. 

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

Post a reply to this message

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.  If 
it does this badly you won't have such a gain (factor 10 would already 
be extremely good).  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.

> 
> 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 

Sure, some time.

> (such as in 
> the next megapov version)?

No.

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:
> 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 
functions like the solutions of the Schrödinger equation and especially 
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

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. 

However, lots of functions (the Schrödinger equation or the marsian 
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

Samuel Benge wrote:

> 
> I guess if you believe (the) linear interpolation patch won't help speed up 
> isosurface rendering
>

Post a reply to this message

Samuel Benge wrote:
>>
>> 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.

I have no idea how you come to this conclusion, to me

http://www.tu-bs.de/~y0013390/files/sam_test1_o01.png

looks much better than:

http://www.tu-bs.de/~y0013390/files/sam_test1_i05.png

and it only uses 5 times the accuracy value.  I am using exactly the 
accuracy values you proposed (x05 meaning accuracy 0.05).

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:
> with Wolfgang's patch:
> 
It's nice to see that you're actually using it (sometimes at least) ;))

Wolfgang

Post a reply to this message

Christoph Hormann wrote:
> I have no idea how you come to this conclusion, to me
> 
> http://www.tu-bs.de/~y0013390/files/sam_test1_o01.png
> 
> looks much better than:
> 
> http://www.tu-bs.de/~y0013390/files/sam_test1_i05.png
> 
...but 
  http://www.tu-bs.de/~y0013390/files/sam_test1_i01.png
looks better than 
  http://www.tu-bs.de/~y0013390/files/sam_test1_o01.png
doesn't it?

BTW, we're not talking about what _looks_ better but what matches 
the actual surface better. 
I'm saying this because of the different looks of the grainy cylinder. 
Seems the grain size is in the order of the accuracy. 

>Since you usually won't use tangential lighting in real scenes for such 
>flat surfaces 
>
Well, I think this argument won't help. Imagine an animation where 
the object is moved relative to the light (rotation e.g.)...

When I think that we would not have all that discussion if R. Suzuki had 
thought of the linear interpolation himself, then it's probably a good time 
to say good night and go to bed... :)

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:

> ...but 
   http://www.tu-bs.de/~y0013390/files/sam_test1_i01.png
> looks better than 
   http://www.tu-bs.de/~y0013390/files/sam_test1_o01.png
> doesn't it?
> 
> BTW, we're not talking about what _looks_ better but what matches 
> the actual surface better. 
> I'm saying this because of the different looks of the grainy cylinder. 
> Seems the grain size is in the order of the accuracy. 


I'm curious to see how the code below would look (close up), with the 
new patch. The lack of interpolation is very clear, I think:

 

isosurface {
  function{
   max(
    abs(x)-2,
    abs(y)-1,
    abs(z)-1,
    -(max(abs(x)-1,-y)),
    -(sqrt(pow(y-1,2)+z*z)-.5)
   )
  }
  accuracy .1
  max_gradient 2
  contained_by{box{<-2.1,-1.1,-1.1>,<2.1,1.1,1.1> }}

  rotate y*35
  pigment{
   bumps
   scale .125 translate<-2,1,0>
   color_map{[0 rgb 1][1 rgb .3]}
  }
}

 
>>Since you usually won't use tangential lighting in real scenes for such 
>>flat surfaces 
>>
>>
> Well, I think this argument won't help. Imagine an animation where 
> the object is moved relative to the light (rotation e.g.)...
> 
> When I think that we would not have all that discussion if R. Suzuki had 
> thought of the linear interpolation himself, then it's probably a good time 
> to say good night and go to bed... :)
> 
> Wolfgang

*sigh* I may have to learn how to compile soon...


-Sam

Post a reply to this message

Wolfgang Wieser wrote:

> 
>>*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


I don't understand this. Does this mean I can download the source, and 
somehow extract some compressed files with the changed code?

-Sam

Post a reply to this message

Samuel Benge wrote:
>>
>> BTW, we're not talking about what _looks_ better but what matches the 
>> actual surface better. I'm saying this because of the different looks 
>> of the grainy cylinder. Seems the grain size is in the order of the 
>> accuracy. 

No, we are talking about what looks better.  Of course it has to 
resemble the actual model to look good but even some quite significant 
difference is acceptable as long as it looks reasonable.

And what you are referring to as 'grain' is simply the pattern function 
used.  The appearance of the cylinder is completely correct in all 
versions and does not profit much from the patch (the random differences 
are mostly due to aliasing).

> 
> I'm curious to see how the code below would look (close up), with the 
> new patch. The lack of interpolation is very clear, I think:

That's a good example, i rendered them in larger:

http://www.tu-bs.de/~y0013390/files/sam_test2o.png
http://www.tu-bs.de/~y0013390/files/sam_test2i.png

As clearly visible the patch only interpolates the t value (the distance 
of the intersection from the camera) it does nothing more!  Therefore 
most artefacts are still there.  Note the black areas are - as assumed 
previously - mostly caused by the use of the high accuracy values for 
normal calculation as well.  If i just use 1/10 of the value for the 
normal they are gone:

http://www.tu-bs.de/~y0013390/files/sam_test2s.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:

> Samuel Benge wrote:
> 
>>>
>>> BTW, we're not talking about what _looks_ better but what matches the 
>>> actual surface better. I'm saying this because of the different looks 
>>> of the grainy cylinder. Seems the grain size is in the order of the 
>>> accuracy. 
>>
> 
> No, we are talking about what looks better.


In the end, yes.

> Of course it has to 
> resemble the actual model to look good but even some quite significant 
> difference is acceptable as long as it looks reasonable.
> 
> And what you are referring to as 'grain' is simply the pattern function 
> used. The appearance of the cylinder is completely correct in all 
> versions and does not profit much from the patch (the random differences 
> are mostly due to aliasing).


Even the texturing seems to become chopped up with the [discontinuous] 
surface, but it's not really noticable with low accuracy values.

 
>>
>> I'm curious to see how the code below would look (close up), with the 
>> new patch. The lack of interpolation is very clear, I think:
> 
> 
> That's a good example, i rendered them in larger:
> 
> http://www.tu-bs.de/~y0013390/files/sam_test2o.png
> http://www.tu-bs.de/~y0013390/files/sam_test2i.png
> 
> As clearly visible the patch only interpolates the t value (the distance 
> of the intersection from the camera) it does nothing more!  Therefore 
> most artefacts are still there.


It looks like only part of the problem has been fixed with that 
patch.... like there's still another opportunity for interpolation 
somewhere. Is there a bit of code which specially controls edge calculation?

> Note the black areas are - as assumed 
> previously - mostly caused by the use of the high accuracy values for 
> normal calculation as well.  If i just use 1/10 of the value for the 
> normal they are gone:
> 
> http://www.tu-bs.de/~y0013390/files/sam_test2s.png
> 
> Christoph


The surface still looks 'sliced up' (for lack of better description), 
but yes, the black spots are gone.

I don't know how the isosurface is calculated, so I can't really give 
super-useful input here.... but it's like the backside of the isosurface 
isn't taken into account, so the edges have nothing to 'tie' to, or 
interpolate with... they are just left hanging there. Or maybe they ARE 
interpolated with the backside, and the artifacts just happen to be jagged.

At any rate, thank you for satisfying my curiosity on this, Christoph! I 
think Wolfgang's patch is still a step forward, but not quite a step all 
the way towards making isosurfaces useful with high accuracy values.

-Sam

Post a reply to this message

Christoph Hormann wrote:

> Samuel Benge wrote:
>>>
>>> BTW, we're not talking about what _looks_ better but what matches the
>>> actual surface better. I'm saying this because of the different looks
>>> of the grainy cylinder. Seems the grain size is in the order of the
>>> accuracy.
> 
> No, we are talking about what looks better.  Of course it has to
> resemble the actual model to look good but even some quite significant
> difference is acceptable as long as it looks reasonable.
> 
Probably this is an attitude based on LOTW and the like. 
People who want to plot physical/mathematical functions (like me) 
may see that differently...

> And what you are referring to as 'grain' is simply the pattern function
> used.  
>
Actually, "grain" just wanted to express what part of the image I was 
talking about. Of course, I knew that the surface was pertubed by the 
granite pattern. 

> The appearance of the cylinder is completely correct in all 
> versions and does not profit much from the patch (the random differences
> are mostly due to aliasing).
> 
If you look carefully, you see that in the unpatched version, part of 
the surface appears to be further apart from the camera. 
Which is, of course, clear. 

> As clearly visible the patch only interpolates the t value (the distance
> of the intersection from the camera) it does nothing more!  
>
[ There is nothing new in this statement. Everybody who reads the patch 
code should immediately see this... :p ]

> Therefore 
> most artefacts are still there.  Note the black areas are - as assumed
> previously - mostly caused by the use of the high accuracy values for
> normal calculation as well.  If i just use 1/10 of the value for the
> normal they are gone:
> 
As mentioned by me earlier, I also first thought "my" black points are caused 
by incorrect normal calculation; this is something which could also still be 
improved. 

The current normal calculation algo has two principal problems: 

(1) It uses no symmetric ("leap-frog" / central) diff like (f(x+h)-f(x-h))/(2h) 
    but (f(x)-f(x-h))/h which has the advantage that 2 fewer 
    function evaluations are needed but the disadvantage that the error 
    is of order O(h) instead O(h^2). 
    If we use central differencing, the image already looks better as can 
    be seen here: 
http://www.cip.physik.uni-muenchen.de/~wwieser/tmp/files/test-central.png

(2) The value h is chosen more or less arbitrarily to equal accuracy. This is 
    not necessary a good approach since the bisection solver can 
    calculate very small accuracies but leading digit cancellation will 
    increasingly spoil the gradient derivation for normal calculation. 
    If we keep the accuracy at 0.1 but use h=0.01 for the normal calc, 
    then the image looks like that: 
http://www.cip.physik.uni-muenchen.de/~wwieser/tmp/files/test-0.1.png

Wolfgang

Post a reply to this message

>> tar xfj povray-3.6.1.tar.bz2
>> ./configure COMPILED_BY=your_name
>> make

> I don't understand this. Does this mean I can download the source, and 
> somehow extract some compressed files with the changed code?
No, but you can apply the changes yourself, as they are clearly listed 
on Wolfgang's homepage. Do it like that:

1. Download the official 3.6.1 sources from the POV-Ray-website
2. uncompress it using "tar xfj povray-3.6.1.tar.bz2"
3. apply the changes he describes on his webpage (Section "The Patch")
4. Make sure you're in the directory where you uncompressed the sources 
to and compile them by doing "./configure COMPILED_BY=your_name" 
followed by "make"
5. You have now a compiled version of the patched POV-Ray in the same 
directory.

This all assumes you're on Linux/Un*x/etc. Dunno about Windows...


HTH,
Florian

Post a reply to this message