[Tomo]

I'm looking at tweaking the warp in/out effect so it's not such a 'hard edged' clip but something a little more subtle - my initial thought is to add a soft-edged 'flash' as they enter subspace itself. (Brighten before entry, then fading to transparent at the clip plane itself).
The obvious place to do that is in a fragment shader - it's going to be rather computationally expensive, and it is completely 'object based' rather than 'screen based'.

Obviously this means I need to work out where the clipping plane for warp is (not just 'is the vertex/fragment clipped or not clipped') and the direction of travel.
- I suspect that these two don't necessarily come automatically.

So, what variables are exposed/available to the various shaders in FSO 3.6.10?

I pulled apart the sdr files in 3.6.10 MediaVPs and they seem a bit obtuse - there don't seem to be any clipping planes referred to at all, or indeed much in the way of comments.

Does anybody have notes on how the current shaders work and what information is made available to the shaders?

Is this actually possible?
- If warp clipping is done in the main program then obviously this won't be possible.

[chief1983]

There's a recently updated document in the wiki you might be interested in - FS2 OpenGL Shaders.  Has info on all the different versions of the shader files in the MediaVPs.

[Tomo]

I've already gone through that Wiki page - it doesn't actually say anything about the guts of the shaders, only what the files are called and where they should be placed.

Hence my question!

I'd rather not pull the FSO source code apart (I don't know C all that well - been coding in Delphi for quite a while), as surely somebody knows what is passed to the shaders and how.

If the warp clipping plane isn't passed already, then obviously to do this I'll need to pull the code apart and add an extra Uniform.
- At which point some other stuff also becomes plausible, but I'm after quick and simple results at present to help me get used to GLSL instead of the HLSL I did before.

[taylor]

The clipping plane is exposed as part of the fixed function built-ins.  Look for the ATI hatred comment in the vertex shaders (accessing the value on ATI triggers a software fallback, no idea why).

The only things that are provided to the shaders are what they already use and the built-ins, not other variables are available.  If you want/need something other than what is already there then you'll have to add it.

[Tomo]

Thanks.
Are we using GLSL v1.20.8 or something newer/older?

Is there a description of the purpose each of the built-ins is used for in the OCP?
Quite a few of them could be used for many purposes, and presumably many are not used at all.

IIRC, in GLSL 1.20 there are 6 clip planes available from the fixed function, so which one(s) get used?
- Should I assume it's gl_ClipPlane[0] for the warp?

With regards to the ATI hatred line - current ATI cards don't support the gl_ClipVertex function and it's also deprecated in GLSL v1.30.08 so it'll probably never be implemented.
This means that changing the value on an ATI machine will force it to software fallback, as it suddenly won't compile for those cards.

gl_ClipDistance is the new method for user clipping in GLSL v1.30 and newer, but it's used differently to glClipVertex...

[taylor]

The reference shaders (the one's that I made) were originally set up to target GLSL 1.10.  Version 1.20 was a little "new" at the time and during initial tests 1.10 was all that was supported on nearly half of the testers cards.  Obviously that is quite different now though, since all of the shader stuff was based on a temporary design initially coded a little over 2 years ago.  The unofficial target was the initial 1.20 spec by the time the code finally hit CVS/SVN, but the reference shaders were never really updated to make any real use of the changes.

For the built-ins, is there something specific that you are interested in (I guess I'm not sure of your question)?  I would say that the only non-obvious built-in being used is where I use texcoord[1] to send the tangent space data to the shaders for normal maps.  The shader code  was intended only to be a temporary place-holder and really was only meant to copy the functionality of the fixed-function pipeline.  The code that is there now was always intended to be completely replaced with proper code in FSO 3.7.  However this was all done when the original ship date of 3.6.10 was June/July 2007, and 3.7 was going to be out in the early fall of 2008.  If I had known at the time that 3.6.10 was going to slip 2 years then I would have written the code a lot differently.

As for gl_ClipVertex, there really wasn't a good explanation why it went to a sw fallback two years ago, hence the little hack to make it work on both ATI and NVIDIA cards.  The changes in GLSL 1.30 make more sense, but that really wasn't something I had to go with when it all was originally coded.

For the clip planes though, it only ever uses one at the time, so gl_ClipPlane[0] is all that you have to deal with.  Do be aware though, that the clip plane is used for more than the warp effect (it's used to ship splits/explosions too), so if you don't add something specific to handle the warp effect then you'll need to keep it in mind as you make the shader effect.

I had always intended to adjust alpha in order to avoid the hard edges on both the warp and ship-split effects.  Initial tests never really seemed to work properly however and the code for that effect never made it passed the early test group.  I did want to revisit it later on, before the whole shader thing went public, but I never did get the opportunity due to various things.

[Tomo]

Thanks taylor - that explains a lot.

Looks like I can do some of what I was looking at, but not all that much without breaking into the code to distinguish between warp and other clipping.

Shame - I wanted to try to make this compatible with 3.6.10, rather than being 3.6.11 or later.
(Like shadows - those can't be done by shaders alone, as shaders do not know geometry/connectivity.)

Although I wonder - explosions might look good with a flash at the edges...  Time to get playing!
- First, an 'obvious' nasty shader to make sure I've got it in the right place.

[chief1983]

If you're talking about modifying the engine, it's probably too late to make it into 3.6.10.  If it's just shader changes, the FSU team might take them into consideration for the next release of the MediaVPs.

[DaBrain]

We certainly will.

Any improvement on the graphics is a huge step forward.
Actually the current shaders work great for fighters. We have all the features needed to make really great-looking smaller ships.
The options for the bigger ships are a bit limited though and some effects really start to look old in some situations.

The warp effect got serveral updates already and it doesn't look bad. What looks bad is when a ship enters the vortex.
(The other thing that is really bugging me, is the shield effects...)

[chief1983]

I only said maybe because changes of that sort might need some significant testing, but I figured I'd leave that up to you guys to decide.

[Tomo]

The two different warp effects I'm looking at are a flash at the boundary, and a 'squash and stretch to infinity' effect.

The latter would be used without the warp cone POF, in the style of Star Trek/Star Wars.

Unfortunately, now that I've done a bit of work it seems that I'll have to dive into the code to make the changes I want, as I don't appear to be able to tell if the user clipping plane is active or not. This makes the ships look a tad strange when *not* warping out.

- The warp flash I've been making is always there across the centre of the ship until it warps, at which point it jumps to the right place and follows it out. Looks quite good while warping (although not quite what I'm after yet), but terrible otherwise!

Annoying, as it means it can't be added to 3.6.10 VPs, and is going to take rather a long time because I'm not that familiar with C++.
(Shader languages are so much simpler, assuming you paid attention to Matrix maths at A-Level)

I have done a bit of cleanup of the shaders themselves, but not enough to warrant re-issuing them. It's mostly to make sure I understand what each bit is doing.

Depending on the calling code, it's likely to be worth taking them up to GLSL v1.30 and using the new kind of user clipping plane, with different planes for each use of clipping.
The key benefit of this would be greatly improved performance on ATI cards, as we won't need to force them to software mode anymore.

Given the user clipping that's done, it would probably make sense to do it in Model space instead - I'm sure that doing it in View space is a legacy of the fixed-function pipeline.
(Doing this in Model space means that you don't need to transform the clip plane to View space on the CPU)

On the other hand, I have read in many places on the forum that the graphics engine is a definite "Here Be Dragons!", so please don't hold your breath.