Horde3D

I was wondering if horde could draw a mesh in wireframe mode while everything else is normally rendered?

I know the debug view mode, but with this mode, everything is rendered with wireframe.

The one large problem with drawing meshes in wireframe view is that the shaders are not applied, and thus no animation/skinning happens. So most likely the answer is no.

Thanks for the answer.

I wanted to draw Spheres and boxes in wireframe to show the bounding box some object. I'm currently making a physic editor for my game with ODE so it could have helped. I think i'm gonna use normalized models wich look like a mesh in wireframe and scale them.

Since v.0.14 you can render your own things after the call to Horde3D::render.
The projection and modelview matrix is set to the last active camera's settings.

This is also the way I render the debug information in the editor.

To ensure that the OpenGL states are preserved use glPushAttrib and glPopAttrib.

Volker is right but you shouldn't use this too extensively because it is rather a hack. If for example the renderer should be replaced (by OpenGL 3 or whatever, although there are no such plans) it would break your application. But I think for very limited debug output it is fine.

By the way, one other problem we had with the editor is that we can't use the depth buffer for rendering the bounding boxes. The problem is that the configurable pipeline makes Horde so flexible that the depth buffer could be anywhere in a texture. But again for simple debug output it is acceptable.

Another solution would be to add a wireframe flag. Should be easy to do. Just add another XML parameter to the material resources and in the setMaterial routine of the renderer call glPolygonMode( GL_FRONT_AND_BACK, GL_LINE ); and glPolygonMode( GL_FRONT_AND_BACK, GL_FILL ); for enabling/disabling wireframe mode depending on the material flag.

We sort of need this for debug view as well, at least to use the vertex shader, as the current debug view gives no animations.

Right, the debug mode is currently rendering using fixed function and doesn't apply any shaders. The reason why we have introduced this is that in our projects we often had situations where we didn't see a model. There are many potential reasons for this, like shader errors, pipeline problem, geometry not loaded correctly, wrong node teansformation, no light source and so on. With the debug mode we can at least exclude several factors and help isolating the problem. If the model is visible in debug mode it certainly isn't a problem with a wrong node transformation or missing gemoetry resource.

Good point, I hadn't thought of that. Maybe a very light (and hard coded into the engine) debug vertex shader that we know performs skinning would be the best way.

That's basically a good idea.
The only thing is that sometimes it is useful to see what the real geometry looks like, without skinning since bounding boxes for example are based on the unskinned data. Hmm, I'm not quite sure what's better here. Maybe the debug mode should become more powerful and configurable by some flags.

Ive tried the draw those line directly with OpenGL but ive got a strange result:

http://img177.imageshack.us/img177/4852/line1mc2.png

In debug mode:

http://img177.imageshack.us/img177/7640 ... bugsf8.png



I'm doing something wrong?

On a related note, I had a quick attempt at integrating ant tweak bar with a horde application last weekend (ATB already calls glPushAttrib/glPopAttrib as it is designed to be integrated with other apps).
However, I found that after initializing Horde, then ATB's texturing would stop working (only solid coloured shapes would be drawn).
Also, after loading the resources for the test scene, ATB would no longer render anything at all.

Does horde use any obscure OpenGL states, which may not be getting pushed/popped correctly? Such as the fragment programs maybe?

I was using ATB with horde 0.13 , and Ive seen absolutely no problem. However, I did not try ATB with Horde 0.14 .

@Mikmacer: Obviously you are using a HDR pipeline. So you are rendering the scene to a render target which also has a depth buffer. This means that the main frame buffer to which you are drawing the bounding boxes is probably not filled with depth values.

Making this work with any arbitrary pipeline is difficult. But if you can modify the pipeline it should be possible to copy the depth values from the HDR render target to the main frame buffer depth channel in a final step. Actually you just would have to bind the HDR depth texture and draw a quad to the main buffer with a shader that accesses the depth texture and copies the values to gl_FragDepth.

By the way, the screenshots look really nice!

@DarkAngel: I assume you are drawing the GUI after the render call? Actually I think that the important states are reset at the end of the rendering but it is well possible that we forgot one. The location where resetting the states is happening is finishRendering in egRenderer.cpp.

Thanks! For now, I will use an another pipeline in the editor until I got time to work on this.

About the screenshots, 90% of the model and the texture are not homemade, they are freely available on the net. I'm using them only for testing, but some members of our team will start to work on the graphical aspect of our project. One of them work in a big video game company, and he will work on the main character, but only on this.

You can look at our wiki, but its only in french:
http://escape.codeurzone.org/wiki/index.php/Accueil

I will present our project in the showcase when we will be more advanced in the development.

Yep, Horde Render -> ATB Render -> Swap Buffers.
I'll look into this again when I get time, and if any tweaks are needed I'll post them in a new thread as it seems others are interested in ATB as well (thanks for pointing out that it works with 0.13 mikmacer!)