Shader patch

For collaboration on developing the mod capabilities of VS; request new features, report bugs, or suggest improvements

Moderator: Mod Contributor

Postby chuck_starchaser » Sun May 11, 2008 7:24 pm

ace123 wrote:Would it be possible to add a "shader" column to units.csv? That way the planet entries in there can have a custom shader.

If klauss has a solution that is also fine... it would be cool to allow custom shaders for some units (For example jump points).

Indeed; jump points are a special case, in the sense that if we do what safemode was suggesting, of actually simulating a wormhole, this would take a snazzy vertex shader, not just a fragment shader. But we shouldn't go crazy; Hellcat is adamantly opposed to shader proliferation, and for good reasons: shader switch overhead, which is huge; and the problem of maintaining multiple shaders. But some specialized shaders are inescapable. Specially planets.

Now, the idea of putting a shader column in units.csv suits me just fine. I think eventually we'll need Klauss' Method thing, but if we can get the units.csv thing to happen faster, I'm all for it. Tons of stuff is NOT happening in the art department because most artists out there don't know how to produce or use bakings. Having a shader column would allow us to switch to having ambient occlusion in the glowmap's alpha channel, and do all the ao dependent calculations in the shader; so models could be updated by just baking the ao and adding it to the glow texture; and changing the shader for it in units.csv. Same with shininess. Shininess computation from specularity doesn't work; but I have a Blender noodle that does a fairly good job of getting a basic shininess map from diffuse AND specular color.

So, yeah, then maybe this idea would remove the urgency for the Method thing, and Kluss could try and get the Tangents to work, first. That would be wonderful, because that's the other thing that's never going to happen in the Arts department: Normalmaps. It's impossible to work on normalmaps with the restriction that front must be North in the texture. Impossible. Well, with a new ship it IS possible, because one is doing a brand new unwrap; but there's no texturers out there that can take an existing mesh and reorient all the UV islands. None. Texturers are not modelers; and even for modelers that's a huge job. We need Tangents yesterday. I mean, a year ago.

By the way, rather than "shader", the column should specify a texture packing version; as shaders may evolve independently of the texture packing version; but what really matters, for shader compatibility, is the texture packing philosophy.

Like,

Version 0 (current) has nothing special
Version 1 has shininess in spec alpha.
Version 2 has shininess in spec alpha, and ambient occlusion in glow alpha.
Version 3 has shininess in spec alpha, ambient occlusion in glow alpha, and a "is_dielectric" bit in damage alpha (to turn on Fresnel).

And so on.

Planets and jump points would have special texture packings, so they'd be covered by this system.
User avatar
chuck_starchaser
Elite
Elite
 
Posts: 8014
Topics: 195
Joined: Thu Sep 04, 2003 9:03 pm
Location: Montreal

Share On:

Share on Facebook Facebook Share on Twitter Twitter Share on Digg Digg

Postby klauss » Sun May 11, 2008 9:34 pm

Techniques won't take that long to implement.
I think I can get them working during the week.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Postby pyramid » Mon May 12, 2008 7:46 am

The planets do not use meshes by the atmosphere fog elements do.

There are 2 types of atmosphere meshes being used in VS:

1)
Code: Select all
<Fog><FogElement file="atmXatm.bfxm" ScaleAtmosphereHeight="0.96" red=".5" blue="1" green=".7" alpha="0.5" dired="1" diblue="1" digreen="1" dialpha=".5" concavity=".99" focus=".01" minalpha="0" maxalpha="0.25"/>
<FogElement file="atmXhalo.bfxm" ScaleAtmosphereHeight="0.96" red=".5" blue="1" green=".7" alpha="0.5" dired="1" diblue="1" digreen="1" dialpha=".5" concavity=".99" focus=".01" minalpha="0" maxalpha="1"/></Fog>


which gives this effect:
Image

2)
Code: Select all
<Fog><FogElement file="sphereatm.xmesh" ScaleAtmosphereHeight="1.01" red=".5" blue=".9" green=".5" alpha=".5" dired="1" diblue="1" digreen="1" dialpha="0.9" concavity="0.3" focus=".3" minalpha="0.5" maxalpha="1" />
<FogElement file="sphereatm.xmesh" ScaleAtmosphereHeight="1.04" red=".5" blue=".9" green=".5" alpha=".5" dired="1" diblue="1" digreen="1" dialpha="0.5" concavity="0.3" focus=".3" minalpha="0" maxalpha="1"/></Fog>


