my geomipterrain has offset of (75km,75km)
if i set bruteforce off, the LOD becomes very low.
if i set NearFar to a very large figure like 100km, the LOD becomes high again.
seems like the focal point should be the coordinate relative to the terrain, not to the world.
but what should the focal point be? if focalpoint is base.camera, the coordinates are taken from camera, then the result is wrong.
another issue, my framerate is higher if i set bruteforce on , rather than if i set bruteforce off and NearFar = (100km,200km) . is that normal?
bruteforce means full detail at all time, right?
after one year, i’m revisiting Panda3D with better understanding of programming.
now i’m at the point of creating a geomipterrain.
i tested a 1025x1025 geomipterrain. setting as:
setPos(-51200,-51200,-50)
setScale(100,100,1500)
blocksize(64)
NearFar(20000,90000)
focalpoint(base.camera)
this piece of terrain is positioned at the center of the world, size is 102400x102400.
i have an orthor cam pointing down like a satellite, to observe the terrain.
i found that, if bruteforce is off, no matter where my camera is, the terrain has the highest detail at the bottom-left corner(-51200,-51200) and lowest detail at top-right corner(51200,51200).
if bruteforce is on, the terrain has highest detail everywhere. but load time is like half a minute, so it’s not a good idea especially in the process of development.
i think there is a bug in geomipterrain.
now i am using 513x513 size of terrain with bruteforce on.
ha, i finally got it working: i have to call setFocalPoint((cameraPosX+51200,cameraPosY+51200)) every time before calling update(). not just setFocalPoint once at the start of program.
but on my PC, if bruteforce is off, it takes more time to update the geometries than setting bruteforce on and let graphic card render all geometries. so the framerate is better with bruteforce on.
i wonder whether the update process of geomipterrain can be done in another thread. since currently the CPU usage is at 10% most of the time. so if the update is done in another thread, CPU usage rises, but framerate can remain stable. anyone has similar experience on the geomipterrain?
One suggestion that I seem to recall seeing was to update the terrain once the camera has moved a certain distance from its last update position, rather than on every update. In other words, store at the start the camera’s position (let us call it “lastPos”). Every update, measure the distance (perhaps distance squared if you’re worried about performance) between the camera’s current position and “lastPos”. When this value exceeds a given threshold, update the terrain and set “lastPos” to the new position.
i think the update() in geomipterrain only update geometries when it’s necessary(when the LOD of any block should be changed). if update() returns false, it didn’t take much time, only loop through the blocks and do testing.
but if focalpoint has changed and some blocks should be updated, usually there is more than 1 block that should be updated - nearly all blocks that are in approximately the “Far” range should be updated.
if i have NearFar at (10000,30000), then more that a dozen blocks need updating in that single frame. that cause the frame time to rise dramatically and so, visible stuttering.
unless geomipterrain can update each block at different frames to even out the update time, a very fast CPU is needed to keep framerate stable.
i guess i need to divide the terrain into smaller pieces and manage the updating process by my own program if i really need to disable bruteforce.
I think that I got my information from this thread; I suggest taking a look at it, starting at the post that the link should take you to, and try the suggestions given there (I gather that the person who posted that linked-to post is speaking from some degree of experience with GeoMipTerrain).
Based on what I see there, it might be worth trying the distance calculation despite the lower execution time on returning “False” – it may be that it has a greater effect than expected.
i think in that forum thread, Tah is using normal clock mode.
in normal clock mode, the objective is to make framerate as high as possible. by not updating geomipterrain every frame, the average framerate/overall framerate increases.
i’m using limited clock mode. the objective is not to make average framerate higher, but to keep the dt of every frame under the maximum allowed dt, which equals to, the reverse of defined framerate.
if the update time of geomipterrain exceeds the maximum dt, i can see the stuttering. that is not acceptable even if the dt of other frames are every low because the terrain doesn’t update in those frames.
in my case, because my CPU can’t do the terrain(1025x1025) update within the dt limit, so i don’t want to update the terrain at all.
but if the terrain is split into smaller terrains, maybe the update time of each terrain can be lower than dt. so if i manage the updating of each small terrain correctly(each terrain updates at different frames). i may use the updating and still keep the framerate at my target framerate.