[Reprobator]

i don't know much the way it should works , but does antialias apply to texture too?
because when i set it driver level it looks it apply only on geometry's edges.

[Kaine]

i don't know much the way it should works , but does antialias apply to texture too?
because when i set it driver level it looks it apply only on geometry's edges.

It's intended to smooth geometry edges but because of the way it works, some mild effects will be seen on textures. The lower quality/more pixelated the texture is, the more AA will affect it. See Quake2 with and without AA for an example. Particularly in software rendering mode.

[blackhole]

AA shouldn't technically affect textures. Anisotropic filtering is used for textures.

[DaBrain]

Well, at least SSAA has quite a nice impact on the textures.


SSAA is also very slow and needs a lot of memory.

I usually use it for FS2 though, cause I still get a constantly good frame rate.
32XAA (2x2 SS + 8x MS)+TSSAA

[Reprobator]

I didn't saw SSAA in my caltalyst 3d section maybe it's only available on froceware?


Another things , i don't know if it would be ever possible would be to intergrate a stereoscopic fliter, to let the the players play with old 80's blue/red glasses 

[Nuke]

all youd need to do is pixel multiply the screen by red in frame 1 and blue in frame 2, up the gamma, and change the camera offset to match.

[Aardwolf]

I tried to figure out how to do that, once, but ... failed.

Not because it's a hard task, but because I had no idea where to put the code.

And you don't need to multiply or anything, just use glColorMask(bool r, bool g, bool b, bool a);

[DaBrain]

Before we do some of the complex stuff like shadows and relief mapping, there are some basic features I'd like to see first.

I.e. Vertex colors. They won't require shaders (backward compability), don't need new maps and look quite nice if your model has enough polygons. Baking radiosity, or simply recoloring a part of a ship is no problem with vertex colors.

Sorry for the crappy example, but it should be enough to get the idea:





Collada (DAE) supports vertex colors, so there shouldn't be a problem getting them into the game.
I think it's a pretty good example of how simple stuff can be used for really nice effects.

[chief1983]

Just for clarification, it wouldn't require shaders, but to be supported when shaders are enabled would require a shader to be written for it, so the effect would then need to be written twice, wouldn't it?  One for the fixed-rendering pipeline and one for the shader-driven one.  I could be wrong though.

[taylor]

This would be simple vertex coloring, like what is used with retail lights and various other things.  You would just load the lighting data into the VBO with the rest of the vertex info, then it would be referenced with gl_Color in the vertex shader and easily passed on to the fragment shader.  Even in cases where the vertex color info doesn't exist it will simply use the default color, which is white in our case.  It would basically just require a one line addition to the existing vertex shaders to get the desired affect and the changes would be fully backwards compatible too.

[Galemp]

I'm gonna pop in here and say I've been tooling around with the shaders in Quake III Arena this weekend, where every texture has a .shader text file that specifies that texture's bitmaps, blending, lighting, and effects like environment mapping, translation and tiling.

Is that what we're talking about here? 'Cause if so... holy crap awesome.

[blackhole]

Before we do some of the complex stuff like shadows and relief mapping, there are some basic features I'd like to see first.

I.e. Vertex colors. They won't require shaders (backward compability), don't need new maps and look quite nice if your model has enough polygons. Baking radiosity, or simply recoloring a part of a ship is no problem with vertex colors.

Sorry for the crappy example, but it should be enough to get the idea:

Am I confused or is that screenspace ambient occlusion? Because I'm pretty sure that baking radiosity using vertex shaders would either look really bad or not work at all unless you had an excessive number of polygons even on flat surfaces, which is just a waste of rendering resources IMO.

it should be screenspace ambient occlusion, really, but we have no postprocessing support.

I'm gonna pop in here and say I've been tooling around with the shaders in Quake III Arena this weekend, where every texture has a .shader text file that specifies that texture's bitmaps, blending, lighting, and effects like environment mapping, translation and tiling.

Is that what we're talking about here? 'Cause if so... holy crap awesome.

No I think that's the texture system thats never going to be implemented As far as I know we're currently talking about supporting vertex colors.

[Nemesis6]

a good stuff would be anti aliasing fsaa and such, but i don't know how hard it is to code.

Well, driver level anti-aliasing is available but it seems that anti-aliasing is somehow responsible for the infamous thruster flickers, at least on my rig...

I thought I was the only one with that problem!

Anyway, come to think about it, parallax maps could f right off in favor of self-shadowing on capital ships. Either that, or light-shafts. Got that idea when watching this video from the BTRL team: http://www.youtube.com/watch?v=6zG2fTeFk30
Some scenes in Freespace just beg for that effect.

[DaBrain]

Am I confused or is that screenspace ambient occlusion? Because I'm pretty sure that baking radiosity using vertex shaders would either look really bad or not work at all unless you had an excessive number of polygons even on flat surfaces, which is just a waste of rendering resources IMO.

it should be screenspace ambient occlusion, really, but we have no postprocessing support.

It is just radiosity, but yes, those cubes have a few hundred polygons. The models do require a constant polyflow (well... in you need shadows everywhere.
So it wouldn't work as well for ships, but all it needs is a little bit of tweaking by hand. You can edit the radiosity vertex colors. So you can simply recolor ugly spots back to white. It works very well for occluded areas and anything that should be just dark.

For a ship like the Deimos, I guess it would take 15-20 minutes to fix up all the badly shaded areas by hand.
I am convinced it would improve the graphics a lot, pretty much without any cost. (Just bigger model files.) Even without adding more polygons.

[DaBrain]

I'm gonna pop in here and say I've been tooling around with the shaders in Quake III Arena this weekend, where every texture has a .shader text file that specifies that texture's bitmaps, blending, lighting, and effects like environment mapping, translation and tiling.

Is that what we're talking about here? 'Cause if so... holy crap awesome.

That would be (kinda) part of the material system. Although you probably wouldn't be able to set up animated translation in there, but would pick a shader that animates your UVs.



@blackhole

Even though I really have absolutely no time right now, I made an example, using the Deimos. Probably not perfect, but good enough to make a difference.

On the left, is the light traced version, using a map. That's pretty much the best you can get.
I the middle is the slightly tweaked vertex color version. No additional polygons. Close enough, if you ask me.
On the right is the standard version without any "ao" shadows.



Rather than just using radiosity, I rendered a lightmap and converted that to vertex colors on the mesh. I get slightly more artifacts, but thanks to the smoothing tool in the vertex painter, that's no big deal.


Any coder who adds support for this to the POF format and the engine, will be my personal hero for at least a month!

[Bobboau]

this would require you to be able to specify the geometry format on the fly within the POF. this was one of the things the material system was supposed to support (also upgrades to the pof file format), but you know how that's gone so far.

the thing I think the engine needs more than any other feature is multi-textureing, and I mean with multiple UV coordinates, that would be the awesomest thing ever.

[DaBrain]

I agree. We need mutliple UV channels for many many things.

It would take a bit artist work, actually not even very much, but the possible visual improvements would be more than stunning. 

[Nuke]

thirded. you know how much of a pain in the ass it is not to overlap anything on your diffuse texture. and you loose lots of pixel resolution. you could easily bake the texture coords out so every polygon has its own uv space and stick that in another mapping channel. then generate normal maps to that channel. which would allow you to overlap lots of stuff on your main channel. a ship with biaxial symmetry pretty much requires twice as many pixels now that we got to worry about normal mapping, and a lot of old ships cant be normal mapped for the same reason.

as for the pof format, its in dire need of lots of things, collision models, materials, better loding, multiple uv channels, the list goes on and on. be kinda cool if we had an ascii pof format, then changes can be added as quickly as they can for tables. another idea is to keep the pof format for geometry only then use an table like file for all the other less complicated chunks like firepoints and such. all geometry can be dumped n lod0 and use named references in the file to describe how the lod heirarchy is stacked based on submodel names. also the possibility of using multiple model files for one ship, modular turrets for example. i think pof needs a major overhaul.

[blackhole]

@blackhole

Even though I really have absolutely no time right now, I made an example, using the Deimos. Probably not perfect, but good enough to make a difference.

On the left, is the light traced version, using a map. That's pretty much the best you can get.
I the middle is the slightly tweaked vertex color version. No additional polygons. Close enough, if you ask me.
On the right is the standard version without any "ao" shadows.



Rather than just using radiosity, I rendered a lightmap and converted that to vertex colors on the mesh. I get slightly more artifacts, but thanks to the smoothing tool in the vertex painter, that's no big deal.


Any coder who adds support for this to the POF format and the engine, will be my personal hero for at least a month!

Ok, I must admit that *any* AO is probably better then nothing, but wouldn't it be a lot more sensible to put this feature on hold until postprocessing comes along, and then you can do supercrazyaccurate screenspace AO and not have to bother about changing the model format and coding the shader 'n stuff?

However, problem: Polygon increases are huge suckers of performance. It doesn't matter if the polygons are the same flat surface, they get rendered all the same, so increasing polycount would definitely be a noticeable performance hit. If you are really that obsessive about it, then I'd say do it if you can get away without a polycount increase, otherwise don't bother.

On a totally unrelated note, the DirectX11 tessellation feature would be so unbelievably perfect for this...

the thing I think the engine needs more than any other feature is multi-textureing, and I mean with multiple UV coordinates, that would be the awesomest thing ever.

By multiple UV coordinates do you mean adding support for multiple textures to be rendered on to a polygon using unique UV coordinates for each texture? If so, I would ask WHY THE HECK ISN'T THIS ALREADY IMPLEMENTED but hey, this is FSO, anything is possible!

I suspect the reason this isn't implemented is due to the unbelievably horrible graphics code again. Therefore, from this thread, we can conclude one thing:

The graphics code needs a complete overhaul if you guys are going to do anything, except maybe some minor improvements here and there. And I'm not volunteering

[Bobboau]

we haven't done it yet because it requires changeing the model format any and all converters, and the model loading code. basicly it requires rewriteing everything while maintaining backwards compatibility.