which gives this effect (as chuck said, the shader confuses this one with glass copulas):
Image

The material difference between those 2 meshes is minor and consists mainly in the emissive matrial component:
Code: Select all
<Emissive red=".5" green=".5" blue=".5" alpha=".5"/>

and the alpha values in diffuse, ambient, and specular.
Why is actually the first one working and the second one not, is beyond my comprehension. Other than that the first mesh consists of triangles, while the second is made of quad faces.

I'd actually prefer to use the second mesh for the atmosphere fog since it's much more detailed (1024 faces) and can be accurately scaled to the appropriate radius to simulate almost realistic atmospheric scattering (with the previous shader).

You can checkout latest svn and run ./vegastrike test/planets.mission. Look on Atlantis (first fog mesh) or Barnoose (2nd fog mesh) to see this effect in game.

Btw, are the dielectric value statements (dired, diblue, digreen, dialpha) in fog used for anything at the moment? They don't seem to make a change.
User avatar
pyramid
Expert Mercenary
Expert Mercenary
 
Posts: 960
Topics: 44
Joined: Wed Jun 14, 2006 6:02 pm
Location: Somewhere in the vastness of space

Postby klauss » Mon May 12, 2008 8:58 am

The planet shaders I was developing do the atmosphere with the same sphere mesh (but different vertex program). When the techniques are done, those weird fog meshes won't be necessary, only a relatively long list of shader parameters.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Postby chuck_starchaser » Mon May 12, 2008 12:55 pm

I know nothing about fogs; but I just wanted to make an off-topic comment. Something I said many times to deaf ears, but that was before Pyramid's time. Well, Vegastrike is not my mod; but I can't help it... Gotta get rid of intersecting rings for ringed planets, guys. Not only do they look awful aesthetically speaking, but they look *ignorant*. There CANNOT be intersecting rings. It is physically impossible. They would mutually annihilate in the space of a week.

One planet <=> one ring plane.

Basta!
User avatar
chuck_starchaser
Elite
Elite
 
Posts: 8014
Topics: 195
Joined: Thu Sep 04, 2003 9:03 pm
Location: Montreal

Postby pyramid » Mon May 12, 2008 1:02 pm

Great. Though *I* can't wait, the techniques can wait until the other more urgent stuff is done.
User avatar
pyramid
Expert Mercenary
Expert Mercenary
 
Posts: 960
Topics: 44
Joined: Wed Jun 14, 2006 6:02 pm
Location: Somewhere in the vastness of space

Postby pyramid » Mon May 12, 2008 1:16 pm

chuck_starchaser wrote:One planet <=> one ring plane. Basta!

He, he. This is just the planet.testmission. Admittedly, it was copied from some system file and I really haven't given it a big thought (besides the ring texture). Now that you say it, it makes absolute sense.

There are many issues with systems and they will need to be reviewed completely before turning-off system autogeneration. Adjustment of lighting conditions for the new shaders, atmosphere fog change, the rings, correct xml formatting, ...
User avatar
pyramid
Expert Mercenary
Expert Mercenary
 
Posts: 960
Topics: 44
Joined: Wed Jun 14, 2006 6:02 pm
Location: Somewhere in the vastness of space

Postby klauss » Mon May 12, 2008 1:34 pm

I've been thinking about XML formatting. We need DTDs, those would help document what XMLs have, and would help us verify their correctness.

Plus, with comments, it can serve as inline documentation as to what each element means.

Techniques will be stored in .xml files along with shaders (in /programs). So I'll start the movement by adding the DTD for techniques :D

BTW: Techniques are part of the roadmap for 0.5.1 - there isn't anything more urgent than that. Techniques and Tangents are slated for 0.5.1, so...
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Postby chuck_starchaser » Mon May 12, 2008 1:42 pm

What are DTD's? Some kind of comments?
User avatar
chuck_starchaser
Elite
Elite
 
Posts: 8014
Topics: 195
Joined: Thu Sep 04, 2003 9:03 pm
Location: Montreal

Postby klauss » Mon May 12, 2008 1:44 pm

Document-Type-Descriptors

They're some kind of document layout specification, machine readable, that XML verifiers can use to verify correctness of a particular kind of XML structure.

Plus you can decorate them with comments, typing out in people-readable form what each element means.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina


Previous

Return to Modding Engine Room

Who is online

Users browsing this forum: No registered users and 1 guest