This is my first post to this group so these things may or may not be
obvious and/or silly. If so, I apologize in advance.

  Firstly, I'm not new to POV, having started with the DOS version many
years ago with a copy that was included in the book 'Ray Tracing Creations'.
Despite my long time acquaintance with POV I have really only dabbled from
time to time, never building anything truly complex. For me, I enjoy POV's
math and geometry as much as the finished images. Bizarre isn't it?  Anyway,
on to my current problems:

  I've noticed that some object modifiers are not universal in their usage
and only work on certain objects or need to be specified in a certain order
when used on specific objects. Since the documentation is spotty in a few
areas and perhaps incorrect in a select few cases I decided to see if anyone
could clear up a few of the following things for me:

  I can not seem to get the angle keyword to have any effect whatsoever with
panoramic cameras despite the documentation's claim to the contrary. More
generally, I'd like to know which camera types should use the various values
like up,direction,right, and angle and in what order they should be
specified (since this seems to make a difference).

  I'm also not quite clear on the usage of certain keywords. I've noticed
sturm can be used on prism spline types not mentioned in the documentation
and was wondering if there was a reason for this not being mentioned, like
perhaps it shoudn't be used in these cases. Also, can hollow and inverse be
applied to any object, even non-solid ones? It seems to be allowed, although
I cannot understand what hollow would do to a bicubic patch, for example.

  Finally, I noticed that the water-level modifier for height fields will
generate an error if placed after the hierarchy keyword. Is this a bug or is
there a reason for this that I just don't see. Are there other instances of
objects/cameras/lights that require keywords in a certain order to function
properly?

Thanks in advance for any assistance.

Post a reply to this message

in news:web.3d4ac5678ae935ff23878ff90@news.povray.org Mike wrote:

> I'd like to know which camera types should use the various values
> like up,direction,right, and angle and in what order they should be
> specified (since this seems to make a difference).
> 

Mike,

let me reply with a question, what version are you using? In POV-Ray 3.5 
the only requirement for cameras is that the camera type is specified 
first, the others camera statements can be used in any order (an exception 
may be the orthographic camera, depending on the way you want to use it).

Ingo

Post a reply to this message

ingo wrote:
>let me reply with a question, what version are you using? In POV-Ray 3.5
>the only requirement for cameras is that the camera type is specified
>first, the others camera statements can be used in any order (an exception
>may be the orthographic camera, depending on the way you want to use it).

Haha, oops, I didn't even think to mention the version. Yes, I'm using 3.5.
I saw it mentioned that the look_at point should come after other keywords
because other camera movements would cause the camera to cease looking at
that point. I thought perhaps other keywords could behave this way too. For
example if I specify up, direction, and right vectors and then follow with
an angle will I get different results than if I placed angle first? Or
should I not use up and right when using angle? I still can't get angle to
change my panoramic scenes in the slightest.

I realize some of these may sound like odd questions but I have a good
reason for asking (well at least I think it's a good one.)

What I'm attempting is to write my own entires for the 'Insert Menu' with
all the primitives,camera types, and lights done with a full list of
modifiers on each one set at their default values. Mostly I'm doing it for
myself, but I'd gladly share it with anyone who might want to use it as a
sort of crutch to learning POV. Here's an example (made for 3.1, not yet
updated for 3.5):

blob{
  threshold   1
  sphere{
    <0,0,0>
    1
    1
    texture   {Texture1}
    rotate    <0,0,0>
    scale     <1,1,1>
    translate <0,0,0>
  }
  cylinder{
    <0,0,0>
    <0,2,0>
    1
    1
    texture   {Texture1}
    rotate    <0,0,0>
    scale     <1,1,1>
    translate <0,0,0>
  }
  sturm       off
  hierarchy   on
  hollow      off
  //inverse
  //no_shadow
  //clipped_by {}
  //bounded_by {}
  material    {Material1}
  rotate      <0,0,0>
  scale       <1,1,1>
  translate   <0,0,0>
}

So instead of trying to remember blobs can have sturm and hierarchy
keywords, and individual components can be followed by a texture...I can
insert a generic blob with all the possible modifiers and just alter
coordinates, add components, etc. Thus my concern over which modifiers
really apply to which objects, what the order should be (when that
matters), and what the defaults are. Most of this I have gotten from the
documentation and my list is nearly done, but there are a few holes and
unexplained behaviors I have yet to work out. The panoramic camera is one
of them. Height field water_level was another, and sturm applying to
various prism types yet another. I'm trying to be completely accurate with
respect to 'correct' usage of various keywords. For instance cylindrical
cameras don't respond to the up and right vectors as other cameras do(being
a cylinder after all) yet flipping the sign of the vector will still flip
the camera view, so I haven't decided if my cylinder camera entries should
include those vectors or not.

Sorry if this all sounds silly or pointless. It's just something that I felt
I wanted to do.  :)

Post a reply to this message

Mike wrote:
 >
 > I can not seem to get the angle keyword to have any effect
 > whatsoever with panoramic cameras despite the documentation's claim
 > to the contrary. More generally, I'd like to know which camera
 > types should use the various values like up,direction,right, and
 > angle and in what order they should be specified (since this seems
 > to make a difference).
 >

Mike,

