From: Rick van Haasen (rick.van.haasen++at++philips.com)
Date: 01/10/2006 01:05:46
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.
> >
This archive was generated by hypermail 2b29 : Tue Jan 10 2006 - 01:07:43 PST