Working water and terrain grass with Darkmod

[ghost]

I tried this map earlier for Darkmod which has animated grass and water. It runs quite smoothly, the only thing missing is player collision with the grass to flatten it.

Here is the link to the pk4: http://www.moddb.com/mods/the-dark-mod/addons/arcturuss-animated-grass-demo

[BielBdeLuna]

we might need some special code for the grass, maybe make a "entity2" for things that should be ion the world, but not have a presence as normal entities do, and maybe imagine a system more efficient to handle huge amount of entities. normally idTechX has a limit of 1024 entities, this limit could be reached if we add every plant and tree as an entity, and it seems entities are more complex things, plants and trees could be more systemic. maybe a entity2 system where those entities do less (so there can be more of them, maybe there isn't a thread for every one of them but a more collective thread for all of them?

[ghost]

The grass on that map seems to be billboard based instead of added geometry which could allow it to bend and deform. I've modeled clumps of grass using textures which has around 170 vertexes per clump. On my low end hardware I've tested a scene using instances of the models in Blenders game engine without optimization settings on, the frame rate drops from 60-25 when viewing around 170,000 vertexes of grass.

From what I understand instancing models cuts down on the need for draw calls to be made to increase performance instead of having to reload the resource or duplicating the object which results in doubling the data. The problem with using instances is that Radiant as far as I know does not create instances of objects and also doesn't have any terrain tools to paint objects onto terrain. Even if added it could result in terrible viewport performance unless there is some changes to clipping and occlusion.

If we could use terrain models from a third party tool in the engine using vertex painted layers, then we could control distribution of where models such as rocks, grass, trees appear. This may help viewport performance however the objects itself will not be rendered in Radiant which may make it difficult for artists to see the full environment.

Maybe making different entity types for the grass, trees, rocks, flocks etc and having LOD data contained within will improve performance. Also dissolving away unseen geometry, for example geometry behind a rock could improve performance. Including a fade distance before objects disappear could help as well. Using all these methods in its own thread should work. If we can manage large terrain areas through maybe some level/map streaming method, we could have shaders/entities stored in a folder or memory ready to be loaded when things need to appear visually. Then again I'm no expert and I am most likely talking out of my ass.

[BielBdeLuna]

the problem of the ammount of vertices to draw is a secundary one, first you have to get something there, and this something occupies entity slots. you could expand those or contain all flora in a different system

[ghost]

Sounds good. So it's best to have it's own threads? Could we have these entities interact with IDphysics for some more realism such as wind direction blowing foliage or trees destruct when hit by maybe a rocket, vehicle? I'm considering modelling the trees to break and to model other objects such as pillars to break apart when shot.

[BielBdeLuna]

let's wait for that, first we need a system so those models get there and can be there, it should take into account what the player sees, and cull what player doesn't see, and maybe assign the visible flora to a limited list of slots, so maybe it needs to add not all the flora visible but the most important first and then the filler (and this filler has to be organized in some intelligent way too) I guess the best bet is to make the system multi-threaded, maybe one thread can be used for draw calculations (what can be seen and what cannot be seen) maybe another thread could manage the list of visible flora, and maybe another thread could manage which of the filler is added to the list and how)

then we have to figure out a way to render this stuff, and only then can we think about interactions with other stuff, like physics effects and entities

[ghost]

I agree 100%, speed over visuals. With tall foliage scenes such as wild grass we could cull out grass and rocks based on what is unseen by the players vision, maybe based on the depth buffer. For destructible trees we can have a state system and once it is triggered then the physics can be activate for the tree to fall over.

If we can get someone to do GLSL code, then we could maybe also do leaves and branch geometry with 3D textures and fractals, which could be maybe be deformed within the shader to have movement as well.

For water we could maybe also apply push forces to simulate currents that push the player around a bit.

[BielBdeLuna]

https://www.youtube.com/watch?v=aJXULtV9dkw how MGSV engine does it

[kortemik]

That lightning, we just gloom.

But yes something like that might do it, although we first need in game editor working.

On Tue, Oct 20, 2015 at 8:28 PM, Biel Bestué de Luna < notifications@github.com> wrote:

https://www.youtube.com/watch?v=aJXULtV9dkw how MGSV engine does it

— Reply to this email directly or view it on GitHub https://github.com/OpenTechEngine/Discussions/issues/23#issuecomment-149640225 .

[ghost]

@kortemik Could we add light emission via emission textures to generate light? I think the DarkPlaces engine for Quake 1 has something like that. Otherwise maybe a screen space global illumination shader.

[BielBdeLuna]

on "pushing the player around" this can be done, and I actually tried this in the scripting, but c++ doesn't inform the code where the pain came from, I'll add this once the scripting is done. as well as pushing the player with currents (non painfully way)

and no, I can't assume all pain done to a character comes from the direction the one that cause it is, because not all pain inducing interactions in the game might involve a lineal trajectory.

[BielBdeLuna]

note that in the MGS video the grass is not randomly put, but it serves to hide the seams between different models (like a tree and the ground, or stones and the ground) it might be either vertex painted in, or literally painted with a "foliage texture" where the more colour the more foliage from a specific style there is. this "foliage texture" or vertex weight is in the terrain texture but for caves and or temples where foliage (or whatever clutter we want in the ground) we might want to do it per surface, rather than just the ground, whatever surface. so if we do "foliage texture" them we might need a new material stage in the idTechX material system.

but before this I would look into how to show several times the same model without making 10000 calls, there fore look into memory instancing in the GPU.

this would also require a LOD system and some new way to calculate the visualization, maybe something using voxels like they did with Alan Wake? because portals with open areas are useless. I'd keep portals like they do in Far Cry 1 where the interiors are portalized. and also a some way to affect the clutter if we don't want it static, I guess using any physics with hundreds of elements might ruin the speed somewhat, in Crysis 1 all plants have "physics"? or just a bunch of selected ones have, and the other clip through?

[ghost]

I agree with you. As I mentioned on another post when discussing a exporter for Blender to OTE with Kortemik, we could use maybe Blenders particle system to place foliage, rocks etc, by using ID's for each object being placed, for example, rock00=ID1, rock01=ID2, TallGrass00=ID3, BirchTree=ID4 etc. Then in the engine maybe call up those object based on distance, so the engine only calls when in view. Each ID can have LOD file to decrease detail in the distance.

For physics, or to fake it, we could have bones in the trees and some deforming shaders to give the illusion of movement and bending, which could be a sleep state, then the real physics can be activated by an awake state when collided with, possibly by making the call for the awake state based on the affectors distance, e.g, a car about to hit the tree, then have the tree physics activate in the area where the car penetrates. Then put the state back to sleep when there is nothing to affect it.

As for foliage texture/materials, we also have to consider the transparency/translucency as light sources penetrate it, the whole Subsurface scattering thing. I tried doing some experiments with the material shaders code to fake SSS, however it returned slow fps and glitches at times. And to create more variance, we could maybe assign a vertex color to change the hue/brightness of say a grass texture in an area for the variance.