Page 4 of 4

PostPosted: Sun May 11, 2008 7:24 pm
by chuck_starchaser
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.

PostPosted: Sun May 11, 2008 9:34 pm
by klauss
Techniques won't take that long to implement.
I think I can get them working during the week.

PostPosted: Mon May 12, 2008 7:46 am
by pyramid
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.

PostPosted: Mon May 12, 2008 8:58 am
by klauss
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.

PostPosted: Mon May 12, 2008 12:55 pm
by chuck_starchaser
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!

PostPosted: Mon May 12, 2008 1:02 pm
by pyramid
Great. Though *I* can't wait, the techniques can wait until the other more urgent stuff is done.

PostPosted: Mon May 12, 2008 1:16 pm
by pyramid
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, ...

PostPosted: Mon May 12, 2008 1:34 pm
by klauss
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...

PostPosted: Mon May 12, 2008 1:42 pm
by chuck_starchaser
What are DTD's? Some kind of comments?

PostPosted: Mon May 12, 2008 1:44 pm
by klauss
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.