 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c30b4c0@news.povray.org> , "Rune" <run### [at] mobilixnet dk>
wrote:
> Specifying the orthographic keyword as the last thing in the camera
> definition has always been a *very* handy feature which meant you didn't
> have to fiddle with the width and height vectors. It's even stated clearly
> in the documentation:
>
> "If you add the orthographic keyword after all other parameters of a
> perspective camera you'll get an orthographic view with the same image area,
> i.e. the size of the image is the same. In this case you needn't specify the
> lengths of the right and up vector because they'll be calculated
> automatically."
>
> The discussed feature change (not bug fix) would be a *major* brake of
> backwards compatibility and would make it much more annoying to work with
> the orthographic camera in general. Please don't cripple the software like
> that! :(
Calm down. First of all, you can always use the old style, simply by having
version set to 3.1 when specifying the camera. (**Read the next paragraph**)
Second, and more important, all the issues that I know will result out of
the enforced keyword will be worked out. However, the camera object and the
side effects of individual keyword within camera are *extremely* complex.
As some bug reports have shown, in some cases they are not desired. As your
report shows, there are also various cases where a specific order matters or
provides a special feature.
So, let me put it this way: The current change, which will be either in its
current or in a more advanced form be in the next beta does not mean the
feature is locked for 3.5. It also does not mean it suddenly breaks all
scenes without workaround. Old scenes do continue to work with a version
setting.
Even more important: For a future rewrite it is necessary to have
well-behaved features with deterministic rules. Right now there are a lot
of implicit assumptions when creating a camera. These will be replaced with
well specified and homogenous rules that will also make the feature easier
to use - as the current docs point out, it is easy to make mistakes when
creating a camera and POV-Ray will not tell you, it will just not work.
This is what will change, no feature will be removed or inaccessible.
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 <3c30caf5@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:
> It's a well known fact that the order in which the parameters of the camera
> is specified is important.
These order dependencies will (and cannot) be removed. they have not been
removed nor did I imply they have been removed. Only the camera type has to
be specified at a point so that POV-Ray can take the right action later.
Some of the bug reports regarding camera suggest users magically expect
POV-Ray to guess which of two (both logical) models of thinking they use and
adjust the behavior of the camera. Obviously POV-Ray has no mind-reading
interface (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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c30caf5@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:
> There are some other such examples, and in general it's rather difficult to
> fully understand how all the parameters in the camera interact (I don't
> *fully* understand it myself). The documentation helps a lot though, if you
> read it thoroughly.
Honestly, even from the code it isn't all that clear because a few
calculations are done while parsing, while originally everything was done
when rendering. All the code needs is a bit cleanup. It will eventually
make the camera fully predictable. Don't worry about lost features. And
you old scenes will all continue to work as well!
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 <3c30caf5@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:
> There are some other such examples, and in general it's rather difficult to
> fully understand how all the parameters in the camera interact (I don't
> *fully* understand it myself). The documentation helps a lot though, if you
> read it thoroughly.
Another note regarding this:
It would be good to have a short list of all keywords that are supported by
a specific camera type and if they had to appear before or after the camera
type was specified. If you could post a draft of such a short summary here
(not the docs, they are too long and contain too much information not
relevant to the keyword order and usage itself) and other would the complete
it so there is a complete list of what behaviors users expect and which they
don't expect (both exist in cameras up to 3.5 beta 9), I would be very happy
to engineer the camera parsing code to exactly match user expectations,
without the nasty side effect that currently exist.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Please also note my recent additions in the Dec 24th list thread.
>
> Regarding:
> job000208
> with orthographic camera objects disappear when "angle" keyword is used
>
> Analysis:
> It turns out this never was a bug. 'angle' works exactly as advertised in
> the manual. The problem is the user specified the camera type after the
> angle, which assumed it was applied to a perspective camera and
consequently
> changed the direction vector length, which makes it look like the object
> disappears.
I bet you are already fed up with plain users arguing with the real
programmer, but this may be interesting :o)
The scene in the bug report was basically two spheres thrown in front of an
orthographic camera. It rendered *perfectly* until I put a couple of
additional spheres in, after which everything disappeared (no ray/shape
intersections).
This made me believe that the camera setup was correct and what I was
witnessing was a bug. And I'm still not entirely convinced it isn't. I hope
it's not a big sin to drop the slightly modified source in again (a couple
of lines):
camera { location <0,1,-1> look_at <0,1,0> angle 30 orthographic }
sphere { 0,1 texture { pigment {color rgb 1} finish {ambient 1} } }
/*sphere { <0,1.2,0>,0.18 texture { pigment {color rgb <1,0,0>} finish
{ambient 1} } }
sphere { <1.2,0,0>,0.18 texture { pigment {color rgb <0,1,0>} finish
{ambient 1} } }
sphere { <-1.2,0,0>,0.18 texture { pigment {color rgb <0,0,1>} finish
{ambient 1} } }
sphere { <0,-1.2,0>,0.18 texture { pigment {color rgb <1,1,1>} finish
{ambient 1} } }*/
sphere { 0,5 texture { pigment {color rgb 1/2} finish {ambient 1} } }
/*plane {y,-100}*/
Here is a new finding: the scene renders perfectly in this form, but if you
bring back any one of the spheres that are currently commented out (or put
any new objects in, like the distant plane), the white sphere disappears.
Which means the camera works as expected as long as there aren't more than
two objects in the scene!
beta9 (but I guess it's the same with any version), w2k
---
Gergely
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c339434@news.povray.org> , "Gergely Vandor"
<ger### [at] vandordatanethu> wrote:
> I bet you are already fed up with plain users arguing with the real
> programmer, but this may be interesting :o)
Well, computer programs are no magic. What you describe is an effect caused
by what I explained. There is no check if there are more than two objects
to then let some specific ones disappear in POV-Ray, I am sure! :-)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 31 Dec 2001 12:24:37 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > crash during debugging of parsing
> > http://news.povray.org/332m2uspk9nfqfq6g7oc8qtmkcu5higjs7@4ax.com
>
> > crash with loop
> > http://news.povray.org/3c2cb9b7@news.povray.org
>
> Both logged as job000205.
You know sources however I want note (I played with those bugs a lot) they are
different.
First
- works only when #stream directive is used and works fine without it.
- not depend on length of loop
- crash in second run after stop of first parsing
Second
- it is not related with any #stream (or only input stream)
- depends on length of loop (infinite loop)
- crash in every run
There are probably more differences.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)&_((x+y)*.7,z,.1)&_((x+y+2)*.7,z,.1)&_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c339d81$1@news.povray.org...
> In article <3c339434@news.povray.org> , "Gergely Vandor"
> <ger### [at] vandordatanethu> wrote:
>
> > I bet you are already fed up with plain users arguing with the real
> > programmer, but this may be interesting :o)
>
> Well, computer programs are no magic. What you describe is an effect
caused
> by what I explained. There is no check if there are more than two objects
> to then let some specific ones disappear in POV-Ray, I am sure! :-)
>
I understand this is like beating a dead horse, so I only have a last
question.
In the scene I quoted, it is clear to see that including certain objects
(objects far away from the camera, etc) make other objects vanish from the
resulting image. This happens with all the camera options unchanged. Does
this mean that in this case povray somehow takes the objects of the scene
into account when interpreting camera options?
So far you have only stated that certain combinations of camera options can
have unexpected results. In this case we are talking about combinations of
camera options and object placement.
---
Gergely
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c3452bf@news.povray.org> , "Gergely Vandor"
<ger### [at] vandordatanethu> wrote:
> So far you have only stated that certain combinations of camera options can
> have unexpected results. In this case we are talking about combinations of
> camera options and object placement.
The camera could not care less for the objects in the scene. There is no
interaction. If you are lucky one of the advanced users will have the time
to look into your scene and find the problem in it.
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:
> The camera could not care less for the objects in the scene.
It could perhaps be a bounding problem. Bounding is reliant on both the
camera and the objects in the scene and automatic bounding is indeed not
used when the amount of objects is below a certain number.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Jan 2)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
