Horde3D

Would you mind explaining how you fixed the seams in the atlas? I hope you don't mind, but I borrowed your atlas texture above to do a quick attempt at procedural texture-splatting:

Click for full size

_________________
Tristam MacDonald - [swiftcoding]

Nope, I don't mind at all.

I downsized each individual texture from 256x256 to 250x250, centered it inside its part of the atlas, and then tiled its edges. The UV sample region has to adjust for it, but its just a "gutter_size" float. 250x250 was chosen arbitrarily. This seems to be the dominant way of solving atlas seam issues but I haven't tried using different texture2D functions yet (the ones with bias and such).

All right, I thought that was going to be simple to implement. However, something must still be wrong with my border code, because mipmapping still produces very noticeable borders.

By-the-bye, have you had a chance to look at this entry by Ysaneya on atlas-based terrain texturing? I have been able to implement mipmapping successfully using his method, were the mipmap level is calculated manually in the shader, using dFdx() and dFdy(). This doesn't require the use of borders on the altas, but does push the minimum GPU-spec up a lot.

Click for full size


I would be interested in pursuing your method further at some point, but for now this does the trick

_________________
Tristam MacDonald - [swiftcoding]

That's what I meant when I said bias, for some reason I was thinking that bias was the GL term used for all that stuff, consulting the orange-book says I was wrong. That's great that it worked for the seams, I had read some conflicting stuff so was weary about using it.



No I hadn't, everything I looked at existed before I started, a blessing from the heavens that he'd pop that out in this particular time frame. I love his planetary stuff.

Shouldn't be too bad for performance unless you're blending textures, which IMO looks too fake in many cases.

I meant to ask you about that - your screenshots look like you are performing some blending. Is it full blending, or just a single repeated blend?

Apologies for hijacking your thread again, but further progress, this time slope and altitude dependant:

first image full size
second image full size

_________________
Tristam MacDonald - [swiftcoding]

The blending is incidental, its not real and is probably just a consequence of having a default texture. I've still been working primarily over a base color map which is probably also helping to soften it up.

I've started posting this stuff to the wiki, I've only got the detail texturing stuff up at the moment. Use this thread to make commentary on the wiki posts as well as the thread itself.

I probably won't write up anything about the atlas usage since Ysaneya's article pretty much covers everything in explanation and code.

Side note:
I'm not sure about my parallax mapping, it acts funky with lights in the scene, so I probably botched something with the surface normals as I still don't have intimate knowledge of the whats and whys of the terrain extension, or the whats and whys of parallax mapping either.

Hello!

In the new ShaderX6 there is an article on Filtered Tilemaps, which i think discusses some these issues.

Erlend

btw 1. Just looked into Horde3D and it seems like a great rendering framework!

btw 2. I implmented the GpuTerrain thing in ShaderX4 in OpenGL and am trying to extend it to several heightmaps. I havent looked into the terrain extension that much, but it seems to be kind of the same algorithm.. Im doing the dot product thing for detail textures, but havent figured out how to get the colors right yet.. only dividing 4 detail textures into on texture. But this kindof limits the num of detail textures.. One way It can be done (i think) is to divide the terrain using a quadtree than generate each textures per quad when needing by blending a number of textures into one based on some alpha values (or other attributes) either using shaders, or using alpha blending.

There's no article really focused on terrain rendering in ShaderX4, just terrain texturing. Being "Dot-Product for Efficient Detail Texture Mapping" and "Cached Procedural Textures for Terrain Rendering." If you're referring to the latter article then the terrain extension is considerably different. That article uses a Thatcher Ulrich style chunk LOD scheme, the terrain extension is essentially a quadtree block rendering scheme from what I can see in the guts of it.



Gasp! Book is too new. The best information is all in older books, especially GRAPHICSProgramming Gems I - V (anyone remember those?). I am kidding of course. Thanks for the article reference.

I actually meant to say, game programming gems 6, Gpu Terrain.. Of course there are waste of methods of generating lod terrain, but i believe offsetting vertices in the vertex shader using texture sampling is the way to go on todays gpu's.

If I remember right they said they already gave vertex texture fetch a shot with the terrain extension and that CPU was faster than GPU, there was no mention of hardware used. I would expect that hardware from more recent series that are DX10 capable would be pretty fast with vtf.

If you are willing to limit your audience to brand-new NVidia gaming rigs, then yes. ATI cards don't in general have VTF, instead they use the more flexible Render-to-Vertex-Buffer. Unfortunately, most NVidia cards don't do this well, so you have to implement both code-paths.

However, I still don't see the necessity of either approach for something as trivial as LOD terrain - every LOD terrain I have built has been pixel-bound. True, one could free up a few more CPU cycles for AI, etc. by moving to vertex textures, but it doesn't seem worth the effort at this juncture.

_________________
Tristam MacDonald - [swiftcoding]