Post Your Irrlicht Screenshots / Render Here.

[hendu]

Ground seams finally gone

[Granyte]

yes but the skirts made new issues visible and it's a never ending story

[hendu]

I think my gardener is starting to get the hang of it.

[roelor]

I think my gardener is starting to get the hang of it.

That is pretty

[kornwaretm]

TreeSceneNode, cheap newbie voxel, cheap grass, some dude and, fake god rays. these whole "cheat based" GPUs produces nice images

[christianclavet]

Hi, Here are new screenshots of IRB
Here is ingame test:


Here is the map in editor view:


I will really need hardware instancing in that project. The ingame screen render at 30FPS with the vegetation in, and at 400FPS with no vegetation.
The slowdown is entirely related to the trees, that take the FPS down.

I just wonder how come Crytek was able to render so much vegetation at the time with "FARCRY" in 2004!

[hendu]

The patches didn't apply to trunk?

My last screenshot in this thread ("gardening") uses instancing.

[christianclavet]

Hi, Hendu.

I'm using trunk SVN, and there was too many changes in the OpenGL driver since 1.7. I would have to understand clearly the code, to know what lines to change, and I'm not at that level. Hopefully, it will be there for 1.9, or 2.0. Hoping that it will be there for 1.9 to enjoy that level of vegetation with IRB (Will add grass blades once it there, right now it would not make sense)

Many thanks for your B3D object saver (patch worked with trunk svn), it really made a big difference in loading time when loading back a project, and as another plus, we can edit the terrain tiles in 3DS Max or in Blender and add caves now! Seen on one of the threads that this patch might be in soon. (B3D saving abilities)

[Mel]

Try simply "baking" sets of meshes into large meshes (whenever they share the materials, it doesn't matter). The hardware instancing is only useful if you're going to animate all those trees on their own and outside a vertex shader (i.e. you REALLY need their transformation matrices for something besides drawing them on screen).

[christianclavet]

Hi, Mel.

The idea is to add later a vertex shader on each instance, to have them simulate wind. I don't think that baking would work in that case (would have a huge mesh being distorted by the vertex shader).

I've seen another code for instancing on the forum that might work (I still prefer the version that hendu made because it create a custom node), If the dev decide that they won't implement it, I'll try this one. And try to increase my skill, but I don't know nothing about pure GL coding (Main reason I use Irrlicht is that I don't have to go at that low level). So not sure I would be able to patch correctly my 1.9SVN version. I already failed with the patches hendu done on 1.7 that I wanted to apply to 1.9 (The project require new features on 1.9 also)

My project need another release and It will have to do without it for the moment. I'm trying to do a new release once a year, then it will have to be implemented for 2016. (Hopefully)

I'm thinking of doing LOD versions of the trees, that I would display/hide depending on the distance, once instancing is there, it should help gain even more performance.

[hendu]

Well there are advantages in real instancing:
- possible to animate inside a vertex shader, but per-instance (this tree breaks at this moment, others do not)
- much less VRAM use, which could also mean faster rendering
- possible to move/rotate/remove individual instances cheaply as Mel said

The VRAM is the main reason to me to use it.

[Mel]

If just they implemented instancing for DX9 (with their setStreamFrequency thing and all...) , it would be great. Although, instancing is just part of the solution to render large amounts of meshes. While it is necesary, there are other considerations to keep in mind. The lod, for example, is a good example, you have to hold several meshes, which, in the end, can't be instanced among them (i.e. instances are all copies of the same mesh)

I am currently trying to figure how to implement a dynamic scene culling algorithm (the CHC algo), and it seems to be advisable to split the scene into a hierarchical structure of subspaces and render them separately. In this case, Irrlicht's octree meshes are quite the best approach, but, to make it really efficient, you need to know what not to render. Try to figure out how to use the occlusion queries efficiently and you will have a lot gained. I am almost there, but i still can't understand some stuff. The most curious thing is that CHC, precisely, works better (i.e. adds less overhead if compared) when the scene is more complex.

[hendu]

Lod is a valid point, but creating instances is very cheap, so you could potentially re-create the instancedNode of each lod every few frames, perhaps based on distance from the camera. Then there are on-GPU ways of doing lod: geometry shader is fairly easy, but ups hw requirements; vertex-shader-only lod is more tricky, requiring specifically built meshes, but possible on very lowly hardware.

Another way to handle lod would be to do it on a per-block level. Say a forest of 1km x 1km was divided into 50m x 50m blocks, each block being one instanced node. The mesh could be changed to a lower-lod one per-block, making the transition extremely cheap. This would also help with culling, as each instancedNode is culled as a whole unit.

[christianclavet]

Hi! Cool ideas!

and it seems to be advisable to split the scene into a hierarchical structure of subspaces and render them separately.

Seem something like this used in URHO3D scene editor (Studying it, their API seem really complex), they have some kind of scene node that cover an area of the map, and other nodes are assigned to it, then it would do an octree subdivision on them. This would be really good for bigger meshes. (I'm already loading bigger meshes as OCTREE). Their way of doing it, load all meshes, then the node will create octrees out of the assigned nodes is only different...

[Mel]

In fact, the point of an octree is exactly that, divide the space into cells and render each of them if they're visible. The advantage is that if a particular node is not visible (i.e. using an occlusion query of the bounding box of that node, or simply because of frustum culling) the node, and its children can be skipped.

That works very well for static meshes, you can split the mesh into the cells, and the dynamic meshes (even instances, for example) can be placed into the structure very fast using simple tests, even an octree of depth 5 has a lot of nodes to work with and it consumes very little computing time to place each node in a cell in real time (5 tests at most), even with large amounts of nodes. The scene then, turns into rendering this octree.

The biggest drawback is the increase of renderstate changes, but it is a tradeoff between rendering small scenes and rendering very large ones. Even rendering each material at a time can be useful, because it can cover pixels of the scene that may act as a sort of quick (incomplete) Z-prepass for the rest of the materials.