 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] tomandlu couk> 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
|
|
| |
| |
|
|
|
|
| |
|
|
