El 06/03/16 a las 14:04, William F Pokorny escribió:
> In the meantime I did find some time and attempted a mesh camera
> solution. See the attached POV-Ray file. Please read the header in
> the file as there are some quirks with how scenes must be set up and
> the resultant image used.

   I think you nailed it, only to have it rendered unnecessary in a
matter of hours with the new function-based camera. :( But at least
you illustrated a point: the meshcam is a great feature with yet unknown
uses.

--
jaime

Post a reply to this message

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

   Typical POV-Ray developer mindset: why solve an specific usage case
when you can have it all? :)

--
jaime

Post a reply to this message

> There are a lot of VR Headset now in the market.
> Oculus Rift, GearVR, HTC Vive, Google cardboard etc.
> Also YouTube support 360 panoramic.
>
> I understand there are a lot of options about rendering with other raytracing
> software, but i don't find any information about Povray.
>
> The projection model it's called ODS and is full explained in this Google doc:
> https://developers.google.com/cardboard/jump/rendering-ods-content.pdf
>
> I'm trying to render an ODS, 360 3D shot with Povray.
> There are a function inside the above doc that return the viewing ray for a
> given pixel in raytracing,
> but i don't understand how to use it in Povray.
>
> Any advice? Thanks.
>
>

I see a problem if anyone tries to prerender an omnidirectional stereo 
image: When looking up, or down, not even verticaly, and turning around, 
the DIRECTION of the offset need to change. It can be done using real 
time, raster line rendering. I highly doubt it's even remotely possible 
if the image is to be rendered before hand.
And, what about tilting your head? Tilt your view by any amount, and the 
direction of the offset will change.
That's why the Oculus Rift gear need top of the line gaming oriented 
computer using behemoth video adapters.

If the image is to be sphericaly mapped, using non-stereo imagery, it 
can be done easily without the mesh camera.
Just use:
camera{
  ultra_wide_angle
  location 0
  up y
  right x*2
  look_at z
  angle 360
}


Alain

Post a reply to this message

> Would you please render, view and
> let us know if the result OK or not?


Your .pov in attachment, rendered with square 2048x2048 resolution:
http://www.clodo.it/host/images/5f9811c6314aefa13bc7f619424fd0537f2b9483.png

Rotate 90 CW with an external image:
http://www.clodo.it/host/images/ec5b3235955cef0cbab6707b4a54259dcbd111dc.png

and played in VR headset (spherical environment, stereo top/bottom) look almost
ok in front view, but
looking vertically up, there are issue:
http://www.clodo.it/host/images/252fbce0fdc3188a7e1a2fedd7da7ba75e0471bc.jpg
look the "leg" of the X, it's deformed and inverted between eyes.

Sorry but it's difficult to understand if the 3D effect is correct in your
example, and i'm fail to render other scenes.
I took the "spherical.pov" sample from Povray distribution.
standard camera{spherical} render (2048x2048):
http://www.clodo.it/host/images/4ecb53b74a7ffdb39369f14fd2664aeb7c6aa817.png
Simply comment the camera, adding your code (final .pov on pastebin:
http://pastebin.com/ajyHzH1E )
render:
http://www.clodo.it/host/images/69f31e143d340ce078a07a349108b0466271b868.png

Also my scene with your mesh camera render totally unexpected big pixels:
http://www.clodo.it/host/images/160d46699c5da84daa11d06362b36856173497a7.jpg


All tests rendered with version 3.7.0.msvc10.win64, the official stable.

--------------------------------
In the mean-time, i compiled the patch of Paul Bourke
http://paulbourke.net/stereographics/povcameras/
with old PovRay 3.6.1 sources, with my scene with floating spheres,
settings zero-parallax far away (1000), IPD 0.065 and test in with VR headset.
For me, it's perfect, projection, scale and 3D effect.

I still have issue to porting it to POV-Ray 3.7, i don't know how to convert
VLinComb3, Ray->Initial etc.

--------------------------------
The new function-based user-defined camera available in 3.7.1 alpha look
interesting, but i'm totally newbie about using it to render a spherical stereo.

Post a reply to this message

@Bill P, a little note:
You try to render both eye in a single renderer.
Paul Bourke patch require two different render (manual switch of IPD), and mix
with an external editor image.
I don't think that two different rendering is a bad approach, also because there
are many standard out there (some people render top/bottom, other side-by-side
etc). If the render of both eye is cause of trouble with the mesh, i think you
can skip it, imho. Just my cents.

Post a reply to this message

Am 06.03.2016 um 18:40 schrieb Jaime Vives Piqueres:

>> 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:
> 
>   Typical POV-Ray developer mindset: why solve an specific usage case
> when you can have it all? :)

