Note how close the camera is zoomed in, and yet the map does not look like shit. Achieved by splatting 4 different detail textures on.

...which means when normalmaps arrive, the epicness will be complete

this wont turn into another sm3 debugdebakel?
i mean, will it be easy to use, just two additional black&white textures for mapconverter, one telling how strong the effect is, the other which detailtex is applied were?

Currently that is exactly how its done.
Im not sure about normal maps, to be honest, we seem to be doing a pretty good job of burning them on, and Im not sure that low resolution normal maps would even have a point, and resolutions on par with the smf textures might be a big load

If the normalmap tiles were tiled like a detail tex, then they'd be plenty high in resolution, and add a terrific amount of apparent detail. Combine with a big spectex to determine the scale / color of said specularity, and there you go- map-wide control, lots of small details up close.

I guess you misunderstood where I was going with that, basically- I don't want normalmaps at the spectex resolution, that would look like ass.

Ahh, looks good man.

Kloot, where do I have to dig around to add a tdf parameter to a map? I got it all in the engine, but the path string is hard coded atm cause I dont know what part of the code parses the tdf files. Just like the specularTex=... bit.

I know this sounds really noobish, but I did a ctrl+f on the codebase for speculartex and couldnt find any part relating to tdf loading

Wait, you mean baked-in normal maps? I thought normal maps were impossible to bake since they simulate real geometry and change appearance correctly when camera moves?

Let me rephrase that; we use normal maps to bake lighting into the terrain knowing that the suns direction is fixed. And the results are quite decent.

Do any of the textures that I uploaded get tiled if you assign them to your SSB map? One solution I have lined up would be to split the spectex into 1K chunks, but I'd rather not go there yet (unless this is a problem for more people too).

Also, can you verify that it always happens when sizeof(spectex) > 1024, or only when sizeof(spectex) > [sizeof(diffusetex) / 8]?



SMD parsing is the domain of the maphelper Lua scripts.

Texture split bug is still there, but im ignoring it for now, as I have run into this:

Im passing a detailtexture distribution map to your shader, its a uniform sampler2D

If I use your code:


Then fps is 400 in my benchamrk case, and cpu use is 50%

If I use my code in the fragment shader (vertex shader unchanged, notice I use the speculartex coords for the detailtex distribution, fragment shader also the same with only these parts changing)

Then I get 380 fps, but 100% cpu use. I get this cpu use difference consistently every time I try this.

I also did

instead of

In my solution, but that kept the 100% cpu use, and resulted in 2% less frame rate.
Im using a widget to set up pre defined camera states for benchmarks, and am using low terrain detail to make sure the gpu is doing alot of texture filling work.

Been working on this.
What it still needs: water absorbtion - though that can be done without, if the perf cost is too high.
And map base fog - i wouldnt mind this going at all.

CPU use issue is unrelated.

More of what it can do:






At the moment it can do a common, adjustable resulution based splatting of 4 different grayscale detail textures and and adjustable intensities for each detail texture. No performance loss on my hardware.

Kloot rocks! http://github.com/spring/spring/commit/535b480b190f9a3b0745745f8bc82b4059a33c2a

I have a few questions though:
Spring seems to use manhattan distance for fog. Doesnt length(vec3) use sqrt? Is this a performance hit?
Also, is this shader using the compatibility profile? Because if so, why not use the built in in float gl_FogFragCoord ?

Euclidean distance actually (standard for linear fog), so there was always a sqrt involved.

I think you mean gl_FogCoord (gl_FogFragCoord is an out-parameter for vertex shaders), which needs to be initialized via the FFP to be usable.

Water absorption will be cheap enough; I've got it almost-done locally.

Is your patch in a releasable state yet?

OK... so...

1. Is this in current master yet?

2. If so, how do we test it out?

3. It still won't respond to light angles?

Really impressed with that beach, btw.

I am very close to release, just need a smart way to handle fallback to the case where there is glsl map rendering but no detail tex splatting (fallback to old dtex)

Also, is there any reason we are not defining alot of the stuff as const?

If we want it to look correct for the lighting angle, we have to do that manually though, I take it?

And yes, there have been reports suggesting issues with const and ATi, although I really have my doubts that's the real problem.

Yes (as you could have inferred from the rest of this thread).



Read the first post.



What?




ATI's tend not to like it.

IOW, it's just a color overlay with alpha, not a bumpmap? I know it creates a specular highlight, but I'm trying to understand how that interacts with the camera angle, that's all.