|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: (simple?) Isosurface patch request
Date: 14 Aug 2004 17:52:18
Message: <411e8991@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: (simple?) Isosurface patch request
Date: 14 Aug 2004 18:02:40
Message: <411e8bff@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: (simple?) Isosurface patch request
Date: 16 Aug 2004 16:42:33
Message: <41211c38@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Florian Brucker
Subject: Re: (simple?) Isosurface patch request
Date: 21 Aug 2004 09:07:52
Message: <41274928@news.povray.org>
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |