Hi!
I implemented GPU Clipmaps to replace my old Chunked LoD system and I have texture splatting of up to 5 texture but I have a problem:
The whole idea of GPU Clipmaps and the system I am using now is so it streams the height data from disk as needed and the terrain can continue forever without loading screen. But how would I go for changing the 5 texture I am blending on the go? considering that I am filling up heights into a height map in real time as is done in the Clipmaps technique, it means that I can't just say "from this chunk use those other 5 textures" as there are no specific chunks when it moves to the Clipmaps.
Anyone may have an idea on that which allows to keep the open world with no loading or zone transitions but still allow for smooth change of the 5 blending textures?
Thanks in advance :)
GPU clipmaps texture question
Well, how are you streaming in your other textures? If you're using heightmap data from the disc, you still need to stream in those source textures to sample from when rendering your toroidally accessed heightmap. You would need a similar streaming mechanism for changing the splatting textures too.
Author
I can easily stream textures from disc, the problem is that due to the nature of geometry clip mapping I can't just say "from this line start using those 5 textures instead" as it will change everything to use the 5 textures, also there are no specific borders in GPU clipmaps, as it works by dynamically filling a height texture that creates different levels.
I could instead stream a whole texture and use something like mega texturing but somehow I feel that will be both harder to edit and harder to create good detail per pixel.
I could instead stream a whole texture and use something like mega texturing but somehow I feel that will be both harder to edit and harder to create good detail per pixel.
Are you using D3D9 (or OpenGL 1.x/2.x) or D3D10/11 (or OpenGL 3.x/4.x)?
If you are using D3D10 or up, you can use a Texture Array with the diferent textures in each slice in combination with a Index Map (a texture with indices).
If you are using D3D10 or up, you can use a Texture Array with the diferent textures in each slice in combination with a Index Map (a texture with indices).
well wait a second, you have to be using Shader Model 3.0 because the algorithm relies on vertex texture fetch.
if you want to have different splatting sources for different sections of the terrain, you'll need to store that data then. You're already storing the height data and the normals... why not store a splat index in the alpha channel of the normals texture you generate? Regardless, you have to have some system on the CPU that determines what splatting textures are necessary to render the map from the current position, so as to bind them before rendering your vertex data.
if you want to have different splatting sources for different sections of the terrain, you'll need to store that data then. You're already storing the height data and the normals... why not store a splat index in the alpha channel of the normals texture you generate? Regardless, you have to have some system on the CPU that determines what splatting textures are necessary to render the map from the current position, so as to bind them before rendering your vertex data.
Author
Yes, I am using shader model 3, this was never asked.
I can put the blend map and stream it to the texture, I have, I said that already.
Are you suggesting to put 20 different texture and choose which 5 of them to take by using the alpha value of the normals texture as an index?
I could do that, but as far as I remember reading "dynamic branching" isn't that effective and it will be as if it sampled all possible 20 textures, which will be a performance kill. So is it?
I can put the blend map and stream it to the texture, I have, I said that already.
Are you suggesting to put 20 different texture and choose which 5 of them to take by using the alpha value of the normals texture as an index?
I could do that, but as far as I remember reading "dynamic branching" isn't that effective and it will be as if it sampled all possible 20 textures, which will be a performance kill. So is it?
you'll have to come up with some kind of system within your framework (perhaps a quadtree?) which let's you know exactly which textures are going to be necessary based on your current position within the terrain. branching in the shader is irrelevant; you have to know exactly which textures to upload to the card in order to draw the full terrain from an arbitrary position within your height data.
Author
Quote:Original post by Funkymunky
you'll have to come up with some kind of system within your framework (perhaps a quadtree?) which let's you know exactly which textures are going to be necessary based on your current position within the terrain. branching in the shader is irrelevant; you have to know exactly which textures to upload to the card in order to draw the full terrain from an arbitrary position within your height data.
Knowing which textures I need is not the problem as I said, the problem is the way GPU clip mapping works that there are no specifically defined quads that I can say "here start using those 5 textures for the splatting" as you feel in the heights as you move around into a texture from a steam.
I am having the same obstacle too with my clip maps.
At this moment I am using two RGBA alphamaps to have up to 8 textures for the whole terrain. I haven't noticed too big performance hit with sampling so many textures, but it is something that I know that could be done better. Besides it is rather limiting to have just 8 textures for huge terrains.
I remember reading a paper about using one big textures (like 4k) for each of the nested grids. I can imagine that a texture of that size should be precise enough for at least distant terrain. You can stream and or generate the data for that terrain texture as you do for you terrain geometry, and it should be cheaper to sample one texture instead of 5 or more.
For the grids nearby your camera you'll probably need some sort of detail texturing, but there you can sacrifice a bit texture fillrate.
Cheers!
At this moment I am using two RGBA alphamaps to have up to 8 textures for the whole terrain. I haven't noticed too big performance hit with sampling so many textures, but it is something that I know that could be done better. Besides it is rather limiting to have just 8 textures for huge terrains.
I remember reading a paper about using one big textures (like 4k) for each of the nested grids. I can imagine that a texture of that size should be precise enough for at least distant terrain. You can stream and or generate the data for that terrain texture as you do for you terrain geometry, and it should be cheaper to sample one texture instead of 5 or more.
For the grids nearby your camera you'll probably need some sort of detail texturing, but there you can sacrifice a bit texture fillrate.
Cheers!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
