Screenshots for IndexSplat -- around 3M

Jon

06-06-2007 21:51:39

Here are some screenshots showing the current state of the blending. I am back to using a shader, as I have a couple of ideas which might pan out. So far it looks like this will work.

The shader approach is running about 70% of the FPS of Base (same camera location and orientation).

I apologize for the lack of "real" textures. These are some I threw together just to have something to work with.

First the most disappointing of the lot: land in the foreground blending with water to the rear.

.

Next a couple of grass/dirt blends:


and


All the blending is done in real-time based on differences in texture indexes. That is, if grass is next to dirt the blending will be based on the distance from the center of each texel, using colors sampled from the appropriate textures.

I never appreciated how good height-based shaders have it until now.

Paulo

07-06-2007 01:53:26

I thought you gave up on this idea totally, pleased you havent.

Blending is looking realy nice, and the speed sounds great, you might find you get an extra speed boost when you do something about the mipmap problem aswell.

Jon

07-06-2007 02:37:29

Well I had given up on it, until I realized it was going to take 400G to texture a small map :cry:

Mipmaps aren't an issue here. I've used volume textures with mipmaps, and without. Perhaps I need to do something extra to make use of the mipmaps, I am assuming that since the default is "unlimited" that textures with mipmaps automatically use them.

Another problem I'm seeing is oversampling. There is a shimmering on the horizon. If I turn on ansiotropic filtering there is a haze extending from about 3-feet in front of the camera. This is at levels from 1-16. I'll likely need to ask on the main forums.

Jon

07-06-2007 22:16:38

OK, mipmaps and anisotropic filtering are working together. The volume texture was tossed in favor of a 2D texture atlas, which isn't much of a limitation.

The shimmering is gone. Performance is still 70% of base.

I have also shortened the blending distance considerably (getting it large was the hard part).

Regarding the water crawling up the rocks, it turns out that is not due to blending, but the index assignment. When I turned off blending I could plainly see water texels on the side of a cliff. I'd much rather deal with that sort of problem than a blending issue.

Here are a couple of coastlines. The white lines are an artifact of the anisotropic filtering (I asked about this in the main forums).


and

Paulo

07-06-2007 23:25:40

The lines are a well known problem with texture atlases + tiling that i mentioned in earlier posts, it happens when any of the filter options are used, not just anisotropic.

there are ways around it but they have overheads, these might help:

http://www.gamedev.net/community/forums ... _id=438831

http://www.ogre3d.org/phpBB2/viewtopic. ... 6f4e2718c6

Jon

07-06-2007 23:31:14

The lines are not bleeding between textures, and the lines are not present if anisotropic filtering is not being used.

There is an NVidia whitepaper on texture atlases which says that bleeding will not occur if everything is a power of two. And true to form I have not seen it, even with mipmaps.

The 0.5 offset sounds promising though, I'll adjust the atlas and see if that helps.

Paulo

07-06-2007 23:38:59

:shock: your kidding me!

I'm sure i had everything a power of two when i tried this, i always do anyway... that is incredibly annoying, i ditched that system because i thought the overheads werent worth it.

The link i put first in the message above was wrong, there was some usefull stuff in that post as i remember, ive edited it but here it is again:

http://www.gamedev.net/community/forums ... _id=438831

Jon

08-06-2007 00:37:57

Perhaps it was how you were building your atlas. I was using Nvidia's TextureAtlasTool (ver 2.00).

I'm afraid I need to waffle a bit on this subject, as if I haven't taken every position under the sun already. Mipmaps are definately contributing to the problem. Limiting the number of mipmaps in the material to 2 makes it very livable.

The uv clamping discussed in that link (thanks btw) didn't work for me. I tried different varients without success. The line corresponds to x=0 on the lookup, clamping it up just smears it and makes the line even more noticable.

Here is the worst angle I could find, with 2 mips.