The current 'evaluate' keyword seems to confuse some people. 
I think following behavior is more logical and it would be
easy to implement. 

----------------------------------------------------------
evaluate P0 [, P1 [, P2]]
  P0: case (0)     : no warnings
      case (non 0) : same as the current version
      default value:1

  P1: case (0)    : no dynamic max_gradient estimation
                           (i.e. fixed max_gradient)
      case (non 0): same as the current version 
      default value:0

  P2: same as the current version
      default value:1
----------------------------------------------------------

Then, we can use "evaluate on", "evaluate off".

R. Suzuki

Post a reply to this message

In article <3c0f196a@news.povray.org> , "R. Suzuki" <r-s### [at] aistgojp> 
wrote:

> evaluate P0 [, P1 [, P2]]
>   P0: case (0)     : no warnings
>       case (non 0) : same as the current version
>       default value:1
>
>   P1: case (0)    : no dynamic max_gradient estimation
>                            (i.e. fixed max_gradient)
>       case (non 0): same as the current version
>       default value:0
>
>   P2: same as the current version
>       default value:1

I am not really sure I understand the suggestion.  In particular I don't
understadn P1 case 0 and I am not really sure I understand your idea for
P0...

    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:
> I am not really sure I understand the suggestion.  In particular I don't
> understadn P1 case 0 and I am not really sure I understand your idea for
> P0...

For example, in biscuit.pov, if there are more than 10 thousands of crumbs
(small isosurfaces), most windows users will be in trouble due to the
warning message.
In such cases, P0=0 should be needed.

Currently, no evaluate keyword means "evaluate with fixed max_gradient"
and "evaluate P0, P1, P2" means dynamic max_gradient estimation.
But if we use P0 as evaluate switch, we need additional switch to
select fixed max_gradient or dynamic max_gradient.

I've made a source code for this proposal.  I will send it to you by e-mail.

R. Suzuki

Post a reply to this message

In article <3c124c8b@news.povray.org> , "R. Suzuki" <r-s### [at] aistgojp> 
wrote:

> For example, in biscuit.pov, if there are more than 10 thousands of crumbs
> (small isosurfaces), most windows users will be in trouble due to the
> warning message.
> In such cases, P0=0 should be needed.

Keep in mind that the message should not be displayed for a max_gradient
that is zero, but it currently is (which is incoorect).  There is also a
possible solution to the repeated output of messages for the same function
if it is the result of a copied isosurface that would only output the
maximum found max gradient for the function rather than the isosurface
itself.

    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

I just tested the beta 8 with one of my more complex scenes with
isosurfaces. The report of the max_gradient warnings took about two minutes.
They did not tell me much new, as they said, I should lower max_gradient
from 4 to something between 0.5 and 2.5. I could do that, but the gain in
speed is probably to be neglected. In addition the message pan scrolled all
messages away, which where reported before the evaluation-warnings. If there
were useful warnings before, I don't know, as they scroll away much to fast.

Most of the warnings where reported for one function which is used for many
Isos, but they differ quite a lot in the values as a randomly translated
pigment-function is involved.

None of the warnings report a max_gradient of 0.

Note that I did not use evaluate in this scene!  Why is it necessary to give
me all that warnings I can't do anything about (AFAIK - the last one told me
that max_gradient is 4.316 but max_gradient was set to 5) and that do not
help me, as they are gone to fast? Okay, I could switch the warning stream
of - but there may be a warning I'm really interested in. Don't know,
couldn't see it.

I could redirect the stream to a file I think, but that is not very
convenient as I see it.

