I didn't know about the currentUserData() call. At first glance, it looks
like it has what's necessary for pbuffer creation/usage. (...within the draw
routine) Unfortunately, creating pbuffers for each display when needed is
*very* slow. On the plus side, there could always be a couple "if"
statements to get around this so it is only created on the first visit to
draw(). I'll have to play with it a bit to see if there are any remaining
[mailto:vrjuggler-info-admin@...] On Behalf Of Allen
Sent: Thursday, July 29, 2004 11:33
Subject: Re: [vrjuggler-info] Display systems and p-buffer
Eric Maslowski wrote:
> I just wanted to add one reason why my co-workers and I would love to have
> such information, dynamic shadows. This is something that would require
> access to off-screen buffers and context switching. (e.g. pbuffers) There
> are methods, such as stencil shadow volumes, that can bypass this
> limitation, but require higher CPU usage, all objects to be
> two-manifold/closed surfaces, high fillrate requirements, inability to
> alpha blended surface shadows, expensive "soft" shadows, etc...Where as,
> depth shadows have dedicated circuitry on modern GPUs and scale very well
> more polygons get thrown into the scene. (important for commodity based
> clustered of PCs) It would be nice to have this option at one point.
> My $0.02
What specifically are you missing in order to do this?
As far as I know there are no limitations that prevent the creation of
pbuffers or switching contexts.
> Eric Maslowski
> Graphics Programmer & 3D Artist
> University of Michigan 3D Lab
> -----Original Message-----
> From: vrjuggler-info-admin@...
> [mailto:vrjuggler-info-admin@...] On Behalf Of Todd J.
> Sent: Thursday, July 29, 2004 09:56
> To: vrjuggler-info@...
> Subject: Re: [vrjuggler-info] Display systems and p-buffer
> I somehow lost the replies to this, but I wanted to comment on the issue
> of not being able to get info about the display system out of VR
> Juggler. I understand the philosophy of not giving programmers access
> to such information, but I think there are an increasing number of
> instances where it is practical to have such information. We need to
> recognize that while display abstraction works in a lot of instances,
> every Juggler app is displayed on a screen eventually. If a programmer
> can use display information responsibly, then why not give them access
> to that information?
> Some time ago, I raised the issue of being able to query the screen
> dimensions in order to be able to scale object automatically to fit in
> screen space. Brendon's questions raise the issue of wanting to do
> software edge-blending, which I think is common with commodity
> projectors that don't have that feature in hardware.
> So, I am posing this question to the Juggler developers: Can we create
> an API that can access display information? Is there a practical reason
> why we cannot?
> Brendon Stanton wrote:
>>We have a couple questions about using vr juggler for our curved screen
>>surface. We're using it to drive a three projector system onto a curved
>>screen and are using edge blending to overlap the images.
>>First, is there a way to tell which window vr juggler is drawing to? With
>>the three projectors, we need the edges to be blended on both sides for
>>middle window, but only on one side for the two outside projectors.
>>Second, we're rendering the scene to a p-buffer to handle the distortion
>>and edge blending which has its own gl context. How can we get VR Juggler
>>to do its transformation calls it does behind the scenes to this pbuffer
>>context instead of the window's context?
>>Thanks for your help.
>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>FREE Java Enterprise J2EE developer tools!
>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>vrjuggler-info mailing list
-- Allen Bierbaum allenb@...
-- Research Assistant and PhD Candidate
-- VR Juggler Team http://www.vrjuggler.org
-- Virtual Reality Applications Center http://www.vrac.iastate.edu
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
vrjuggler-info mailing list