[Paraview] VRPlugin (some feedback)

[Stephan Rogge]

Hello Nikhil,

yeah, I see it. I've test the plugin and seems to me it is working. 

Under Windows a small error during compilation occurs in
"vtkVRConnectionManager.cxx". 
When PARAVIEW_USE_VRPN is defined the internal member "QPointer<vtkVRQueue>
Queue;" would not be declared. Moving this line behind that check works for
me.

struct vtkVRConnectionManager::pqInternals
{
#ifdef PARAVIEW_USE_VRPN
  QList<QPointer<vtkVRPNConnection> > VRPNConnections;
#endif
#ifdef PARAVIEW_USE_VRUI
  QList<QPointer<vtkVRUIConnection> > VRUIConnections;
#endif
  QPointer<vtkVRQueue> Queue;
};


Cheers,

Stephan

Von: Nikhil Shetty [mailto:nikhil.shetty at kitware.com] 
Gesendet: Montag, 13. Februar 2012 19:36
An: Stephan Rogge
Cc: paraview at paraview.org; Christian Wohlschlager; Aashish Chaudhary
Betreff: Re: [Paraview] VRPlugin (some feedback)

Hi Stephan,
On Fri, Feb 10, 2012 at 3:39 AM, Stephan Rogge <Stephan.Rogge at tu-cottbus.de>
wrote:
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.

This is fixed in the latest code (you may have already noticed). There were
a few API incompatibilities with the latest paraview code and the VR Plugin
which got fixed. 
 
Where I can deactivate QTSOCK? There is no option in cmake-gui visible. Or
is this feature
And the future?
The QTSOCK will definitely be gone. Its not even an option (just old code :)
). The future!!! Well it mainly depends on what people would like to see and
who's funding it. But with the current round of funding there are a few
things in the immediate pipeline. 

1. Support for side-by-side stereo (for 3dtv's etc in VTK).
2. Adding tests for VR plugin (so be can better identify breakage).
3. Fly-mode interactor style.
4. Hopefully a better way of configuring VR displays and inputs (maybe
implementing a GUI for this). But this is of lower priority for now.

-Nikhil


@ 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