Geometry clip-map blending.
Author
I have been trying to introduce limited updates to my geo clip mapping engine, i.e. after a certain number of polygon updates during a frame no more are done. This is the method suggested by Hoppe's paper to maintain a steady frame rate. What it means in practice is that when the camera starts to move faster over the terrain, the highest resolution patches start to fall behind, until thier active area is completely clipped, and the patch is no longer visible or active.
One of the features of the updating process in clip-maps is that if a level is updated then that guarentees that all levels underneath will need updating aswell, which means that during some frames more updates are needed than during other frames, even if the camera is moving at a constant rate.
This feature coupled with the limited updates means that, every so often (more often at greater speeds), the higher resolution levels will fall behind, then catch up again. The causes some real bad popping and I was wondering how this should or could be dealt with?
I am not using the blending function from Hoppe's geo clip-map paper as I had already written mine before I read it, but I can't imagine any spacial blending scheme which could cope with the popping I describe.
Thanks for any help!
Every level has access to it's data (elevation and normal) and its coarser level data. So you can't do blending between level I and I+K (k>1). I think the best solution would be to change finest active level to that level, that you are able to blend as usual. Notice that when you move fast, you need less geometry precision, so dropping some levels is acceptable.
Switching active levels themselves can be blended too. I have in my geoclipmapper additional blending as a function of height (so when I switch active levels, I get smooth transition).
For your problem:
Just drop some active levels depending on vertical camera speed, but don't do switches rapidly. Instead of this add another blending factor for smooth switches.
(oh and probably you'll need some delaying function if your camera changes speed fast)
I hope you know what I mean
and that you are aware that I can be wrong
ghostace
Switching active levels themselves can be blended too. I have in my geoclipmapper additional blending as a function of height (so when I switch active levels, I get smooth transition).
For your problem:
Just drop some active levels depending on vertical camera speed, but don't do switches rapidly. Instead of this add another blending factor for smooth switches.
(oh and probably you'll need some delaying function if your camera changes speed fast)
I hope you know what I mean
and that you are aware that I can be wrong
ghostace
Author
Yeah, my engine uses camera height and xy offset from the center of the current level to calculate the blend map.
Does your engine allow levels to drop behind, or deactivate them when they can no longer be fully maintained?
One of the problems I am having is how to determine when a level can be created again (when the camera is slowing down), if the polygon update rates are not constant for constant speed.
I don't want to have to limit the acceleration and decceleration of the camera (i.e. no time dependant blends).
Does your engine allow levels to drop behind, or deactivate them when they can no longer be fully maintained?
One of the problems I am having is how to determine when a level can be created again (when the camera is slowing down), if the polygon update rates are not constant for constant speed.
I don't want to have to limit the acceleration and decceleration of the camera (i.e. no time dependant blends).
Quote:
Yeah, my engine uses camera height and xy offset from the center of the current level to calculate the blend map.
I am using vertex textures, so I don't need a blend map. I have never implemented geoclipmaps with only vertex/index buffers (I suppose this is how you do this).
Quote:
Does your engine allow levels to drop behind, or deactivate them when they can no longer be fully maintained?
My interface allow to manually swith active levels, and perform updates (one function call). It can also do this automatically by keeping track of camera. I currently do not perfom any sophisticated stuff for high camera speed (just some simple time intervals, and camera position delta checks) - my last post was just an idea, but I am sure it would be easy to implement.
Quote:
One of the problems I am having is how to determine when a level can be created again (when the camera is slowing down), if the polygon update rates are not constant for constant speed.
I don't want to have to limit the acceleration and decceleration of the camera (i.e. no time dependant blends).
I really don't know what you mean. Are you saying about you current approach or my idea? I don't understand why you are concerned about not constant update rates and why would you want to limit acceleration/decceleration ... Maybe your problems are somehow related to your implementation?
ghostace
I'm not sure I understand your problem. Let's take an example to see if I understand right :
You travel at 1000 km / h, so at this speed, assuming a quite low vertices update budget, you will only have your coarsest level updated. So the geometry is quite flat. Your problem is that if you suddenly stop, then all the finer level will catch up, and suddenly the terrain will gain a lot of grain, and it will be very noticeable ?
Well, in this case, you can't avoid that. This algorithm take advantage from smooth accelerations / decelerations. And in this case, the finer levels will catch up in a smoother manner, and if you use the blending algorithm of Hoppe, you really don't have any problem.
In my implementation, I first compute for each clipmap what are the areas I need to update (the L-shaped area for each clipmap level) I then compute how many clipmap (starting from the coarsest one) I can update with my update budget. I then update the vertices of the clipmaps, discarding the finer ones if my budget was exceeded.
At this point, I know the bouding boxes of each clipmaps. So here, I start from the finest clipmap, and if it is completely outside the BB of the next coarser level, I disable it (I simply have a boolean which I set to false, so that it will be ignored during the building of the index buffer and the rendering)
And that's all. After that, I only need to rebuild the index buffers for each clipmap. The finest clipmap needs to be updated entirely (it's not cropped by anything) as usually. The only difference is that it is the finest clipmap amongst the "enabled" levels (remember I disabled clipmaps levels that felt behind in the previous step)
Like I said, the only problem with that is really quick speed variations. Going from 1000kmh to 0kmh will gives popping artefact, since you will go from the coarsest clipmap level to the finest one in only a few frames. But I don't know how to solve that. In my implementation, I disabled the update budget, since the terrain is used in a car driving simulation, and I don't have really high speeds, so I don't need to bother with update budget.
You travel at 1000 km / h, so at this speed, assuming a quite low vertices update budget, you will only have your coarsest level updated. So the geometry is quite flat. Your problem is that if you suddenly stop, then all the finer level will catch up, and suddenly the terrain will gain a lot of grain, and it will be very noticeable ?
Well, in this case, you can't avoid that. This algorithm take advantage from smooth accelerations / decelerations. And in this case, the finer levels will catch up in a smoother manner, and if you use the blending algorithm of Hoppe, you really don't have any problem.
In my implementation, I first compute for each clipmap what are the areas I need to update (the L-shaped area for each clipmap level) I then compute how many clipmap (starting from the coarsest one) I can update with my update budget. I then update the vertices of the clipmaps, discarding the finer ones if my budget was exceeded.
At this point, I know the bouding boxes of each clipmaps. So here, I start from the finest clipmap, and if it is completely outside the BB of the next coarser level, I disable it (I simply have a boolean which I set to false, so that it will be ignored during the building of the index buffer and the rendering)
And that's all. After that, I only need to rebuild the index buffers for each clipmap. The finest clipmap needs to be updated entirely (it's not cropped by anything) as usually. The only difference is that it is the finest clipmap amongst the "enabled" levels (remember I disabled clipmaps levels that felt behind in the previous step)
Like I said, the only problem with that is really quick speed variations. Going from 1000kmh to 0kmh will gives popping artefact, since you will go from the coarsest clipmap level to the finest one in only a few frames. But I don't know how to solve that. In my implementation, I disabled the update budget, since the terrain is used in a car driving simulation, and I don't have really high speeds, so I don't need to bother with update budget.
Let my try to get your problem right:
When you move at any (constant) speed, the clipmaps need to be updated once in a while. Say, the time between two updates of the finest level is T seconds. Then, due to the dyadic structure of the clipmaps, the next coarser level needs an update every 2*T seconds. The next level every 4*T seconds and so on. Your problem is now that if a very coarse level needs an update (say the one with update every 128*T seconds), then all finer levels need an update, too. So they drop behind because you need to update the coarse levels first. Later - in between the 128*T seconds - they catch up again, which causes the popping.
Well, I can't help you much if that's the problem. I've observed that effect in my engine, but it never caused problems. The update takes place so fast that one doesn't realize that effect.
Ah, one last try: Are you using per-vertex lighting or per-pixel lighting (with normal maps)? You should definitely switch to normal maps, because they can be blended smoothly between levels and per-vertex lighting can not, which might cause the popping.
When you move at any (constant) speed, the clipmaps need to be updated once in a while. Say, the time between two updates of the finest level is T seconds. Then, due to the dyadic structure of the clipmaps, the next coarser level needs an update every 2*T seconds. The next level every 4*T seconds and so on. Your problem is now that if a very coarse level needs an update (say the one with update every 128*T seconds), then all finer levels need an update, too. So they drop behind because you need to update the coarse levels first. Later - in between the 128*T seconds - they catch up again, which causes the popping.
Well, I can't help you much if that's the problem. I've observed that effect in my engine, but it never caused problems. The update takes place so fast that one doesn't realize that effect.
Ah, one last try: Are you using per-vertex lighting or per-pixel lighting (with normal maps)? You should definitely switch to normal maps, because they can be blended smoothly between levels and per-vertex lighting can not, which might cause the popping.
Author
paic & Lutz, thats what I am talking about, hard to explain without knowing the word dyadic!
I am using vertex normals, and vertex colors at the moment, switching to textures is my project for this week.
I have got speed up to 50-70 fps for n=64 levels=11 using VBOs and limited updates. Haven't added frustrum culling yet, and the update limits are static rather than automatically calibrating, so I can probably squeeze alot more out of it.
Thanks for the tips guys.
I am using vertex normals, and vertex colors at the moment, switching to textures is my project for this week.
I have got speed up to 50-70 fps for n=64 levels=11 using VBOs and limited updates. Haven't added frustrum culling yet, and the update limits are static rather than automatically calibrating, so I can probably squeeze alot more out of it.
Thanks for the tips guys.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
