Jeremy,
As someone who is actively developing 2D GUI's (within Virtual
Reality) using Open Scene Graph, your work is of interest to me. The
software I am developing (CoVE, http://cove.opentechinc.com) renders
window content to textures (via framebuffer, osg::Image, etc) I have
not yet addressed the scrolling issue within OSG itself because I only
have 1 texture per window and the content of that texture is changed/
updated from a in-memory buffer to do any scrolling. So far
performance is fine for doing movies/scrolling, but I am sure that I
am saturating the bus to keep the textures updated.
That said I think that your first solution is the most elegant and
least resource intensive. I would think that any shader or scissor
testing would be slower than direct texture coordinate mapping. I
don't know how you have designed your code, but it seems to me that
having flexible control over mapping the texture to the window would
be a key design consideration.
Dan
On Nov 12, 2007, at 10:05 AM, Jeremy L. Moles wrote:
> Some of you may remember a few months back I started working on a
> project I'm calling "osgHUD" which aims to solve the issue of doing
> simple-to-moderately-complex 2D UI's in OSG without subbing work out
> to
> external libraries. I haven't had much opportunity to work on this
> lately, but I'm back at it now and have come across another thing I'd
> like an opinion from the target audience of the software. :)
>
> As you know, GUI's require having some notion of a "scrollable"
> region--that is, being able to display only a subset of the window or
> rectangular region in question. I've been thinking about this all
> weekend and the only things I can come up with to achieve the effect
> are:
>
> 1. Render the "scrolled window" into an off-screen texture and use
> only
> the portion I need. However, this approach would almost certainly
> require a re-working of the rest of the architecture, but I'm
> willing to
> do it if necessary.
>
> 2. Use a shader to define an "active region" of each window; if the
> pixel in question falls within this arbitrarily defined region, render
> it--otherwise skip. I'd hate to impose a GLSL restriction without a
> fallback, but maybe it's the best way.
>
> 3. Somehow introduce the use of GL_SCISSOR into my NodeKit, though
> I'm
> not entirely sure what it is or what it does. Cursory research tends
> to
> indicate it would allow me to render only a portion of a 2D quad, but
> also alludes to performance issues and flickering.
>
> I hope I'm making sense here, and I'd love if anyone who has done
> something similar before could give me a few keywords to research or
> advice on how to proceed. I'm trying to figure out how CEGUI does it,
> but the code is pretty hard to look at sometimes, and their
> API-agnosticism gives them a lot of liberty in their internal
> implementations...
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
