SM3

[Tobi]

What should be done is storing blending data in the vertex instead of in texture map

Oh, so basically rebuild the vertex at runtime, store that in multitexcoords? That makes sense, and it would speed stuff up a lot.

To make this work you would need a static grid size -> more polygons + more vertex data -> you would just shift the load to the vertex shader ...

It does reduce required memory bandwidth quite a bit though, and as far as I have seen SM3 already has static grid size for each LOD of each quad.

(N blendmap lookups per fragment -> N blendmap lookups per vertex; so when each triangle is, say, 8 pixels, bandwidth [for blendmap lookups] is already reduced by 8/3.)


EDIT: Hmm on the other hand required bandwidth for 6 blendmaps is approximately same as required bandwidth for a single layer (diffuse + normal map), so this probably wouldn't help that much.

[Argh]

So... maybe... pre-build several LODs, and then, depending on the end-user's detail level settings, camera angle, and position of the camera relative to the map, we could use a lower or higher static LOD?

There would be some pop-in issues, but we already have plenty of those in SMF anyhow, and end-users could use a setting to determine how many LODs it would build- people who just wanted raw performance could set one, at a very low detail level. It would be more costly over long view-distances, so we'd force the LOD down according to the angle (so, Smoth's happy, he can specify maximum detail levels and maybe 5-6 LODs, it will look pretty awesome all the way up to the camera being flat-on with the X plane).

EDIT: Hmm on the other hand required bandwidth for 6 blendmaps is approximately same as required bandwidth for a single layer (diffuse + normal map), so this probably wouldn't help that much.

Texture loading time is not the issue (er, assuming that it's not doing something really wrong). The load of all the textures in a SM3 with 5 blend layers is tiny fraction of the load in a typical World Builder scene.

[Tobi]

EDIT: Hmm on the other hand required bandwidth for 6 blendmaps is approximately same as required bandwidth for a single layer (diffuse + normal map), so this probably wouldn't help that much.

Texture loading time is not the issue (er, assuming that it's not doing something really wrong). The load of all the textures in a SM3 with 5 blend layers is tiny fraction of the load in a typical World Builder scene.

I wasn't speaking of texture loading, but of bandwidth inside the card, i.e. basically how much texture lookups need to be done per rendering frame.

[Forboding Angel]

So where are we at on this so far?

[Beherith]

It works, its usable, but still needs a lot of work imo to be all that it could be.

You can make maps if you so desire, but keep in mind that making something that looks nice and uses normal mapping and 4+ layers of textures will be FPS hell.

[Forboding Angel]

I was thinking base layer + 2. Seems like 3 total layers (a la, narrow passage) keeps framerates a little better or on par with smf.

[Beherith]

But you lose all that you gain once you add bumpmaps. Adding them should really be a no brainer, since they look so awesome.

[Forboding Angel]

Not really... Narrow passage has bumps and I get a lot better framerate on it than I do in smf maps. Are you sure your perspective isn't skewed due to using omghuge textures in your sm3 map (I dunno how that affects performance)?

[Beherith]

Well, tbh I dont think narrow passage looks good at all. Its tiles hard, blending looks like wierd fake alpha transitions, normal maps arent deep enough.

I tried to fake custom detail textures per large texture which resulted in texture bloat on my end. But its the only way to make it look halfway decent with the current support.

Also:
large maps fail (dunno the precise limit)
very bad feature placing support
no geo support (afaik)
no detail texture support
Current spring needs an additional shader to work.

So altogether I would not deem it ready.

[AF]

Feature placement is not an issue, anyone with any sense realises that the best way to do ti is using lua map gadgets, did you not wonder why smoth and argh both built dedicated tools?

[Argh]

1. Performance isn't great, unless you want to accept a lot of tiling, which is pretty much what I expected.

I've built a map that I actually think looks pretty good, and performance was acceptable, but a further experimental map (tried to build a genuine-feeling mountain range) ended up so tiled that I really wasn't happy with the results. SM3 works well for very monochrome worlds (you could make a kickass asteroid map)... but that's it. Maps that need a lot of real color variation simply don't work well, imo- the tiling is obvious and very ugly, if you want performance to be reasonable (I got to test my maps with a 9800GS, and it's fine, but meh, people will be unhappy when I explain how to do it). Bottom line: you simply cannot achieve the level of messiness, subtlety and detail that you can with SMF. You can fake it, you can use normalmaps to make the gee-whiz factor high enough that maybe people won't notice too much, but it's really not there for some uses.

2. The normalmaps are still wrong; I presume that will either get fixed, or we're just going to move on to the next stage.

3. A detail texture really won't help, unless it's specific to a given tileset, because it'll just increase noise levels without really helping, detail-wise.

4. I used to have Geo support for World Builder- I'll look into that. Geos and Spring trees on a WB map do not need a game with WB integration to operate (as we're talking Features here, which require no high-level support... although some P.O.P.S. stuff I'm doing might be a good idea to borrow).

5. The shader requirement's one release away from being addressed; however, that's just one minor issue imo compared to the rest of the situation.

[Argh]

Water and SM3... eh... it's bad.

OK:

1. Water 0. Works all right, but doesn't seem to obey the absorb.
2. Water 1. Ditto.
3. Water 2. Ditto.
4. Water 3. Shader doesn't compile on my hardware any more
5. Water 4. Does all sorts of Weird Stuff. The shorewaves work, now that I've figured out some of what's screwy. Seems that the following settings will give you something like water with SM3:

Code: Select all

		WaterBaseColor=0.3 0.5 0.3;  //color at water surface
		WaterAbsorb=0.01 0.01 0.01;  //how fast different colors are absorbed by the water
		WaterMinColor=0.1 0.2 0.3;  //the min value the water colors will go down to
		WaterPlaneColor=0.3 0.5 0.3; 

		//WATER 4 OPTIONS
		surfaceAlpha=0.8;
		specularPower=0.5;
		specularFactor=1.0;
		ambientFactor=0.0;
		diffuseFactor=0.0;

However...

A. Does not obey absorb.
B. Looks like specular is going to start, but then there's a buggy result where the water looks perfectly still. Switch to a camera and go low, and you can see reflections getting distorted a bit, so IDK exactly what's up with this.
C. Units have an odd "halo" around Units, like a cutout, that is clearly visible and shows the map underneath.

Now, I can fix the absorb issue by using some ground-fog, I suppose. Well, assuming it will go underwater... and assuming it works. But the weirdness with Water 4 is pretty bad atm.