 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can the camera be included in a union{}? If not, why, or why not?
I know that the current implementation does not allow this. That isn't
what I wanted to know. I am thinking of the difficulty of having
the camera follow the exact path that an object follows. i.e. The tip of
a finger on an IK figure. You don't necessarily compute the placement of
the tip of the finger. But if the camera could be included as part
of a union{}, those calculations would not have to be done by the scene
designer.
As an example for discussion, lets try
#declare Hand =
union {
object { Palm texture {...} scale ... rotate... translate... }
object { Thumb texture {...} scale ... rotate... translate... }
union {
object {FirstFinger}
camera {...translate < somewhere just outside of the finger>}
texture {...}
scale ... rotate... translate...
}
object { SecoundFinger texture {...}scale ... rotate... translate... }
object { ThirdFinger texture {...}scale ... rotate... translate... }
object { ForthFinger texture {...}scale ... rotate... translate... }
texture {...}
scale ... rotate...
}
// note: all named objects have been declared in another file.
So: anywhere that union of FirstFinger and camera gets placed, the
camera "sees"
Any texture that is applied to the finger or hand need not apply.
The scale and translate modifiers would only affect the position of the
camera.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You can do something like this:
#declare ObjectTransformations =
transform
{ // whichever combination of rotate and translate. Scale is not good.
}
camera
{ location CamLoc // Location of the camera when the object is at the origin
look_at 0
transform { ObjectTransformations }
}
object
{ MyObject // centered at the origin
// possible scale and other non-moving transformations here
transfrom { ObjectTransformations }
}
This has the same effect as if you had written something like:
union
{ camera
{ location CamLoc // Location of the camera when the object is at the origin
look_at 0
}
object
{ MyObject // centered at the origin
// possible scale and other non-moving transformations here
}
transfrom { ObjectTransformations }
}
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This works well if the object that you want the camera position to
follow is not part of a complex, jointed structure. Take the example
of the FirstFinger on the hand. If the hand were attached to an arm, and
that arm attached to a body, and the body was climbing down a hill, the
position of the body and the angle and length of the arm and the angle
of the hand and the angle of the FirstFinger on that hand would most
certainly
define a position for a hypothetical fingertip on that finger. I would
not
have to do any convoluted positional calculations to place a fingernail
on that fingertip, it could just be included as part of the union{}.
And as the body moved so does the fingernail. So if I replace the
fingernail
with a lightsource{}, it gets positioned just as easily as the
fingernail
did and follows the finger around as the body gets moved, just as the
fingernail did. And I don't have to compute beforhand where I want to
put
the hand or finger that is attached, it just gets moved when the part it
is unioned with does.
Why should the camera be any different? Is there some fundamental
difference
between cameras and lightsources and other objects that makes this
change to the cameras
union-ability impossible? (Besides the obvious one: the parser wont let
me.)
Warp wrote:
>
> You can do something like this:
>
> #declare ObjectTransformations =
> transform
> { // whichever combination of rotate and translate. Scale is not good.
> }
>
> camera
> { location CamLoc // Location of the camera when the object is at the origin
> look_at 0
> transform { ObjectTransformations }
> }
>
> object
> { MyObject // centered at the origin
> // possible scale and other non-moving transformations here
> transfrom { ObjectTransformations }
> }
>
> This has the same effect as if you had written something like:
>
> union
> { camera
> { location CamLoc // Location of the camera when the object is at the origin
> look_at 0
> }
> object
> { MyObject // centered at the origin
> // possible scale and other non-moving transformations here
> }
> transfrom { ObjectTransformations }
> }
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr. Art <mra### [at] chesapeake net> wrote:
: Why should the camera be any different?
If you apply a scale (specially a non-uniform one) to the union, how should
the camera behave?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3b7a5a3f@news.povray.org...
>
> If you apply a scale (specially a non-uniform one) to the union, how should
> the camera behave?
>
Like a point light-source?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
: Like a point light-source?
A point light-source has no dimensions, while a camera has.
If a scale command in the union only changes the location of the camera,
then it would be contradictory to what happens if the same scale command
is inside the camera statement.
If the scale command in the union affects the camera in the same way as
if it was inside the camera-statement (ie. the camera geometry is changed
accordingly), that may not be what people usually want.
So it's not such a trivial question.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have tried to scale a camera before when testing the limits
of POVRay and I couldn't tell that the scale statement did any
more than change the cameras position when the camera was not
at the <0,0,0> coordinates. But, in these tests I never did use
a non uniform scale, so I don't know yet.
I would hope that the camera could be a "special" object type
that like lightsources, would only pick up the location/orientation
information from the objects they are unioned with. I certainly
don't think that picking up any normal{} information in the
"lens" would be a good thing.
Warp wrote:
>
> Tom Melly <tom### [at] tomandlucouk> wrote:
> : Like a point light-source?
>
> A point light-source has no dimensions, while a camera has.
>
> If a scale command in the union only changes the location of the camera,
> then it would be contradictory to what happens if the same scale command
> is inside the camera statement.
> If the scale command in the union affects the camera in the same way as
> if it was inside the camera-statement (ie. the camera geometry is changed
> accordingly), that may not be what people usually want.
>
> So it's not such a trivial question.
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr. Art <mra### [at] chesapeakenet> wrote:
: But, in these tests I never did use a non uniform scale
Well, there you are.
: I would hope that the camera could be a "special" object type
: that like lightsources, would only pick up the location/orientation
: information from the objects they are unioned with.
What if somebody really wants it to be consistent and that non-uniforms
scales applied to the union would also apply to the camera?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Personally, I have a hard time visualizing why a person
would want to have a camera view that is distorted
in the modeling processes.
Imagine attaching a camera to the end of a crane. If
you decide the crane needs to be longer and wish to
change the length by scaling, what once might have been
a good camera definition gets distorted. Then you would
have to do more scaling to the camera to get back
to the camera definition that you wanted. Very messy.
And having to follow through a long line of #include
files to find what scaling information had been applied to
a model w/ camera attachment... Forcing someone into that
extreme would get lots of negative comments too.
Warp wrote:
>
> Mr. Art <mra### [at] chesapeakenet> wrote:
> : But, in these tests I never did use a non uniform scale
>
> Well, there you are.
>
> : I would hope that the camera could be a "special" object type
> : that like lightsources, would only pick up the location/orientation
> : information from the objects they are unioned with.
>
> What if somebody really wants it to be consistent and that non-uniforms
> scales applied to the union would also apply to the camera?
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Exactly, but my point was that if a non-uniform scale in the union does
not work in the same way as in the camera, that would be inconsistent with
the default behaviour of POV-Ray transformations. A scale in a union has
the same effect as if you had applied the same scale to each object in the
union separately. It would be inconsistent if the scale suddenly wouldn't
affect one of the items inside the union.
Of course this is not the only place where there are two interpretations of
the same phenomenon and choosing one causes an inconsistency from the point
of view of the other.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think the camera should be scaled non-uniformly if the union it's inside
is scaled non-uniformly. It's the only reliant and fully predictable method.
(It is however likely to produce non-perpendicular vectors, which will
produce an error in many cases).
Anyway, the smart user should not need to worry.
Instead of writing:
union {
object {...}
object {...}
camera {...}
scale Non_Uniformly
}
He would write:
union {
union {
object {...}
object {...}
scale Non_Uniformly
}
camera {...}
}
I can't think of any cases where this wouldn't be a possible solution.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> He would write:
>
> union {
> union {
> object {...}
> object {...}
> scale Non_Uniformly
> }
> camera {...}
> }
Hadn't thought of that. Good point.
I thought of another something for a camera that might make anims a lot
easier: a "lock-on" function that allows you to look at a location
regardless of how the camera gets rotated. This is not as redundant
as it might first sound. If the camera was allowed in unions and the
union was rotated, the direction that the camera looks would no longer
be as was set with look_at, it would be adjusted by the rotation. This
could be a desired result. But to set the camera to look at what you
had hoped to view from your new viewpoint might be a bit tough.
So lets imagine two vector functions:
set_marker: would designate a vector variable as a marker.
get_marker: would return the position of a marker variable.
and an optional keyword for the camera statement:
maybe it could be called "lock_on <vector>".
The marker might work like this:
set_marker{ markername }
the point that is marked is the local
<0,0,0> of the object it is unioned to as it was built.
The named point would then have all scales,
rotations, and translations applied.
get_marker( markername )
the vector returned is the position of the marker
with whatever positional transformations applied.
#declare Position_marker1=<0,0,0>;// name a vector for use.
#declare some_good_looking_object_walking_by =
union {
object {...}
object {...}
set_marker {Position_marker1}
}
#declare someobject=
union {
union {
object {...}
object {...}
scale Non_Uniformly
}
camera {...lock_on get_marker(Position_marker1) }
}
I know that the camera can be specified anywhere in the files for a
scene, but I
don't know when it gets evaluated. For a camera to work as envisioned
here the
camera would have to be evaluated last. This would give the program the
chance
to get all needed information to evaluate the marker variables. The
camera statement
could still come anywhere in the source, it would just be dealt with
last.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There's a nice feature in the povray camera: You don't have to specify all
camera parameters at once, but you can do it in many parts.
This is perfectly possible (or would be, if the camera was allowed in a
union):
union
{ whatever
camera { ... }
lots_of_transformations
}
camera { look_at somewhere }
Currently this means that you can make things like:
camera { location -z*10 angle 35 }
...
camera { rotate x*45 translate x*2 }
...
camera { look_at 0 }
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I always had the impression that the last camera defined
was the one used. I never thought of breaking the camera
definition up into parts. Nice feature.
Warp wrote:
>
> There's a nice feature in the povray camera: You don't have to specify all
> camera parameters at once, but you can do it in many parts.
> This is perfectly possible (or would be, if the camera was allowed in a
> union):
>
> union
> { whatever
> camera { ... }
> lots_of_transformations
> }
>
> camera { look_at somewhere }
>
> Currently this means that you can make things like:
>
> camera { location -z*10 angle 35 }
> ...
> camera { rotate x*45 translate x*2 }
> ...
> camera { look_at 0 }
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr. Art <mra### [at] chesapeakenet> wrote:
: I always had the impression that the last camera defined
: was the one used. I never thought of breaking the camera
: definition up into parts. Nice feature.
A camera statement doesn't define a whole camera from scratch, but instead
changes values of the camera settings (and changes only those specified).
The same works for the global_settings block.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Coolness.
Warp wrote:
>
> Mr. Art <mra### [at] chesapeakenet> wrote:
> : I always had the impression that the last camera defined
> : was the one used. I never thought of breaking the camera
> : definition up into parts. Nice feature.
>
> A camera statement doesn't define a whole camera from scratch, but instead
> changes values of the camera settings (and changes only those specified).
>
> The same works for the global_settings block.
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