I don't know if the changes you mentioned would help, but I think they
wouldn't. IMHO it would be really good to let the user decide if he/she
wants the max_gradient warnings as it happened with the old
"evaluate"-command. It's not that you have to worry about a max_gradient set
to high, as long as you are willing to wait for the render to complete. It's
not that you are doing something wrong (f.e. not following the syntax
specifications, like with leaving out a semicolon after a #declare), it's
just that you are not working that efficient.

If you want that the warnings you give are noticed, it's in my opinion to
reduce them to those the user really needs - with my scene file I get
serious information overflow.

Please return to the old warning behaviour or implement a switch to turn the
warnings of"

Marc-Hendrik


Thorsten Froehlich schrieb in Nachricht <3c125006@news.povray.org>...
>In article <3c124c8b@news.povray.org> , "R. Suzuki" <r-s### [at] aistgojp>
>wrote:
>
>> For example, in biscuit.pov, if there are more than 10 thousands of
crumbs
>> (small isosurfaces), most windows users will be in trouble due to the
>> warning message.
>> In such cases, P0=0 should be needed.
>
>Keep in mind that the message should not be displayed for a max_gradient
>that is zero, but it currently is (which is incoorect).  There is also a
>possible solution to the repeated output of messages for the same function
>if it is the result of a copied isosurface that would only output the
>maximum found max gradient for the function rather than the isosurface
>itself.
>
>    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

In article <3c128906@news.povray.org> , "Marc-Hendrik Bremer" 
<Mar### [at] t-onlinede> wrote:

> I don't know if the changes you mentioned would help, but I think they
> wouldn't. IMHO it would be really good to let the user decide if he/she
> wants the max_gradient warnings as it happened with the old
> "evaluate"-command.

The point is to not give the user this freedom.  It causes a lot of people
to report holes and other bugs in isosurfaces because they simply forget
about or (worse) don't understand max_gradient.  Only a warning gets their
attention.

    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

> The point is to not give the user this freedom.  It causes a lot of people
> to report holes and other bugs in isosurfaces because they simply forget
> about or (worse) don't understand max_gradient.  Only a warning gets their
> attention.

But a max_gradient value that's too high will not cause problems except a
difference in rendering speed. So can't you have it only warn when the
max_gradient is set too low (unless evaluate is being used)?

Post a reply to this message

Thorsten Froehlich schrieb in Nachricht <3c12ac6f$1@news.povray.org>...
>In article <3c128906@news.povray.org> , "Marc-Hendrik Bremer"
><Mar### [at] t-onlinede> wrote:
>
>> I don't know if the changes you mentioned would help, but I think they
>> wouldn't. IMHO it would be really good to let the user decide if he/she
>> wants the max_gradient warnings as it happened with the old
>> "evaluate"-command.
>
>The point is to not give the user this freedom.  It causes a lot of people
>to report holes and other bugs in isosurfaces because they simply forget
>about or (worse) don't understand max_gradient.  Only a warning gets their
>attention.
>


Yes, I know, I answered to a lot of these messages myself. But ... they
won't see the info after they got used to all the warnings. As I said: with
a bunch of Isosurfaces in one scene (placed with loops f.e.), there is
absolutely no gain in all these warnings. With the past behaviour, one could
set "evaluate" in only those isosurfaces one was working on. You get the
info you need, you find the info you need. But if you get "spammed" with all
those warnings, they are just meaningless. You switch the warning stream off
and ask others why your Iso does not render properly. In addition - if you
want just one specific max_gradient in your scene, you have to comment out
most of the others or there is a good chance that the message pan will
"forget" that specific warning before you can read it.
IMHO there is nothing that could be done against users, which use the
program the wrong way. It's the same as with the sturmian solver - if you
don't read the docs you will have to ask others for a solution.
I'm willing to answer any "my isosurface shows unexpected holes" on the
groups I read with an individual message or a link to the FAQ/Docs, but in
the given form, the evaluate-warnings are absolutely useless if you have a
bunch of Isos in your scene: either you get Info you already had (and used
to set max_gradient the way you wanted), or you miss the info you want to
have (or have to search for it in all the warnings). For one or two Isos in
the scene, the given behaviour is a good one and a useful one - but I use
hundreds of them and so do others.

Regards,

Marc-Hendrik

Post a reply to this message

"Thorsten Froehlich" wrote 
>It causes a lot of people to report holes and 
>other bugs in isosurfaces because they simply forget
>about or (worse) don't understand max_gradient.  
>Only a warning gets their attention.

Yes, they need a warning.  
Thus, the default setting of my proposal is "evaluate on", 
i.e. users will get a warning in default.  

But for advanced users or people who just want to use POV 
scene files written by advanced users, the "evaluate off" 
option should be required.

The below code is an example. There are 20,000 isosurfaces.
It is easy to parse and the rendering speed is quite fast.
Please try it. 
Using this technique, we can generate many interesting objects.
But the current behavior is quite inconvenient for these objects.

R. Suzuki

----------------------------------------------
#include "functions.inc"

camera {location <20,40,28> direction 2.5*z look_at <0,0,0>}

light_source {<-140,200,300> rgb <1.0, 1.0, 0.95>*1.5}
light_source {<140,200,-300> rgb <0.9, 0.9, 1.00>*0.5 shadowless}

#declare r1 = seed(0);

#declare Tex_B =
texture {
   pigment {color rgb <0.90, 0.70, 0.45>}
   normal {dents 1.2 scale 0.01}
   finish {phong 0.2 brilliance 0.25}
}

#declare Fun_Sphere = function {x*x - y*x +z*z}
#declare Crumb =
isosurface {
   function {Fun_Sphere(x,y,z) + f_noise3d(x*2,y*2,z*2)*1}
   threshold 1
   max_gradient 3
   accuracy 0.01
   contained_by {box {-1,1}}
   scale 0.5
}

#declare r1 = seed(0);

#declare I = 0;
#while (I < 1)
   object {
      Crumb
      rotate rand(r1)*360
      scale 0.2+rand(r1)*0.3       
      #declare xx=(rand(r1)-0.5)*20;
      translate <xx,cos(xx),(rand(r1)-0.5)*20>
      texture {Tex_B}
   }
   object {
      Crumb
      rotate rand(r1)*360
      scale 0.1+rand(r1)*0.15
      #declare zz=(rand(r1)-0.5)*20;
      translate <(rand(r1)-0.5)*20,cos(zz),zz>
      texture {Tex_B}
   }
   #declare I = I+0.0001;
#end

Post a reply to this message

R. Suzuki schrieb in Nachricht <3c14ce92@news.povray.org>...

>The below code is an example. There are 20,000 isosurfaces.
>It is easy to parse and the rendering speed is quite fast.


Yes, that's a good example: total time for parsing and tracing was 1min 10
sec (reported at the Message Pan). Total elapsed time until pov stats that
it's finished: 4 min 37sec. The warnings propose about one quarter of the
times that I should increase the max_gradient, as it is to low and 3/4 it
proposes that I should lower it, as it's set to high.
So what should a newuser make out of this?

Marc-Hendrik

Post a reply to this message