|
 |
I write a post on my blog about all my ODS experiments with POV-Ray:
https://www.clodo.it/blog/omni%C2%ADdirectional-stereo-ods-with-pov-ray/
The post contain the latest edition of ODS user_defined camera.
I hope that can be the final version, and my experiment can be useful to anyone
as starting point to explore this subject.
Any of my works can be used as public-domain, for example if POV-Ray team want
to use as sample in docs or wiki.
I still think that ODS will deserves a C++ user-friendly implementation in
POV-Ray codebase. A lot of video contents are under development around the
upcoming VR market.
Ciao!
Fabrizio Carimati / Clodo
Post a reply to this message
|
|
|
|
Le 03/04/2016 20:23, Clodo a écrit :
> I write a post on my blog about all my ODS experiments with POV-Ray:
>
> https://www.clodo.it/blog/omni%C2%ADdirectional-stereo-ods-with-pov-ray/
>
> The post contain the latest edition of ODS user_defined camera.
>
Nice text. Really very cool.
> I hope that can be the final version, and my experiment can be useful to anyone
> as starting point to explore this subject.
>
You provide the fast setting as quickres.ini... I would have liked:
* also the various scenes for the above illustrations (if anybody want to make them
again), as downloadable links (no need to display them online)
* maybe instead of adding to quickres.ini, another file name ? (such as easyods.ini ?)
(just a suggestion)
> Any of my works can be used as public-domain, for example if POV-Ray team want
> to use as sample in docs or wiki.
>
> I still think that ODS will deserves a C++ user-friendly implementation in
> POV-Ray codebase. A lot of video contents are under development around the
> upcoming VR market.
The best I could do was adding omni_directional_stereo camera to my own fork
(hgpovray).
It does not have the limitation of camera's direction of your text. (as well as right
& up that can be adjusted too).
Did you see it ?
About the vertical modulation, it was not in the original paper.
Is it now a requirement to have some vertical modulation ?
One of the link (Oculus VR Camera) seems to indicate that the modulation (start and
curve) could
be different for nadir and zenith (each its own settings)
Also on the same link, there is the nvidia cube and 3x2 cube map (in addition to
Longitude+latitude projection),
are there any use or interest for them ?
Do they also need a modulation for nadir & zenith ? (seems so, but I always like
contributions)
Post a reply to this message
|
|
|
|
> Nice text. Really very cool.
Thanks! Note that i'm not english native, and i'm not a math or 3d expert, i'm a
software security expert (ddos, XSS, VPN, stuffs like that). I made this ODS
only for fun.
> * also the various scenes for the above illustrations (if anybody want to make them
again), as downloadable links (no
need to display them online)
I will do.
> * maybe instead of adding to quickres.ini, another file name ? (such as easyods.ini
?) (just a suggestion)
Ouch, i simply don't know the multiple .ini files feature :P
> The best I could do was adding omni_directional_stereo camera to my own fork
(hgpovray).
> It does not have the limitation of camera's direction of your text. (as well as
right & up that can be adjusted too).
> Did you see it ?
No sorry, never tried, i will look soon.
>
> About the vertical modulation, it was not in the original paper.
> Is it now a requirement to have some vertical modulation ?
> One of the link (Oculus VR Camera) seems to indicate that the modulation (start and
curve) could
> be different for nadir and zenith (each its own settings)
It's not a requirement.
But it's an HELL write a user_defined camera function.
Use a odsVerticalModulation of 0.0001 pratically generate the same image we can
obtain without any vertical modulation. So i prefer to not add other select() in
the user_defined formula.
I read a lot about the nadir/zenith issue. But same as above, it's a pain add
different method/params on user_defined function. Much easy in C code.
But i don't know if my patch will be accepted in povray official code, so i
prefer to maintain identical the user_defined function and my C code.
From what i understand, software like 3DS Max, Maya, Softimage etc use
DomeMaster, that apply a simple texture to filter that.
At the end, it's a limit of ODS, and content creator need to avoid object at
nadir/zenith. I prefer to avoid additional complexity of user_defined functions
right now.
> Also on the same link, there is the nvidia cube and 3x2 cube map (in addition to
Longitude+latitude projection),
> are there any use or interest for them ?
> Do they also need a modulation for nadir & zenith ? (seems so, but I always like
contributions)
Theory VS practice. I own an Oculus Rift and soon a Vive. Pratically there isn't
any image/video player that support cubemap, or are very very rare. For this
reason, i don't know anything about that.
There are a lot of website that share video/image for HMD, i never seen a
cubemap format, always omnidirectional (Stereo or Mono).
I'm working on another project right now, but i hope soon to test your hgpovray
fork.
Ciao!
Post a reply to this message
|
|
