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