Generating geomipmaps
Author
I''m aware of the general theory and have a version implemented but I''m not quite sure if it''s optimal so:
1)my patches of terrain are (2^n)+1 vertices per edge ie 33x33 to get a 32x32 patch. Do get the 1st level mipmap from original, do I just average every 2x2 section of the patch, or should I include adjacent patches as well for better continuity. The latter seems more sensible but that''s not how I understand it''s done.
2)I have a method to determine errors in height fata between a mipmap and the original but colour is a factor too. A completely flat patch might have very big colour changes which would indicate you want to keep a higher mip level than height errors would suggest. But what quantitative methods could be employed here?
Thanks.
Any thoughts anyone?
Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor
John 3:16
You will have one and only one vertex buffer. To mesh this buffer you will use an index buffer. The index buffer references the vertex buffer. You loop through the index buffer from front to back and it should ideally give you several rows of triangle strips that draw out your particular chunk. To create a mipmap of the chunk, you generate more than one index buffer. Each index buffer will be one mipmap at a certain LOD, so they get progressively shorter. Each mipmap level has an odd number of vertices, 2^n+1. The index buffers for the mipmaps simply skip every other vertex.
Regarding 2 (colour mipmaps):
Texture maps are normally used which means the colour detail is not dependent on the number of vertices. Colour is not per vertex as you are probably assuming.
Texture maps are normally used which means the colour detail is not dependent on the number of vertices. Colour is not per vertex as you are probably assuming.
Author
It is in my engine!
y2kiah: I see what you''re suggesting but that''s not really geomipmapping as I understand it. You''re approach is basically to read every 2nd point or 4th point etc to get a reduced size patch wheras I want to filter the original so that all vertices contribute to the next mip-level. Like with a 2x2 grapics image you''d average the 4 pixels to get a 1x1 mipmap rather than just using the (0,0) pixel in the original.
y2kiah: I see what you''re suggesting but that''s not really geomipmapping as I understand it. You''re approach is basically to read every 2nd point or 4th point etc to get a reduced size patch wheras I want to filter the original so that all vertices contribute to the next mip-level. Like with a 2x2 grapics image you''d average the 4 pixels to get a 1x1 mipmap rather than just using the (0,0) pixel in the original.
that would mean storing the vertices for every level. if you have 32x32 patches. thats 6 levels so you have 1365 vertices or 341 vertices extra per patch. with a 512x512 heightmap thats 256 patches or 87296 vertices extra. assuming you also want correct normals and colors as bytes without alpha thats 9 floats per vertex.
3MB of additional data isnt even as bad as i thought it would be. but connecting different lods would be a pain, as you would need a lot of additional linking pieces.
concerning the colors: wouldnt it work to just treat them as a vector and do the same as you do with the heights?
3MB of additional data isnt even as bad as i thought it would be. but connecting different lods would be a pain, as you would need a lot of additional linking pieces.
concerning the colors: wouldnt it work to just treat them as a vector and do the same as you do with the heights?
Author
Yeah for rgb colours that would be simple, should''ve seen that one!
I worked out the extra memory for a a complete mipmap chain once, based on the fact that each level is 1/4 the memory of the one above. For a full mipmap series I think the whole set of mipmap levels together take up pretty much precisely 1/3 the memory of the original data. Which is quite small.
I worked out the extra memory for a a complete mipmap chain once, based on the fact that each level is 1/4 the memory of the one above. For a full mipmap series I think the whole set of mipmap levels together take up pretty much precisely 1/3 the memory of the original data. Which is quite small.
quote:Original post by d000hg
For a full mipmap series I think the whole set of mipmap levels together take up pretty much precisely 1/3 the memory of the original data. Which is quite small.
yep, at first i thought it would cause horrible hunger for memory (maybe because im currently trying to minimize it and no matter what you save at one point, you need it at some other point.. so im constantly at around 60mb).. even connecting the patches doesnt sound that bad anymore, as long as you make sure that the edges dont change.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
