PixelShade & terrain - safe my time....
Hi...
I''ve implemented my terrain (heightmap terrain) with splat technic..
I render my buffer 2 times, and with 6 64x64 chunks I get 50 fps...
I''ve done it in 3-4 weeks ... and now I''ve discovered that is possible to make it with PS 1.1 with a better performance...
is true?
I''ve wasted 4 weeks of my life?
Do you advise me to learn pixel shade?
I''m a bit frustrated... If your answer is yes I will have to throw away all my work...
byezz
Hi,
I am working on some terrain code aswell. I also have 64 x 64 chunks (4 chunks x 4 chunks = 16 chunks) .
I implemented it using texture splatting. I got about 250 FPS.
Then I implemented it using a simple PS shader (HLSL) just doing simple additive texture blending of 2 textures. No alpha maps.
I got about 300 FPS from this. So, about a 50 FPS increase.
I am using ATI RADEON 9800 PRO.
With the ATI''s I hear that they replicate the fixed function pipeline, using shaders. So even if your NOT using shaders, you really are. Thing is though, the shaders are probably a little bloated to support the general case. You can therefore, often get better performane by writing your own minimal shader manually.
I am working on some terrain code aswell. I also have 64 x 64 chunks (4 chunks x 4 chunks = 16 chunks) .
I implemented it using texture splatting. I got about 250 FPS.
Then I implemented it using a simple PS shader (HLSL) just doing simple additive texture blending of 2 textures. No alpha maps.
I got about 300 FPS from this. So, about a 50 FPS increase.
I am using ATI RADEON 9800 PRO.
With the ATI''s I hear that they replicate the fixed function pipeline, using shaders. So even if your NOT using shaders, you really are. Thing is though, the shaders are probably a little bloated to support the general case. You can therefore, often get better performane by writing your own minimal shader manually.
What kind of texture blending are you doing ? Alpha Maps? How many textures?
Your post caused me to go back and look at my pixel shader. I was doing a 2-pass additive blend (no alphas) and then realized a way to do it in just a single pass. I got a 100 FPS boost out of this.
So, I''m looking at ~ 250 FPS with texture splatting (no pixel shader) and ~ 400 FPS with the pixel shader.
Your post caused me to go back and look at my pixel shader. I was doing a 2-pass additive blend (no alphas) and then realized a way to do it in just a single pass. I got a 100 FPS boost out of this.
So, I''m looking at ~ 250 FPS with texture splatting (no pixel shader) and ~ 400 FPS with the pixel shader.
You didn''t waste time, you hopefully learned something.
It is essential that you do learn pixel and vertex shaders as
they will make your life a lot easyer.
Using HLSL you can probably replicate all your work
quickly
It is essential that you do learn pixel and vertex shaders as
they will make your life a lot easyer.
Using HLSL you can probably replicate all your work
quickly
I use 3 textures for chunks, plus 2 textures for alpha map...
First I render all chunck with opaque base texture, then I render others two splat-chuncks ( that together are smaller than chunk ) with the its texture and alpha map...
50 fps with my ATI Radeon 9600 pro and Athlon 3200+....
Compliments... excellent performance.
mmmmm... yes, but when I''ll use splat technic again?
Ok... then I''ll search some tutorial and I''ll learn it..
thanks
First I render all chunck with opaque base texture, then I render others two splat-chuncks ( that together are smaller than chunk ) with the its texture and alpha map...
50 fps with my ATI Radeon 9600 pro and Athlon 3200+....
quote:
I got about 250 FPS.
Compliments... excellent performance.
quote:
You didn''t waste time, you hopefully learned something.
mmmmm... yes, but when I''ll use splat technic again?
quote:
Using HLSL you can probably replicate all your work
quickly
Ok... then I''ll search some tutorial and I''ll learn it..
thanks
Besides, you now have a technique that works on cards which don''t support PS1.1. If you add detection code to your game as it starts up, you could switch between this method and the PS1.1, thus increasing the size of your potential audience...
That comment about Fixed Function just isn''t true about ATi''s cards. It''s true about DirectX. At GDC this week, if you stop by AMD''s booth for their DirectX talk, you''ll see this. DirectX looks at the render states and write a shader for you. You should get speedups when going from FF->Programmable (even if they do the same stuff), because then you don''t have branch prediction. Is blending on? is Lighting turned on? etc.
i''d have thought it would have made sense to use a shader as a ''default'' fix function pipeline on programable hardware, saves you having to include the fixed function stuff in silcon (sp?)
@bluechip: I think in your case it''s not a question of using pixel shader or not - problems should exist somewhere else. I would suggest to simplify the design & locate where''s the slowdown in your current implementation, before using pixel shader solely for speedup...
(just my little idea.. maybe I''m wrong)
(just my little idea.. maybe I''m wrong)
There is a little detail many people seem to forget: any optimization done in the pixel pipeline will only affect fillrate (pipeline delays, GPU <-> VRAM memory bandwidth, etc). Nothing more, nothing less.
This means in practice, that if you are not fillrate limited, such optimizations will give you an impressive framerate increase of exactly - zero.
gamelife hit the point: before optimizing anything, profile your code. Know your bottlenecks, and target them in your optimization. In your case, a have a very strong feeling that your problem has absolutely nothing to do with the pixel pipeline, nor with the geometry pipeline. You''re probably wasting cycles somewhere where you never imagined it (CPU side data streaming, culling, LOD stuff, etc).
So, happy profiling
This means in practice, that if you are not fillrate limited, such optimizations will give you an impressive framerate increase of exactly - zero.
gamelife hit the point: before optimizing anything, profile your code. Know your bottlenecks, and target them in your optimization. In your case, a have a very strong feeling that your problem has absolutely nothing to do with the pixel pipeline, nor with the geometry pipeline. You''re probably wasting cycles somewhere where you never imagined it (CPU side data streaming, culling, LOD stuff, etc).
So, happy profiling
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement