On 03/08/2016 04:56 PM, Clodo wrote:
> The big issue it's the same issue that also have the "Bill P. mesh camera" and
> "Paul Bourke povray 3.6 patch":
> near the polar in Y axis, a spiral effect.
>
> http://www.clodo.it/host/images/42c1548d0620db0c5e54324e6ad6cd23ee86f8fb.png
>
> Tested with two of more popular image/video player for Oculus Headset: Virtual
> Desktop & MaxVR . No differences.
>
On your modification of source code for this camera - well done!

Interesting to me too is that the green cylinder behind the Y+ character 
at the pole in your image is 10m away - much more than the 3.5m the 
Google ODS PDF recommends at the poles - and no distortion is apparent 
for that shape to my eyes.

Supposing the distortion is in fact out at those distances too, but 
given image resolution & typical environments (ground/sky) at larger 
distances we often enough won't see it.

The ODS "rule" of >=3.5m open space at the poles is certainly 
inconvenient given typical human dimensions and our inside environments. 
Light fixture on a ceiling, a patterned throw rug on the floor or 
walking through a doorway as problematic examples. :-)

Bill P.

Post a reply to this message

On 03/09/2016 08:17 AM, Clodo wrote:
>
> Thanks clipka.
>
>
> Quick Benchmark: scenes/camera/spherical.pov, 4096x2048 AA 0.3, no-stereo
> (tested 3 times each).
> All three method generate the same identical image.
> ----------------
> Default camera{spherical}: 22 seconds
> ----------------
> With my C implementation of ODS, direct in tracepixel.cpp (
> http://pastebin.com/fJ0Z978Q ), mode 0 (no-stereo): 19 seconds
> ----------------
> With the below user-defined camera: 22 seconds
>
> #declare ipd = 0.065;
> #declare eye = 0; // 0: No-Stereo, 1: Left, 2: Right
> camera {
>        user_defined
>        location {
>          function { cos((x+0.5) * 2 * pi - pi)*ipd/2*eye }
>          function { 0 }
>          function { sin((x+0.5) * 2 * pi - pi)*ipd/2*eye }
>        }
>        direction {
>          function { sin((x+0.5) * 2 * pi - pi) * cos(pi / 2 - (1-(y+0.5))*pi) }
>          function { sin(pi / 2 - (1-(y+0.5))*pi) }
>          function { cos((x+0.5) * 2 * pi - pi) * cos(pi / 2 - (1-(y+0.5))*pi) }
>        }
>      }
> ---------------
>
> clipka, my C implementation can render directly in one image both side-by-side
> or top-bottom.
> I was unable to do the same thing with user_defined camera.
> Besides the need of declaration/computation of common variables theta/phi in
> each vector3 components (i can't find a method to define it outside),
> i don't find the right syntax for inject some #if.
> For example
> function { #if(x<0.5) x #else 1/x #end }
> don't work...
> I'm missing something about syntax, or isn't possible? Thanks for any feedback.
>
>
>
Functional camera implementation - again well done.

There is a select() function which I think will work for you.

Bill P.

Post a reply to this message

Sorry, a mistake:
#declare eye = 0; // 0: No-Stereo, 1: Left, 2: Right
it's wrong, the correct is
#declare eye = 0; // 0: No-Stereo, -1: Left, +1: Right


Anyway, i still think the above user-defined camera can be used as proof of
concept of the new great camera type.
But imho ODS (used by up-coming VR market) deserve a C implementation, with
user-friendly params for users.
Maybe current 'spherical' can be extended with ODS params, maintain backward
compatibility if absent, without need a new camera type.

Writing a full ODS user_defined camera, considering both eyes render in
different formats, and also start location and direction, can result in a huge,
unreadable macro.

Just my cents.

Post a reply to this message

> There is a select() function which I think will work for you.

Thanks!


// user_defined camera, OSD, both eyes in one image side-by-side.
#declare ipd = 0.065;
#declare cameraLocationX = 0;
#declare cameraLocationY = 10;
#declare cameraLocationZ = 0;
camera {
      user_defined
      location {
        function { cameraLocationX + cos(select(x,(x+0.5)*2,(x*2)) * 2 * pi -
pi)*ipd/2*select(x,-1,1) }
        function { cameraLocationY }
        function { cameraLocationZ + sin(select(x,(x+0.5)*2,(x*2)) * 2 * pi -
pi)*ipd/2*select(x,-1,1) }
      }
      direction {
        function { sin(select(x,(x+0.5)*2,(x*2)) * 2 * pi - pi) * cos(pi / 2 -
(1-(y+0.5))*pi) }
        function { sin(pi / 2 - (1-(y+0.5))*pi) }
        function { cos(select(x,(x+0.5)*2,(x*2)) * 2 * pi - pi) * cos(pi / 2 -
(1-(y+0.5))*pi) }
      }
    }

Render:
https://www.clodo.it/host/images/b6175498afef1f961cfed2d2dba2c5b5df515f39.png

Post a reply to this message

Le 06/03/2016 15:49, clipka a écrit :
> Y'all might want to try the latest and greatest POV-Ray development release:
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8509766%2Bav119
> 
> It adds a new function-based user-defined camera:
> 
>     camera {
>       user_defined
>       location {
>         FUNCTION, // x-coordinate of ray origin
>         FUNCTION, // y-coordinate of ray origin
>         FUNCTION  // z-coordinate of ray origin
>       }
>       direction {
>         FUNCTION, // x-coordinate of ray direction
>         FUNCTION, // y-coordinate of ray direction
>         FUNCTION  // z-coordinate of ray direction
>       }
>       CAMERA_MODIFIERS
>     }
> 
> where each FUNCTION takes the screen coordinates as parameters, ranging
> from -0.5 (left/bottom) to 0.5 (right/top).
> 

It's nice, but it is not generic enough:
you cannot have a non-traced area, like for fisheye and omnimax camera.

Yep, give me a finger, I would take the arm to the elbow... of the other side, with a
leg or two.

(where to I put the whole collection of smileys ?)

Post a reply to this message

Am 09.03.2016 um 21:12 schrieb Le_Forgeron:
> Le 06/03/2016 15:49, clipka a écrit :
>> Y'all might want to try the latest and greatest POV-Ray development release:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8509766%2Bav119
>>
>> It adds a new function-based user-defined camera:
>>
>>     camera {
>>       user_defined
>>       location {
>>         FUNCTION, // x-coordinate of ray origin
>>         FUNCTION, // y-coordinate of ray origin
>>         FUNCTION  // z-coordinate of ray origin
>>       }
>>       direction {
>>         FUNCTION, // x-coordinate of ray direction
>>         FUNCTION, // y-coordinate of ray direction
>>         FUNCTION  // z-coordinate of ray direction
>>       }
>>       CAMERA_MODIFIERS
>>     }
>>
>> where each FUNCTION takes the screen coordinates as parameters, ranging
>> from -0.5 (left/bottom) to 0.5 (right/top).
>>
> 
> It's nice, but it is not generic enough:
> you cannot have a non-traced area, like for fisheye and omnimax camera.
> 
> Yep, give me a finger, I would take the arm to the elbow... of the other side, with
a leg or two.

Ooooh -- I can give you _the_ finger if you like:

To identify regions that should be left untraced, simply have the
`direction` functions all return 0. :P

Post a reply to this message

My current ODS user_defined camera (side-by-side only):

#declare odsIPD = 0.065;
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsDirectionX = 0;
#declare odsDirectionY = 0;
#declare odsDirectionZ = 1;
camera {
      user_defined
      location {
        function { odsLocationX + cos(select(x,(x+0.5)*2,(x*2)) * 2 * pi -
pi)*odsIPD/2*select(x,-1,1) }
        function { odsLocationY }
        function { odsLocationZ + sin(select(x,(x+0.5)*2,(x*2)) * 2 * pi -
pi)*odsIPD/2*select(x,-1,1) }
      }
      direction {
        function { sin(select(x,(x+0.5)*2,(x*2)) * 2 * pi - pi) * cos(pi / 2 -
(1-(y+0.5))*pi) }
        function { sin(pi / 2 - (1-(y+0.5))*pi) }
        function { cos(select(x,(x+0.5)*2,(x*2)) * 2 * pi - pi) * cos(pi / 2 -
(1-(y+0.5))*pi) }
      }
    }


I want to complete it and clean/optimize it, maybe useful in docs as example if
it deserves.
- In original Google docs formula about ODS, there isn't any reference about the
starting location and direction of the camera.
  The above code render always in forced direction <0,0,1>.
  Anyone can help me about where to place the odsDirectionX,Y,Z unused
variables? I don't know almost nothing about 3d maths...
- There is a function that return a float component from a given Vector?
  I aim to write
  #declare odsDirection = <0,1,1>
  and in function
  odsLocation.X
  ...
  because i'm forced to have six function that return float for location and
direction,
  or i can write two function that return a Vector?

Post a reply to this message

Hi to all, some update on this topic.

I done a lot of test, and, for me, the Google ODS docs:
https://developers.google.com/cardboard/jump/rendering-ods-content.pdf
are simply wrong (i mean the raytracing suggested algorithm).

I write a mail (i'm still waiting for a feedback) to Mach Kobayashi, that seem
related to the work:
https://community.renderman.pixar.com/article/991/rendering-for-vr.html

This .pov source: http://pastebin.com/aPbGSDud
generate this image with the Google ODS formulas:
http://www.clodo.it/host/images/f6febe4d2a5739483562719923fc528c31ac378b.png

With my Oculus Rift, the front and bottom view are perfect, but looking
left and right the 3D seem reversed.
Focus on the little 4 yellow balls (front, left, right, bottom).
Look here, i manually draw yellow lines:
http://www.clodo.it/host/images/50ca1ff17fc834e167d44c0ab24484acd90bfd3f.jpg
From what i understand, on top (left eye) image, yellow ball need to
stay always at right of the yellow line.
---------------------
So, i rewritten the ODS with another logic:

// ODS, Top/Bottom
#declare odsIPD = 1;
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsAngle = 90;
camera {
      user_defined
      location {
        function {  odsLocationX +
select(-y,-1,+1)*odsIPD/2*cos(-pi+2*pi*(x+0.5+odsAngle/360))}
        function {  odsLocationY }
        function {  odsLocationZ +
select(-y,-1,+1)*odsIPD/2*-sin(-pi+2*pi*(x+0.5+odsAngle/360))}
      }
      direction {
        function {  sin(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2
-select(y, 1-2*(y+0.5), 1-2*y) * pi) }
        function {  sin(pi / 2 - select(y, 1-2*(y+0.5), 1-2*y) * pi) }
        function {  -cos(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2
-select(y, 1-2*(y+0.5), 1-2*y) * pi) * -1}
      }
    }

I removed the Google ODS ray_origin formulas.

user_defined location function X it's in range -0.5..0.5, and in panoramic mean

So i used it to rotate the IPD vector <-/+IPD,0,0> around Y axis.

Now it's correct:
http://www.clodo.it/host/images/66a61ebcd04180d9203276741ad78075262d20a3.jpg
and look perfectly in all direction with Oculus Rift.

Here:
https://forums.oculus.com/viewtopic.php?f=28&t=30854
there are some updated sample rendering.
---------------------
I'm almost ready to build a POV-Ray Wiki page about ODS, i need only to write
user_defined function for side-by-side and single-eye versions.

Post a reply to this message

Am 22.03.2016 um 02:55 schrieb Clodo:

> This .pov source: http://pastebin.com/aPbGSDud
> generate this image with the Google ODS formulas:
> http://www.clodo.it/host/images/f6febe4d2a5739483562719923fc528c31ac378b.png
> 
> With my Oculus Rift, the front and bottom view are perfect, but looking
> left and right the 3D seem reversed.

That's no surprise, because in the camera direction Z-axis formula you
have a surplus "-1" factor at the end that's /not/ in the original
Google formulae.

If this is intended to compensate for a left-handed vs. right-handed
coordinate system, you need to apply the same factor to the camera
location Z-axis formula.

> So, i rewritten the ODS with another logic:
...
> Now it's correct:

That depends on what spatial orientation you originally aimed for;
removing the surplus "-1" factor gives a different result, flipping the
handedness and looking in the -Z direction rather than the +Z direction.


My suggestion would be to go back to the original Google ODS formulas,
and use a factor "Handedness" rather than a constant "-1" (also, make
sure to use the factor on both Z-axis formulae), which can then be set
to either "-1" for left-handed or "1" for right-handed.

Post a reply to this message

> That's no surprise, because in the camera direction Z-axis formula you
> have a surplus "-1" factor at the end that's /not/ in the original
> Google formulae.

Ouch. Caused by my incompetence in 3D math... i'm a software security expert,
i'm working on ODS only for fun.

> My suggestion would be to go back to the original Google ODS formulas,
> and use a factor "Handedness" rather than a constant "-1" (also, make
> sure to use the factor on both Z-axis formulae), which can then be set
> to either "-1" for left-handed or "1" for right-handed.

Reverted to the original Google ODS:

// ODS - Top/Bottom
#declare odsIPD = 0.065; // Interpupillary distance
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsHandedness = -1; // "-1" for left-handed or "1" for right-handed
#declare odsAngle = 0; // Rotation, clockwise, in degree.

camera {
      user_defined
      location {
        function {  odsLocationX + cos(((x+0.5+odsAngle/360)) * 2 * pi -
pi)*odsIPD/2*select(-y,-1,+1) }
        function {  odsLocationY }
        function {  odsLocationZ + sin(((x+0.5+odsAngle/360)) * 2 * pi -
pi)*odsIPD/2*select(-y,-1,+1) * odsHandedness }
      }
      direction {
        function {  sin(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2
-select(y, 1-2*(y+0.5), 1-2*y) * pi) }
        function {  sin(pi / 2 - select(y, 1-2*(y+0.5), 1-2*y) * pi) }
        function {  -cos(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2
-select(y, 1-2*(y+0.5), 1-2*y) * pi) * odsHandedness }
      }
    }

The GOOD news for me: this generate pixel per pixel the same image of my
rewritten version of yesterday night.

So, the function above seem the release candidate for the Wiki page. I will
prepare the equivalent side-by-side and single-eye.

Thanks, thanks, thanks for your feedback.

Post a reply to this message