Hi Stephan,<div><br></div><div>Thank you for the feedback. I&#39;m eager to learn more about your experience on Windows. I must admit that&#39;s the least tested platform for our VR development (due to our client&#39;s VR systems primarily being Linux driven).</div>
<div><br></div><div>It will be great to know more about what issues you encounter.</div><div><br></div><div>-Nikhil</div><div><br></div><div><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 6:21 AM, Stephan Rogge <span dir="ltr">&lt;<a href="mailto:Stephan.Rogge@tu-cottbus.de">Stephan.Rogge@tu-cottbus.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Nikhil,<br>
<br>
yeah, I see it. I&#39;ve test the plugin and seems to me it is working.<br>
<br>
Under Windows a small error during compilation occurs in<br>
&quot;vtkVRConnectionManager.cxx&quot;.<br>
When PARAVIEW_USE_VRPN is defined the internal member &quot;QPointer&lt;vtkVRQueue&gt;<br>
Queue;&quot; would not be declared. Moving this line behind that check works for<br>
me.<br>
<br>
struct vtkVRConnectionManager::pqInternals<br>
{<br>
#ifdef PARAVIEW_USE_VRPN<br>
  QList&lt;QPointer&lt;vtkVRPNConnection&gt; &gt; VRPNConnections;<br>
#endif<br>
#ifdef PARAVIEW_USE_VRUI<br>
  QList&lt;QPointer&lt;vtkVRUIConnection&gt; &gt; VRUIConnections;<br>
#endif<br>
  QPointer&lt;vtkVRQueue&gt; Queue;<br>
};<br>
<br>
<br>
Cheers,<br>
<br>
Stephan<br>
<br>
Von: Nikhil Shetty [mailto:<a href="mailto:nikhil.shetty@kitware.com">nikhil.shetty@kitware.com</a>]<br>
Gesendet: Montag, 13. Februar 2012 19:36<br>
An: Stephan Rogge<br>
Cc: <a href="mailto:paraview@paraview.org">paraview@paraview.org</a>; Christian Wohlschlager; Aashish Chaudhary<br>
Betreff: Re: [Paraview] VRPlugin (some feedback)<br>
<div class="HOEnZb"><div class="h5"><br>
Hi Stephan,<br>
On Fri, Feb 10, 2012 at 3:39 AM, Stephan Rogge &lt;<a href="mailto:Stephan.Rogge@tu-cottbus.de">Stephan.Rogge@tu-cottbus.de</a>&gt;<br>
wrote:<br>
Hello,<br>
<br>
@Christian:<br>
I cannot say, that we have problems by displaying data bigger than 7.5 MB.<br>
Our focus lies on CFD visualization. But when I understand the other threads<br>
right,<br>
this problem has been identified.<br>
<br>
@Nikhil:<br>
<br>
&gt;&gt; Further modifications was necessary in the the vtkVRStyleTracking in<br>
order<br>
&gt;&gt; to update the HeadPose. The proxygroup name must be changed to &quot;views&quot;.<br>
The<br>
&gt;&gt; group name &quot;interactorstyles&quot; in the post mentioned above is NOT working,<br>
&gt;&gt; otherwise the plugin crash, since no proxy or property can be found and<br>
the<br>
&gt;&gt; pointer are still NULL after configuration.<br>
&gt;&gt;<br>
&gt; What you did is hardcoded to the view. The tracking style can be used for<br>
&gt; tracking other things like the hand etc. This is configurable from the<br>
&gt; state file (see document).<br>
In my last post I wrote about the problem of defining the the proxy group<br>
name. I&#39;ve made<br>
a mistake and addressed the class &quot;vtkVRStyleTracking&quot; for this<br>
modification. This is not<br>
the case.<br>
The class &quot;vtkVRInteractorStyle&quot; with its method<br>
&quot;GetProxy( std::string name, vtkSMProxy ** proxy )&quot; required that<br>
modification. And here<br>
I had to &quot;hardcoded&quot; the proxy group name &quot;view&quot; as a first parameter. I<br>
think, the group<br>
name shall be provided as an additional parameter or attribute in the *.pvsm<br>
file.<br>
<br>
This is fixed in the latest code (you may have already noticed). There were<br>
a few API incompatibilities with the latest paraview code and the VR Plugin<br>
which got fixed. <br>
 <br>
