Wolfgang Wieser wrote:
>>
>>What you describe seems to be specific to shadow rays, does your
>>suggested change also influence the appearance of the actual surface
>>(i.e. camera rays). You could try rendering with a fairly large accuracy
>>value for testing.
>>
> 
> Well, in iso code there is no difference between viewing and shadow rays. 
> The in_shadow_test flag is never actually used except for some cache 
> which is handeled at a higher level and should not matter here. 

So what?

My question was if your change makes a difference to the appearance of 
an isosurface despite possible effects on shadow ray tests.  This is 
best to test with high detail surface features of a size similar to the 
accuracy value.

>>I agree with Thorsten that the interpolation will probably cause
>>slowdown without much advantage 
>>
> 
> I am not sure about that. Because the gain in accuracy is considerably.

Note this is not a real gain in accuracy - it would be if the function 
value changed linearly between the two points but obviously it does not 
in most cases.  A comparitive test with raising accuracy and using your 
technique vs. current technique with low accuracy value would be necessary.

>[...]
> should work as well (and does for my scenes). All the other conditions 
> are just to work around conditions which I am not sure about. 

You should at least test with the most common special situations (use in 
CSG, view of the isosurface from inside, high gradient functions etc.).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Thorsten Froehlich wrote:
> 
> Yes, there are vi, then there are the vi clones and improvements.  Then
> there is this editor that is its own operating system (you know which one I
> am talking about), there are improved versions of it.  

Actually in *this* editor it is quite possible to customize the settings 
to a large extent, in most cases you just need to set:

tab-width
indent-tabs-mode

according to what you need.

(Not to mention that you can of course quickly re-indent a whole file if 
someone else has messed it up)

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:

> My question was if your change makes a difference to the appearance of
> an isosurface despite possible effects on shadow ray tests.  This is
> best to test with high detail surface features of a size similar to the
> accuracy value.
> 
I don't know. But since you are the isosurface expert around here, 
it would be nice if you could have a look at it and run some tests. 

>>>I agree with Thorsten that the interpolation will probably cause
>>>slowdown without much advantage
>>>
>> I am not sure about that. Because the gain in accuracy is considerably.
> 
> Note this is not a real gain in accuracy - it would be if the function
> value changed linearly between the two points but obviously it does not
> in most cases.  A comparitive test with raising accuracy and using your
> technique vs. current technique with low accuracy value would be
> necessary.
> 
It _is_ generally a real gain as long as 
- you use steady functions, i.e. functions with finite gradient which is 
  what you always do and 
- the function does not change very much in scale of accuracy. 

So it is a gain for nearly all real-life scenes. And for such things 
like high micro-details on the surface, it should at least not do 
worse. 

>>[...]
>> should work as well (and does for my scenes). All the other conditions
>> are just to work around conditions which I am not sure about.
> 
> You should at least test with the most common special situations (use in
> CSG, view of the isosurface from inside, high gradient functions etc.).
> 
Could you please?

Wolfgang

Post a reply to this message

In article <403e78b2@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
wrote:

> The idea is that in case we cross the isosurface threshold and 
> one point is outside (EP1) while the other one is inside (EP2), 
> then the average of the two depth values should give a better 
> estimate for the actual intersection than merely using EP2. 

Linear interpolation is a pretty common last step in the bisection 
algorithm...I did it for the blob2 object, I wasn't aware the isosurface 
object didn't do it.

This is also close to the regula falsi or false secant method. The idea 
with this method is that when you have a pair of points that bracket a 
root, approximate the function as linear within that interval and use 
the computed root as the new splitting point. It is similar to Newton's 
method, but doesn't require a derivative of the function. It converges 
faster than bisection in most cases, but is only guaranteed to converge 
if you start out with a bracketed root. I've considered using a variant 
of this as a second stage to the isosurface root solver...use bisection 
to locate the roots to within a certain crude precision, and then use 
regula falsi to refine the roots.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> This is also close to the regula falsi or false secant method. The idea 
> with this method is that when you have a pair of points that bracket a 
> root, approximate the function as linear within that interval and use 
> the computed root as the new splitting point. It is similar to Newton's 
> method, but doesn't require a derivative of the function. It converges 
> faster than bisection in most cases, but is only guaranteed to converge 
> if you start out with a bracketed root. I've considered using a variant 
> of this as a second stage to the isosurface root solver...use bisection 
> to locate the roots to within a certain crude precision, and then use 
> regula falsi to refine the roots.

