Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nemesis6 on February 05, 2009, 10:16:46 pm
-
Is there any possibility of future support or just a tech demo build of some sort showcasing something like relief or parallax mapping? Would help a lot on capital ships. Normal mapping works, so I guess it shouldn't be that hard...? No idea about shaders or shading, I just know of a couple of them, so don't beam me out of the sky if there's some huge obstacle I don't know about. Just curious. :)
-
what the engine needs is shadows and better lighting. then more advanced mappings would be cool. other than that i dont think youd notice them in the 0.3 seconds you have between ligning up for the kill, and getting sliced in two by a bfred.
-
shadows and improved lightening would be awesome,
just imagining a flight inside a dense asteroid field with a star behind that cast shadows ... O-°
We could make some use of new types of turret too , like a sort of lighthouse turret who scope around it's parent's ship...
Shadow and lightning would add a lot to the ambiance of the game ;)
-
actually I believe the earlier pixel shader packs had parallax mapping but it was removed because you couldn't tell
-
I coded in parallax mapping, which is similar to relief mapping. Relief mapping is just a more elegant and prettier way of doing the same thing - and its far more difficult to implement in an engine like FS2.
The issue is simply that the capital ships aren't using parallax mapping.
ALL MY CODE HAS GONE TO WASTE! :(
Shadows do need to be added but are currently impossible due to the fact that the innards of FS2's rendering code are like trying to figure out the internal organs of a cthulhu. I've tried on 3 seperate occasions to re-order and/or adjust the FS2 rendering code to try and get it to render everything in one go, but it usually only resulted in me saying "What the F*CK?!" repeatedly at my monitor.
-
Do you mean that parallax mapping is working already?
edit : the 4th try could be the good one ;7
-
You know I make height maps for all my normal maps, but when they're actually used they introduce nasty artifacts that more than make up for any benefit the parallax mapping would have afforded.
Maybe there's some kind of trick to it, I dunno.
-
Do you mean that parallax mapping is working already?
Parallax mapping was working day one actually. It has always been there, so long as the model has both height and normal maps provided. The shaders in the MediaVPs have tweaked values for parallax mapping from what I originally had however, which I feel introduces more strange artifacts to the maps.
But the issue with more advanced mapping/shader features is simply that the rendering code has never really be updated properly. It's old, slow and just plain inefficient. I cut out numerous features from the shader code just because the game grinds to a halt with them enabled since the rendering code isn't optimized at all. The other problem is that since we don't have a material system in place all of the shaders are forced to be completely generic, which greatly limits what can be done with them.
-
But the issue with more advanced mapping/shader features is simply that the rendering code has never really be updated properly. It's old, slow and just plain inefficient. I cut out numerous features from the shader code just because the game grinds to a halt with them enabled since the rendering code isn't optimized at all. The other problem is that since we don't have a material system in place all of the shaders are forced to be completely generic, which greatly limits what can be done with them.
The other problem is that the code is freakishly difficult to understand.
-
Hopefully you can freeze all other work and focus entirely on rewriting the graphics engine to get it over with.
-
The other problem is that the code is freakishly difficult to understand.
Largely because so much has just been tacked on over the years. It was originally set up to be used with a software renderer with 3Dfx stuff on top of that, then D3D/OGL was put on top of that, and then you've got the HTL conversion which is mostly just a series of hacks on top of all that other crap. Add to that the fact that there is multiple ways to render any one thing and it doesn't take long to get really complicated. Most of the code optimizations are still just what was used for the software renderer, with everything else mostly just being brute-force rendering. It's some pretty crazy stuff. :sigh:
Hopefully you can freeze all other work and focus entirely on rewriting the graphics engine to get it over with.
Assuming that somebody with the know-how actually volunteers to do it that is, since there isn't currently an active coder on the team with the ability to handle the needed rewrites. But, now that keeping D3D working isn't a barrier I suspect that it will be somewhat easier for someone to do now.
-
Which is why i must point out that most of my experience is in D3D, not openGL.
-
Yeah, it would probably be better at this point to start most of it over... It's too bad I have little coding experience and nobody here seems to be an OpenGL expert.
-
Oh there's plenty of OpenGL experts, it's just that rebuilding the entire rendering engine from the top would be an absolute nightmare, since, from what I understand, it's not entirely encapsulated, so altering the code would mean tracking down every single link with external code and somehow fixing that, or risk simply creating the same problems all over again.
It would basically require another re-write of the almost the entire game (as I say, as I understand it).
-
from what I understand, it's not entirely encapsulated, so altering the code would mean tracking down every single link with external code and somehow fixing that, or risk simply creating the same problems all over again.
It would basically require another re-write of the almost the entire game (as I say, as I understand it).
Its more like its not escapulated at ALL, and would require rewriting 80% of the game's code. You're better off coding your own space sim engine.
-
and then, Ferrium.
-
Is it just me or is "Ferrium" becoming synonymous with the "THIRD BASE!" line from "Who's on first"? We seem to be getting to that a lot lately.
-
Still, I don't think FSO performs that bad at all.
With the shader support it looks quite ok and any medicore pc can run FSO with everything maxed out/enabled and still gets solid 60 fps all the time.
Even with some of the more complex models and bigger textures in SoL, it's hard to notice slow-downs. And my PC was build in 2006, so it's not high-end at all.
I think there is still room for more features, even if they run horribly inefficient.
A semi-decent material system would be enough to keep the FSO graphics on a good level for quite a while and would also allow some heavy content optimizations. Mainly by reducing the memory usage for a lot of EFF/ANI maps.
-
a good stuff would be anti aliasing fsaa and such, but i don't know how hard it is to code.
-
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 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.
-
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.
-
AA shouldn't technically affect textures. Anisotropic filtering is used for textures.
-
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
-
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 :pimp:
-
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.
-
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);
-
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:
(http://i43.tinypic.com/2i16kz.jpg)
(http://i44.tinypic.com/2iawwtt.jpg)
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.
-
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.
-
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.
-
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.
-
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:
(http://i43.tinypic.com/2i16kz.jpg)
(http://i44.tinypic.com/2iawwtt.jpg)
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 :P As far as I know we're currently talking about supporting vertex colors.
-
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! :p
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.
-
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.
-
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.
(http://i41.tinypic.com/mk7l3a.jpg)
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! ;)
-
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.
-
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.
-
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
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.
(http://i41.tinypic.com/mk7l3a.jpg)
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 :p
-
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.
-
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.
So, same old, same old? :P
-
Well, something has to be done someday.
-
If someone has the patience to sit down and unthread that ball of wool, then it will get done, otherwise, it won't :p
-
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?
It doesn't look like anything is going to happen any time soon. So any improvement we can get now, will help the visuals for months.. maybe years, before somebody reworks the graphic engine.
More importantly: Vertex colors can do many things. The more polygons you have, the better they look. Even Crysis uses them for a lot of stuff. They don't have to be used only for baking radiosity. And the memory use is almost a joke.
Even with SSAO, it would still be a very nice feature to have. And if it's actually not that hard to put it in, I'd still say we should go for it.
And SSAO is in my eyes still a fake. It's an impressive feature, but it's very smooth... so it might work better for organic stuff.
And I also often see weird white or black areas around objects on the foreground, even though there is nothing directly behind them.
I'll call them "ghost shadows"
(http://www.radioactive-software.com/urbanempires/October11/Crysis_SSAO.jpg)
(http://boris-vorontsov.narod.ru/screenshots/mafia10.jpg)
If someone has the patience to sit down and unthread that ball of wool, then it will get done, otherwise, it won't :p
How many coders in the SCP team would actually be capable of doing this?
-
Of the active ones, I'd guess at Taylor or Blackhole, but I'm not too up on the respective skills/activity status of most of the members.
Thing is, there's already the sub-format that is created for models, I suppose you could create a new format and convince SCP to use either/or system, but that makes reconverting over the older Pof models into a real PITA things like the MediaVP would, if they wanted to use the newer format, have to convert over all the old ones to get the effects. The old ones would still work, and look good in the engine, but you'd have to reconvert all the models, though, come to think of, whether the format is pof or not, I suspect reconversion would be required for this effect to work on a ship anyway.
-
Reconversion to get new effects/shaders wouldn't be a problem.
I think there are more than enough artists here that would pick up that task with pleasure. ;)
But blackhole's SSAO solution would work without any changed on the models.
We'd *just* have to get post processing working...
-
We'd *just* have to get post processing working...
Working or implemented? :)
-
And I also often see weird white or black areas around objects on the foreground, even though there is nothing directly behind them.
That's because they're doing it wrong, IMO. I've noticed it and intend to fix it while coding my own implementation. That doesn't really matter though, since FSO isn't going to support postprocessing any time soon.
It doesn't look like anything is going to happen any time soon. So any improvement we can get now, will help the visuals for months.. maybe years, before somebody reworks the graphic engine
...
if it's actually not that hard to put it in, I'd still say we should go for it
This would make sense if implementing vertex colors was easy, but its not. This looks like a feature that is simply not very compatible with the FSO engine, period. I can code the vertex shading code, but you have to understand that the real problem here isn't the feature itself; its getting the stupid FSO engine to load up, store, and process the information to get the feature to work, and that involves model formats and code that I have absolutely no familiarity with.
That, and I'm not an active coder; I'm busy with my own things.
-
Ok let me see if I understand this right...
Parallax mapping is supported?
Parallax is basically normal + bump right? (Was is filename-height right?)
Relief mappihg is a version of parallax mapping with no modder intervention necessary?
-
Relief mappihg is a version of parallax mapping with no modder intervention necessary?
Parallax mapping is supported, its a normal + height map.
Relief mapping is a completely different way of doing the same thing except it looks better, but its still too graphics-intensive to be even considered for FSO, when FSO doesn't even have shadows yet.
-
Ah ok got it... Woooo it's really wonky. In the current state it doesn't seem that useable, the textures actually moves around.
-
Ah ok got it... Woooo it's really wonky. In the current state it doesn't seem that useable, the textures actually moves around.
That's what parallax mapping does...
-
I think the reason why parallax mapping looks strange and cause weird things is because it's hard, really hard, to actually make it match the perceived elevation changes from the normal map in both location and elevation.
Using the height map from which the normal map was created is a bad idea because the normal map cannot be used to add rectangular surface geometry changes, it's all angled... so basically you can get a gradual change in elevation when you look at the normal map, but an immediate change when you look at the parallax effect from the height map. Additionally, the amount of parallax shift is difficult to match exactly to the elevation change that is perceived by the width and the angle of the changes on the normalmap.
or in images, if the original height map has sharp transitions like this:
(http://i43.tinypic.com/2q87r5y.gif)
The normal map generated from this will look something like this (depending on the filter used, this uses 3x3 filter):
(http://i43.tinypic.com/m3slg.gif)
So profile-wise, the original height map in this case looks something like this:
(http://i40.tinypic.com/14d36ti.gif)
...while the normal map's profile looks more like this:
(http://i41.tinypic.com/r8to1s.gif)
Ideally, the parallax map would need to be re-created from the normal map in order to avoid the profile changes, and I don't really have any tools that can do that properly; GIMP's normal map plugin does have a convert to height option, but it doesn't work very well and adds a silly gradient to the images like this:
(http://i39.tinypic.com/raam82.png)
so I'm sure you can see what that would do to things like tiling and general accuracy of the parallax map. :ick: nvDXT interestingly has -toHeight flag in the instructions, but using it jsut tells that it's an unknown option, so go figure. :sigh:
Anyway, even if I could convert the normalmap back to an accurate heightmap profile-wise, that doesn't really answer to the problem of scaling the normal map and parallax map to match each other's elevation (or perceived elevation), which can cause weird things when some areas' parallax seems to be more, or less, than what the normalmaps apparent elevation difference would suggest. That's likely the reason why normal maps tend to work better alone than with the parallax maps, at least on ships. I don't really know how it would be possible to truly match the two different maps into one seamless effect.
-
Working or implemented? :)
That's because they're doing it wrong, IMO. I've noticed it and intend to fix it while coding my own implementation. That doesn't really matter though, since FSO isn't going to support postprocessing any time soon.
This would make sense if implementing vertex colors was easy, but its not. This looks like a feature that is simply not very compatible with the FSO engine, period. I can code the vertex shading code, but you have to understand that the real problem here isn't the feature itself; its getting the stupid FSO engine to load up, store, and process the information to get the feature to work, and that involves model formats and code that I have absolutely no familiarity with.
That, and I'm not an active coder; I'm busy with my own things.
Yes, and I appreciate that you put as much time into the shader enhancements as you did, and even listend to all the crazy SoL requests without freaking out. ;)
Anyway, as far as I understood, the engine already used vertex colors for the light sources. So the main problem appears to be storing the data in the model and loading it somehow, hopefully without yet another extra files besides the POF.
It's a very basic feature, but it can be very very useful for a lot of things. Maybe even for shaders... or ... dunno, mabe even as particle emitter, or some other crazy stuff.
Working or implemented? :)
I honestly have no idea. I don't know if anybody is still working on it.
Ok let me see if I understand this right...
Parallax mapping is supported?
Parallax is basically normal + bump right? (Was is filename-height right?)
Relief mappihg is a version of parallax mapping with no modder intervention necessary?
Yes, parallax mapping is supported.
No, you can't use your bumpmap as "-height" map. As you've noticed, it moves texture, or probably (I think) the UVs.
So hard cuts/contrasts will look horrible. You need a rather smooth map in order for the effect to work.
Crazybump does a pretty good job, at least for organic textures.
And it doesn't really work for technical/hard sturface textures... at least not for many.
Afaik Relief Mapping requires eactly the same from the artist as parallax mapping (or it *can*/*might*). For the coder it's a different story. ;)