[blackhole]

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?

[Dark RevenantX]

Well, something has to be done someday.

[Flipside]

If someone has the patience to sit down and unthread that ball of wool, then it will get done, otherwise, it won't

[DaBrain]

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"

If someone has the patience to sit down and unthread that ball of wool, then it will get done, otherwise, it won't

How many coders in the SCP team would actually be capable of doing this?

[Flipside]

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.

[DaBrain]

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...

[Nemesis6]

We'd *just* have to get post processing working...

Working or implemented? 

[blackhole]

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.

[Scooby_Doo]

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?

[blackhole]

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.

[Scooby_Doo]

Ah ok got it... Woooo it's really wonky.  In the current state it doesn't seem that useable, the textures actually moves around.

[blackhole]

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...

[Herra Tohtori]

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:



The normal map generated from this will look something like this (depending on the filter used, this uses 3x3 filter):




So profile-wise, the original height map in this case looks something like this:



...while the normal map's profile looks more like this:




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:



so I'm sure you can see what that would do to things like tiling and general accuracy of the parallax map.  nvDXT interestingly has -toHeight flag in the instructions, but using it jsut tells that it's an unknown option, so go figure.

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.

[DaBrain]

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.