at the time I wrote a patch for POV 3.1 some months ago (creating
stereoscopic images), I noted that angle and aspect ratio were rather
confusing and behaved not the same way especially for the panoramic,
fisheye (and the like) camera types. In Megapov there are some patches
to the camera section, and IIRC these were adapted for POV 3.5
So I am now curious, what happend to this part of the source code...


Anyway, if you are confused on how a camera behaves, the best
way in my opinion is to set up a small camera test scene with a
very defined geometry. I used a scene with camera at origin and
a circular structure around it with cylinders (as marks) every 30
degrees. So one can find out empirically, what "angle" does.
It is helpfull to render this test scene with quadratic
image aspect ratio (i.e. right=up)

With respect to the camera parameters, I find it usefull to
distinguish "basic parameters" and "convienience shortcuts".
The former completely define a camera, but are often tricky
to set up, wheras the latter are only a more convienient way
to set up the former.

location, direction, up and right are "basic parameters"

angle is a "basic parameter" for some (all?) panoramic cameras
and for fisheye, but it is a "convienience shortcut" for the
standard pespective camera (it adjusts the direction vector
i.e. the focal length).

sky and look_at are "convienience shortcuts".

hope this helps a bit.

Hermann Vosseler

Post a reply to this message

=?ISO-8859-1?Q?Hermann_Vo=DFeler?= wrote:
>Mike wrote:
> >
I had set up some test scenes, although adding posts at specific angles is a
great idea I hadn't thought about. I'll try it tonight and see if I can get
angle to do something.  :)

So for the perspective camera, specifying angle after direction will
override the value give in diection? I presume it works both ways, i.e.
angle before direction means angle is overridden? I'll have to experiment
with this on various camera types.

That's exactly the kind of thing I'm looking for. Thanks.

Any other cases like this you can think of?

Post a reply to this message

Aha! I think I finally get it.

I was just playing around with a scene with marker posts like you said and
think I finally understand what is going on.

Placing angle before or after direction isn't important. Like you said it
scales the direction vector to gain the correct angle; it doesn't
'override' the values for direction and right, like I mistakenly imagined
it did. I guess my confusion arose because you could leave out right, up,
and direction and just specify an angle...It didn't occur to me that angle
then simply acted on the default vales for these vectors, rather than
'replacing' them.

Whew.

Now, I'll see if I can get angle to do something with my panoramic
cameras...

Post a reply to this message

Mike wrote:
> Hermann_Vosseler wrote:
> ...
> 
> So for the perspective camera, specifying angle after direction will
> override the value give in diection? I presume it works both ways, i.e.
> angle before direction means angle is overridden? I'll have to experiment
> with this on various camera types.
> 


(I can't look it up in the source to make it 100% shure at the moment.)

The perspective camera has only the "baseic parameters" location, 
direction, up and right. I.e. they need to be defined when the
rendering starts.

angle, sky and look_at are resolved in the parser.
When the parser e.g. finds a "angle" keyword, it takes the
right vector defined *at that moment* and modifies the direction
vector so the image will show the given angle.

To say it the other way round: perspective camera has no
parameter "angle". When "angle" is encountered, the parameter
"direction" ist modified, but the float value given behind the
"angle" keyword is not saved outside the parser. If you specify
"direction" again later in the camera definition, the
previous direction value (and thus the effect of the your
angle keyword) ist owerwritten.
The same holds true for look_at
If you specify direction again after the look_at or if you
rotate your camera, the effect of the look_at-statement is lost.


But -- on the contrary -- the panoramic-type cameras *do have*
a "angle" property, i.e. for this cameras "angle" is needed by
the raytracer itself (it needs to know how much of the image
cylinder has to be scanned)
On the other hand some cameras don't use direction. Bottom line:
rather confusing, can't find a simple rule.



Hermann

Post a reply to this message

Mike wrote:
> Aha! I think I finally get it.
> 

"mid air collision" :-)
I tried to explain it further with my previous post,
but you alredy got how it works.


> 
> Now, I'll see if I can get angle to do something with my panoramic
> cameras...
> 
> 

If you excuse my shameless plug,
maybe, you want to have a look at the test images
for my stereo-patch. Of course, this page is focused
on how my stereoscopic camera behaves, but a bit more
down on this page there are some images renderd with
POV 3.5 builtin cameras "panoramic", "cylinder",
and "ultra-wide-angle". As you can see, the
"cylinder" camera has problems retaining the
given aspect ratio.

http://www.geocities.com/StereoPOV/camtest.html



Hermann Vosseler

Post a reply to this message

Thanks I understand it now.

I just discovered that if angle is present it will take precedence over a
direction vector, no matter what order they are specified in. So a
direction vector following an angle will not have an effect and will not
override the angle value. The right vector can still be modified however. I
suppose this is the desired behavior.  :)

On the other hand, angle will still not affect my panoramic cameras at all.
I used marker posts as suggested and I'm getting what appears to be an
angle of 180 degrees no matter what I specify. The right and direction
vectors change the appearance of the image, but the overall angle remains
at 180.   :(

Post a reply to this message

Mike,

there have been substantial changes to the camera code in 3.5 to
eliminate any dependence on the order of keywords. The only
requirement is that camera type goes first.

That said, you should not use (angle) and (up or right or direction)
in the same camera statement. Since now camera keywords act
simultaneously, and not in order, you should not use keywords which
override each other.

If you want old-style camera behavior, set #version 3.1; before the
camera block:

#version 3.1;
camera { ... camera parameters ... }
#version 3.5;

Hope this helps.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message