More Detailed Textures

Topics: User Forum
Jan 15, 2007 at 9:54 PM

I love your component. It has been a great learning tool for me, although a little tough going in parts.

Would it be possible for you to explore, or just chat here, with ideas concerning adding a higher level of detail to the terrains?

I'm a bit of a noob, so I'm not sure what the norm is... I guess my idea centers around creating a texture file 10 to 20 times larger than the heightmap image. This would obviously then exceed the maximum texture size XNA / Video hardware would support (in my case it does anyway, learnt from experience!), and then using some partitioning algorithm to automatically partition the large image file into say, 4 smaller ones and then lay these over the appropriate sections of the generated terrain.

Any ideas how this could be done / how it's achieved normally?

Jan 16, 2007 at 4:18 AM
I'm not an expert on terrain detailing, but I have done it in the past where I use a smaller texture (say, 256x256) that is repeated over top of the large texture. This gives a grit like effect. You can get the general look (snow, sand, dirt, grass) feel in the large texture then repeat the grit every sector (16x16 pixels in the heightmap) with an alpha or some other type blending.
Another idea that I was thinking of, is using a pixel shader that bump mapped using some fast noise function. That would give detail that would respond to where the light (sun?) was coming from. I haven't yet found a really fast noise function, so it would need to be a normal map (bump map?) that the shader used.
I have also seen where mulitiple textures are used (each large) on seperate sections of the terrain. Like you said, XNA (directx/hardware) generaly don't allow really large textures, so people cut a large texture (say 4096x4096) into 4 peices and the texture coordinates in the heigtmap are generated 0.0-1.0 for the first and second half left to right and same verticle, then a different texture is used for each quarter.
Each of these will cause a slow down of the drawing, but some worse than others.
I currently have a version (not yet released) of the Quadtree project that sorts the sectors (and therefore models and gamecomponents) front to back, making drawing faster.
If different textures are used, then each sector would need to check if the previously set texture was the same as what it used. That would cause texture changes (fairly expensive, I think).
If an overlay detail texture is used, then the same 2 textures are always used on all sectors of the quadtree.
I may need to try several ways to see what works best overall (or allow multiple options, if possible).
What do you think?
Jan 17, 2007 at 5:53 PM
I like your bump-mapping idea (although I did just learn about what it actually is on Wiki 5 minutes ago!).

I think it would give a seemingly random feel and unique feel to the terrains.

I don't believe it to be necessary to start overlaying additional textures unless the application really needs it. I'd have thought the only other things requiring adding to a terrain would be scenery objects which you already do in your example application with the rocks. If you take a bare scenery, add some rocks, trees, shrubs and water in the same manner the terrain would soon come to life.

I don't think the texture needs to be more detailed as such, it just needs to look sharper if you get what I mean. i.e. it appears when I run in say 1024x768 that I am running in a lower resolution. Sharpening the image and adding more subtle detail such as the bump-mapping would, I think, give it a sharper, more detailed feel without having to sit down and spend hours detailing a texture and making sure it matched the height map. I believe whatever is possible should be done dynamically with shaders / filters / etc.

I am thinking to applications I like the look and feel of the terrain, most notably sim games such as Sim City 4 and Rollercoaster Tycoon (latest version #?). I can't see that they would use a whole texture map for their terrains, I'm guessing they used a texture per tile and repeated it as often as possible. Maybe that is the way to go?!

Anyway, enough of my ramble! :)
Jan 18, 2007 at 12:26 AM
BigWinston, rambling is okay, I think they call it BLOGging these days :)
Anyway, that's how ideas are generated, talk about possiblities, no matter how impossible or improbable they may seem at the time, it might spark another idea that comes to life...
I had in mind that the terrain would be used for realtime strategy type games (although not exclusively) where lots of time for AI (path finding, goal setting and execution, etc) would be needed, so I hope to come up with terrain tiling that would be fast, yet look acceptable so that player(s) don't get distracted by the view, but get immersed into the gameplay.
If someone wants to do a game like "Zoo Tycoon 2" or something where the player can change the terrain on the fly.....then the terrain needs to be able to support seperate textures (or parts of a texture, ie, multiple tiles in a texture) to allow the user to modify it but still render fast. These games are somewhat semi-realtime in that framerate is not quite as important as games that require you to act in an instant to movement of other players or AI charaters (ie, to shoot them or evade them).

Thanks for your participation in these forums. It is good to discuss these issues with someone :)
Jan 18, 2007 at 12:43 AM
Another thing I had thought about doing is to return the Quadtree nodes that need to be rendered to the Quadtree user code. That way, it can be rendered how ever one would like, but the quadtree would only return a list of nodes that are in view, and sorted front to back (for speed and LOD, etc....)....
Then other compoenents could be written that handle the quadtree rendering in various ways, depending on the specifics of a particular game.
(I wish I could edit my posts on this forum, I could add this to the previous post).
Jan 18, 2007 at 12:47 AM
(dang, I should think these out before hitting reply).....

Anyway, another thing I have been thinking about is allowing the user to pass a vertex declaration into the quadtree to allow them to add extra per vertex data that I don't currently use. It would have to have at least the elements Position, Normal and Texture, but could have other things added for their shaders to use. I would have to figure out a good way to let them add their data to the vertices.
Jan 18, 2007 at 1:55 AM
Hey Clyde,

Funnily enough, I was thinking about trying my luck at an RTS game too. I think in an RTS game, unless you wanted some REALLY tasty camera shots, that the details doesn't need to be too great, as most of the time you're staring straight down at the ground. As long as the main grass/snow/sand texture is OK, as thats what you'd see most of the time, then I think the rest could be done with objects.

Following my recent post, as I was a little bored at work, I started typing some code out, using yours and some other tutorials as examples, for a terrain editor. I like the idea of the 'sim' games type that you don't have to paint your own textures, you can just select a terrain type for each tile. I'm not a particularly great artist, so I figure that is my best approach!

It wont be anything too great, but will hopefully allow you to drag terrain heights by vertex, smoothing, etc...

Jan 18, 2007 at 6:04 AM
Once you allow editing of the terrain, you might want to use the float, array instead of the Texture2D so they have a much greater control of the terrain height.