Hi Matthias,
On Tue, 2004-09-21 at 14:38, Matthias Biedermann wrote:
>
> Thanks for your advice: both the refresher from the documentation and
> Dirk's summary definitely clear things up. But I like that iteration-
> thingy, too, so here we go...;)
>
> > Hm, that's an interesting one. This gets into Window/buffer management
> > territory, and that part of the map says "Here be dragons". ;) I haven't
> > used ARB_draw_buffers before, what exactly are you thinking about?
>
> First of all, it should read "ATI_draw_buffers" - seems like I was a bit
> too enthusiastic about the ARB process...
I know the feeling (ARB_render_texture anyone? :-|)...
> My idea behind it would be to use its capabilities to render into
> (multiple) render targets that aren't limited to OpenSG's (framebuffer-
> based) 8 bit pixel format, thus being able to render HDR (cubemap)-textures
> for use in further steps. I guess this could have been done earlier with
> float-pbuffers and the like, too, but now this functionality seems quite
> comfortable to use - at least looking at all those shiny conference
> slides...
If you have a GeForce FX 6800, probably. I'm a little confused about ATI
in this respect. Looking at the delphi3d.net database, the current crop
of ATI cards supports the extension, but no framebuffers with AUX
buffers, which makes it pretty pointless. has anybody tried getting this
to work on ATI?
> However, I'm still not sure about any interference by using such things in
> OpenSG's "dragon arena", as you cannot work as in pure OpenGL applications
> where you just use the functionality exposed, right? And I know my needs go
> even beyond Enrico's questions, because composing viewports for cubemap
> rendering as a workaround would be no option for floating-point data.
Well, Your situation is a little different. OpenSG doesn't like
interference in areas that it tries to manage, but the whole Window and
Buffer management is largely left to the app anyway, so OpenSG doesn't
care if you allocate a Visual with AUX buffers and use Shaders with MRT.
> In my case the former. I was wondering about the exact role of OSGGLEXT.h
> as it contains just a copy of all the platform's extension definitions,
> doesn't it?
Yup. All the ones that OpenSG uses, at least.
> If I got things right, it would be completely perfect to use my
> current system's extensions as a basis for my application, and then keep it
> running on another system, no matter what the OSGGLEXT there looks like?
Absolutely.
> Sure, I have to take care about the target platform that might not have
> extension XYZ; but, for simplicity, we'll leave out any worst case scenario
> here...;)
You can use OpenSG extenion registration mechanism, if you want to,
there are no compiled-in aspects in that.
> (puuh, feels like digging deep into OpenSG but I guess that's just
> scratching the surface...)
No, you're more like scratching thin air a couple inches away from the
surface, so you should be fine.
Hope it helps
Dirk
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
