real time deformation and splatting

Hi

I'm using the last EMT built (2.2 i think), and do real time deformation using TerrainManager::deform(...) and splatting using SplattingManager::paint(...).

My question is, is this terrain manager suitable for these in real time? My game spikes especially when there are multiple calls to to both functions at the same time.

Thanks.

Absolutely it is - look at some of the editors using ETM, they all do real-time deforming.
The point is just that every terrain update call does take some time, so if you're having trouble with it, you may be calling it too often. Try limiting the update rate to 20-30 updates per second max.

Sorry, I edited my post and adding real time splatting too.

Okay, so I assume real time splatting as well should post no threat?

hmm

Okay I think I found out where the bottleneck is with the deformation. If i try to call TerrainManager::deform with an x and z coordinate that is out of bounds, then it cause my game to pause for a split second.

However, with real time splatting using the paint method, it really spikes my game even if i make sure the bounds are within the terrain.

Is the real time splatting suitable to be done in real time? Or could you give me some suggestion if i can edit/change/look out for anything in my code?

Again, try to limit the update rate. The splatting manager needs to update textures, whereby the texture update is not done optimally (ETL fares better here), but it's still not a major problem. Unless, of course, your splatting textures are really rather huge.

In any case, I really don't know what exactly you're doing. Real-time deformation and splatting for editor-like applications is definitely no problem.

I Cabalistic

Thanks for your fast reply. Would love to show you what I'm doing with your library. Please take a look.

If that doesnt work you can just view it here in youtube(they are just the same).

As you can see, there can be multiple bombs landing at the terrain at the same time - whenever a bomb has touch the terrain, it generates a hole - using deform and paint.

I'm merely polishing and optimizing my demo game now, and I think using the paint(...) together with a call to deform(...) pauses the game for a split second.

AS for updating the lightmap, I do it every 5 seconds coz I don't think its that important so don't have problem with it.

Also one quick question, if I may add - I just tried to add shadows now to my demo, and the whole terrain is white. Would you have any idea? I call this before initializing the terrain: mSceneMgr->setShadowTechnique(SHADOWTYPE_STENCIL_ADDITIVE);

Thanks.

Hm, can't readily help you there. Do you have other CPU-intensive things you do regularly?
I assume that for each bomb you have just one single update call to both terrain and SplattingManager. You can reduce the performance impact of terrain deformations by choosing smaller tile sizes. And how big are your splatting maps? I suppose anything above 256x256 might begin to cause trouble if CPU time is already spare.

As for shadows: You will very likely have to write a custom shader for the terrain to get shaders working correctly. Also forget about stencil shadows, you'll need texture shadows.

If you're using the default ETM demo lighting technique the huge spike you're seeing is when the lighting map is regenerated. If that's the problem dynamic lighting may be a solution.

Edit: NM, I just read where you mention only updating it every 5 seconds. Try not updating it at all and see if you get a big performance increase. If you do, then my above statement about dynamic lighting is useful. If not, then it isn't relevant.