What problems with ATI cards are you talking about? Ever since Kloot did some fixes to the format they work just fine - even with shadows on. It currently just seems to have bigger problems with NVIDIA and shadows...

Any problems an ATI user gets are from missing semi colons in the TDF file, not the make of their cards, after all how can you complain about SM3 maps not working on gfx cards when the SM3 maps refuse to even load off the disk because of syntax errors?

Reading. It's not just for old people anymore!

Still I don't see what you mean with the ATI problem. I myself am using an ATI card and ever since Kloot did his fixes things work just fine. The only problems I saw here recently all were related to shadows on a NVIDIA card...

Nvidia 9600gt

Hmm, lets have a correction... Used to work fine for me.

Poop.
Without sm3 shaders


With sm3 shaders


also this map has lower fps than forbs.

Thats a familiar issue, I noticed when testing arghs map back when sm3 was new, that there was a visible line across the map where things on one side where darker and the other lighter, though it was never a solid black, and it depended on the angle the camera made to the map, if I did ctrl+scroll, I could move the line across the map

Tested it too now; only thing I can find which doesn't work is shadows. (units don't cast a shadow on the map when shadows are enabled.)

This is on a nVidia Corporation G86 [GeForce 9300M G] (rev a1) (driver: 185.18.36), with EE Narrow Passage v02.

Prolly related to the shadowmap fixes Kloot did- this may actually be addressed in buildbot Spring.

Appears this was with SM3ForceFallbackTex=1.

With SM3ForceFallbackTex=0 I get the same problems as Forboding and smoth.

With bumpmapping forced off (renderer->config.useBumpMaps = false at Sm3Map.cpp:79) it becomes this:



i.e. nice sharply defined holes in the mesh, that move around and appear/disappear (smoothly, not flickering) when the camera is moved around. Wireframe rendering seemed to suggest that there is still mesh there, but rendered exactly in the background color.

Background color, but still solid? But you're not sure? Well, do any sm3 maps have skyboxes or thick fog? Or an existing map could be tweaked.

I have examined it a little bit more after making that post and I'm now sure the geometry is still there. There are just sharp lines where the rendered color suddenly changes into the 'background color'.

Which areas seems to be related to the direction at which they are facing the camera. (I found mostly approximately left or backward facing surfaces showed this issue.)

I suspect some incorrect calculation in the shader.

Fixed.



To try, either get recent BuildServ build, or apply the following workaround (works with current Spring!):

1) Create a directory shaders in your Spring directory.
2) Download this shader into that directory.

O_O!!!! Wait, does this mean that sm3 is fixed?!?

BTW, as a refresher... I remember that JC designed sm3 with 3 texture layers in mind (base + 2). Do you guys think I could get away with 4 total and not cause massive performance drop? Whakamatunga Riri was somewhere around 10 layers iirc and ran (albiet on a 7600GT at 15 fps), or should we stick fairly religiously to the 3 layer limit?

I only took a short look on current implementation, so this is nothing more than a guess:
Currently even lowend graphics hardware has at least 16 TMU's.
(GF8600GT)
You need (2 * layers) TMUs to do the blending in a single pass. (including bump/normalmapping)

This means 8 layers should be ok.
If you want to aim for a specific hardware, just look at their TMU count and divide it by 2.
Highend cards currently have 80 TMUs

This is all based on an optimal implementation. The code seems to generate the shaders on the fly, so I guess it is optimized to use all available TMUs - but I did not dig deep enough to verify this.

PS: GF7600GT has 12 TMUs -> 6 Layers max for singlepass rendering.
PPS: Single pass means: Nearly no performance loss in contrast to less layers.

Update:
I did not know each layer has the option of an own normalmap.
Each layer now has Texture+optional normalmap+Blendmap (minus 1, because the first layer needs no blendmap).
New Formula:
TMU's needed = (2 * layers) - 1 + usedNormalmaps
Incase of each layer uses a normalmap:
TMU's needed = (3 * layers) - 1

I couldnt resist, and took a shot at completing one of my old sm3 renders:
Its 5 layers, 50 meg sauce (dont kill me, I had to fake detail textures, so thats why its so large)
It seems that each layer proporitionally decreases performance (3 layers 130 fps, 4 layers 100 fps, 5 layers 80 fps)
Bump maps are included but dont seem to work. Using sm3 shaders.
Geforce 8800GT


You can dl the map if you want to test!
http://beherith.eat-peet.net/stuff/Beheriths_sm3_sampler.sd7

Ok, this defeats my point...
But then again this just means there is room for optimization

room for optimization is not bad. Maybe some here has a gamedev.net account? perhaps somewhere there could give us suggestions on optimizations?

Until then can we not make it so we could allow multiple versions of a map that are functionally equivilant but have different numbers of layers?

e..g we could mark a set of layers as non-important, and thus they-ll get rendered on faster machines, without leaving lower end machines out in the cold, or machines under heavy stress.

I'm thinking of a new terrain texture quality slider, filtering out layers the mappers flagged as unimportant , and downsampling textures