[Paraview] On further investigating the VRPlugin

[Aashish Chaudhary]

Hi Emiliano,


On Sat, Mar 1, 2014 at 2:40 AM, Emiliano Pastorelli <hogancito at gmail.com>wrote:

> Hi All,
> I managed to achieve an almost optimal configuration of screens and
> tracked devices on a small 3-screens display (through vrpn only yet, I use
> a razer hydra to track the wands interaction and a wintrackerIII for the
> head position).
> Now with all of that properly configured, i had a chance to test more in
> detail the vrplugin.
>
> My feeling is that it's based on a couple of wrong assumptions.
> One above all, it's based on the origin of the scene. That means that if
> you're moving you're object a bit around (and i've seen most of the users
> do it a lot), at a certain point the head movement goes wrong.
>

it depends on whether or not object is in front of the project plane or
behind. depending on your configuration it may be feel its moving quite a
bit. As a test move your object's center on the project plane Z and it
should rotate around that point.


> If I try with a simple cylinder built on the origin, and i bring it on the
> 0,0,0 of my system (defined in the cave file in relation to my screens
> potions), then the head movements are correct.
> If my move my head to the left, i see the object correctly "rotating" so
> to show me his right side (considering the cylinder facing me) and it
> slides to its own left a bit as it should (therefore also moving properly
> among the screens as well).
> But if i push the cylinder back a bit, cause maybe i wanna have a look at
> it in smaller size, then i move the head to my left, the object also moves
> to the left, in a completely wrong behavior.
> Shouldnt therefore the 0 of the tracker always be based on the 0 of the
> system and not on the 0 of the scene?
>
> Also, the translation with the wand works well, it's natural to be used,
> but the rotation axis, move with each consecutive rotation of the scene,
> and therefore, if i first rotate on one axis the scene, the second rotation
> is gonna be based on the already transformed axis system, and soon it will
> become completely unnatural (not a single test user i had on the system
> felt confident with it).
>

I see. Sorry, we couldn't send you the latest code. I am still waiting for
our collaborator to push the code we had. I believe this is fixed in there.


>
> I see that not many people are using paraview in VR environments, but i
> think with the proper adjustments it could really become a popular tool,
> specially in low cost VR systems like mine (thanks to the fact that doesn't
> require any expensive lib to run).
>

Thanks. On this note, please feel free to push your changes / patches to
ParaView Gerritt or over the email. I am more than happy to review them.

>
> One last thing, i'm running paraview on a single 16-cores machine with 4
> Nvidia4000 (one for each screen, each with 2 DLP projectors and one for the
> control displays), and specially when i deal with volume visualization,  it
> tends to be even slower than when i run it single screen in my other simple
> test machine that only has a 4-core and nvidia 600. Is there any known
> reason for that?
>

I am surprised that volume rendering is working for you in the VR
environment correctly. Did you choose smart mapper for the volume
rendering?

- Aashish


>
> Best,
> H
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
>



-- 
| Aashish Chaudhary
| R&D Engineer
| Kitware Inc.
| www.kitware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20140306/8cb94fff/attachment-0001.html>