Archive Notice: This thread is old and no longer active.
It is here for reference purposes. This thread was created on an older version of the
flipcode forums, before the site closed in 2005.
Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
I'm also working on a ROAM based engine at the moment. I'd be interested in hearing what you've come across in the way of texturing with ROAM. I want to be able to have multiple textures (ie grass, sand, rocks etc) on the same patch of landscape. The only solution I've come up with so far is to tesselate more finely around the areas where texture changes.
Why does everyone have to point out every single thing in a screenshot that doesn't match their vision of reality? Isn't that one of the nicest things about 3D computer graphics, that we can mold our own realities? I would like to see those people with valid tips and pointers, give suggestions, but I'm sure my mother wasn't the only one who said "If you have nothing nice to say, then say nothing". Not everyone submitting screenshots is John Carmack, and I for one enjoy seeing all screenshots, from beginner to advanced and would hate for people not to submit their screenshots for fear of negative comments from people who I personally am starting to suspect, could do no better. Just my two cents.
Where can I find out about ROAM rendering in more detail? From the sounds of it it's something like constant polygon count rendering? Just what *DOES* "ROAM" stand for anyway?
Also, couldn't we just imagine that it's part of a panning shot of a military base at night? That would explain the night sky / bright foreground dichotomy. It's about to be broken into by someone ... :P
Best thing I've come across for texturing ROAM-based landscapes is a detail texture rendered with vertex coloring. I use a color map much the same way the heightmap is used to determine vertex colors. The detail texture should be luminance/alpha. If you don't feel like using an additional map for vertex colors, you can always figure some way to calculate them based on terrain height and/or slope.
There are two options on the detail map I've come down to. One is to use a simple texture (noise, grain or something similar) and tile it across the terrain. Of course, this limits you to one texture for the entire landscape and can appear repetitive.
An alternative (and I like the results better, but it might not work for older cards) is to use a separate larger detail texture (I use 1024x1024) and skin it once over my landscape. The texture requirement is relatively larger and I'm not so sure how it fares with several landscapes pieced together (each with their own detail texture).
Another option (though it's probably a heavier requirement) is to just use different rgb textures with an alpha map for each layer of textures on the terrain (dirt, grass, stone, etc). This is speculation on my part since I've not tried it. However, I suspect I'd find the second option I mentioned the most pleasing (especially since you can use vertex colors to shade the terrain).
If I've not said enough to give you the right idea, feel free to send me an e-mail. I'll be glad to discuss it more at length.
Using vertex colours for a ROAM based landscape is a bad idea since you will get *very* visible popping artifacts when a new vertex is added that is different colour than the surrounding vertices. I would suggest putting your terrain into blocks then using a unique texture for each block
Colour popping can be reduced just as much as geometry popping by including colours in your priority calculations. Even better you could introduce geomorphing, but i'd challenge anyone to do that convincingly with ROAM as it is quite unstable. My hacks so far only partly solve the problem... more to come ;)
The colour map might be worth a try. I've tried seperating the terrain into blocks but this causes other complications, such as all blocks need to have the same dimensions otherwise the relationships (neighbour pointers) between the blocks don't work because there is too much difference in the levels.
Another technique which I am trying to implement is simply to check how many different textures are within a triangle and tesselate more finely near the changes in texture.
Finally I've also looked at creating another map, similar to the heightmap, which I call a priority map. The higher the priority values within a triangle the more likely it is to split. Then higher priorities could be set around texture changes etc.
This would have the added advantage that if an item or object is placed on the ground (eg tree, wall, etc) then a high priority value near it's location would ensure that the landscape around it is finely tesselated and that it doesn't float.
The priority map you talk about is used in most brute force (i.e. non split-merge que) versions of the ROAM algo, and is normally called a variance map (coined by Seumas McNally?)
It describes the "variance" of a triangle of terrain over its surface area, this is how you get the tesselation in the area's that require it.
I'm playing with texturing of my own roam-alike (basically sameas Seumas), so I'll see if its useful to incorporate texture information in the variance values.
I'm favouring having "sub meshes" with individual texture tiles.. just seems more natural.. my heighfield data is basically created as a tile map, so I am thinking that the texture data
would be equally well served by using texture tiles.
One thing Ive seen in most good algo's for landscape, is that there is a "layered" texture system, i.e. multiple
texture tiles are stacked up. To choose a texture, you basically look at the height of your tri, and blend between
the correctponding textures for that height.
Interesting area though, I'm kind of moving away from the ROAM stuff, because I really dont like the popping..
I also use a varience error metric similar to Seamus McNally's implementation, the reason for such a priority map is because I each time I check if a triangle needs to be further tesselated I check it's variance against a maximum allowable variance, by adjusting this value I can adjust the detail, and also therefore the rendering speed. However I have found there are places on a patch that need to be highly tesselated regardless of the current maximum setting, for example around items placed on the ground to ensure that these do in fact look like they are on the ground.
Really though my engine is in the really primitive stages, I quickly knocked together a renderer in a couple of hours to see how it worked, now I've spent a week trying to tidy up the code.
I really liked the idea of using what you call "sub-meshes" however in all my research I have found that for this to work properly all these "sub-meshes" must be of the same size which can't easily be done in my engine, however I may have missed something here, if so please enlighten me.