Is it possible to include a camera statement in a union?
I want to place the camera in the head of a figure, but
POV gives an error for this.
I am using POVray 3.1g for Windows.

Post a reply to this message

Don't think so.  'camera' can be declared though only for inclusion into
another 'camera' statement.  I have tried in CSG before like you and got
that error.

Bob

mr.art <mr.### [at] gcinet> wrote in message news:381B623D.F2F721CF@gci.net...
> Is it possible to include a camera statement in a union?
> I want to place the camera in the head of a figure, but
> POV gives an error for this.
> I am using POVray 3.1g for Windows.
>

Post a reply to this message

Don't think so.. it doesn't work out...
You could #declare the head locations in something like this (don't know if
it correctly written, haven't tested it out)

#declare Location = <0,5,0>;

camera{
location {Location}
look_at {Loaction+z*2}      (is this right?)
}
sphere{Location ,1 pigment {White}

I think you can make something similar with a rotate statement.

| Is it possible to include a camera statement in a union?
| I want to place the camera in the head of a figure, but
| POV gives an error for this.
| I am using POVray 3.1g for Windows.
|

Post a reply to this message

Thanks for the replies. I had had hopes.
Maybe it could be a project for a patch
someday.

Post a reply to this message

mr.art wrote:
>Is it possible to include a camera statement in a union?
>I want to place the camera in the head of a figure, but
>POV gives an error for this.
>I am using POVray 3.1g for Windows.

I don't think it is possible.

I would #declare a transformation, and apply it to
both the camera and the object:

// start of code

#declare Transformation =
transform {[scale, rotate and translate here...]}

camera {
   [camera settings here]
   transform Transformation
}

object {transform Transformation}

// end of code

Greetings,

Rune

---
Updated October 17: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

Thanks for all the info. The process
of keeping track of the location of one object
in a union of moving parts that can itself be
positioned most anywhere needs a function
or something. I mean, the render engine has that
info anyway, why not #declare PosHead = vlocation(Head,0)
for the location and #declare NormHead =vlocation(Head,1)
for the normal info for the Head?

Personally, I think being able to "mount" a camera on an object
and letting it get moved as the object gets moved is the best option.

Post a reply to this message

There can be difficulties in how the 'sky' vector gets applied I think.  Say
the camera is on a Ferris Wheel that also turns around the y axis too, if
the camera doesn't rotate along with it (stays aligned to the ground plane
for instance, as if seated in real ride) then nothing is apt to go wrong. If
it follows the Ferris Wheel path as though afixed to it then it might flip
from one orientation to the next.
I'm not sure of the associated problems but I have seen what appears to need
consideration as far as the sky vector goes.

Bob

mr.art <mr.### [at] gcinet> wrote in message news:382061B8.102F1907@gci.net...
> Thanks for all the info. The process
> of keeping track of the location of one object
> in a union of moving parts that can itself be
> positioned most anywhere needs a function
> or something. I mean, the render engine has that
> info anyway, why not #declare PosHead = vlocation(Head,0)
> for the location and #declare NormHead =vlocation(Head,1)
> for the normal info for the Head?
>
> Personally, I think being able to "mount" a camera on an object
> and letting it get moved as the object gets moved is the best option.
>

Post a reply to this message

On Wed, 03 Nov 1999 07:24:24 -0900, mr.art wrote:
>Thanks for all the info. The process
>of keeping track of the location of one object
>in a union of moving parts that can itself be
>positioned most anywhere needs a function
>or something. I mean, the render engine has that
>info anyway, why not #declare PosHead = vlocation(Head,0)
>for the location and #declare NormHead =vlocation(Head,1)
>for the normal info for the Head?

Because the render engine doesn't actually have that information,
perhaps?  For example, if you uniformly scale, translate, and 
rotate a sphere it will just modify the radius and the center
and will keep the transform set to the identity.

Okay, maybe it can have that information in some cases if it assumes the 
initial "position" (whatever that means) of the object was zero and the 
initial "orientation" was Y, but designing objects that way is just a 
guideline, not a requirement.

In short, such a function would be impractical and fragile.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

However, the ability to "attach" a point to the object, and have the
point be automatically transformed with the object, would be nice. Of
course, it would require that the object be #declare'd or #local'd.

#declare Head =
OBJECT {
    blahblah
    #attach Center = < 0, 1, 0>;
}

#transform Head, TRANSFORM;

#declare HeadCenter = Head.Center;
or
camera {location Head.Center look_at < 0, 0, 0> angle 35}

Notice the #attach command, which would attach a point to the object,
and the #transform command, which would transform an object without
redefining it. #declare would make a new object, with it's own
#attach'ed variables, and the variables would be initialized to the
original, so #declare could be used to do the same thing without this
addition.
If this is done, perhaps #attach should be #attach_point, which would
attach a transformable point to the object, and #attach would just
attach a variable of any type to the object. This could lead to some
interesting data structures, maybe there should be a void {} object type
which would just be a container for attached variables.

Alternatives for #attach that I can think of:
#link and #link_point
#bind and #bind_point
Any suggestions? Perhaps I will attempt to implement this, it shouldn't
be *that* hard.
Hmm, perhaps this should be in a thread of it's own...

Post a reply to this message

Ron Parker wrote:

>
> Because the render engine doesn't actually have that information,
> perhaps?  For example, if you uniformly scale, translate, and
> rotate a sphere it will just modify the radius and the center
> and will keep the transform set to the identity.
>
> Okay, maybe it can have that information in some cases if it assumes the
> initial "position" (whatever that means) of the object was zero and the
> initial "orientation" was Y, but designing objects that way is just a
> guideline, not a requirement.
>
> In short, such a function would be impractical and fragile.
>

If I tried something like
#declare Head =
union    {
object{Nose translate -x*.5}
object{Ear translate <0,.2,-.45>}
object{Ear translate <0,.2,+.45>}
object{Eyes translate +y*.2}
rotate <0,45,20>
translate +y*3
}

I would expect that all parts would stay together.
And if I tried something like
camera{location 0 look_at -x rotate <0,45,20> translate +y*3}
I would expect that the camera would point to where
I had wanted it. I know from experience that you can even
scale a camera. It only effects location. The size of a camera is
not effected.
So why not put the camera on an object in a union?
Then I could do this
#declare VideoHead =
union{
object{Head}
camera{location 0 look_at -x translate -x*.51}
rotate <0,45,20> translate +y*3
}
Anything that I could do that would then change the
position and/or scale of object{VideoHead} would
also change the camera location.

All these things POV does for every object.
And for the camera. I thought it natural that
the camera, as an object, could be included in
a union{}.

Post a reply to this message