[Paraview] VRPlugin (some feedback)

[Nikhil Shetty]

Hi Stephan,

Thank you for the feedback. I'm eager to learn more about your experience
on Windows. I must admit that's the least tested platform for our VR
development (due to our client's VR systems primarily being Linux driven).

It will be great to know more about what issues you encounter.

-Nikhil


On Tue, Feb 14, 2012 at 6:21 AM, Stephan Rogge
<Stephan.Rogge at tu-cottbus.de>wrote:

> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120214/3a965087/attachment.htm>