[Paraview] VRPlugin (some feedback)

Stephan Rogge Stephan.Rogge at tu-cottbus.de
Fri Feb 10 03:39:58 EST 2012


Hello,

@Christian: 
I cannot say, that we have problems by displaying data bigger than 7.5 MB. 
Our focus lies on CFD visualization. But when I understand the other threads
right, 
this problem has been identified.

@Nikhil: 

>> Further modifications was necessary in the the vtkVRStyleTracking in
order
>> to update the HeadPose. The proxygroup name must be changed to "views".
The
>> group name "interactorstyles" in the post mentioned above is NOT working,
>> otherwise the plugin crash, since no proxy or property can be found and
the
>> pointer are still NULL after configuration.
>>
> What you did is hardcoded to the view. The tracking style can be used for
> tracking other things like the hand etc. This is configurable from the
> state file (see document).

In my last post I wrote about the problem of defining the the proxy group
name. I've made
a mistake and addressed the class "vtkVRStyleTracking" for this
modification. This is not
the case. 
The class "vtkVRInteractorStyle" with its method 
"GetProxy( std::string name, vtkSMProxy ** proxy )" required that
modification. And here
I had to "hardcoded" the proxy group name "view" as a first parameter. I
think, the group 
name shall be provided as an additional parameter or attribute in the *.pvsm
file.

Where I can deactivate QTSOCK? There is no option in cmake-gui visible. Or
is this feature
And the future?


@ Aashish:
Ok. So I have to concentrate more on tracking system calibration :-). What
is the best approach
of defining the room coordinate system? I have chosen a symmetric approach.
Our system
consists of two walls with an angle of 112° which means, those two walls
construct a triangle.
The user looks into the corner of the triangle. The origin of my room
coordinate system is
the center of the triangle base. All edge points of the two screens are
defined in respect to
this coordinate system. My question is, is this a good approach? Or should I
place the origin 
directly on of those edge points?


Nevertheless, many thanks for your valuable answers.

Cheers,
Stephan 


>>> "Stephan Rogge" <Stephan.Rogge at tu-cottbus.de> 2/8/2012 1:38 PM >>>

Hello,

I’ve start to work intensively with the VRPlugin from git-master and want to
get some feedback. First of all it works almost great :-). As a tracking
system I’m using A.R.TrackPack2 with two infrared cameras and their VRPN
server implementation.

To be able to compile that Plugin some modifications were necessary:
*  As mentioned in this post
(http://www.paraview.org/pipermail/paraview/2012-February/023816.html) the
proxy API undergone some changes. But it seems, that the author of this post
mixed up the parameter order.  He referred to proxy name and proxy group.
But it has to be swapped...
* Not important to me but required  to compile without errors:  In
vtkVRUIPipe.h the flag QTSOCK is checked for existence. I had to put it in
manually ("#define QTSOCK 1"). Don't know why.

Further modifications was necessary in the the vtkVRStyleTracking in order
to update the HeadPose. The proxygroup name must be changed to "views". The
group name "interactorstyles" in the post mentioned above is NOT working,
otherwise the plugin crash, since no proxy or property can be found and the
pointer are still NULL after configuration.

But so far, I was able to use the VRPlugin in ParaView in a two-side VE and
I've got the feeling, that virtual object placed in front of the screens...
:-)

Now, I have a kind of problem. When I am moving parallel (left to right) to
the screens, I can observe a sort of rotation which can be not described as
moving parallax. It seems, that the rotation point lies in the center of my
projection displays. Object which came out of screen "standing" not on the
same position. They are flying around. So, my question is addressed to
experienced Virtual Reality user: Is this described behavior right or not?

Cheers,
Stephan



More information about the ParaView mailing list