Horde3D

Hi there!

I’m using Horde3D for creating a realistic simulation of natural environment.
At the moment I’m trying to plant grass to the scene. This is done by a loop casting Rays vertically from top down to the scene. At the intersection-points the algorithm is planting a grass node using “h3dAddNodes”. For achieving a good result, there should be a huge amount of grass nodes, which leads directly to the problem I’m having at the moment: increasing the number of planted grass dramatically decreases the framerate. I searched the forum and I think, that’s because of the draw calls for each node of grass since the polyCount shouldn’t be the problem with a total of about 20.000. So should I batch the randomly placed grass nodes together to one or few nodes to reduce draw calls? Found some topics in which this is mentioned to solve such problems, but I don’t know how to do this. Is there a possibility doing this with dynamically positioned objects of the same Source with Horde3D?

Thanks

I was just about to ask exactly same question, because i have exactly same problem.
Right now i'm generating grass as one big model (well, multiple models, one for each terrain segment), but i'd really like to have destructible foliage in my game. Any ideas anyone?

This might become an interesting thread

As you may already guessed there is no single switch to speed up the drawing of geometry. So we first have to find out where most of the time is spent. Could you try commenting out the graphics rendering calls and do some profiling? I would guess that the creation of the rendering queues might take the most time but since we currently don't have a similar testing setup we can't check that easily.

If we know where most of the time is spent in case someone has a lot of nodes but only few vertices, we might be able to optimize this part of the code.

I don't know enough about H3D to deactivate parts of the engine, so here's all I know so far:

-nodes with inactive flag don't slow down
-but if you exclude material class from rendering (something like <DrawGeometry context="ATTRIBPASS" order="FRONT_TO_BACK" class="~foliage"/>) it slows down. Same when shader doesn't have used context.
-sorting doesn't seem to affect speed (no change in framerate when set to none)

I also couldn't manage to profile my program... for getting use of the internal Profiler I switched to VS2010. After some help from a good friend of mine the program is now running in VS2010 – lost a lot of nerves on the way achieving this. The further problem is that I can’t manage to get the profiler to profile my program. I’m not very skilled in the use of VS and also not in profiling
But I found out something: my grass is currently made of 2 planes. I know, isn’t the newest invention, but is sufficient enough for the first tests. First these 2 planes were separate planes. After joining them to one model in my favorite modeling tool, the decrease from 2 to 1 object per grass-node doubled the framerate. So in my special case the framerate is almost indirectly proportional to the count of grass-nodes.

Well, you are completely CPU bound on draw calls - which is very understandable in your case. Even if the drawcall setup in Horde were heavily optimized, thousands of individual objects with just a few triangles would be highly inefficent. The GPU wants a continuous stream of polygons in a single batch.

What you can do instead is combining more of your grass planes in a single drawcall. One way to achieve this would be using a dynamic vertex buffer to which the geometry of your transformed grass instances gets copied. This could be done in a SceneNode extension, similar to the Terrain Extension which generates terrain patch geometry based on the computed LOD. This presentation by DICE might have some good inspiration for you as well.


If you have a lot of objects which share the same material, there should definitely be a noticeable speedup when sorting is enabled.

Some tricks that all work, yet which one is best depends on your scene:

1. Level of detail + culling
Grass that is right next to the camera is drawn with every leaf intact, grass that is further away is instead just a quad with a few shader tricks to make it look like that. Even further away, the grass is completely removed, yet you can see the ground texture, which looks somewhat like grass if you squint (or are far enough away).

Then I implemented something like this (just not as awesome)
http://www.youtube.com/watch?v=pqt3KFkdpqc

You can use the H3DNodeFlags and MaterialFlags for this. To make a quick check if this works in your setup at all, just flag 'NoDraw' for every entity that is far enough away from a cube around your camera every x Frames. You can make it pretty later on.


2. Batching
In my case, I just joined a bunch of quads to have patches of grass, instead of single leafs. If your scene is small and static, you could even make all grass in your scene a single batch. To test this, I would suggest to just add multiple grass elements together in your favorite 3D model program so you have patches of grass that you can place around the scene. This could then later be dynamic and such.


3. Shaders
I can't find the video anymore, but it is possible to make a shader that looks like waving grass on flat surfaces. It is really an awesome concept, yet the optical illusion only works as long as you look at your scene from the top. From the side, it looks pretty weird.

I think it was on the Irrlicht forums somewhere... There was a Windows-Executable Demo for this. Sorry I can't help you more on this.
[Edit]
Found it http://irrlicht.sourceforge.net/forum/v ... hp?t=24794

Thank you for your replies!
I added the sectoridea from johannes to my project and also some other things. I even managed to profile my project now
There’s a screenshot of the profiling:



Looks like the biggest part is consumed by the “nvoglv32.dll”. Let me guess this dll has something to do with the draw calls? *g* The next big point is the dynamic vertex buffer, which Marciano mentioned. At the moment I have no idea how to realise this, but at the weekend I will have a look at the terrain expansion to see, how it could be done.

At the moment my application runs at 15 to 25 frames on my notebook. Still very CPU-bound. Here’s a “work in progress” screenshot of it:

Hi guys,

the draw-call-problem is solved: Hooray
At the init my application spreads the grass throughout the scene batching each sector-geometry to one single mesh. That completely solved the CPU-bound-problem, introducing a new one: video-memory-consumption At first my grass consisted of only 3 planes forming a grass-billboard. Spreading a huge amount of them isn’t that memory-consuming as I thought. I can place enough of them and only consume about 60mb of graphics-memory. But for a cooler look and more detail I added a second grass-type to my scene: a grass-blade model. It’s only visible very close to the camera and is then turned off to save GPU-time. It looks quite cool, but batching them together and not instancing them completely exhausts my graphics-memory

A search in the forum led me to one topic of anchor “::Invisible nodes geometry::” http://www.horde3d.org/forums/viewtopic.php?f=2&t=1352. This sounds quite interesting for me, but unloading the invisible sectors from the GPU’s memory using the “h3dUnloadResource” seems to delete it also from the system-memory. Is there any possibility to only unload it from the GPU’s memory, but leave it at the system-memory, so that I can quickly reload sectors that become visible again? I tried to generate the sectors in real-time upon becoming visible again, but they couldn’t be generated fast enough, which leads to some kind of lagging when moving around.

Here’s a screenshot with the grass-blades in front, at midrange there are grass-billboards and in the far-range sectors there someday will be parallaxed-grass or a other “grass-looking” but not geometry consuming thing. The type of grass or something similar, which Johannes posted in his video, would be very nice for far away sectors

is very good. cool job. This screenshot must necessarily add to wiki gallery