I’m creating an RTS named Dominion and I’m using geoMipTerrain objects for the terrain. However, the block size appears to be an issue. If it’s too high, my mouse picking does not work as it should (it skips between blocks), but if the block size is too low, I get a performance issue. Does anyone know any work-arounds I can use so my terrain can handle mouse picking at a frame rate higher than 4.2 FPS?
Thanks in advance,
XboxJoshOne
i think you have a logic flow in your picking if you care about block sizes.
Describe what is your algorithm?
Are you using a collision ray to do picking? An alternate method might be to do something like shader assisted painting where the map position is encoded in a separate texture and you extract the colours from a buffer to get the position in the map.
You could keep two copies of the terrain - one for rendering, with a higher block size, one for collision, with a low block size and a high minlevel.
pro’s right. the thing is:
rendering wants as few big chunks of data as possible.
picking wants as small chunks as possible in a well structured way.
as you can see. you can either get good picking performance or good rendering performance if you keep using a single mesh.
seperating the 2 makes most sense. having one optimized for rendering (like geomipterrain is doing). and have a hidden copy of the terrain (can be a high-resolution-tesselated copy) with an quadtree/octree structure for picking.
So how would I hide the collision mesh, just NodePath.hide()?
Yes.
Thanks, the terrain now renders at high speed (~30-40 FPS), however now my collision mesh is not working. If I put the mouse one place, the model I’m using to show where the mouse is goes somewhere completely different. I uploaded the code, you can get it at http://www.jandestuff.com/safe/Dominion.zip. I think it may have something to do with changing the Z scale of the render mesh to 30. To run the test, run the file cam1lev1.py
P.S. You can get the complete source here
wouldnt you want to do
self.myHandler.getEntry(0).getSurfacePoint()instead of getIntoNodePath()?
to get the actual location of the ray-terrain intersection. and then set the smiley position to this point?
I did not know I could do that, that saves a lot of effort!
When running, the frame-rate drops back down to ~9-10 FPS, but when I stop polling for the collision it shoots back up to ~30 FPS. Is this normal?
only check collisions when user clicks.
you can actually use the self.myHandler.getEntry(0).getSurfacePoint() on the real nonsubdivided terrain to get the point.
Thanks for your input, treeform, and no offense, but this was what I have been doing (well, I was using the spacebar instead of a click, but… 
). The lag only happened when I rapidly clicked the spacebar.
well even with small block sizes, a geomipterrain is still made to be rendered. so by its structure its not very collision friendly.
try to octree-fy your collision mesh. treeform made an exccelent python script for this purpose, try searching the forum for “octree”.
by simply re-arranging the node structure of the collision mesh, panda can skip hundrets, sometimes literally hundrets of thousands unneccessary collision checks. so it might help in your,case .too.
I think having a hidden GMM that’s more subdivided is better then messing with my eggOctree stuff for terrain stuff.
I don’t know, I got a 2-3x speed increase when I went to octrees for a similar game…I simply generate the octree on startup (well the whole terrain is generated on startup…). With a huge terrain it only takes 1-2 seconds which is not bad (and then I cache it for better performance next time)
Well, the geoMipTerrain kinda implements a sort of quad-tree by blocks - having a terrain with a low block size gives you a better quadtree for collision.