Le 24/03/2012 02:45, clipka nous fit lire :
> Am 23.03.2012 19:22, schrieb Le_Forgeron:
> 
>>> We definitely need custom-projection warps and cameras. You know, with
>>> functions defining the projection.
>>
>> For custom-camera, you would need a way to output 2 vectors (origin,
>> direction) from the inputs of 4 vectors (location, up, right,
>> direction), 2 doubles between 0 and 1, and whatever you do with them as
>> hard-coded/SDL-coded formulas (including other SDL data and hard-coded
>> values).(you might see it as a function of 2 doubles which must provides
>> 2 3D-vectors)
> 
> Not really.
> 
> The location, up, right & direction vectors just orient the camera;
> that's a simple matrix operation that is independent of the projection
> formula.
> 
> For a truly generic projection we'd need six funcions, each taking two
> numbers (X and Y coordinate in resulting image): Ray origin X,Y,Z and
> ray direction X,Y,Z.
> 
> For any cartographic projection, two functions would suffice: From two
> screen coordinates (X,Y) we'd have to compute two spherical coordinates
> (phi and theta).
> 

Unless you are always mapping from below (center of the planet), I
prefer for an absolute custom camera to be able to set the origin and
direction of each ray (well, each pixel ray, as well as AA sub-rays).
It seems more natural to thing of the camera as a flying satellite
(well, rather a parallel set of raster satellites using their own single
"laser beam"). Probably something along a mathematical-function(s) based
"mesh camera" (without a mesh)

[so far, I have no intent to implement that fully custom camera. yet ?]

It could also allow for easy (easier ?) setting for stereographic render
(half left-picture for left eye, half right-part for right eye)
(not sure about naming that stereographic)

Simulating the eye(s ?) of bee or fly could also be done (once someone
found the formula)

>> Did you say projection warps ? I would have thought about projection
>> map_type.  (from a 3D point, some others data (assume origin&  other ?),
>> provide a couple of doubles : integer part can be used to isolate the
>> "once" (0.x,0.y) and the part after the dot is the coordinate on
>> map/picture (scale to 0 to 1 in both direction)
> 
> Map types can only be used with input images; implementing the stuff as
> a custom warp instead would allow to do the same operations on other
> patterns as well.

Oh, nice thought. I would never have added a warp in a pigment/image_map
to change its type. Nor using a classical pattern.

maybe it would be "safer" to drop map_type and push the usage of warp
(doing it one way) for image_map.

About using other pattern, it might be more troublesome, as some are
really 3D and cannot be limited to a plane. (and other are using more
than just the position).

Post a reply to this message