Results 1 to 16 of 16

Thread: More than one CL_FrameBuffer and gc.set_map_mode()

  1. #1

    Default More than one CL_FrameBuffer and gc.set_map_mode()

    I've experienced some problems developing an xml post-process compositor for my engine (it's similiar to the Ogre3D CompositorManager concept).

    A post-process compositor can involve more than one CL_FrameBuffer that can be used both as render target or as texture source.

    When more than one CL_FrameBuffer is involved in that process if I not call gc.set_map_mode(cl_map_2d_upper_left) each time before rendering to a CL_Framebuffer I lose the map mode and I have strange results on display.

    To solve the problem without using gc.set_map_mode(cl_map_2d_upper_left) I can call gc.reset_frame_buffer() after each time I render to a CL_Framebuffer.

    Is this normal ?
    When I started to develop my CompositorManager I thought that I could call gc.reset_frame_buffer() only one time before drawing my post-process final result to the screen but I now I'm calling this function each time I draw to a Cl_FrameBuffer.

    Thanks for any help.

  2. #2
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    The way its supposed to work (but sounds on your description there's a bug) is that when you set a mapping mode, this one remains active until you change it, regardless of frame buffers set active and so on.

    However, there are two exceptions to this rule:

    • If you set the map mode to custom, the automatic mapping code will not make any adjustments needed (since the application now control the modelview matrix)
    • If you change the projection or modelview matrices using custom OpenGL. Generally this is not safe unless you set the map mode to custom, since ClanLib may change the projection and modelview matrices when changing the active framebuffer


    The reason a reset()+set() of a framebuffer fixes the mapping mode is because ClanLib reapply its settings to the projection and modelview matrices. It is a bug if you need to do this. The bug is in ClanLib if you did not do any custom OpenGL matrix operations. But if you did do custom OpenGL you may be able to fix the problem by properly restoring the matrices after the OpenGL code, or by first switching to the custom mapping mode and then back to 2D mapping afterwards.

    The reason ClanLib reapply the mapping mode on framebuffer changes is because the coordinate system in OpenGL starts in the lower left corner, while our mapping defaults to the upper left. This means that if the height of the frame buffer changes, we have to adjust the matrices to the new height.

  3. #3

    Default

    Thank you for your explanation.
    Unfortunately in my code I never changed the projection or modelview matrices using custom OpenGL and the only projection I use is cl_map_2d_upper_left at the moment.

    The reason ClanLib reapply the mapping mode on framebuffer changes is because the coordinate system in OpenGL starts in the lower left corner, while our mapping defaults to the upper left. This means that if the height of the frame buffer changes, we have to adjust the matrices to the new height.
    I think that something wrong happens when I write to a framebuffer from a framebuffer.

    Code:
    void CL_OpenGLGraphicContextProvider::set_map_mode(CL_MapMode mode)
    {
    	// Invert the mapping mode for FBO's 
    	if (framebuffer_bound)
    	{
    		if (mode == cl_map_2d_upper_left)
    			mode = cl_map_2d_lower_left;
    		else if (mode == cl_map_2d_lower_left)
    			mode = cl_map_2d_upper_left;
    	}
    ...
    I found this code on set_map_mode function. Maybe if I write to a framebuffer from a framebuffer I've a double inversion of map mode?

    I'm sure the solution isn't far away...

  4. #4
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    I think that something wrong happens when I write to a framebuffer from a framebuffer
    I am not sure what you mean. How can you read from a framebuffer?

    A FrameBuffer contains a texture image or a renderbuffer image, that is written to.

    In theory, you may be able to have a framebuffer to write to a texture that is also used as a texture unit, but as far as I know, the results will be undefined.

  5. #5

    Default

    I am not sure what you mean. How can you read from a framebuffer?
    You are right, I was not clear.

    I would have to say that something strange happens to my map mode when I draw a texture,that was previously used as color attachment of a framebuffer, to a color attachment of another framebuffer.

    Example:

    1) Framebuffer 1 has a color attachment called "MyTexture1"
    2) I draw something to "MyTexture1" with one shader.
    3) Framebuffer 2 has another color attachment called "MyTexture2"
    4) I draw "MyTexture1" to "MyTexture2" with some post-process shader applied for example.
    5) I draw "MyTexture2" to the screen

    If I'm not wrong if in the passage 4 I don't call gc.set_map_mode(cl_map_2d_upper_left) I will have an inverted image in the final window.

  6. #6

    Default

    I've written a basic example to show the problem. It's useless but it reproduces the situation.

    I include the source code.

    The result of this program:
    Attached Images Attached Images  
    Attached Files Attached Files

  7. #7

    Default

    This is the original texture used:
    Attached Images Attached Images  

  8. #8

    Default

    I solved changing in set_frame_buffer() (opengl_graphic_context_provider.cpp)

    from:

    Code:
    	if (!framebuffer_bound)	
    	{
    		map_mode_before_framebuffer = map_mode;
    	}
    
    	framebuffer_bound = true;
    	if (map_mode != cl_user_projection)
    		set_map_mode(map_mode);
    to:

    Code:
    	if (!framebuffer_bound)	
    	{
    		map_mode_before_framebuffer = map_mode;
    
    		framebuffer_bound = true;
    		if (map_mode != cl_user_projection)
    			set_map_mode(map_mode);
    	}
    to avoid a second inversion of the map mode when another buffer is already set.

    I don't know if this create other problems. In any case I include the patch.
    Attached Files Attached Files

  9. #9
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    That looks correct. I'm not ClanLibbing today, so I can't test it. As long as the GUI example works, it should be fine

  10. #10

    Default

    I just tested GUI example and it works fine

    Moreover I extensively use more than one framebuffer and all looks ok.

    By the way I discovered that this patch solved a weird mapping effect in my soft shadows that are applied as a post-process effect with the compositor manager of my engine.
    Attached Images Attached Images   

  11. #11
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    The images look awesome very nice

  12. #12
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Bergen, Norway
    Posts
    588

    Default

    I have no idea what that image depicts, but it sure looks cool. What project are you working on?

  13. #13

    Default

    The images look awesome very nice
    I have no idea what that image depicts, but it sure looks cool. What project are you working on?
    Thank you. Currently I'm only working on the game engine but the image tests belong to the first project I want to develop after the engine will be more mature.

    The name of the game will be SupaMix and it's a remake of a famous old boulderdash-like game: Supaplex.


    I started some year ago to think about it. Before discovering ClanLib I started to develop the engine in real 3D with Ogre but I found that this type of games are still better in 2D and with shaders you can give a fake 3D effect with a better performance. Currently ClanLib in its 2.x version is the only library that I found to be such complete..you think about something that you need..and it has it!
    Attached Images Attached Images   
    Last edited by wizardofoz; 07-14-2009 at 07:38 PM.

  14. #14

    Default

    Loved that game! It will be nice if you can complete the remake

  15. #15
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Quote Originally Posted by wizardofoz View Post
    Before discovering ClanLib I started to develop the engine in real 3D with Ogre but I found that this type of games are still better in 2D and with shaders you can give a fake 3D effect with a better performance.
    Just a note to say that ClanLib 2.0 can do real 3D. I have written an application where you fly around a huge landscape (10km^2) where the landscape (scene) and objects were created in Lightwave3D. All using ClanLib 2.0 API (no direct OpenGL calls).

  16. #16
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    ( set_frame_buffer.patch applied, many thanks)

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •