The Graphics Thread

[chuck_starchaser]

Just a place to discuss all graphics related stuff.

Here's a link I don't want to lose, (wikipedia) pixel shader versions table.

I'm organizing a bunch of folders for techniques and shaders according to level of sophistication; kind of following
the pixel shader versions; not quite. I will commit it soon.

In other news, I was suggesting to Klauss we get rid of star textures. Why? Because they suck, first of all.
Secondly, stars are bright enough to saturate (and destroy) your retina's receptors, not to speak of trying
to represent so much brightness with a cheap monitor made by slave labor in the butt end of the world.
So, there should be no deviation from white in any pixel within a star's radius. Never mind sun-spots; have
you ever seen them with your naked eye? It's NOT impossible, here on Earth, under the protection of the
atmosphere; but don't try to look for them in space.
Thirdly, there's a management problem: If the star color is specified as red, but the texture is greenish,
there's nothing in the engine that will object and throw an exception; wish there was; we just end up with
an inconsistency.
Fourthly, we end up with stars looking brighter when reflected on surfaces than when looked at directly.

On reflection:


Direct view:


Fifthly, star textures suck.
Wouldn't it be cool if they looked like they do on reflections?


(For those not in the know, reflecting the texture is totally out of the question; the reason the star's
reflection looks nice and round is months of writing and working out math to figure how to hack the
phong shading formula to do it. Trust me.)

[charlieg]

I agree that the current textures suck, but what would also suck [from a gameplay perspective] is being blinded every time a star comes into view. Surely at this point in time there'd be a technological solution [such as limiting the strength of the incoming light through the cockpit glass].

[chuck_starchaser]

Yeah, we're going to have a "windshield" shader. A special shader to simulate lense flare effects and other stuff
on the cockpit glass. Could add automatic anti-glare, I guess. That's not easy though; the control has to be done
in the cpu, because the shaders cannot read the color on the background as they paint the screen over; they can
only blindly apply alpha as per an input passed to them.

[chuck_starchaser]

Klauss, I know too little about the cause of this to write a ticket for it yet, but I have to break out of denial and bring it up:
Cubemaps are not really working; no idea why. They work for backgrounds, but something is terribly wrong with environment
mapping. Take a look:

Probably not specularity, but an ambient light fetch here:


Phong reflections look perfect here:


...but look what happens with textureCubeLod fetches:




Any idea what could be happening?
I did check each cubemap with the LOD slider in CubeMapGen, as I was generating them, and none showed
such thick seam artifacts, --much less differences in tone between faces. Could it be that the DDS data
gets corrupted on its way to the videocard?
I can't imagine how a shader could produce these artifacts if it wanted to.

[klauss]

I've seen a few bugs in uber.fp, mainly related to negative colors slipping away and creating weird errors.

I'll post a patch when I'm done, and I'll keep an eye out for that cubemap stuff.

[chuck_starchaser]

I've seen a few bugs in uber.fp, mainly related to negative colors slipping away and creating weird errors.

I'll post a patch when I'm done, and I'll keep an eye out for that cubemap stuff.

Uber is not being used. Nor are cinemut or high_shader_plus.
The highest techniques/shaders I'm using are fireglass, highend and highend_flat (the latter for the agri base only);
but I tried to find your shader loading logs in both stdout and stderr, and can't find them.
What I did find, and it's kind of surprising, is three cubemap load entries; --and I didn't do any jumping around...
From stderr.txt:
..............
Reading Cubemap backgrounds/black_light.cube
......................
Reading Cubemap backgrounds/somered_light.cube
.....................
Reading Cubemap backgrounds/emerald_light.cube
...................

[klauss]

black is used in the main menu (yep... it needs a background )

One of those must be the one needed by the system you're in. The other one... I don't know

About uber... shock and awe... why is my vegastrike.config bent on using it then?
Ok... there goes some nice bugfixing down the toilet

[chuck_starchaser]

black is used in the main menu (yep... it needs a background )

One of those must be the one needed by the system you're in. The other one... I don't know

Mystery...

About uber... shock and awe... why is my vegastrike.config bent on using it then?
Ok... there goes some nice bugfixing down the toilet

Oh, not at all; the reason I'm not using them is they are buggy as hell, so any help is appreciated.

Changing topics for a bit, since this is a graphics potpourri thread:

I'm still working on the folders for techniques. I'll commit them soon just for peer review and feedback.
But what I've decided to do is move the shaders into the techniques sub-folders, to live together with
their techniques. I think it makes a ton of sense to have technique+vp+fp in one place; and it should
remove the need for some path string concatenations, and duplicating the subfolders system.
I hope this is okay with you.

And I have a new idea:
What about if we split the shaders and techniques yet another level? Namely, I think it would make
a ton of sense to have "stage folders" under techniques:

