Horde3D

I'm using SFML graphics lib to draw overlays [game GUI] on the screen. After updating from official SDK to the community SVN [rev428] , overlays look broken. Codepoets workaround to this problem is to enable Horde3Ds overlays [for example : showOverlay or h3dutShowFrameStats] and voila ! it's working.

Best Regards, Siavash.

Not sure if I understood it correctly. What overlays are broken? The one you are rendering with SMFL or the one with Horde3D? What exactly is broken? Could you provide a bit more details to what is not working as expected?

I'm using SFMLs graphics library instead of Horde3D overlays to draw a few spirits and texts on the screen [GUI] after Horde3D finishes rendering. With official Horde3D beta4 SDK everything goes well and spirits are drawn correctly on the screen.

There is minor problems with official SDK too, when camera cuts/collides with models, spirits positioned on that point won't draw correctly, but let's ignore them atm. With latest SVN none of SFML drawings [spirits, texts, ...] will appear on the screen.

I've discussed this problem with Codepoet today and his cure for this problem was to use Horde3D overlays to draw a few other things temporary. After using h3dutShowFrameStats, SFML spirits appeared on the screen too while drawing over the Horde3D overlays [FrameStats window].

EDIT : Just wanted to mention that old trick with Forward pipeline isn't working in HDR pipeline and SFML drawings will not appear weather Horde3D overlays are used or not. Also HDR pipeline isn't working correctly, it looks like that models are only shaded with white specular lights and then glowed.

I'm using plain OpenGL calls to draw some billboards and a few lines into the scene. After upgrading to r424 this was broken, even after I've updated my shaders.

See attached screenshots. In broken.png you can see a few straight black lines, originating at (0, 0, 0). Also everything I'm rendering with raw OpenGL calls is not visible when I'm farther away from (0, 0, 0). See ok.png for comparison. ok.png was rendered with a call to h3dShowOverlays, broken.png not.

There have been several refactorings related to rendering states recently. A lot of the fixed function calls were removed. For example, the camera and projection matrices are no longer set as GL_MODELVIEW/GL_PROJECTION.

Codepoet, I would suggest to use GPU PerfSudio to check the rendering states when you draw your custom geometry. Also, do you know which revision is the last one which worked?

I'll have to look for a Linux debugger, GPU Perf Studio seems to only work on Windows.

The first revision with the bug is r419. I've attached a Python example which reproduces the bug: Replace app.py (it's not a patch, phpbb refuses .py files...) with this file, then run chicago.py. Then look upwards and at some point the lines will disappear / are replaced with black lines. Alternatively you can port the OpenGL calls to the C++ version of chicago.

Any updates?

Hi, I've just downloaded the GPU PerfStudio and decided to give it a try too see where were the problems. Sorry long post, please don't get angry at me

Test #1 : Horde3D SVN rev250
Horde3D is going to draw overlays : After finishing drawing the scene, switches from glUseProgram(30) to glUseProgram(0) then starts to draw the overlays after calling the glUseProgram(6). After drawing the overlays, Horde3D again switches back to glUseProgram(0). Then SFML loads the font textures and continues to draw them without any problem.

Horde3D isn't going to draw any overlays : Horde3D leaves the render state to glUseProgram(30) (and a texture that contains a cubemap of a depth buffer? is still visible in the active textures tab). Then SFML loads its font texture too and that render state (30) contains the previous texture (cubemap and font texture visible at active texture tab) and nothing will be displayed.

Test #2 Horde3D SVN rev277 :
Horde3D is going to draw overlays : In the final parts of the rendering the scene, render states are switched from 27 to 30 and from 30 to 27 without calling glUsePrograms(?). Then Horde3D starts to draw the overlays (without calling glUseProgram(0) or (6)) and render state changes to 6 suddenly. Horde3D draws a few elements with render state still being at 6. In middles of the process glUseProgram(30) is called, but render state still remains at 6. Horde3D finishes drawing the overlays with render state still being 6. Suddenly render state changes to 0 (with out calling glUseProgram(0)) and Horde3D tries to draw a square (filled with pink color) on the screen without any textures (active textures tab is empty). I've noticed that square is placed at the position of first character that SFML is going to draw later (render state still being at 0). After drawing that square, glUseProgram(0) is called (with render state being 0). Now it's SFML's turn but the texture it was going to use for the fonts isn't loaded. SFML continues to draw a few other squares (filled with pink color; active texture tab is empty) at the exact location of the text characters.

Horde3D is not going to draw any overlays : After drawing the whole scene, a little pink square is placed at center of the scene and tons of glBindTexture and glActiveTextures are called (with render state being 30). In the end glUseProgram(0) is called but render state is still 30 and two textures are left from previous in the active textures tab. Now it's SFML's turn, font texture isn't loaded, render state is 30 with previous textures. SFML calls a few glVertex2f and glTexCoord2f to draw the texts on the screen like always but this time no squares are going to be drawn on the screen nor GPU PerfStudio follows the vertex locations and that pink square remains in middle of the scene.

Excuse me if I'm not too much useful here, just wanted to let you know that still there is a few problems with render states, may be that's helpful for other people that they are trying to integrate other kind of GUI systems.

Best regards, Siavash.

Not sure If I correctly followed your description, but both SFML and Horde are "fighting" for OpenGL states, without knowing the presence of each other. Certainly this will go wrong, as SFML might assume certain states and so does Horde.
In our engine we have even more separate subsystems/libs which struggle for OpenGL state, so we ended up wrapping state-modifying code with some glPushAttrib/glPopAttrib calls.
But as we're currently at Hordne SVN 266 I can't comment on SVN 277, where a lot of render/state management has changed.