Wasn't it Thorsten Froehlich who wrote:

>> Isosurfaces *much* slower in beta 7?
>> (isosurfaces with "evaluate" are now very slow)
>> http://news.povray.org/3bdf24b3$1@news.povray.org
>
>Already fixed in beta 9.

Is the fix still obscured by other isosurface bugs?

The given example file (http://news.povray.org/3bdf2d82@news.povray.org)
runs a little slower on my machine in beta 9 than it did under beta 8:-

beta 6          29 secs
beta 7   2 mins  6 secs (reported as a bug)
beta 8   1 min  51 secs ("fixed", but obscured by other bugs)
beta 9   2 mins  6 secs ("fixed")

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

In article <zsD### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> The given example file (http://news.povray.org/3bdf2d82@news.povray.org)
> runs a little slower on my machine in beta 9 than it did under beta 8:-
>
> beta 6          29 secs
> beta 7   2 mins  6 secs (reported as a bug)
> beta 8   1 min  51 secs ("fixed", but obscured by other bugs)
> beta 9   2 mins  6 secs ("fixed")

Note that the usage of evaluate changed between beta 6 and beta 9.

Anyway, the given function is too complex to say there wasn't simply another
change that simply causes the slowdown you see.  It might never have been
influenced by the real bug in there, as the bug has changed otherwise
evaluate could not work correct at all, which it does.

    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 <zsD### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> Is the fix still obscured by other isosurface bugs?
>
> The given example file (http://news.povray.org/3bdf2d82@news.povray.org)
> runs a little slower on my machine in beta 9 than it did under beta 8:-
>
> beta 6          29 secs
> beta 7   2 mins  6 secs (reported as a bug)
> beta 8   1 min  51 secs ("fixed", but obscured by other bugs)
> beta 9   2 mins  6 secs ("fixed")

Wait a second.  The scene uses max_gradient with evaluate on outdated style
and you end up comparing apples and bananas!!!

I clearly explained when I described the changes that that combination did
not actually use evaluate but only activated the max_gradient message in
beta 6 and any version of isosurfaces (official or unofficial) before beta 7
changed the behavior.  So you are comparing one scene that uses evaluate
(beta 7 and later) and one that never used it (beta 6 and earlier).  The
correct solution is to remove the completely unnecessary "evaluate".

    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

Wasn't it Thorsten Froehlich who wrote:
>In article <zsD### [at] econymdemoncouk> , Mike Williams 
><mik### [at] nospamplease>  wrote:
>
>> The given example file (http://news.povray.org/3bdf2d82@news.povray.org)
>> runs a little slower on my machine in beta 9 than it did under beta 8:-
>>
>> beta 6          29 secs
>> beta 7   2 mins  6 secs (reported as a bug)
>> beta 8   1 min  51 secs ("fixed", but obscured by other bugs)
>> beta 9   2 mins  6 secs ("fixed")
>
>Note that the usage of evaluate changed between beta 6 and beta 9.

Is there any chance of having the new functionality documented? The
evaluate documentation is unchanged from beta 6.

I know that the changes were discussed in various threads, but I got a
bit confused thought that the outcome was that almost all of the
functionality of evaluate had been moved into the non-evaluate code, and
that the evaluate keyword was effectively redundant. What does evaluate
still do that causes such a large increase in render times?

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

In article <2+c6A### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> What does evaluate
> still do that causes such a large increase in render times?

All the evaluate did in your scene up to beta 6 was to activating the
printing of the max_gradient.  The parameters didn't have any effect.  They
only used to have an effect when no max_gradient was specified.  With beta 7
and later evaluate always works like evaluate, no matter if max_ gradient
has been specified or not.  It was all explained in the "Isosurfaces *much*
slower in beta 7?" thread.  The documentation hasn't been updated because
the issue with max_gradient messages when using evaluate has not been fully
solved yet.

    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

3c2f9e16@news.povray.org...
> > Black outline in smooth meshes
> > (The outline of smooth meshes exhibit black dots or areas (which go away
> > with double_illuminate))
> > http://news.povray.org/3bf6794e$1@news.povray.org
>
> Does this have something to do with surface normals?  The current behavior
> might actually be correct...

It may have something to do with surface normals, since they are faked, and
the current behavior could be "correct" as far as the the algorithm is
concerned.

However, it's certainly not correct from a user's point of view. It has
certainly be a problem when using meshes, even highly detailed ones, on a
bright background. In some cases, I spent hours manually removing the dots
afterwards on large renders. No fun at all... The double_illuminate
workaround works, but may cause other problems, even more disturbing (I
still have to investigate that).
Meshes weren't much used by Povers until now, so the problem was quite
unnoticed (and unimportant) but I bet that more people will use meshes in
Povray now on.

G.
--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

On Sun, 30 Dec 2001 18:14:36 -0500, "Anders K."
<and### [at] prostard2gcom> wrote:

>> > Camera is off by half a pixel
>>
>> Will be changed in a future beta of 3.5 if #version 3.5 is used.
>
>So that's what you meant. :-) Thanks!
>
>Anders
>

Cool!  I was just using povray to render a bunch of buttons
and this half pixel bug reared its ugly head in the worst
way.  Can't wait for the next beta.  :-D

Post a reply to this message