• 0_background
• 1_planets (and moons, stars, nebulas, rings )
• 2_ships (and stations and asteroids)
• 3_cockpit (and windshield, and dynamic textures on geometry)
• 4_HUD (and eye effects)

Or maybe just three folders, since you were saying there are 3 stages.

Each of these folders would have a system of sub-folders as the one I've been working on.
The motivation is not to get the shaders and techniques for different stages mixed up.
Each stage should have one shader only for all transparencies; thus, in the stars and
planets stage, there should be ONE shader that does atmospheres, nebulas (volumetric
I mean) and stars or star halos. (ONE version of it under each sub-folder, of course.)
In the ships and stations stage, the ONE shader for transparencies is fireglass.
But in the cockpit stage, there will have to be one shader that can do windshield flares
and auto-screening, HUD stuff, and eye effects; and maybe volumetric smoke if you're
taking damage.
But yeah, I really do think the techniques and programs for different stages should not
be all bunched together.

[klauss]

About uber... shock and awe... why is my vegastrike.config bent on using it then?
Ok... there goes some nice bugfixing down the toilet

Oh, not at all; the reason I'm not using them is they are buggy as hell, so any help is appreciated.

Ok, will commit the fixes then.

I'm still working on the folders for techniques. I'll commit them soon just for peer review and feedback.
But what I've decided to do is move the shaders into the techniques sub-folders, to live together with
their techniques. I think it makes a ton of sense to have technique+vp+fp in one place; and it should
remove the need for some path string concatenations, and duplicating the subfolders system.
I hope this is okay with you.

Hm... maybe, if all techniques will have their own version of shaders.
The idea was to be able to reuse shaders in different techniques... but you can use whatever layout feels more comfortable for you, the whole idea is to make things easy to work with.

And I have a new idea:
What about if we split the shaders and techniques yet another level? Namely, I think it would make
a ton of sense to have "stage folders" under techniques:

• 0_background
• 1_planets (and moons, stars, nebulas, rings )
• 2_ships (and stations and asteroids)
• 3_cockpit (and windshield, and dynamic textures on geometry)
• 4_HUD (and eye effects)

Or maybe just three folders, since you were saying there are 3 stages.

Organizing yourself in folders isn't bad, but I'd do that as you add custom techniques to the bfxms... leave the generic default shaders.. generic.

[chuck_starchaser]

I'm still working on the folders for techniques. I'll commit them soon just for peer review and feedback.
But what I've decided to do is move the shaders into the techniques sub-folders, to live together with
their techniques. I think it makes a ton of sense to have technique+vp+fp in one place; and it should
remove the need for some path string concatenations, and duplicating the subfolders system.
I hope this is okay with you.

Hm... maybe, if all techniques will have their own version of shaders.
The idea was to be able to reuse shaders in different techniques... but you can use whatever layout feels more comfortable for you, the whole idea is to make things easy to work with.

This doesn't actually subvert the idea of reusing shaders. What it does (happily) subvert is for techniques in one sophistication level calling shaders in another; they can use any shaders as long as they are in the same folder.

And I have a new idea:
What about if we split the shaders and techniques yet another level? Namely, I think it would make
a ton of sense to have "stage folders" under techniques:

• 0_background
• 1_planets (and moons, stars, nebulas, rings )
• 2_ships (and stations and asteroids)
• 3_cockpit (and windshield, and dynamic textures on geometry)
• 4_HUD (and eye effects)

Or maybe just three folders, since you were saying there are 3 stages.

Organizing yourself in folders isn't bad, but I'd do that as you add custom techniques to the bfxms... leave the generic default shaders.. generic.

Hmmm... You probably mean that some techniques/shaders are used in more than one stage, right?
Yeah, for instance highend_simple and fixed_simple. Hmm...
Well, okay, how about this?:
Under techniques, have folders..

0_fixed_gl
1_ps1.2
2_ps1.4
3_ps2.0
4_ps2.0b
5_ps3.0
6_ps4.0
7_ps4.1
8_ps5.0
STAGE_FAR
STAGE_MEDIUM
STAGE_NEAR

With the last three having a system of folders 0 through 8 again, each.
The "default" shaders (used in more than one stage) can be in the 0-8 folders under techniques.
The stage-specific shaders can be in subfolders 0-8 of their specific stage folder.

[klauss]

I like the idea that different sophistication levels shouldn't mix.
We'll have to copy a few shaders, but keeps things safe (ie: from having a noncompliant shader bit slipping into the wrong sophistication level).

[klauss]

I committed the uber shader & technique. It's probably not your uber shader and technique, so you'll have a lot of diffing to do.

I thought you had committed the uber techniques, but apparently not

[chuck_starchaser]