I am quite sure you will miss some intersections this way (cases where 
the function is negative only in a very small interval along the ray and 
is positive otherwise for example).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <cfh### [at] tritonimagicode>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> I am quite sure you will miss some intersections this way (cases where 
> the function is negative only in a very small interval along the ray and 
> is positive otherwise for example).

You also miss roots with the bisection method. This is just one of the 
things you have to deal with when finding roots numerically.

However, if the function is monotonic on the interval you start with, 
either entirely increasing or entirely decreasing, there is only one 
root possible and this method will only tighten the interval closer to 
the root. If you break the function up into small enough intervals, for 
example with the variant of the bisection method the current solver 
uses, losing roots is rarely a problem. Neither method will find roots 
where the function just touches 0 without crossing it, though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

> In article <403e78b2@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> The idea is that in case we cross the isosurface threshold and
>> one point is outside (EP1) while the other one is inside (EP2),
>> then the average of the two depth values should give a better
>> estimate for the actual intersection than merely using EP2.
> 
> Linear interpolation is a pretty common last step in the bisection
> algorithm...I did it for the blob2 object, I wasn't aware the isosurface
> object didn't do it.
> 
To see the actual accuracy improvement achieved by my patch, I 
finally made some comparative renderings with different accuracy 
settings using a "Water on Mars" test scene. 

Details here: 
http://www.cip.physik.uni-muenchen.de/~wwieser/tmp/poviso.html#accuracy

Wolfgang

Post a reply to this message

Sorry for buggin' again, but the following two sentences
seem to contradict each other, don't they ?

 > You _should_ always use tabs for indention because
 > [...] anybody can adjust the
 > indention depth on his own editor to fit his needs.

>> [me] and to break long lines before the 80th caracter.
> Me too. Because it is dangerous if one cannot see what gets clipped away 
> on the right and uneasy to navigate when the lines are folded.

	That is: how can you always guaranty the line-break to occur before
the (on-screen) 80th caracter using variable-length-customized tabs ?

	- NC

Post a reply to this message

In article <404323a9$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>  > You _should_ always use tabs for indention because
>  > [...] anybody can adjust the
>  > indention depth on his own editor to fit his needs.
>
>>> [me] and to break long lines before the 80th caracter.
>> Me too. Because it is dangerous if one cannot see what gets clipped away
>> on the right and uneasy to navigate when the lines are folded.
>
>  That is: how can you always guaranty the line-break to occur before
> the (on-screen) 80th caracter using variable-length-customized tabs ?

If you still use 80 character per line terminals to edit text, you have
worse problems than tabs! ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> In article <404323a9$1@news.povray.org> , Nicolas Calimet
> <pov### [at] freefr>  wrote:
> 
>>  That is: how can you always guaranty the line-break to occur before
>> the (on-screen) 80th caracter using variable-length-customized tabs ?
> 
Easy. 
I am using tabwidth 4, so it is sufficient to make sure that lines 
do not get cut off on the right when using tabwith 4. 

> If you still use 80 character per line terminals to edit text, you have
> worse problems than tabs! ;-)
> 
If you hadn't used the smiley I'd probably say that sometimes it is 
of great advantage to _think_ prior to posting. :)

Because even if I can zoom my editor to width >=160, I prefer to 
be able to have 2 to 4 windows non-overlapping on the same screen. 
And because I do not want lines to get cut off at the right (too 
dangerous to overlook something), I need to use some horiz. limit. 
(Because I do not like folded lines.)

But I'd prefer not to discuss indention and window sizes but isosurface 
accuracy instead. Did anybody with some more isosurface experience 
and aproptiate test scenes on the hd have a run?
Even if, from my presence on this news server, I deduced the rule of 
thumb that "no response is good response". 

Wolfgang

Post a reply to this message