Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Kobrar44 on September 15, 2013, 10:09:31 am
-
As some of you probably noticed, I had some luck implementing parallax mapping into FSO shaders. Here are the effects:
Parallax mapping
DL SHADERS (http://www.mediafire.com/download/2nd0q56dtvdpjfc/effectsP.rar)
DL MOD (http://www.mediafire.com/download/25mktp3rbcuv0an/Parallax.rar)
Parallax occlusion mapping
DL SHADERS (http://www.mediafire.com/download/0d55agdgaiaaqvy/effectsPRT.rar)
DL MOD (http://www.mediafire.com/download/8yysk748y2i8ie2/ParallaxRayT.rar)
Mod packages contain fixed Karnak heights[which isn't a good example anyway because uv layout].
Both of them require height maps to function[ green channel of -height map ], but they are not compatible[ height map for PM won't work properly with POM].
The reason for that is because PM[in its current implementation] assumes everything of height 0.5 sits exactly where it is, while everything of higher height is higher and everything of lower height is lower [ :D ], while POM assumes 1.0 is the normal height and visually insets everything of lower height. There is no proper conversion between the two. I tried to make POM work a bit like PM, but I think I failed[also no one does that really]. It may be reasonable to sample the HEIGHT_SCALE from other channel in the height map instead of using a single macro for everything.
-
The scary part is, I was having trouble discerning between modeled greebles and the parallax mapping.
-
The scary part is, I was having trouble discerning between modeled greebles and the parallax mapping.
it will certainly impact the balance of model detail vs texture detail again.
---
what kind performance overhead are we looking at?
-
Parallax mapping stuff is actually 3 lines of code plus few more lines for setup. Takes 1 sample and does simple computations. It's almost free. Parallax occlusion is serious business and here we are talking about 15 samples or so. My algorithm of choice would be PM, but there can always be advanced shader pack or something.
-
There are ways we can reduce the hit POM inflicts. We could just limit it's use to LOD0 where subsequent LODs just use parallax mapping or even just normal maps. You could also make a function that produces a dynamic number of samples based off of the dot product between the viewing normal and the surface normal so shallow viewing angles get more samples while steep viewing angles get less.
-
Just playing the devil's advocate here, since I'm really excited about your work, Kobrar:
My understanding is that POM looks better/is more efficient when a surface has highly irregular bumpiness, such as rough bricks, stone walls, pebbled floors, where duplicating the contours would be a huge waste of tris. Its shortcoming lies in the inability to accurately reproduce a sillouette from the height map. (Unless you do wizardry like https://www.youtube.com/watch?v=gcAsJdo7dME)
However, most of the surface details on FS models (but not all) are ship greebles and the lines between hull plates. Both of these feature highly regular details with lots of straight edges, flat surfaces, and perfect cylinders. Wouldn't it look better (and might perform better) if these details were modeled (as is the case with most new ships with greeble panels) or left to the normal map (plate gaps)?
I guess Vasudan ships kind of fall into the category of having highly irregular surface detail, so maybe that's where we'd see most of the benefits? (Also decals with POM are sexy, but that's decals)
-
I updated the Parallax occlusion shaders. I tried to optimize them, but the way shaders work is so bloody weird that I give up. Algorithm isn't slow anyway. I replaced second linear search with binary search which allowed slight quality increase at [almost]no cost, but that's like all about the improvements. Dynamic number of samples produced inacceptable overhead, just like most of optimizations I tried.
Just playing the devil's advocate here, since I'm really excited about your work, Kobrar:
My understanding is that POM looks better/is more efficient when a surface has highly irregular bumpiness, such as rough bricks, stone walls, pebbled floors, where duplicating the contours would be a huge waste of tris. Its shortcoming lies in the inability to accurately reproduce a sillouette from the height map. (Unless you do wizardry like https://www.youtube.com/watch?v=gcAsJdo7dME)
That is no wizardy, believe me. It's cutoff at texture border and that doesn't work on anything else than quad or cube :P
-
Incredible work. Thank you
-
Kobrar44, thanks for your efforts. I plan to use Parallax Occlusion Mapping for my mod, FreeSpace: Reunited and the future version of the MediaVPs.
-
Shaders updated yet again.
Since FSO currently has height maps only because they weren't deleted, I suspect there is room for improving their support. The issue I can see here is that since both pm and pom are useful, there should be way to use both. I was thinking of additional -relief map which would trigger pom. If -relief would be found -height wouldn't need to be loaded. Also, since pom uses arbitrary number of samples, there could be some .tbl with user-specific parameters, similarly to how post_processing.tbl works with godrays[but pom is no post-proc :nervous:]. Any thoughts?
-
Only with someone potentially trying to override a relief map in a VP with a height map in the filesystem, possibly as part of a re-map effort for a ship.
-
i just cant see it. what release are you using to run it?
When height it's eneble, it look like there's no normal map neighter.
when I turn height off, it's show the normal map.
-
Did this ever get vetted enough to push into trunk? If not, do we know what the blockers are? I know the fotg in particular has a number of ships that were made with this and would get an instant upgrade if it's supported.
-
Aren't those just shaders, though? Aside from FSO possibly getting rid of parallax occlusion code, height maps were already supported for a long time, and this just fixed them in the shaders. I might be wrong, of course.
-
There is parallax mapping and parallax occlusion mapping. As long as you are ok with an additional -height map for a ship and you willl only use one of those for the entire mod I will make sure it is ready to go and supply you with an appropraite shader. If you want to use both, well.. I got stuck on that part.
-
Kobrar, thanks for hopping on irc today and taking a look at this for us. You earned major kudos in my book. I got a crash when I tried your initial mod, but admittedly am not on the greatest hardware to test with - intel graphics on a linux laptop. I'll test it at home in windows and see if I can get it to work.
-
I've released an update to your shaders, Kobrar44. The vertex and pixel shaders have been updated to handle Swifty's new deferred lighting and shadowing code commited to the main branch just after the release of FSOpen 3.7.2. Next, I'll adapt them for his physically-based rendering feature some time in the near future.
To install them, you just have to extract the zip file to the effects folder in the data directory of both parallax/relief texture mapping mods where the shaders are stored.
And, BTW, I always hope that you'll update yours to the latest version, Kobrar44. Thanks in advance.
[attachment DELETED!! by Strong Bad]