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

Title: Relief, parallax mapping, all that stuff
Post 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. :)
Title: Re: Relief, parallax mapping, all that stuff
Post by: Nuke on February 06, 2009, 01:16:33 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Reprobator on February 06, 2009, 01:49:03 am
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  ;)
Title: Re: Relief, parallax mapping, all that stuff
Post by: Bobboau on February 06, 2009, 01:58:00 am
actually I believe the earlier pixel shader packs had parallax mapping but it was removed because you couldn't tell
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 06, 2009, 04:10:44 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Reprobator on February 06, 2009, 05:06:04 am
Do you mean that parallax mapping is working already?


edit : the 4th try could be the good one  ;7
Title: Re: Relief, parallax mapping, all that stuff
Post by: Galemp on February 06, 2009, 05:12:51 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: taylor on February 06, 2009, 03:31:20 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 06, 2009, 04:49:09 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Dark RevenantX on February 06, 2009, 05:09:10 pm
Hopefully you can freeze all other work and focus entirely on rewriting the graphics engine to get it over with.
Title: Re: Relief, parallax mapping, all that stuff
Post by: taylor on February 06, 2009, 05:15:08 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 06, 2009, 05:28:00 pm
Which is why i must point out that most of my experience is in D3D, not openGL.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Dark RevenantX on February 06, 2009, 05:34:13 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Flipside on February 06, 2009, 07:24:53 pm
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).
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 06, 2009, 07:33:41 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: redsniper on February 06, 2009, 11:02:34 pm
and then, Ferrium.
Title: Re: Relief, parallax mapping, all that stuff
Post by: chief1983 on February 08, 2009, 01:40:46 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 08, 2009, 01:49:01 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Reprobator on February 08, 2009, 05:58:52 pm
a good stuff would be anti aliasing fsaa and such, but i don't know how hard it is to code.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Herra Tohtori on February 08, 2009, 06:07:03 pm
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...
Title: Re: Relief, parallax mapping, all that stuff
Post by: Reprobator on February 09, 2009, 01:45:38 am
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.

Title: Re: Relief, parallax mapping, all that stuff
Post by: Kaine on February 09, 2009, 02:09:54 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 09, 2009, 05:11:26 am
AA shouldn't technically affect textures. Anisotropic filtering is used for textures.
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 09, 2009, 01:11:29 pm
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

Title: Re: Relief, parallax mapping, all that stuff
Post by: Reprobator on February 10, 2009, 02:20:43 am
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:
Title: Re: Relief, parallax mapping, all that stuff
Post by: Nuke on February 10, 2009, 03:43:06 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Aardwolf on February 10, 2009, 10:55:59 am
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);
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 10, 2009, 05:22:11 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: chief1983 on February 10, 2009, 05:44:24 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: taylor on February 10, 2009, 06:02:07 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Galemp on February 10, 2009, 08:06:50 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 10, 2009, 08:15:23 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Nemesis6 on February 10, 2009, 10:15:42 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 11, 2009, 01:21:15 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 11, 2009, 04:13:36 pm
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! ;)

Title: Re: Relief, parallax mapping, all that stuff
Post by: Bobboau on February 18, 2009, 11:54:37 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 20, 2009, 03:00:01 pm
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. 
Title: Re: Relief, parallax mapping, all that stuff
Post by: Nuke on February 21, 2009, 05:13:16 am
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.

Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 21, 2009, 05:31:58 am
@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...

Quote
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
Title: Re: Relief, parallax mapping, all that stuff
Post by: Bobboau on February 21, 2009, 04:48:26 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 21, 2009, 05:44:31 pm
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
Title: Re: Relief, parallax mapping, all that stuff
Post by: Dark RevenantX on February 21, 2009, 07:26:04 pm
Well, something has to be done someday.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Flipside on February 22, 2009, 02:40:40 pm
If someone has the patience to sit down and unthread that ball of wool, then it will get done, otherwise, it won't :p
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 22, 2009, 03:39:49 pm
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?

Title: Re: Relief, parallax mapping, all that stuff
Post by: Flipside on February 22, 2009, 04:47:30 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 22, 2009, 05:14:28 pm
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...

Title: Re: Relief, parallax mapping, all that stuff
Post by: Nemesis6 on February 23, 2009, 10:52:37 am
We'd *just* have to get post processing working...

Working or implemented?  :)
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 24, 2009, 05:45:30 pm
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.

Quote
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Scooby_Doo on February 24, 2009, 06:05:55 pm
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?
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 24, 2009, 07:56:03 pm
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: Scooby_Doo on February 24, 2009, 10:13:31 pm
Ah ok got it... Woooo it's really wonky.  In the current state it doesn't seem that useable, the textures actually moves around.
Title: Re: Relief, parallax mapping, all that stuff
Post by: blackhole on February 25, 2009, 04:25:56 am
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...
Title: Re: Relief, parallax mapping, all that stuff
Post by: Herra Tohtori on February 25, 2009, 07:58:46 am
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.
Title: Re: Relief, parallax mapping, all that stuff
Post by: DaBrain on February 25, 2009, 04:34:06 pm
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. ;)