Horde3D

I'm working on converting an existing isometric, orthographically-rendered game over to Horde3D. The existing engine uses pre-rendered sprites with anti-aliased edges, requiring an alpha blend against the background to draw correctly. The pipeline I am using consists so far of two steps: one step draws meshes with material class "Ground" and the next step draws meshes with material class "Wall".



The shader used is very simple as well:



The various wall pieces are rigidly-cell based; that is, they are derived from the sides of a unit-sized cube, instanced, and transformed into place in a grid pattern. The camera is a basic isometric (rather, dimetric) camera: 30-degree azimuth, 45-degree around Y axis, orthographic projection. It seems straightforward enough, and is a variant of what I have gotten to work in other 3D engines before. However, I'm having the issue that it doesn't actually seem to be sorting the meshes back-to-front. As evidenced by:



(closeup)



You can clearly see halos, where the front wall pieces are drawn before pieces behind them, leaving behind depth in the zbuffer that prevents the back piece pixels from being drawn. Am I misunderstanding the use of the order attribute of DrawGeometry in the pipeline definition? Is there some other way I should be sorting these primitives instead?

Thanks,
Josh

Hi Josh,

basically your usage should be correct. Horde is sorting meshes by distance based on the closest distance to the AABB. You can easily check the rendering order using GPU PerfStudio. As sorting by distance is not used/tested a lot at the moment, there might be some bug though. Setting a breakpoint in SpatialGraph::updateQueues where the sorting is done might be helpful.

Edit: Quickly checking back-to-front sorting in Chicago worked as expected. Is this a single cell or four? Note that sorting is not done on a per-polygon level but only on a mesh level.

Okay, thanks for pointing me to where the sorting is done, marciano. That helped me figure out what I was doing wrong. I had my camera set up like so:



Doing it like this is useful, since I can simply set the camera node position to the point in the map I want to be centered on the screen, but the sorting in updateQueues doesn't like it when nodes lie behind the camera, since it uses fabs() when calculating the sort key.

I updated the camera so that it is offset in Y to be greater than the maximum node height, and and add an offset to X and Z calculated from the Y value in order to place the camera at the correct location to center the map view.

Thanks for your help. Love this library, by the way. The handle-based API made it an absolute breeze to bind to Lua, and everything seems clean and functional.

Ah, you used a negative near plane. The camera origin is taken as reference point for the distance computation.

The fabs should not be the root of your problem, it just makes sure that the function returns 0 whenever the point is inside the AABB. An undirected distance can never be negative.


Thanks, glad to hear that!