Indeed. I really felt that it was high time to add /some/ means of
generating stereoscopic imagery that didn't involve excessive parsing
times (which I think is the biggest drawback of the mesh camera), but
implementing OSD support would have taken a few more days, and would
also have come with the risk of me screwing up the maths.

So I decided to just implement a basic generic solution, and leave the
work and the screwing-up to you guys :P

(No kidding. This /is/ indeed the main reason I've implemented the
user-defined camera just right now.)

An obvious benefit is of course that the implemented mechanism can be
used just as well for arbitrary other camera formats waiting to be
implemented in POV-Ray, including light probe-style angular and cube
mapping, side-by-side stereograms, mercator and other map projections
for your self-made virtual planet, and what-have-you-not.

Post a reply to this message

Now i started from Bill mesh camera .pov file.
Commenting camera mesh part, adding a simple camera{spherical} :
http://www.clodo.it/host/images/0f258e33fe64385e5f9b465a13644a9295ee3118.png
tested on Rift DK2, perfect (but 2D).

Now, i convert it to PovRay 3.6:
http://pastebin.com/Yx74HQ3i
- convert srgbft to rgb
- convert text "internal 1" to "ttf "timrom.ttf""
- comment #version 3.7
- removed mesh directives

Adding Paul Bourke camera syntax, render with PovRay 3.6.1 patched,
left eye:
http://www.clodo.it/host/images/1f2635881f4bab3d5ae82b805aa032435e8b588c.png
right eye:
http://www.clodo.it/host/images/1a2fb3332d9ae97699138b7e4debff075ea70d33.png

Mixed in a unique 4096x4096 (left image on top, right image on bottom) and
tested with Rift DK2.

In my previous message i tell that Paul Bourke method is perfect: not true,
sorry.
The above stereo image generated with Paul method have a correct aspect (X,Y,Z
at right place), but if i'm looking at top <0,+inf,0>
it's seem it render a spiral at infinite (like the Escher spiral). On both Y+
and Y- 'horizon'.
This seems the same issue that occur in mesh camera method, the "deformed leg"
of the X.
Sorry i don't know how to explain it better.

The default 2D camera{spherical} don't have this issue, it's perfect.

So, the situation imho:
0- Default camera{spherical}: 2D only, but perfect.
1- Bill mesh camera method: Y spiral issue, aspect-ratio restrictions, other
undefined issues
2- Paul Bourke stereospherical method: Y spiral issue.
3- Clipka function-based user-defined camera method: anyone can build a .pov
example to test? Thanks.

Post a reply to this message

My brainstorming method:

Default camera{spherical} render pixels columns from 0 to 360 angle. Ok.
Alter the current spherical behiavour by adding a single param "eye-offset"
(generally +/-0.065/2)
For each pixel, if "eye-offset" it's not 0 (for compatibility)
 rotate the vector3 <-eye_offset,0,0> to the same rotation Y axis of the pixel
column current rendering
 and adding it to the 'location' of the camera for the current pixel
computation.
If anyone can suggest to me how to hack the tracepixel.cpp, i can try it, if
anyone think that can works. I don't know if can generate the Y spiral issue.

Post a reply to this message

On 03/06/2016 04:41 PM, Clodo wrote:
>> Would you please render, view and
>> let us know if the result OK or not?
>
>
> Your .pov in attachment, rendered with square 2048x2048 resolution:
> http://www.clodo.it/host/images/5f9811c6314aefa13bc7f619424fd0537f2b9483.png
>
> Rotate 90 CW with an external image:
> http://www.clodo.it/host/images/ec5b3235955cef0cbab6707b4a54259dcbd111dc.png
>
> and played in VR headset (spherical environment, stereo top/bottom) look almost
> ok in front view, but
> looking vertically up, there are issue:
> http://www.clodo.it/host/images/252fbce0fdc3188a7e1a2fedd7da7ba75e0471bc.jpg
> look the "leg" of the X, it's deformed and inverted between eyes.

