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