Up to this point, I’ve been able to find answers to problems by searching the forums. Now I’m stuck, and this is somewhat significant. I like the idea of using GeoMipTerrain over the less efficient imported terrain mesh, but my game world is to be quite large in size. I have three questions:
Is there a way to load several heightfields and attach the rendered terrains side-by-side? If this is possible, then my method would be to give each map an ID and load the map the character is on as well as the adjacent maps. Note: a “seamless” world is what I’m aiming for.
If that is not possible, then is there a way to rescale the terrain to get more out of a smaller heightfield? I’ve tried setSx() and setSy(), but that messes up the Z information and results in my character running right through the ground.
If neither is possible, then is the only way to come up with a large “seamless” world map with GeoMipTerrain by using a large heightfield? The problem with this is when I try rendering from a large heightfield, I get a serious performance drop (75 FPS to < 20 FPS is what I call serious). I’ve tried setting the camera lens’ far plane to a relatively short distance, but still I face the same performance drop. This drop occurs only when my camera lens faces the direction of a majority of the terrain. For example, if my camera is located on one corner and my lens is facing the opposite corner, then I get the performance hit. If a large heightfield is necessary, then what can I do about the performance drop?
best sollution ,as you pointed out, is to to arrange several terrains side by side. this usualy is called pageing. implementations can differ. as for now and as far as i know geomipterrain does not support this yet, thought i guess it’s not that hard to add if you know some c++.
scaleing usualy is no problem. it might be when you use geomipterrains getHeigh function which is sorta hand-written to avoid the overhead of the collision system. if this should be a bug you better report it to pro-rsoft who wrote the entire terrain thing.
about your 3rd question.this can have several reasons. either too many vertices(and too large area per face to draw), or too many geomnodes. running pstats and using yourterrainnode.analyze() can point you to whats the problem in this case. maybe using different settings for geomipterrain can help. you can tune performance quite a lot with those.
ultimately if really everything else fails. there remains an very old-school way of doing “endless” terrains. it simply uses small parts of terrains which are loaded and unloaded only around the player. those usualy have no kind of lod. so viewing distance is comparebly low. low but solid workaround which allows “almost” infinite level sizes
Thank you for the quick reply. The simplest task you mentioned was running through PStat to see what was causing the frame rate to drop. From what I could get out of it, too much is being drawn on-screen at once. I may be a bit ignorant here, but wouldn’t the camera’s far plane cut off polygons being drawn beyond visible range? I even tried bringing the far plane so close the character wasn’t even standing on visible ground, yet the lag still spiked as I rotated the view toward the heavy end. Perhaps GeoMipTerrain neglects the far plane when drawing? More probably I’m missing something here.
I’ll play around with scaling and see what I come up with. And about the GeoMipTerrain settings for increasing performance (e.g. LOD), I’ve tried setting a few of those to what the documentation claims is very low quality (and thus high performance), but nothing seems to have changed in terms of the drawing issue. I will say that I haven’t experienced overloaded drawing on 129x129 heightfields, but once it goes at least 513x513, frames come in slower. This is precisely why I figured that using several small 129x129 heightfields would do the trick. I couldn’t find anything in the references for GeoMipTerrain that would allow such a task, so I assumed, as you said, that it was not supported. I do know C++, so I’ll see what I can find.
For this project, a seamless world is too significant to replace with single maps connected by exit points and fading transitions (which would be quite simple with GeoMipTerrain’s native capability of setting individual heightfields). But I do have faith that things will work out. I like to stick to the motto “where there’s a will, there’s a way.”
clipping planes wont cull out geomnodes which are still partly on the visible side of the plane. which causes the entire geom-node to be send to the graficcard… this might be caused by geomipmapterrains auto-flatten function. try to terrain.setAutoFlatten( AFMOff ) or AFMLight
pageing support for geomipterrain should be on pro-rsofts to do list. if not. it’s possible to sorta force geomipterrain into it. when pro comes back you’ll know more.
there are other projects going on which are waiting for paged terrain to go into geomipterrain,too.
as already mentioned. in worst case you can use geomipterrain to generate a brute-force terrain. those are full resolution but you can use it to create smaller terrains which tile side-by-side (there might be an small issue with vertex normals at the border, nothing serious to fix if neccessary).
I’ve tried messing with auto-flatten and have gotten the same results as before. I’ve toggled on bruteforce, and you were right to say that would be the “worst case;” ppython.exe crashes. For some reason, it’s crashing every time I try running it with bruteforce set to True. Toggling it off, however, gets it to run. Odd indeed.
Well, even if I have to wait for pro-rsoft, it’ll be all right. There’s plenty more to work on meanwhile. Thank you again for your help. Your effort is most appreciated.
if brute force crashes i assume you are using panda 1.5.2 .
this bug has already been fixed in 1.5.3 which is not yet officially released. you could download the pre-release package or compile from source yourself.
maybe you simply have un-suited geomipterrain settings for the terrain quality. wrong settings can break performance big time.
can you post a sample-terrain + code you’r using to display it?
You’re right about the version. I really should use the latest version of Panda3D. I got the installation file for 1.5.3 already; just haven’t actually–well, you understand.
All right, I’ve uploaded a heightfield that’s caused problems. I’d use a more personal server, but the guy I’m working with just recently switched hosts and has yet to provide such space. http://www.filedropper.com/map1
And yes, the transitions aren’t very smooth. It’s only a test heightfield, really, produced by the aforementioned guy.
As for code, here’s the terrain-related code I’ve been using for the tests…
Note that the setMinLevel() was set to the example given on the manual. Before this, I tried setFactor(100) and setMinLevel(0), and afterward I tried setFactor(20) and setMinLevel(20). No change there seemed to affect anything performance-wise. I also tried messing with setBlockSize() and, as I mentioned before, setAutoFlatten().
on my machine your test-terrain runs perfectly fine. always hits my refresh-rate limit of 70fps,even when brute-forcing. tuning the settings work fine for me.
you can try to set
root.setRenderModeWireframe()
to render the terrain in wire-frame mode.
note this is SLOWER than rendering faces. but you can see if the terrain gets optimized correctly.
oh. and be sure to have a task which calls self.terrain.update() . can be called every frame or once every second or so , depending on how much your camera moves around (rotation doesnt matter).
what sort of hardware do you have?, cause i can run geomipterrains quite well even on an 800mhz machine with savage3 grafichips. so there might be some another issue than just geomipterrain in your case.
Yeah, I get 70+ FPS as well–until I face the heavy direction. It’s not the hardware. My rig is pretty well suited for the task; 2.66GHz Intel Core 2 Duo processor, 4 GB DDR2 800 RAM, nVidia GeForce 8800GT 512MB GDDR3 graphics card. If this baby can run Crysis at maximum detail settings without lag, then it shouldn’t have a problem with something like this.
Until I can get this resolved (be it by pro-rsoft and paging or somehow backing into a big red button that solves all my problems), I’ll be working in a nice little map generated by a 129x129 heigtfield. heightfieldSize(‘small’) == lag(0)
And since you put in even more effort, I believe more thanks is in order. Thank you for persisting with this problem I’m having. This is one of the reasons I love the Panda3D community so much; first from lurking and seeing what you guys do for others, and now from first-hand experience.
your always welcome. but if you have trouble with the terrain on a gf8800gt there HAS to be something wrong. and if something is wrong it has to be fixed, at least on mid and long-term. btw. crysis,too uses geomipmapping to optimize their terrains as you can see here http://home.arcor.de/positiveelectron/files/crysis-wire.png , thought their settings are a little bit “off limits” for lower-end hardware. even though its proven to work even on very old machines.
the strange thing is… your machine should even be able to run the entire terrain in brute-force with decent performance. are you sure that terrain is causing this? and not something else?
setFactor 20 already results in pretty low-detail terrain which runs fine on old hardware.
you might want to try a larger blocksize. 64 for example or 128.
if framerate still drops there really IS something seriously wrong. and i doubt its geomipterrain.
Goodness gracious! Well, I had previously tried a block size of 64, but not 128. I just tried 128, and the lag is gone! Frame rate stays at the stable 74-75 FPS! I also tried a 2049x2049 heightfield as an experiment with this block size concept, and doubling it to 256 cut any lag on that as well. I had no idea block size could be that significant. While I’m sure paging heightfields would be more efficient than loading gigantic segments at once, the point is this works. Thank you very much for that suggestion. I didn’t think to increase the block size by that much.