Thanks for testing. First, am I correct that the top/bottom vs 
left/right in the stereo VR world refers to the placement of the left 
and right eye images and not to the intended orientation for head 
movement? Think the answer is yes, but want to be sure.

The pull apart up and down with the X doesn't surprise me. What I 
believe is happening is that at the top and bottom we are fulling seeing 
the pupil offset in the ODS approximation. This approximation is not 
noticed where things are all grey, but we see it clearly on the leg of 
the X while happens to be at the top pole.

It seems to me the ODS scheme will work reasonably well at the equator 
so to speak, and less well the further one or both eye tilt off it for 
single top/bottom images. It relates to what Alain said in another post 
to this thread in that to really do things cleanly you pretty much have 
to render another image/frame once one or both eyes much leave the 
existing image's horizontal/pupil equator.

That said. What I've got no clue about is what games might be getting 
played in the VR hardware itself & perhaps I missed some existing 
adjustment when reading the PDF? I can, for example, imagine a scheme 
which forfeits the 3D effect at top and bottom to prevent the visual 
pull apart.

Do you have other golden images where there is a thin shape like the leg 
of the X cross at or very near straight up or down? Might clue us in to 
what special handling gets done at the poles - if any.

>
> Sorry but it's difficult to understand if the 3D effect is correct in your
> example, and i'm fail to render other scenes.
> I took the "spherical.pov" sample from Povray distribution.
> standard camera{spherical} render (2048x2048):
> http://www.clodo.it/host/images/4ecb53b74a7ffdb39369f14fd2664aeb7c6aa817.png
> Simply comment the camera, adding your code (final .pov on pastebin:
> http://pastebin.com/ajyHzH1E )
> render:
> http://www.clodo.it/host/images/69f31e143d340ce078a07a349108b0466271b868.png
>
> Also my scene with your mesh camera render totally unexpected big pixels:
> http://www.clodo.it/host/images/160d46699c5da84daa11d06362b36856173497a7.jpg
>
>
> All tests rendered with version 3.7.0.msvc10.win64, the official stable.

The spherical.pov is set up with the camera location at a y of 10 where 
the mesh camera as defined is at the origin. Something I should have 
added as a note in the header is that the usual available camera {} 
transformations do not work with the mesh camera. You can move the mesh 
camera to the same location at the spherical camera in spherical.pov by 
changing the line :

  mesh { Mesh00 rotate x*(360*(i/ImageHeight))}

to

  mesh { Mesh00 rotate x*(360*(i/ImageHeight)) translate <0,10,0> }

This will eliminate the big pixels - at 0,0 the camera is sometimes at 
or in the scene's plane.

This leaves us with the fact spherical.pov is set up as shapes on the 
X,Z plane Y up which doesn't match the ODSC mesh cameras fixed X+ up so 
the result will be oriented differently than the spherical camera result.

>
> --------------------------------
> In the mean-time, i compiled the patch of Paul Bourke
> http://paulbourke.net/stereographics/povcameras/
> with old PovRay 3.6.1 sources, with my scene with floating spheres,
> settings zero-parallax far away (1000), IPD 0.065 and test in with VR headset.
> For me, it's perfect, projection, scale and 3D effect.
>
> I still have issue to porting it to POV-Ray 3.7, i don't know how to convert
> VLinComb3, Ray->Initial etc.
>
> --------------------------------
> The new function-based user-defined camera available in 3.7.1 alpha look
> interesting, but i'm totally newbie about using it to render a spherical stereo.
>

Yes, cool feature for sure & not just for stereo implementations. I too 
would need to think for a bit on how to code up the ODS camera with it.

Bill P.

Post a reply to this message

On 03/07/2016 07:27 AM, William F Pokorny wrote:
...

I took a quick look at the Google PDF again and with respect to the X 
leg pull apart at the pole and I see this note:

"Objects appearing directly above or below the camera should remain at 
least 3.5m from the camera (relative to an IPD of 6.5 cm)."

I placed the text much closer (1m?) and I think the "rule" above is 
precisely about minimizing the distortion of shapes at the poles.

Bill P.

Post a reply to this message