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...Forboding Angel wrote:Smoth, if it doesn't properly support ati cards, then what's the point? I want sm3 as much if not more than the next guy, but I also want it to be able to be used by everyone as well.
SM3
Moderator: Moderators
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: SM3
Re: SM3
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?
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: SM3
Reading. It's not just for old people anymore!FLOZi wrote:So I thought I'd take a look at how SM3 is running these days; I downloaded Forbs 'Narrow Passage' ( ) map ( http://jobjol.nl/225 ), fixed up the numerous tdf parser errors and had a peek.
I'm getting 150 - 250(+!) fps depending on zoom, which is (much) better than I get on most sm2 maps, running 0.79.1.2 (and fwiw with latest git which i finally got to compile again)
Anyone have links to other SM3 maps? I tried Argh's 'Urban' map and all i got was a blank white screen; probably some error in the sm3 i overlooked and the parser didn't catch. Particularly any known to be 'heavy' performance wise (SM3 version of whatamunga riri, Forb?)
Here's the fixed Narrow Passage:
http://www.zshare.net/download/61874138ccda336a/
How does it perform for anyone else?
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: SM3
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...
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: SM3
Nvidia 9600gt
Hmm, lets have a correction... Used to work fine for me.
Hmm, lets have a correction... Used to work fine for me.
Re: SM3
Poop.
Without sm3 shaders
With sm3 shaders
also this map has lower fps than forbs.
Without sm3 shaders
With sm3 shaders
also this map has lower fps than forbs.
- Attachments
-
- screen084.jpg
- Without sm3 shaders
- (311.65 KiB) Downloaded 2 times
-
- screen085.jpg
- With sm3 shaders
- (330.81 KiB) Downloaded 2 times
Re: SM3
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
Re: SM3
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.
This is on a nVidia Corporation G86 [GeForce 9300M G] (rev a1) (driver: 185.18.36), with EE Narrow Passage v02.
Re: SM3
Appears this was with SM3ForceFallbackTex=1.Tobi wrote: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.
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.
- Attachments
-
- screen018.png
- (533.89 KiB) Downloaded 2 times
Re: SM3
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.
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.
Re: SM3
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.
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.
- Attachments
-
- screen019.png
- (597.76 KiB) Downloaded 2 times
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: SM3
O_O!!!! Wait, does this mean that sm3 is fixed?!?
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: SM3
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?
-
- Posts: 179
- Joined: 17 Jul 2007, 00:52
Re: SM3
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
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
Code: Select all
TMUs - max Layers (no normalmaps) - max Layers (fully normalmapped)
8 TMUs: 4 - 3
16 TMUs: 8 - 5
24 TMUs: 12 - 8
32 TMUs: 16 - 11
64 TMUs: 32 - 21
80 TMUs: 40 - 27
Last edited by Frostregen on 14 Dec 2009, 07:33, edited 1 time in total.
Re: SM3
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/Behe ... ampler.sd7
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/Behe ... ampler.sd7
-
- Posts: 179
- Joined: 17 Jul 2007, 00:52
Re: SM3
Ok, this defeats my point...
But then again this just means there is room for optimization
But then again this just means there is room for optimization
Re: SM3
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
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