I like the idea that different sophistication levels shouldn't mix.
We'll have to copy a few shaders, but keeps things safe (ie: from having a noncompliant shader bit slipping into the wrong sophistication level).

Glad you like it.

I committed the uber shader & technique. It's probably not your uber shader and technique, so you'll have a lot of diffing to do.

I thought you had committed the uber techniques, but apparently not

I don't get it, but I'll have a look. Ehm, yeah; it's quite possible I may have uncommitted stuff around in techniques and programs.

Wrote ticket #14, about the textureCubeLod artifacts; and added some thoughts.
http://vegastrike.wcjunction.com/trac/t ... angeset=on

[klauss]

Actually, I've been looking into that matter.

It seems to be the edge fixup thing. I'm not sure what ATI does to hide the artifacts, if you can research the matter it would be much appreciated, but the cubemaps are simply broken with that edge fixup thing. It's really a dumb thing to do.

They average the texels across the entire face and set the edge texels to that value - nonsense - so, in environments where one face has different energy than another, the opposite sides look totally wrong.

Say, I have a face with high energy and on the opposing side a face with nil energy. Say +Z and -Z. Then, the face connecting both (+X) will have one side with high energy (+X+Z) and one with low energy (+X-Z) - the average is wrong for both ends. So the end with high energy will have a sharp edge with lower energy, and the end with low energy will have a sharp edge with high energy. Dumb as hell.

You'll see the effect better if you change the LOD from 8.0 to 7.0 or 6.0 in ambientmapped_simple.fp.

I think the edge fixup problem has to be worked out somehow... at the very least by not adding the edge (disable edge fixup and just accept the imperfect interpolation between faces). The edge fixup hack is a solution that is worse than the problem IMNSHO.

[chuck_starchaser]

Okay, in that case, I think it's time to hack CMG. I'll have a first quick look at the sources.

[chuck_starchaser]

I thought I had sources; it was only headers...

http://forums.amd.com/forum/messageview ... did=127401

[klauss]

Hey, just porting the fixes in uber to highend, and I wanted to ask something: did you set shininess from alpha for a reason? (ie: to force artists to produce shininess maps?)

Because everything looks weird with shininess from alpha when no specmap has such a channel, and everything looks 10 times better (with a few quirks) if set to ad-hoc shininess from specmap.

I'd like to commit that change, if it's ok.

[chuck_starchaser]

Hey, just porting the fixes in uber to highend, and I wanted to ask something: did you set shininess from alpha for a reason? (ie: to force artists to produce shininess maps?)

That is EXACTLY what I did; and why I did it.
The other solution I considered was to implement the hacks I implemented in PU's shaders; namely, I made the
shaders look at those colors in xmesh, their alpha: When the alpha for specular is zero, the shader knows that
there's shininess in alpha. When the shader sees alpha = 0 in emissive color in xmesh, it knows there's AO in the
alpha channel of the glowmap. Etceteras.
And you might ask, why do this, when we put in techniques precisely so that we can specify a technique in
xmesh? Well, because, in the end, it would cause an absurd proliferation of techniques and shaders.
So, I figured, might as well make the models look like shit, and FORCE the lazy bum artists to put shininess
and ambient occlusion.

Because everything looks weird with shininess from alpha when no specmap has such a channel, and everything looks 10 times better (with a few quirks) if set to ad-hoc shininess from specmap.

I know; but if we do that we will never get the art fixed.

I'd like to commit that change, if it's ok.

Please don't!

[chuck_starchaser]

Preliminary shader and technique reorganization folders and files committed.
r12673

OT:
The wcjunction server is currently down; my room-mate is trying to upgrade the distro on it.
/OT

[pheonixstorm]

Ok, thanks for the heads up. I was wondering what happened.

[chuck_starchaser]

New: Ticket #15, about color specifications in techniques.

[klauss]

Ok then... I'll commit the fixes but leave shininess in alpha.

[chuck_starchaser]

Thanks!

[charlieg]

You guys were discussing bugs in cubemaps / ati... this may or may not be relevant.

Bloodfrontier commit titled "ati_cubemap_bug workaround":
http://cia.vc/stats/project/bloodfronti ... age/711015

[chuck_starchaser]

Interesting. No text explanations, though. In any case, this seems to pertain to some gpu bug, in
perhaps some gpu models.
The bug we're talking about is in an off-line tool offered by ATI, free as in beer but not FOSS,
unfortunately; or not yet. Maybe you could persuade them to foss it. I tried, but got no reply.
http://forums.amd.com/forum/messageview ... did=127401
In fact, I was just thinking about perhaps writing our own CubeMapGen, because this needs to
be fixed like yesterday.
Whaddya say, Klauss; are you game? I could start writing the classe interfaces and stuff.
Shouldn't be too difficult.
I fear more the dds file writing and user interface than the algorithm.