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