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