Hi Thomas, hi Robert,
I did some more tests on the fbo-issue and I got it working on my side,
but the fix is hackyish and not ready for primetime.
The underlying issue is the following:
on the iphone all rendering goes into a bunch of FBOs, when you want to
"swap buffers" (there are no implicit buffers, only FBOs to my
understanding) you tell the system to blit the FrameBufferObjects to the
screen.
So I added a static setter for the standard fbo-id to switch back after
rendering into an osg-fbo. I set this to the fbo-id which is used for
rendering (usually 1, 2 if you had enabled MSAA) when creating a window
and its fbos inside GraphicsWindowIPhone.
But this approach will not work with multiple contexts, as every context
has its own set of fbos needed for rendering.
So what's your opinion to tackle this issue? Another virtual method
inside GraphicsWindow? Something like
virtual void osg::GraphicsWindow::unbindFbos() {}
where GraphicsWindowIphone override this method and bind its fbo-ids again?
Or is there a better approach?
I checked my hacky changes into the git-repository. Have a look here:
https://github.com/stmh/osg/commit/ffc18a791105477b2a38b5d09cf8c2e905f88e03
It makes no difference on the device vs. the simulator.
cheers,
Stephan
Am 04.11.10 15:06, schrieb Thomas Hogarth:
> I occurs on the hardware,I haven't tried the emulator yet as it takes so
> long to build everything :( (Stephan, do you have the emulator running at
> the mo). I got suspicious when I noticed the rtt fbo id was 2, after a
> little reading it became clear this issue had tripped a few people up.
>
> In terms of fixing it with a define, where would you feel the best place for
> the define is as the 0 id is used in FrameBufferObject.cpp and
> RenderStage.cpp. The reason I ask is that you need to #include
> TargetConditionals.h to determine we are on the IOS platform and this is
> already done in GL header. So I was wondering if perhaps I should put it
> into GL header.
>
> On a slightly different note. I'm starting to feel the need for an
> OSG_TARGET_PLATFORM or something similar. As we do more gles platforms I
> think determining the platform we are building for is going to become more
> difficult and at the moment it can be a problem for things like IPhone as
> CMake and XCode may just think we are building for OSX, since thats the
> platform we are on. An OSG_TARGET_PLATFORM define would give us a one stop
> shop for that information.
>
>
> Cheers
> Tom
>
> On 4 November 2010 09:29, Robert Osfield <[email protected]> wrote:
>
>> Hi Thomas,
>>
>> Interesting investigation and fix. Does this issue occur on the
>> target hardware and software emulators of it?
>>
>> Robert.
>>
>> On Thu, Nov 4, 2010 at 5:56 AM, Thomas Hogarth
>> <[email protected]> wrote:
>>> Fixed it,
>>>
>>> So after a bit of thinking I realised that the default buffer must be re
>>> binded at some point so did another search and found 3 calls to
>>>
>>> fbo_ext->glBindFramebuffer(GL_FRAMEBUFFER_EXT, 0);
>>>
>>> And my earlier hunch was correct that ios' default buffer id is actually
>> 1
>>> so changing to the below makes it work
>>>
>>> fbo_ext->glBindFramebuffer(GL_FRAMEBUFFER_EXT, 1);
>>>
>>> So now I need to add a DEFAULT_FRAMEBUFFER define or something in the
>>> FrameBufferObject header file that is set it to 1 on ios
>>>
>>> Over all though, good news. Performance seems great too.
>>>
>>> Tom
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
