update on my indexSplat texture technique

I've had some time to spend on this, and while the texture application is fine the alpha blending leaves a lot to be desired. It is driving me batty trying to come up with a weighting which looks nice, and most of my time and effort is spent in Excel at present. Progress really took off after I made the spreadsheet. Go into PIX and see a point I'd like to know more about, get the pixel position and enter it into the spreadsheet, then I have all of the calculations and intermediate values on the screen in an instant.

On the performance side, I see that frame rates are about 70% of what I get using BaseTexture. Considering that the shader isn't optimized yet I think the final result will be good.

Edit: it runs 150% the speed of InstantBase. Same terrain, same camera position and orientation. Measurements based on fps after all load queues have emptied. I expect it to drop a bit as I work on the alpha blending more.

On the plus side, debugging the shader has provided me with a very nice education.

Hello, i managed to get it working aswell, and the performance was good because there was only 2 accesses to different slices of the 3D texture (i found moving between slices slow) but like you say the problem is getting the blending looking good, i couldnt get anything like as good results as with alpha's per splat, i hope you beat me and come up with something spectacualr

How are you getting around the mipmap problem? i was going to just use lod's ...

I have a 12-texture access shader which runs at 80% the FPS of BaseTexture, so texture lookups are not necessarily bad.

I turned off mipmaps in the material, so they haven't been an issue for me. When I get the blending looking good I'll revisit them. I am not looking forward to that right now.

I fear the real-time automated texture blending is probably not going to happen, and I'll need to preprocess it.

It is time to rethink the wisdom of this approach.

The cost of this approach exceeds that of image texturing, and I feel foolish for not seeing that earlier.

While it was entertaining to get the huge splats working, the realization I came to today was that I could pre-splat everything offline and generate an image file which was no bigger than the index. Thus, the volume texture is excess.

The blending problem is solved nicely by having the terrain generator perform the texturing. Thus there are no texture limits, there are no restrictions on sizes or numbers of textures in a page/tile.

Some things you just have to figure out for yourself I guess.

I was never satisfied with the blending I was getting in the shader. But I will share this entertaining debug-bitmap (the coordinates were added in Photoshop post-run).

I just found out the current thread, and I find quite e lot of interesting tnings in it.
I have a link that you may like to look out : Ares Lagae's Thesis "Tile-Based Methods in Computer Graphics. "
chapters 1-3 and 5 ...
http://www.cs.kuleuven.be/~ares/PhD/

Lagae (and his professor Dutre) use "colored corners tiles sets" to generate "infinite" random textures ...
I was thinking of using it in a Terrain Manager, but have NO time to test/implement anything

Thanks for the link, I ran across the thesis in Google Scholar and meant to read it when I had time. But that hasn't happened.

As an aside (but still related to the IndexSplat shader), I have come to the conclusion that it is easier to build a shader simulator and develop the shader on it, than debugging on a real shader.

I had hopes that RenderMonkey and FX Composer would fill that need, but I have yet to have a satisfactory experience with either.

OK, updated status.

I have converted the shader to use a 2d texture atlas, and everything is happy. Mipmaps and anisotropic filtering. The solution to the mipmap problem was to pre-generate the mipmap chains using the nvidia atlas tool.

The shimmering I reported elsewhere is gone, performance is fine.

Blending is still a little wonky. Having water crawling up the sides of a cliff is distressing. I also want to have the texture transition occur a little more rapidly (although it is comforting that I can stretch it out across a tile like I'm doing).

If you haven't the time to read the thesis, there are 2 papers that present the "interesting part (in your case) of the thesis :
An Alternative for Wang Tiles: Colored Edges versus Colored Corners
http://www.cs.kuleuven.ac.be/~graphics/CGRG.PUBLICATIONS/LagaeDutre2006AnAlternativeForWangTilesColoredEdgesVersusColoredCorners/
and
Long Period Hash Functions for Procedural Texturing
http://www.cs.kuleuven.ac.be/~graphics/CGRG.PUBLICATIONS/LagaeDutre2006LongPeriodHashFunctionsForProceduralTexturing

Thanks for the links. I had already obtained a copy of the wang-tile paper, but the other one slipped past me.

This morning's update: I have addressed the line problem with more success, using a variant of the technique in the link Paulo provided. The idea is the same: sample from the interior of the texture (just a little bit).

That, plus a new water texture I made up this morning is seen below. The old water texture got on my last nerve. While I'm no artist, this seems to have gotten the job done.



You can still see a little artifact. I probably should move that sample point over another texel.

Makes me wonder if the visual impact of anisotropic is worth the overheads of these work arrounds?

I think you worry too much about overhead. A single affine transform isn't that big of a deal, and it certainly isn't reflected in frame rates. When I see the frame rates drop significantly, then I'll worry.

Therefore, in my opinion the anisotropic filtering is definitely worth it. Without it, there is a significant shimmering near the horizon, which is very distracting. With it on, the shimmering is gone.

I have managed to increase the number of mipmaps to 3 without hurting things. Above that and I see artifacts I couldn't easily work around. I think the 3 mips are a good compromise.

Anyhow, the 18 texture lookups are probably more of a deal, and it still runs faster than most of the texture modes in the demo.

The problem is the impact is relative to the power of your graphics card, i have a geforce fx 5900xt and things like this do have an impact on the frame rate. At the end of the day i suppose its all relative, deppends what hardware you are targeting.

True, but without knowing that *some* card actually is being hurt by the operation, I wouldn't worry. This type of translation shouldn't be an issue on any card with a pixel shader.

For the sake of the argument, lets assume that there is another operation being done which really does affect the frame rate. I would rather sacrifice frame rate and have the graphics look correct than have poor rendering being done fast.

I have also never felt the need to cater to terribly old hardware. If a feature is found on a card for under $50 US, I'm not going to spend time avoiding it. A card like the Geforce 7100GS is $43 at Newegg.

True, its the kind of thing we could argue about for ever, there is no answer...

Just been thinking, why would anistropic filtering be fixing your shimmering problem. Mipmaps reduce shimmering, anistropic filtering gives you the sharpness back that you lose with mipmaps, without reintroducing the shimmering.

Maybe the problem lies somewhere else.

I'm not sure why. I say that the filtering is the cure because I can run with filtering on and mipmaps off and observe the shimmering is gone.

I could hand-wave a bit about averaging of oversampled texels. But I really don't have the answer. I'm just happy to have things looking good.