Where I can deactivate QTSOCK? There is no option in cmake-gui visible. Or<br>
is this feature<br>
And the future?<br>
The QTSOCK will definitely be gone. Its not even an option (just old code :)<br>
). The future!!! Well it mainly depends on what people would like to see and<br>
who&#39;s funding it. But with the current round of funding there are a few<br>
things in the immediate pipeline. <br>
<br>
1. Support for side-by-side stereo (for 3dtv&#39;s etc in VTK).<br>
2. Adding tests for VR plugin (so be can better identify breakage).<br>
3. Fly-mode interactor style.<br>
4. Hopefully a better way of configuring VR displays and inputs (maybe<br>
implementing a GUI for this). But this is of lower priority for now.<br>
<br>
-Nikhil<br>
<br>
<br>
@ Aashish:<br>
Ok. So I have to concentrate more on tracking system calibration :-). What<br>
is the best approach<br>
of defining the room coordinate system? I have chosen a symmetric approach.<br>
Our system<br>
consists of two walls with an angle of 112° which means, those two walls<br>
construct a triangle.<br>
The user looks into the corner of the triangle. The origin of my room<br>
coordinate system is<br>
the center of the triangle base. All edge points of the two screens are<br>
defined in respect to<br>
this coordinate system. My question is, is this a good approach? Or should I<br>
place the origin<br>
directly on of those edge points?<br>
<br>
<br>
Nevertheless, many thanks for your valuable answers.<br>
<br>
Cheers,<br>
Stephan<br>
<br>
<br>
&gt;&gt;&gt; &quot;Stephan Rogge&quot; &lt;<a href="mailto:Stephan.Rogge@tu-cottbus.de">Stephan.Rogge@tu-cottbus.de</a>&gt; 2/8/2012 1:38 PM &gt;&gt;&gt;<br>
<br>
Hello,<br>
<br>
I’ve start to work intensively with the VRPlugin from git-master and want to<br>
get some feedback. First of all it works almost great :-). As a tracking<br>
system I’m using A.R.TrackPack2 with two infrared cameras and their VRPN<br>
server implementation.<br>
<br>
To be able to compile that Plugin some modifications were necessary:<br>
*  As mentioned in this post<br>
(<a href="http://www.paraview.org/pipermail/paraview/2012-February/023816.html" target="_blank">http://www.paraview.org/pipermail/paraview/2012-February/023816.html</a>) the<br>
proxy API undergone some changes. But it seems, that the author of this post<br>
mixed up the parameter order.  He referred to proxy name and proxy group.<br>
But it has to be swapped...<br>
* Not important to me but required  to compile without errors:  In<br>
vtkVRUIPipe.h the flag QTSOCK is checked for existence. I had to put it in<br>
manually (&quot;#define QTSOCK 1&quot;). Don&#39;t know why.<br>
<br>
Further modifications was necessary in the the vtkVRStyleTracking in order<br>
to update the HeadPose. The proxygroup name must be changed to &quot;views&quot;. The<br>
group name &quot;interactorstyles&quot; in the post mentioned above is NOT working,<br>
otherwise the plugin crash, since no proxy or property can be found and the<br>
pointer are still NULL after configuration.<br>
<br>
But so far, I was able to use the VRPlugin in ParaView in a two-side VE and<br>
I&#39;ve got the feeling, that virtual object placed in front of the screens...<br>
:-)<br>
<br>
Now, I have a kind of problem. When I am moving parallel (left to right) to<br>
the screens, I can observe a sort of rotation which can be not described as<br>
moving parallax. It seems, that the rotation point lies in the center of my<br>
projection displays. Object which came out of screen &quot;standing&quot; not on the<br>
same position. They are flying around. So, my question is addressed to<br>
experienced Virtual Reality user: Is this described behavior right or not?<br>
<br>
Cheers,<br>
Stephan<br>
<br>
<br>
</div></div></blockquote></div><br></div>