Hi!

> > [bug] orthographic camera bug?
> > (objects sometimes disappear when the orthographic camera is used)
> > http://news.povray.org/3bdca5eb@news.povray.org
>
> An even simpler scene for this would really help.

I tried to simplify the scene as much as possible an here is the result:

camera { location <0,1,-1.481813> look_at <0,1,0> angle 30 orthographic}
sphere { 0,1 texture { pigment {color rgb 1}  }  }
sphere { <0,2,0>,1 }
sphere { <0,-2,0>,1 }

I removed as much spheres as possible and reduced the number of
texture statements. Normally you should see a dark gray sphere segment
on the bottom half of the image (maybe you have to turn up your monitor's
brightness), but due to this bug you get only an entirely black image.
I made some more experiments with the above example and found out
that the problem only occurs when:

*  camera points exactly in Z direction
*  camera type is orthographic
*  camera location z-value >= -1.481814 for an angle of 30 degrees;
   This value also depends on the size of the first sphere; The smaller the
   the sphere, the smaller the z value must be (e.g. -1.582 for size 0.9)
*  there are at least 3 objects in the scene
*  the vista buffer is enabled

The problem seems to be caused by the vista buffer. When disabling the
vista buffer by adding -UV to the options the problem disappears
entirely; With object counts lower than 3 the vista buffer seems to
be always disabled, so that's why you need at least 3 objects to
reproduce it.

Oh, I nearly forgot:
AMD AthlonXP 1700+, nForce Chipset, 256 MB RAM (224 MB + 32 MB shared)
Windows XP Home Edition (German), POV-Ray 3.5 beta9

Klaus.

Post a reply to this message

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

>>> Save during render
>>> (is very slow)
>>> http://news.povray.org/jhaiduce@engin.umich.edu
>>
>>I am not able to find this on the server.
>
> Oops. My fault. I copied the email address instead of the Message-ID.
> Should be

No problem.  Thanks!

>>> double_illuminate only works with direct lighting
>>> http://news.povray.org/3BF6F1FE.D21B0C6@oreka.com
>>
>>Has not been confirmed.  Might just be a user misunderstanding.
>
> I accepted the re-report of the problem in a different thread as
> confirming it.
> http://news.povray.org/3C03D9FC.B9F5E212@skynet.be

Logged as job000207.

    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 <3c2fe9ec@news.povray.org> , "Klaus Stengel" 
<pro### [at] technologistcom> wrote:

>> > [bug] orthographic camera bug?
>> > (objects sometimes disappear when the orthographic camera is used)
>> > http://news.povray.org/3bdca5eb@news.povray.org
>>
>> An even simpler scene for this would really help.
>
> I tried to simplify the scene as much as possible an here is the result:
>
> camera { location <0,1,-1.481813> look_at <0,1,0> angle 30 orthographic}
> sphere { 0,1 texture { pigment {color rgb 1}  }  }
> sphere { <0,2,0>,1 }
> sphere { <0,-2,0>,1 }

Thanks.  Now logged as job000208.

    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:

>> 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