Horde3D

Hi,

First of all, the function h3dSetNodeTransform uses local space whereas h3dGetNodeAABB returns world space coordinates.
Can someone please explain the difference between world space and local space coordinates.
And what is their range of coordinates?
**EDIT**
I sort of worked it out. The world space coordinates is simply the accumulation of all the bounding boxes in a parent-child relationship.
But I still don't fully understand the local space coordinates...
If someone could answer this, then I probably understand..
If the local space coordinates are rendered to the screen (window) directly without compensating for z-depth, would that relate to a 1-1 pixel relationship?
**EDIT**

What I want to do is render a quad to the screen using pixel coordinates.
The geometry for the quad is already stored in pixel size (coordinates), but when I render the scene node it gets transformed according to the camera projection and the geometry z-depth (as it should). But for these quads, I want to render them to the window coordinates and ignore the z-depth so to speak.

From my understanding, it can be performed in the shader for the material, otherwise I must use an orthogonal camera.
Is this correct?

Can I change the camera to orthogonal and then change it back after rendering those quads?
**EDIT** The answer is No. Because it is not possible to change the camera perspective while Horde3D is rendering with Silly me.
From what I understand the camera simply renders every scene node. it is not possible to tell a camera which nodes to render is it?
**EDIT**

What would you recommend as the best (otherwise the only) way of doing this?

Regards,
vikingcode

I'm a bit in a rush so just a quick answer: to hide scene nodes, you can set the NoDraw node flag before the render call.

If you just want to draw simple screen aligned quads, for example for some kind of UI, you could also take a look at the overlays.

No, because it still depends on the projection matrix. Local space means the transformation is relative to the pivot/origin of the scene node itself, while world space means the absolute transformation regarding the (3D) world origin.

If you want a pixel to pixel rendering, you need to adjust the projection matrix, such that the visible part of the viewing frustum at a specific distance is exactly the size of your window.

Yes I know, but thank you.


Yes I do have it working with overlays at the moment, and that is exactly what I am doing, rendering GUI's.

The problem with overlays is that there is a maximum number of overlays that can be added to the overlay queue. Although the number can be modified, it is still inhibiting.
The GUI's that I am rendering are fed to me (the program) in sets of multiples of 4 vertices. I break them up and separate every quad as a separate overlay just so I can have 1 color per quad, otherwise I'd have 1 color per (possibly) 72 vertices or more. This is why my overlay limit is so quickly exceeded. The GUI can have 72 vertices or more because it may have several quads within the large (main) GUI quad.

Also, overlays can only have a maximum of 1 color per quad, whereas "ideally" I need 1 per vertex.

Ok. I have to think about that. Thanks.
When you say "the visible part of the viewing frustum at a specific distance", are you referring to the z-coordinate where the quad is located?

Regards,
vikingcode

That depends on your projection mode. If you have a perspective projection matrix it depends on the z-coordinate. If you have an orthogonal projection it's not relevant and you simply have to make sure that your frustum fits to your window size.

Thanks. Yes it is perspective projection of course because I need to combine rendering geometry and scene nodes along with rendering a 2D GUI.
Thanks for explaining the orthogonal projection anyways...

To determine the width and height of a frustrum at a particular Z distance the following can be used...

Height = 2 * tan(fov / 2) * zDist
Width = Height * ratio

where ratio = the ratio between the horizontal and vertical fields of view, and fov = vertical field of view.

I'll have a go playing around with that idea.. Get back to you later..

Regards,
vikingcode

Hi Vikingcode,

Are you by any chance trying to get that librocket GUI system to render in a more native way with Horde3D instead of the GL backend? I was studying today about using overlays to do it and came to the same conclusion that you did about vertex colours needing to be unique per-vertex but the overlay system only supporting one colour per draw call. From what I had gathered, Horde also needs an abstraction to the glScissor function as well for it to work the way you want.

Alternatively I'm thinking of just creating a geo resource and MapResStream to that the data you want, coupled with an orthogonal camera rendered after you render your main camera and making a special material class so that only that renders and not the other nodes in the scene (this could be an alternative approach to your issue of needing to hide nodes?).

Good luck!

_________________
-Alex
Website

Another possibility would be to to render libRocket or any other gui completely separated into a FBO associated with a texture and use that texture within Horde. But I don't know libRocket, so maybe there's no separated rendering backend for that. But in theory this solution may be better if you don't want to change a lot in either the GUI rendering or the Horde rendering code.

Good point actually. Well I looked at librocket and it's designed very well to integrate into existing renderers, there's a render class full of virtual functions you override with your own functions, like texture loading, a way to pump vertices/indices, etc. as well as a system class to override with your own file I/O functions. Alternatively you can just use the GL backend right at the end...

_________________
-Alex
Website

Exactly. I have it working already with overlays. The frame rate is quite good too. I use the Knight sample and add some Rocket GUI. The frame rate is nearly the same as the original Knight demo.

Yes, but I just include the appropriate openGL headers and use the methods directly at the moment.
The methods required are glEnable, glDisable, and glScissor.
But you are correct, it probably would be more appropriate if these methods were accessible "via" Horde3D. For example, if Horde3D was extended to use other rendering abstractions such as DirectX, it would be necessary.

Is it possible to setup a camera to only render certain nodes? Or to only render certain materials? I'm not sure I understand what you mean.

That's not exactly an issue... although the libRocket render method is called for every GUI geometry on every loop. Theoretically you could probably just add the node to the scene and let it render itself automatically, and simply update the translation each step. Then remove the node when the geometry is destroyed by libRocket (in a separate method called ReleaseCompiledGeometry).
But if I want to hide them after every rendering and then show them again when libRocket asks to render them, I could keep a list of the geometries in a static array or something like that, so they would be exposed to other files or classes in the application. Then I'd hide them in the Horde3D application after is called.

Thank you.

I don't know if that will be any easier actually. Using overlays as I do now is quite good and not complex. The only reason I want to use nodes is because of the vertex colors... Oh yea and because of the overlay limit.

I still haven't had a chance to try out playing with the projection matrix in the shader. I am playing with that tonight.

Regards,
vikingcode

PS. Thanks for all the help and interest shown.