Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Hery on August 07, 2009, 02:32:37 pm
-
Hello there,
Some time ago I was playing with FS trying to get it all in grayscale (since some parts are still rendered using fixed-pipeline it wasn't a total success and I got "almost-a-Sin-City-style" :P ). What really pissed me of was amount of different shaders I had to modify. So I decided to fix this problem and introduce subtractive shader.
In this approach there is one huge shader with many #ifdefs. 3d engine can choose needed functions during shader compilation (it works in exactly the same way as C preprocessor does). Advantages: we have only one shader (one vertex shader and one fragment shader to be exact), code reusability is significantly increased, and everyting takes less space. Disadvantages: shader code is much harder too understand unless you are using editor that knows what #ifdef means :P (notepad won't be a good idea). Additionally, there should not be any performance loss.
I kept backwards compatibility, so if FS can't find main-v and/or main-f files then its uses old-style shaders.
Full pack (http://www26.zippyshare.com/v/83122016/file.html) (release build, shaders, modified CPP file)
Any feedback will be appreciated.
PS I am rather unaware of SCP development process, hence I don't know it is the most convenient way to send patches made by new developers, but I hope it won't be a problem.
-
This sounds pretty awesome.
-
Looks good. If only the shaders worked with Shader Model 2 cards....
-
If only the shaders worked with Shader Model 2 cards....
Don't look at me ;P I only merged the existing shaders into one ;D
-
At any rate, when making sample builds, could you provide debug builds as well as regular ones? And instead of giving us a complete .c file, could you just generate a patch that can be applied to trunk?
-
Here you are: click (http://www14.zippyshare.com/v/14748412/file.html)
-
If the shaders are using IfDef in this system, we can compartmentalize based off reported SM version from the card.
-
What do they do? Ie screenshots for us nubs plox :nod:
-
They don't change anything, they make them easier to work with the set as a whole if you want to do your own editing. And if you can read the defines.
-
@Zacam: my patch wasn't necessary to do that, OpenGL supports GLSL preprocessor itself. However, I think I'm going to see what I can do in order to make shaders work with SM2.0
@Colonol Dekker: unfortunately it's only a "technical patch" which reduces number of shader files from about 60 to 2. I haven't added any new graphical effects.
-
Don't apologise pal, just because i don't comprehend the imapct doesn't mean it's not appreciated :)
Keep it going. :yes:
-
Right. But what the patch does is simplify the process a great deal to being able to have a more universal set to work with, rather than adding a more cumbersome load set of files.
BTW, I'm testing this out heavily, and I may have new V and F files here shortly. The shine factor seems overly bright and there are a few other general modifications to be made. Givin that you don't have SVN access to the FSU MEdiaVP's, you wouldn't have had those shader files to work with.
Also, what SVN version is the build made on?
*Edit: Nevermind, read the patch. 5509. Sweet.
-
melikeee
But the thing we need to concentrate on with this patch is that it breaks compatibility with VPs - people will need new shader packs in order for this to work.
We really need to figure out a better distribution method (I've been looking at the RakNet autopatcher, however that's going to be a long way off).
-
Uh...teh hell?
If the main-f and main-v are present, they process at priority and the mediavp ones are ignored. If they are NOT present (main-f and main-v) then the mediavp ones get used.
I attached some corrected shader files. It fixes the overly bright specular that occurs when -normal is on. No other real modifications needed, actually. Though I did change the lights load, it seems to be six of one half a dozen of the other on the method used at this point. **Edit: Attachment deleted, diffuse lighting was broken.
What I _need_ to see, is if anyone experiencing the "white polygons of death" debris or any other issues for which the mediavp shaders have been corrected to take in to account. From what I see by a comparison, there should be no problems. But some folks have had some strange issues when certain shader files are present with the rest of them, and the ATI normal's issue, that I need to hear from them with your build and the attached shaders first.
-
It's a case of reading the patch and not the context :nervous:
Sorry!
We still need to check that thoroughly - even if it's only to make sure that nothing is getting mixed.
-
Oh yeah.
The one majorly confusing thing it does.
The debug log will show all the mediavp shader names in the log, when being run with only the main-*.sdr files. This behaviour _must_ be corrected.
-
I've changed format of the log information:
Compiling shader -> real_vertex_shader (legacy_vertex_shader) / real_fragment_shader (legacy_fragment_shader) ...
Keeping the name of the legacy shader will let you know which parts of the main shader are turned on.
Pack (http://www1.zippyshare.com/v/16914871/file.html) (patch based on 5510)
@Zacam: Your shaders look like diffuse lightning is not working very well when normal mapping is turned off (at least on GF8800GT).
-
Really? Interesting, as compared to the current MediaVP shaders, the behaviour is identical.
Scratch that. Yeah, solid black models is not supposed to happen. Fixoring now.
Forgot that fixed rendering is different than just turning of the -normal flag, so, that's my bad.
Okay, so I resolved the issue, but now the specular shine when -normal is on is annoying as hell, and nothing I seem to do to it is fixing it.
*EDIT:
Fixed version. Needed an #ifdef for handling the lights for -Normal separatly from non-normal lights. Check le-v vs lne-v to verify.
FSU-MainShaders.7z (http://zacam.ueuo.com/fsu/FSU-MainShaders.7z)
-
*pokes at people*
Yes, the post processing is shiney as all get out. FSU and SCP would like to know if the patched shaders and the latest build posted here (or Antipodes 2) does not break anything _before_ it goes in to trunk. Because if it breaks in trunk, we may not be so easily motivated towards fixing it _immediately_ because ya'll did not bother testing or reporting it NOW.
Just sayin.
-
what are the most obvious known bugs at the moment? so i can whip up a unified test mission...
-
Debris doing shiny white surfaces or damage lighting/lightning artifacts. Selecting various launcher options in some bizarre combination doing wacky things.
There really is not anything you can script a mission for reproducing. Shader issues are display rendering issues, not mission programmatic ones.
-
i meant to whip up a mission where those display rendering issues might flare up. strewing around some debris, some ships with low health and so on... :p
-
This coupled with post processing could be neat. . If it works for me.
-
Excellent!
That makes playing with the shaders considerably easier, particularly when trying to propagate a change across multiple card capabilities.
Well done.
-
@Colonol Dekker: This patch only contains the code to reduce the number of mediavps shaders to 2. We're going to work through how to add the other stuff after 28th September (Hery is on vacation/holiday/away).
This is now in Antipodes awaiting some solid testing (please test Antipodes rather than the builds given here, as it is the Antipodes patch that will go through)
-
In that case, there are a lot of other pressing issues we need to sort through for the next release. The next set of updates might need to wait so we can start sorting through those.