Hello again folks,

My prior post was "isosurfaces in v3.5 and how to convert them to
heightfields" and there I mentioned that isosurfaces were slower in Pov3.5
due to the lack of "method 1"... Here is the proof, and I humbly ask the
great people developing Pov to take another look at this and eventually
explain why method 1 was removed from Pov 3.5.

Render times for an isosurface on AMD 1 ghz  (full code below):

MegaPOV 0.7:
 Method 2 = 11 secs
 Method 1 =  2 secs

POV 3.5 beta 5:
 Method 2 = 13 secs

//  ----- The code
#version 3.5;

camera { right -1.33*x up 1*y direction 1*z location <-3,0,6> look_at 0
angle 48 }
light_source { <-25,25,35> color rgb 1.5 }

isosurface { function { (x-.5)*(x-.5)+y*y+z*z-1
     + .001^((x+.5)*(x+.5)+y*y+z*z-.75)
     - .0001^abs((y+.2)*(y+.2)) }

//  method 1  // method 2
     max_gradient 278.219 accuracy .008
     contained_by { box { <-1,-1,-1.5>,<1.25,1,1.5> } }
     pigment { rgb 1 } finish { ambient 0 diffuse .67 specular .1 }
no_shadow }

//  ----- End

Post a reply to this message

In article <3bc6d8e2$1@news.povray.org> , "Hugo" <hua### [at] post3teledk> wrote:

>  Here is the proof, and I humbly ask the
> great people developing Pov to take another look at this and eventually
> explain why method 1 was removed from Pov 3.5.

Because it did not meet the code quality and functionality requirements for
an officially supported feature.  If you feel comfortable reading source
code go and see for yourself in the MegaPOV source code of method 1 - it is
really obvious what major problems it has.  If you are not a programmer,
please take my answer as is: Any explanation would be very long and
impossible to understand without knowing the source code and how method 1
works.

As for more discussion about this, please consider

Message-ID: <3B94E1CF.7498B010@pacbell.net>
Date: Tue, 04 Sep 2001 07:14:39 -0700
From: Ken <tyl### [at] pacbellnet>
Organization: POV-Ray Technical Assistance Group
Newsgroups: povray.beta-test
Subject: Attention: Beta Testers
Xref: news.povray.org povray.beta-test:4


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3bc6e99b@news.povray.org...
>
> Because it did not meet the code quality and functionality requirements for
> an officially supported feature.  If you feel comfortable reading source
> code go and see for yourself in the MegaPOV source code of method 1 - it is
> really obvious what major problems it has.  If you are not a programmer,
> please take my answer as is: Any explanation would be very long and
> impossible to understand without knowing the source code and how method 1
> works.

Aww, now I'm intrigued and I didn't even care before.... No offence - I'm sure
you're right - but can we code-idiots have the potted-version and decide for
ourselves that it's impossible to understand.... ;)

Post a reply to this message

Tom Melly wrote:

> Aww, now I'm intrigued and I didn't even care before.... No offence - I'm sure
> you're right - but can we code-idiots have the potted-version and decide for
> ourselves that it's impossible to understand.... ;)

I think you just got the potted-version answer. Thorsten is not interested in
discussing it further.

-- 
Ken Tyler

Post a reply to this message

On Fri, 12 Oct 2001 15:04:59 +0100, Tom Melly wrote:
>"Thorsten Froehlich" <tho### [at] trfde> wrote in message
>news:3bc6e99b@news.povray.org...
>>
>> Because it did not meet the code quality and functionality requirements for
>> an officially supported feature.  If you feel comfortable reading source
>> code go and see for yourself in the MegaPOV source code of method 1 - it is
>> really obvious what major problems it has.  If you are not a programmer,
>> please take my answer as is: Any explanation would be very long and
>> impossible to understand without knowing the source code and how method 1
>> works.
>
>Aww, now I'm intrigued and I didn't even care before.... No offence - I'm sure
>you're right - but can we code-idiots have the potted-version and decide for
>ourselves that it's impossible to understand.... ;)

It'd be nice to be able to make an explanation that means something to code
idiots, but that would require us to have started with code that can be 
understood by someone besides the person or people who wrote it.  There were
no comments, the code flow was all over the place through three seperate 
modules that had no apparent organization, it had global variables that did
weird things at weird times, and on top of all of that it had been ported
from 3.0 to 3.1 in the most expedient possible way by Yours Truly.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...

<snip>

You mean it was a pile of ca-ca (technical expression)?

Why didn't Thorsten just say so... ;)

Post a reply to this message

"Hugo" <hua### [at] post3teledk> wrote..
>My prior post was "isosurfaces in v3.5 and how to convert them to
>heightfields" and there I mentioned that isosurfaces were slower in Pov3.5
>due to the lack of "method 1"... Here is the proof, and I humbly ask the
>great people developing Pov to take another look at this and eventually
>explain why method 1 was removed from Pov 3.5.

"Method 2" is valid for any continuous functions (if you use appropriate
max_gradient and accuracy values) while "method 1" is not.
This is the major problem of "method 1".

>MegaPOV 0.7:
> Method 2 = 11 secs
> Method 1 =  2 secs
>
>POV 3.5 beta 5:
> Method 2 = 13 secs

As discussed in p.b.i,
http://news.povray.org/povray.binaries.images/18925/?ttop=19235&toff=50&mtop
=123788&moff=10
optimization of the function gives us much faster rendering speed
in some cases.

Try following code.

R. Suzuki

//  ----- The code
#version 3.5;
#include "functions.inc"

camera { right -1.33*x up 1*y direction 1*z location <-3,0,6>
look_at 0 angle 48 }
light_source { <-25,25,35> color rgb 1.5 }

isosurface { function {
     min(
       sqrt((x-.5)*(x-.5)+y*y+z*z
         + .001^((x+.5)*(x+.5)+y*y+z*z-0.75)
         - .0001^abs((y+.2)*(y+.2)))-1,
       f_r(x*0.55,y,z*0.7)*0.35
       )
 }

     max_gradient 3.2 //278.219
     accuracy .008
     contained_by { box { <-1,-1,-1.5>,<1.25,1,1.5> } }
     pigment { rgb 1 } finish { ambient 0 diffuse .67 specular .1 }
no_shadow }

//  ----- End

Post a reply to this message

Wow, great tricks you introduce here! I am going to take a closer look at
them and see if I can apply them in general to my isosurfaces cause they all
tend to render slower on Pov3.5... I admit, I'm not so skilled in math as I
would like to be.

Hugo

> optimization of the function gives us much faster rendering speed
> in some cases.
>
> Try following code.
>
> R. Suzuki

Post a reply to this message