 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Andrew C on Mozilla who wrote:
>Isosurfaces... wonderful things, aren't they?
>
>At the present moment, I have one that's going increadibly slowly.
>That's probably because of the huge max_gradiant required to draw it.
>But it surely doesn't help that I have to explain the function I want
>POV-Ray to draw in a very inefficient way...
>
> * * *
>
>Suppose I have a macro like this:
>
>#macro Fn1(x, y, z)
> #declare A = sin(x) * cos(y) * tan(z);
> #declare B = sqrt(x*y / z);
> #declare C = exp(log(x)*y - z);
>
> (A*B - C)*(tan(A+B)-log(C))
>#end
>
>Now, suppose I wanted to draw an isosurface of that. (I completely made
>up the function - I imagine it's not very interesting to look at!) The
>only way I can think of to draw it is something like this:
>
>#declare Fn1 =
>{
> ( (sin(x) * cos(y) * tan(z))*sqrt(x*y / z) - exp(log(x)*y - z) ) *
>(tan(sin(x) * cos(y) * tan(z) + sqrt(x*y / z)) - log(exp(log(x)*y - z)) )
>}
>
>Notice how A, B and C have to be calculated *TWICE*...
>
>Is there any way round this??
>
>Andrew @ home.
I don't think so.
If you write
#declare A = function {sin(x) * cos(y) * tan(z)}
#declare B = function {sqrt(x*y / z)}
#declare C = function {exp(log(x)*y - z)}
#declare Fn1 = function {(A(x,y,z)*B(x,y,z) - C(x,y,z))
*(tan(A(x,y,z)+B(x,y,z))-log(C(x,y,z)))}
I believe that POV still calculates A B and C twice. It certainly takes
quite a bit longer to render the surface when it's written this way than
when you write
#declare Fn1 = function {
( (sin(x) * cos(y) * tan(z))*sqrt(x*y / z) - exp(log(x)*y - z) ) *
(tan(sin(x) * cos(y) * tan(z) + sqrt(x*y / z)) - log(exp(log(x)*y - z))
)}
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <GqstUBAz6c$AFwBa@econym.demon.co.uk> , Mike Williams
<nos### [at] econym demoncouk> wrote:
> I believe that POV still calculates A B and C twice. It certainly takes
> quite a bit longer to render the surface when it's written this way than
> when you write
You can "use" the sum/prod functions to create temporary real variables.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew C on Mozilla wrote:
> Isosurfaces... wonderful things, aren't they?
>
> At the present moment, I have one that's going increadibly slowly.
> That's probably because of the huge max_gradiant required to draw it.
> But it surely doesn't help that I have to explain the function I want
> POV-Ray to draw in a very inefficient way...
>
> * * *
>
> Suppose I have a macro like this:
>
> #macro Fn1(x, y, z)
> #declare A = sin(x) * cos(y) * tan(z);
> #declare B = sqrt(x*y / z);
> #declare C = exp(log(x)*y - z);
>
> (A*B - C)*(tan(A+B)-log(C))
> #end
>
> Now, suppose I wanted to draw an isosurface of that. (I completely made
> up the function - I imagine it's not very interesting to look at!) The
> only way I can think of to draw it is something like this:
>
> #declare Fn1 =
> {
> ( (sin(x) * cos(y) * tan(z))*sqrt(x*y / z) - exp(log(x)*y - z) ) *
> (tan(sin(x) * cos(y) * tan(z) + sqrt(x*y / z)) - log(exp(log(x)*y - z)) )
> }
>
> Notice how A, B and C have to be calculated *TWICE*...
>
> Is there any way round this??
Yes. I once presented a solution to this.
It's halfway down in this message:
http://tinyurl.com/3f642
http://news.povray.org/povray.text.scene-files/message/%3C3fbe6e34%40news.povray.org%3E/#%3C3fbe6e34%40news.povray.org%3E
"My favourite isosurface (see p.b.i. for image)", 21. Nov. 2003
There's source code and more information in the rest of that thread:
http://tinyurl.com/6glf6
http://news.povray.org/povray.text.scene-files/thread/%3Cweb.3fbbe555cd7b5c811235fd70%40news.povray.org%3E
Started by Alex Kluchikov 19. Nov. 2003
--
Tor Olav
http://subcube.net
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew C on Mozilla wrote:
...
> #declare C = exp(log(x)*y - z);
...
Hmmm... That looks suspicious.
Are you aware that you are using the base 10 logarithm here ?
Use ln(x) for the natural logarithm.
--
Tor Olav
http://subcube.net
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> ...
>
>> #declare C = exp(log(x)*y - z);
>
> ...
>
> Hmmm... That looks suspicious.
>
> Are you aware that you are using the base 10 logarithm here ?
>
> Use ln(x) for the natural logarithm.
Oh, yeah, sure... it's not a real function, I just typed randomly to
make an example.
Andrew @ home.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> #declare Fn1 =
>> {
>> ( (sin(x) * cos(y) * tan(z))*sqrt(x*y / z) - exp(log(x)*y - z) ) *
>> (tan(sin(x) * cos(y) * tan(z) + sqrt(x*y / z)) - log(exp(log(x)*y - z)) )
>> }
>>
>> Notice how A, B and C have to be calculated *TWICE*...
>>
>> Is there any way round this??
>
>
> Yes. I once presented a solution to this.
>
> It's halfway down in this message:
>
> http://tinyurl.com/3f642
>
http://news.povray.org/povray.text.scene-files/message/%3C3fbe6e34%40news.povray.org%3E/#%3C3fbe6e34%40news.povray.org%3E
Aaaahhhh.... I seeeee..... If a pass a variable into a second function,
POV-Ray calculates the value to pass ONCE, and then passes it, and it
can then be used multiple times within the second function... excellent!
The *real* function I want to render is recursive... POV-Ray reports
412K tokens. (!!) If I can figure out how to do it this way, it will
hopefully parse raster and render lots faster too... (Will probably have
to use the file-I/O directives to write an SDL file, then #include it
back in.)
Thanks for that!
Andrew @ home.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew C on Mozilla wrote:
...
> Aaaahhhh.... I seeeee..... If a pass a variable into a second function,
> POV-Ray calculates the value to pass ONCE, and then passes it, and it
> can then be used multiple times within the second function... excellent!
Yes, you've got it.
=)
> The *real* function I want to render is recursive... POV-Ray reports
> 412K tokens. (!!) If I can figure out how to do it this way, it will
> hopefully parse raster and render lots faster too... (Will probably have
> to use the file-I/O directives to write an SDL file, then #include it
> back in.)
In this post you can find macros that build a function
recursively:
http://tinyurl.com/5d473
http://news.povray.org/povray.text.scene-files/message/%3C3C9F86D5.778C126F%40hotmail.com%3E/#%3C3C9F86D5.778C126F%40hotmail.com%3E
"Code for NURBS surfaces as mesh2{} objects ", 25. Mar. 2002
(Look at the DeCasteljau_U() and BlendUFunction() and macros.)
First I had special versions of these macros that wrote the
function to a SDL file, but for higher order NURBS functions
this quickly became ugly (i.e. HUGE files). So I let POV-Ray
assemble these functions directly.
I guess that you are working on your fractal functions. If you
don't want to generate these functions recursively, then you
might find this post (and thread) interesting:
http://tinyurl.com/6nthl
http://news.povray.org/povray.advanced-users/message/%3CXns93AC374E6D9E5torolavkhotmailcom%40204.213.191.226%3E/#%3CXns93AC374E6D9E5torolavkhotmailcom%40204.213.191.226%3E
"Re: Use of povray functions to make fractals other than
"famous" Mandelbrot with same scalability? ", 2 Jul. 2003
> Thanks for that!
Just glad to help.
--
Tor Olav
http://subcube.net
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Aaaahhhh.... I seeeee..... If a pass a variable into a second
>> function, POV-Ray calculates the value to pass ONCE, and then passes
>> it, and it can then be used multiple times within the second
>> function... excellent!
>
>
> Yes, you've got it.
>
> =)
I tried it today in my lunch break. It *seems* to go very very much
faster this way - this WITH a higher max_gradient...
(I also figured out how to use the select() function to terminate the
iteration sequence as soon as possible. It actually make the render many
times SLOWER - until I changed it to return a positive number rather
than 0 when it "bails out". Then it was lots faster!)
>> The *real* function I want to render is recursive... POV-Ray reports
>> 412K tokens. (!!) If I can figure out how to do it this way, it will
>> hopefully parse raster and render lots faster too... (Will probably
>> have to use the file-I/O directives to write an SDL file, then
>> #include it back in.)
>
>
> I guess that you are working on your fractal functions.
Yup.
> If you
> don't want to generate these functions recursively, then you
> might find this post (and thread) interesting:
>
> http://tinyurl.com/6nthl
>
http://news.povray.org/povray.advanced-users/message/%3CXns93AC374E6D9E5torolavkhotmailcom%40204.213.191.226%3E/#%3CXns93AC374E6D9E5torolavkhotmailcom%40204.213.191.226%3E
Aahhh... use an *array* of functions... I wasn't sure if you could
actually do that... yes, that saves writing an include file and reading
it back... great!
>> Thanks for that!
>
> Just glad to help.
Maybe you should do it for a living. ;-)
Out of interest... is there a document anywhere that explains the messy
details of how POV-Ray's isosurface drawing system actually works?
(Other than the source code of course. :-P)
Thanks.
Andrew @ home.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew C on Mozilla wrote:
...
>> If you
>> don't want to generate these functions recursively, then you
>> might find this post (and thread) interesting:
>>
>> http://tinyurl.com/6nthl
>>
http://news.povray.org/povray.advanced-users/message/%3CXns93AC374E6D9E5torolavkhotmailcom%40204.213.191.226%3E/#%3CXns93AC374E6D9E5torolavkhotmailcom%40204.213.191.226%3E
>
>
>
> Aahhh... use an *array* of functions... I wasn't sure if you could
> actually do that... yes, that saves writing an include file and reading
> it back... great!
Yes that's one possible solution. But you can also make a
recursive macro that assembles the function directly without
using an include file. (Like the ones in my NURBS code.)
I guess that functions built the latter way will be faster,
because calling other functions within a function takes time.
>>> Thanks for that!
>>
>>
>> Just glad to help.
>
>
> Maybe you should do it for a living. ;-)
Hehe - I have been working as a math and electronics teacher
for the last half year. Now I'm looking for a new job.
> Out of interest... is there a document anywhere that explains the messy
> details of how POV-Ray's isosurface drawing system actually works?
> (Other than the source code of course. :-P)
Christoph Hormann has written a little about this:
http://www-public.tu-bs.de:8080/~y0013390/fast_iso/patch.html
On that page you'll also find a link to a news posting where
Ryoichi Suzuki gives a brief explanation of the algorithm he
used.
Apart from this I haven't seen anything.
- But reading a little about numerical analysis won't hurt :)
(Especially about root finding methods.)
--
Tor Olav
http://subcube.net
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Aahhh... use an *array* of functions... I wasn't sure if you could
>> actually do that... yes, that saves writing an include file and
>> reading it back... great!
>
>
> Yes that's one possible solution. But you can also make a
> recursive macro that assembles the function directly without
> using an include file. (Like the ones in my NURBS code.)
>
> I guess that functions built the latter way will be faster,
> because calling other functions within a function takes time.
Yeah, but the whole point is that passing a value to another function
allows me to reuse a number multiple times without recalculating it...
>>>> Thanks for that!
>>>
>>> Just glad to help.
>>
>> Maybe you should do it for a living. ;-)
>
> Hehe - I have been working as a math and electronics teacher
> for the last half year. Now I'm looking for a new job.
Hmm... fair enough!
>> Out of interest... is there a document anywhere that explains the
>> messy details of how POV-Ray's isosurface drawing system actually
>> works? (Other than the source code of course. :-P)
>
> Christoph Hormann has written a little about this:
>
> http://www-public.tu-bs.de:8080/~y0013390/fast_iso/patch.html
>
> On that page you'll also find a link to a news posting where
> Ryoichi Suzuki gives a brief explanation of the algorithm he
> used.
>
> Apart from this I haven't seen anything.
> - But reading a little about numerical analysis won't hurt :)
> (Especially about root finding methods.)
Right... so... essentially, POV-Ray starts with the segment of the ray
that's inside the isosurface's container, and then does a straight
binary chop looking for intervals where the sign changes (or where the
sign could potentially change, given the specified max_gradient). Is
that about right?
So POV-Ray doesn't use (and hence isn't bothered about), e.g., "flat"
areas in the function? (And presumably it won't be too upset about
single points where the function reaches infinity or isn't defined.)
I take it POV-Ray also doesn't save any of the points it's sampled and
reuse them in any way to speed up subsequent ray intersection tests?
(I presume max_gradient = 17 means that for every POV-unit you travel,
the function's value changes up or down by a maximum of 17? Yes? In that
case, I would imagine if the function evaluates to 1,287 at one
particular point, you can safely say that there are no intersections
within about 75 POV-units of that point. This would seem to be useful
information to reuse...)
(...but then... how to recall that information in an efficient way?... I
suppose you could generate a low-resolution voxel grid and mark all
areas which definitely DON'T contain part of the surface... but it looks
like that's exactly what Christoph's patch does!)
Thanks.
Andrew @ home.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
