From: Mike Weiblen (mew++at++mew.cx)
Date: 01/10/2006 02:56:52
fwiw I've integrated portions of the VRPN device-abstraction library with OSG,
see http://mew.cx/osg/#osgvrpn
I am able to emulate a 6dof tracker using a spaceball filtered through VRPN's
"AnalogFly" device.
cheers
-- mew
Rick van Haasen wrote:
> I have not (yet) used OSG in combination with tracker devices.
> For my Performer applications i use VRCO's trackd in combination with
> Polhemus tracker devices.
> There is also a trackd driver that enables the use of windows input-
> devices (joysticks, gamepads etc.).
> You can also use the lowcost trackir headtracker.
> The trackd sdk is wat you need if you want to make an interface to
> something else.
>
> Rick
>
>
>
>
> John Kelso <kelso++at++nist.gov> wrote on 2006-01-09 23:21:22:
>
>
>>Many thanks for your detailed reply.
>>
>>Were you using OSG in an immersive environment (one or more head tracked
>>stereo screens) by any chance? If so, did you use any package to
>>facilitate this? And if so, do you mind saying which one, and your
>>experience with it? Or, did you create your own?
>>
>>-John
>>
>>
>>On Mon, 9 Jan 2006, Rick van Haasen wrote:
>>
>>
>>>I have used both OSG and Performer on Onyx3400 (2-pipe IR4) and PC
>>>(Linux witn 2x Nvidia FX1400).
>>>
>>>my conclusion (until now) is as follows:
>>>
>>>-on Linux PC systems, using few CPU's and few graphic cards
>>> both Performer and OSG perform well. On Windows PC's OSG could
>>> run better because of multi-hreading (Performer doesn't support
>>> multi-processing on Windows).
>>>
>>>-on larger systems with many CPU's and graphic pipes (like SGI Onyx),
>>> Performer seems to do a better job.
>>>
>>>an architectural difference is the way
>
> multi-processing/multi-threading is
>
>>>done:
>>>
>>>Performer can use a pipeline that enables parallel processing of the
>
> app
>
>>>cull
>>>and draw stages, at the cost of max. 3 frames delay.
>>>while(1) {
>>> pfFrame();
>>>}
>>>
>>>OSG doesn't use a pipeline, but does everything within 1 frame period.
>>>while(1) {
>>> // Do the app stuff
>>> app();
>>> osgframe();
>>>}
>>>calling osgFrame() will trigger both the cull and draw threads.
>>>I have not looked how it is implemented but my guess is
>>>that it compares to what is called the DrawOverlappedCull mode in
>>>Performer,
>>>where a producer/consumer method is used to transfer the cull results
>
> to
>
>>>the draw thread. In that case, after being triggered, the draw thread
>
> has
>
>>>to wait for data being produced by the cull thread, which (at least in
>>>principle)
>>>is less efficient than the pipeline aproach.
>>>
>>>For OSG, the app() processing could also be done parallel to
>
> osgframe()
>
>>>by using a double buffer scheme, were one (or more threads) calculate
>
> data
>
>>>to be processed by osgframe() during the next iteration.
>>>Performer has the pfFlux object for this purpose.
>>>
>>>Performer further scales by using a set of (cull&draw) processes for
>
> each
>
>>>pipe.
>>>OSG uses a set of (cul&draw) threads for each camera.
>>>If you use for example (as in my case) 2 camera's per pipe, OSG will
>>>spawn
>>>more threads than i would like: each pipe can only be used by 1 draw
>>>process/thread
>>>at a time, so its better to let 1 process/thread sequentially process
>
> all
>
>>>camera's
>>>that are "mapped" to a pipe.
>>>
>>>Don Burns (OSG) mentioned a multiprocess/ multithread issue that has
>
> to do
>
>>>with
>>>the location of memory on Prisms (and probably to all shared memory
>
> SGI
>
>>>systems).
>>>The process aproach used by Performer will physicaly locate the memory
>>>more efficient than the thread aproach of OSG (more close tho the CPU
>
> that
>
>>>executes
>>>the process in a CPU locked system). This is more a "category of 10%
>>>performance"
>>>issue. Ask Don if you want to know more about this.
>>>
>>>A last issue is the opensource aspect of OSG. This is a big advantage
>
> of
>
>>>OSG,
>>>which results in an increasing number of plugins being
>
> developed,tested
>
>>>and debugged
>>>by the community.
>>>
>>>
>>>Rick.
>>>
>
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>
>
This archive was generated by hypermail 2b29 : Tue Jan 10 2006 - 02:57:10 PST