Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Swifty on April 16, 2015, 02:49:21 am
-
UPDATE 2/12/2016:
- Increased the color threshold for the brightpass.
- Made specular maps render at all detail levels.
UPDATE 1/16/2016:
- Got rid of "-albedo" maps. Having two different types of diffuse maps just because they didn't look right under unlit environments seemed silly. It was also hard to process transparent vertices for both maps so I think getting rid of "-albedo" was the right call.
- Added support for "-unlit" maps. These maps will only be used if being rendered without lighting. Seemed like a better compromise.
- Added support for "-ao" maps. These maps will be used for ambient occlusion. The red channel is the ambient occlusion map and will only darken ambient lighting. The green channel is the cavity occlusion map and that will affect diffuse and specular.
ORIGINAL POST:
Physically-based rendering builds are ready for testing. Included in this package is a simple mod to use with the 2014 MediaVPs. Just extract and place the folder into a Freespace directory that has a MediaVPs 2014 folder and point the launcher to run the pbr_test mod.
The Ulysses is rendered differently now thanks to the two replacement maps in the mod. One is a simple diffuse map which is black which may seem confusing at first but is normal in a PBR workflow for rendering metallic materials. Another map is what I call a "reflectance map" denoted by -reflect.dds. This is an example of the new specular map format required to take advantage of physically-based rendering. RGB values in the -reflect map is the specular reflectance color. The alpha channel is the gloss map.
Setting the diffuse map to black allows the specular values in the reflectance map to exclusively drive the light response in the rendering of the model. Wear and fine details of the model better respond to light thanks to the gloss channel of the specular reflectance map. Go ahead and take a look at the Ulysses in the F3 Lab to see how it looks.
(http://i.imgur.com/VuLK16i.png)
Also take a look at the Material Overrides button in the F3 Lab next to "Render Options". The Material Override window provides a bunch of sliders you can mess with to get a good idea how how certain parameters look in the new lighting model.
(http://i.imgur.com/kePmY2e.png)
A more exhaustive guide about creating PBR assets (http://www.hard-light.net/forums/index.php?topic=89551.0) has been posted.
PBR-enabled texture maps for the MediaVPs: http://www.hard-light.net/forums/index.php?topic=89583.0
http://www.mediafire.com/download/sa5kj9l84n81jzy/pbr_pbr_ed2bbc35_r2.zip
-
ban this sick filth(http://i.imgur.com/jFs1VhE.png)
-
jesus christ it's an angry manta ray
get in the aeolus
-
If you had a ship which is basically matte (only diffuse lighting), would the PBR method make it look any different? Or does this basically only concern specular lighting?
-
If your ship needs an instant metallic look but you only have a diffuse map, a quick conversion would be to import the diffuse colors into the reflectance map's RGB and set the entire diffuse map to black. You can either set a constant gloss on the reflectance map's alpha channel or copy-pasta the red or green channel of the old diffuse map into the gloss channel. Some parts of the model will look wrong but it's a nice quick and dirty workflow to get started.
-
No, I mean if I have a ship which is completely matte and I make it completely matte in the PBR setup, do they render exactly alike? Or, in other words, does the PBR method offer any visual benefits aside from better specular lighting?
-
Technically, all the changes are in the specular lighting but in reality, everything has some sort of specular. If you want to render a very matte object, you should have a specular color of zero (the engine will correct that to the minimum of (0.04, 0.04, 0.04)) and set the gloss to very low. The object will look very matte and rough. The PBR workflow gives you a lot more power over authoring both matte and shiny objects.
-
Is that 0.04 minimum really necessary? Yes, I've read the blog post you mention in the code but this is a sci-fi game. I see no reason to restrict the artists like that when it could be put to interesting effect.
-
yes, otherwise there's no point in having a gloss parameter if specular can be zero.
-
What? Just because specular can be zero that doesn't change anything if the modeller doesn't decide to make it that way. Why would you deliberately remove that option?
-
Can you just let Swifty work his magic, instead of *****ing about tiny things you probably don't even fully understand?
-
'In reality' everything has some sort of specular, but it's not like there aren't exotic materials (http://en.wikipedia.org/wiki/Vantablack) that you wouldn't find in, say, John Hable's living room, but you might want to render in a science fiction game.
-
I was just playing around in the lab and with all overrides on and set to zero, I can't really perceive any sort of specular/gloss at all at that point. I don't think that minimum value is going to cause anyone who wants a completely matte object any real harm since its pretty much matte at that point.
-
Artemis with material overrides all set to 0 with specular floor in place:
(http://i.imgur.com/lFlkHsh.png)
Same screenshot but with the 0.04 limit patched out:
(http://i.imgur.com/Uj3CGDU.png)
-
Ok, I concede there is a difference.
-
:confused:
You're joking, right? They look identical to me...
-
Might be your screen contrast or something, for me the Artemis is clearly visible in the first shot but only shows up as a sliver of grey on the second.
-
Yeah, the fact that you can somewhat see the model in the first screenshot and not the second is why most if not all modern PBR engines set 0.04 as the minimum specular reflectance value. Thanks for posting the example.
-
Might be your screen contrast or something, for me the Artemis is clearly visible in the first shot but only shows up as a sliver of grey on the second.
I changed my contrast & brightness settings around but it didn't make any difference. Must be my eyes :lol:
More seriously though, what's the point in having (parts of) a model you can't see? After all FSO is a game, not a simulation engine.
-
I dunno, it could be used to interesting effect in a few places. I don't really understand the attitude that the engine has to force modellers not to use very dark speculars in case they abuse them.
-
Might be your screen contrast or something, for me the Artemis is clearly visible in the first shot but only shows up as a sliver of grey on the second.
I changed my contrast & brightness settings around but it didn't make any difference. Must be my eyes :lol:
More seriously though, what's the point in having (parts of) a model you can't see? After all FSO is a game, not a simulation engine.
I adjusted the gamma and it showed up clear as day, everything else is pretty much burning my eyes. :(
-
Chiming in as someone who makes pixels: what does anyone lose by having the option of a pure black specular? Maybe there's a way to make it look cool, maybe not. It doesn't matter because the only decision to make code-side is whether the option is available, and unless there's some cost involved (which there doesn't seem to be), that decision should always err on the side of the option being available.
Yeah, the fact that you can somewhat see the model in the first screenshot and not the second is why most if not all modern PBR engines set 0.04 as the minimum specular reflectance value. Thanks for posting the example.
Maybe I'm interpreting the situation wrong, but if the limit didn't exist, the artist could decide whether to implement the limit themselves (by lightening dark pixels to #0A0A0A), or not. Why should the artist not be able to decide this?
-
What we lose is the wasted time trying to teach artists that zero specular isn't physically plausible and the time spent troubleshooting why someone's gloss map isn't showing. All for the possibility of an effect no one really wants to use.
-
If I'm reading this (http://www.sc0ttgames.com/?p=443) right there are plenty of everyday substances with reflectances of under 0.04. At least lower the minimum to 0.02 as suggested there. (And I would really like to know how 'physically implausible' the actual reflectance of vantablack is.)
-
Just because something isn't physically plausible doesn't mean the engine must hardcode the shader so it can never be rendered. As an artist that isn't an adequate reason to outright refuse to render something the way I define it. Not to mention that Phantom_Hoover already provided an example (http://en.wikipedia.org/wiki/Vantablack) of a near-zero-specular material in reality, so the claim that it isn't "physically plausible" isn't even factual.
Helping new artists understand the PBR workflow is also not an adequate reason to impose a limitation on the engine, IMO. The responsibility to use the tools correctly is the artist's, and the existing documentation on PBR already hammers into people's heads that everything is shiny (http://filmicgames.com/archives/547). I also don't really see many people trying to have a visible gloss map without a bright reflectance map - it's fairly intuitive that there needs to be something to reflect.
-
Okay I'll lower it to 0.02.
-
Material override colors are now gamma corrected so sRGB reference values found on various PBR references should give the correct results now. Uploaded new builds.
-
Sweet galloping gypsies. This made my eyes bleed as I beheld the awesomeness of the render Gods.
-
Sweet galloping gypsies. This made my eyes bleed as I beheld the awesomeness of the render Gods.
:lol: :lol: :lol: :lol:
-
My framerate in the tech lab is very smooth, but my framerate seems to drop to about 4-6 FPS during a mission if a ship model is visible. Is anyone else getting an awful performance hit, or am I doing something wrong?
EDIT: I've found that I don't get the performance hit if I use the -noenv flag.
-
what's your system specs?
-
System specs:
Windows 7 Home Premium 32-bit
Intel Core 2 Duo E7500 @2.93GHz
4 GB RAM
NVidia GeForce 9800 GT (512MB video memory)
-
Turn off shadows and see how that runs. Then turn off deferred lighting if that doesn't work.
-
I already had shadows and deferred lighting, as well as sunshafts turned off. Speaking of which, have those features been optimized yet?
-
There have been a lot of optimizations done to the renderer.
How well do you run the soft shadows and deferred lighting builds?
http://www.hard-light.net/forums/index.php?topic=87121.0
-
Using the FSPort mission "Eve of Destruction" and playing on AdmiralRalwood's April 8 builds, with the FSPort 3.5 MediaVPs 2014:
- I get, at most, 60 FPS with both shadows and deferred lighting turned on. It drops to about 20-30 FPS when I get close to a ship, or when I get into a dogfight.
- There doesn't seem to be a performance hit when I only have deferred lighting turned on.
- The highest frame rate I get with only shadows enabled is 60 FPS. It drops to about 20-30 FPS when I get close to a ship, or in a dogfight.
-
My shadow builds are not quite up-to-date with the latest changes to the shader_transform_deferred branch, but I don't believe the renderer has undergone significant changes since those builds were compiled, so that's probably still a good comparison.
/me starts compiling fresh shadow builds anyway
EDIT: Shadow builds have been updated, if you want to confirm that you get the same performance with the latest code.
-
so, finally got around to try this stuff, first off all, awesome work!
some observations:
i stand by my opinion, hdr bloom is looking awesome, but it is too strong! is there any way for modders to permanently adjust the value?
team colors behave strange, i can not even desrcribe it probably - but all my models look completely weird, as if the contrast on all the colors of the model would have been increased a looooot (and for some odd reason one model that did show them before is not showing team colors at all now, while all the rest still do... hmmmmm)
edit: i just had an idea... actually all my teamcolor maps have a lot of contrast, that was the way to make the dark areas actually look dark with the old rendering system, aparently stuff works completely different in that regard now :shaking:
also, there is a problem with shine not being able to be 0 ( at least i think it has to do with that)
look at this screenshot and the super reflective (although supposed to be transparent!) shield!
(no reflective maps here for all my tests btw, just using the old shine maps)
[attachment deleted by nobody]
-
So, I did a quick build based on current branch (checkout dated 2015/06/06) (after sorting out some MSVC missing entries, which I'll put in a push for once I've gotten them all) and noted an issue with nameplates:
1: There is (or should be) an Alpha fade that overlays that mutes it down to look like it's been properly painted on a ships hull instead of billboarding straight off it like there is no underlying hull.
2: The nameplate slot (and this may just be an F3 Lab issue, still have to test in-mission, but it's easier to position with the mouselight there) the standby texture (that usually gets replaced) will still "fluoresce" at angles. Being that this is the Lab isn't necessarily indicative of an actual issue (like other issues that happen: Turn off Post Processing for example, or check "Fixed Pipeline" for some other shenanigans)
3: On the truly dark side of a ship, it is so visible it looks like it is a neon sign.
Those are just off the top before I forget, I can do screenshots if you like. And after a brief post-work nap, I'll get in those MSVC entries so that others can build (in addition to the origin fixes that makes AVX builds actually use AVX).
-
Wonderful work, Swifty! :)
I hope that you'll integrate PBR into the current branch along with SSAO, but provided that all serious bugs (including CTD ones) are squashed.
-
Swifty, in addition to ambient occlusion maps, what about physically based diffuse albedo map (http://metalgear.wikia.com/wiki/Fox_Engine#cite_note-gdc-17)?
-
you... referenced to a reference m8.
**z64555 applies operator *
[edit] Hmmm, yt doesn't work on this one.
https://www.youtube.com/watch?v=FQMbxzTUuSg (https://www.youtube.com/watch?v=FQMbxzTUuSg)
-
Hmmm, yt doesn't work on this one.
FTFY
-
Hmmm, yt doesn't work on this one.
[snip]
FTFY
oh, thats how it works, thx
-
Anyway, are you going to commit this PBR along with support for ambient occlusion and physically based diffuse albedo maps into main git branch of FSOpen, or you are going to update these builds altogether. I think there are a lots of bugs you all need to address them before doing the former, so the latter is likely.
-
... I think there are a lots of bugs you all need to address them before doing the former, so the latter is likely.
Have these bugs been reported in Mantis or as GitHub issues? Can you please provide links or references.
-
Work is starting to cool down. I have more time to work on side projects again! Therefore I made some improvements to the PBR builds.
- Introduced "-albedo" textures. Any maps with "-albedo" suffixed to their filename will be used as the diffuse map when lit. The base map will only be used for un-lit rendering and fixed function rendering. If your diffuse map can be used in both PBR and un-lit/fixed function, don't bother with the albedo map and just define the base map. But since this is a space game engine and we have plenty of metallic objects flying around, those cases might be rare.
- Fixed gamma correction involving clear and fog colors which caused nebula scenes to be an undiscernible soup of solid color. Nebula poofs should be visible now.
- Added a bunch more rendered objects to the list of emissive objects. Most notable is lightning effects so "As Lightning Fall" is a bit more interesting to play now. Damaged ship lightning arcs now give a nice glow.
- Bloom respects Cmdline_bloom_intensity. The engine will be expecting a value between 0-100.
Based off of commit 61f2e7851 from master on github. Eventually I'm going to merge the work I've done trying to get a more flexible internal material system working in the engine. I'm sick and tired of passing flags and setting global variables to set draw state.
Get yer PBR-enabled models from Shivan Hunter here: http://www.hard-light.net/forums/index.php?topic=89583.0
http://www.mediafire.com/download/4v54533fs33xibl/pbr_61f2e7851.zip
https://github.com/SamuelCho/fs2open.github.com/tree/pabst_bleu_ribbon
-
- Introduced "-albedo" textures. Any maps with "-albedo" suffixed to their filename will be used as the diffuse map when lit. The base map will only be used for un-lit rendering and fixed function rendering. If your diffuse map can be used in both PBR and un-lit/fixed function, don't bother with the albedo map and just define the base map. But since this is a space game engine and we have plenty of metallic objects flying around, those cases might be rare.
Is this proper support for baked AO? So you just add a new texture without the baked AO and add "-albedo" to the name?
-
Yeah, now all that's needed is support for a -ao map.
-
Yeah, now all that's needed is support for a -ao map.
...What would be the point of that? Just bake the AO into the normal diffuse, so it works with both PBR and non-PBR rendering.
-
The albedo/diffuse maps set the color for a given area of the ship. AO says that an area is in shade; keeping AO on the albedo/diffuse would be interpreted by the renderer as that area of the ship being colored differently than it actually is supposed to be, which means that the response to dynamic lighting would be different for those areas than what we would actually expect.
-
The albedo/diffuse maps set the color for a given area of the ship. AO says that an area is in shade; keeping AO on the albedo/diffuse would be interpreted by the renderer as that area of the ship being colored differently than it actually is supposed to be, which means that the response to dynamic lighting would be different for those areas than what we would actually expect.
Right, but you don't keep the AO on the albedo map, that's the point of the albedo map; it's used for when it's lit, so the fact that the base map has AO baked on doesn't matter to its response to light because if it's responding to light, it's using the albedo map...
...or, at least, that's how I interpreted what Swifty was saying, hence why I asked for clarification.
-
Ah, I got you. My point is that the renderer uses either the albedo or the diffuse, and so you'd lose AO information in cases where an albedo map exists, necessitating the addition of an ao map (or using a channel of a different map to hold this sort of info)
-
Ah, I got you. My point is that the renderer uses either the albedo or the diffuse, and so you'd lose AO information in cases where an albedo map exists, necessitating the addition of an ao map (or using a channel of a different map to hold this sort of info)
Oh, I see. I was interpreting it as "when light shines on the ship, the bits that light is shining on use the -albedo map instead of the base map", not "if -albedo is present, it's used instead of the base map". Basically the inverse of an -ao map.
-
In the shader, diffuse/albedo maps are the same thing. It's just, the engine will use diffuse maps for both unlit/fixed function and fragment shaded lighting while albedo maps will exclusively be used in fragment shaded lighting. So if you want to bake your AO into a diffuse/albedo map, you're more than welcome. However, that's negated by the fact that in PBR, metallic materials have a zero diffuse response. Meaning your diffuse/albedo will be black which will negate any baked AO.
So The_E is correct. We're going to have to have a separate AO map system. Perhaps with the red channel being an actual ambient occlusion map that only affects ambient light (And eventually image-based ambient lighting). While the green channel will be a cavity map which will only affect diffuse and specular light.
-
Man... I'm going to have a lot to learn when this is complete in regards to creating textures.
-
A few things I've seen:
damage glowmap applied for no apparent reason:
(http://i.imgur.com/RGYZmDf.png)
(http://i.imgur.com/7Qt1GzU.png)
cockpit glowmap applied to glas geometry for no apparent reason:
(http://i.imgur.com/uZDdfMq.png)
(http://i.imgur.com/jENhYU2.png)
This latter issue is also visible in the F3 lab, and seems to be fairly universal for any model with transparencies.
None of these assets have been converted to PBR.
Also note how much time is spent in page_flip, I am not sure whether that's indicative of anything.
Finally, FXAA seems to not work anymore on my end.
EDIT:
There's also an issue where after playing a cutscene like Icarus, performance seems to tank absolutely. After exiting the cutscene, I got 8 FPS in the lab on something as simple as the MVP Ulysses model, this is clearly indicative of some rather heavy weirdness going on.
These issues can be reproduced using the 2014 MVPs. The Loki is an especially visible example.
-
I can confirm the texture application issue. As far as we can see, it does not appear to be driver related.
As for performance, I get better performance than on previous PBR builds. Ran through Icarus in 1440p at 60 fps most of the time, ending up with an average framerate of 56.4 fps.
-
Man... I'm going to have a lot to learn when this is complete in regards to creating textures.
I just hope this isn't an unreasonable work flow because I totally get where you're coming from. Let me know if you have any issues with how this will all be laid out. Please ask questions if you need me to clarify some stuff. If you're comfortable with PBR workflow in some other engine, whether it be Marmoset, Unreal, Unity, or CryEngine and aren't satisfied with how we're doing it, please let me know about it as well.
-
I have no experience with a PBR work-flow and am really just waiting on a pretty straightforward list of texture types and what they do.
-
usually it would be (as in unreal engine 4, the most prominent example for an pbr engine right now i guess)
- the diffuse color
- rough = how polished the surface is, monochrome image
- normal
- glow
- spec = highlights on NON metal surfaces, doesn't do anything for metals, monochrome image, default value is 0.5
- metal = the amount of metal reflection of the surface, monochrome image
- Ambient occlusion, monochrome image
-
We wouldn't use the UE4 pipeline because we don't have a metalness texture addition, just -albedo, -spec, and -gloss. So instead, we'd use:
-Albedo
-Specular
-Gloss
-Glow
-Normal
-AO
If you already own photoshop and have the money to drop on it, Quixel Suite is one of the better ways to go for PBR texturing, primarily because it does it very fast and has a very large(several thousand iirc) PBR calibrated material library. If you don't own Photoshop already, it may be cheaper to use another method of creating PBR materials.
-
only $99 for Quixel Suite? Yeah, I'll do that when we start working this into the main pipeline. Having a list of maps like that is very helpful to me. When things get more nailed down, I'd love a list like that with a quick description and maybe an example of each map? (Like, I know what normal, glow, and AO are. And I know what specular and gloss means from a rendering sense.. I'd just like a bit of an idea of what that looks like to draw in a texture.) Right now, I draw the diffuse and then make the other maps based on that, but it sounds like the diffuse will be very different in PBR.
-
I have a selfish concern: due to some input bug I have to use antipodes builds. How easily can PBR be merged into those?
-
only $99 for Quixel Suite? Yeah, I'll do that when we start working this into the main pipeline. Having a list of maps like that is very helpful to me. When things get more nailed down, I'd love a list like that with a quick description and maybe an example of each map? (Like, I know what normal, glow, and AO are. And I know what specular and gloss means from a rendering sense.. I'd just like a bit of an idea of what that looks like to draw in a texture.) Right now, I draw the diffuse and then make the other maps based on that, but it sounds like the diffuse will be very different in PBR.
Have some informative videos!
Once things start to move along, I'll make a comprehensive guide specifically for FSO use.
-
Once things start to move along, I'll make a comprehensive guide specifically for FSO use.
:yes: Much appreciated
-
And what about height/parallax occlusion/displacement maps? What does have to do with physically-based rendering?
-
I believe they serve the same purpose as they do in the current rendering system. As it is, they have a similar, but not identical purpose to normal maps. Speaking of which, no changes should be made to normal maps, as they operate the same regardless of PBR being present or not.
I'm currently working on a comprehensive video guide to PBR asset creation in FSO, especially in relation to Quixel Suite. Don't expect it to be finished for quite some time though, as PBR is currently experimental and I don't have any assets ready to be turned into PBR assets.
-
Normal maps and height maps as I understand both give the illusion of geometry that does not exist, but through different means. Normal maps I believe affect the angle of light incidence, allowing to make surfaces appear bumpy or to have light bounce off of creases differently, etc. Height maps go beyond that I believe and actually extrapolate geometry from the map, so that even viewed at more extreme angles you can actually see geometry occluding things behind it, when that geometry isn't actually on the model. But please correct me if I'm wrong.
-
I believe they serve the same purpose as they do in the current rendering system. As it is, they have a similar, but not identical purpose to normal maps. Speaking of which, no changes should be made to normal maps, as they operate the same regardless of PBR being present or not.
I'm currently working on a comprehensive video guide to PBR asset creation in FSO, especially in relation to Quixel Suite. Don't expect it to be finished for quite some time though, as PBR is currently experimental and I don't have any assets ready to be turned into PBR assets.
I know that, but I'm eager to test it. I believe the assets ready to be turned into PBR assets should be those from Shattered Stars, Blue Planet, Inferno, Diaspora and those based on Star Wars.
-
I've tested it with my newly created albedo maps, and I feel it's not consistent with what the MGS5's FOX engine displays on physically based diffuse albedo maps. I need guidance on how to create them, because I do not intend to use the base map w/o albedo for diffuse.
This is the feature I've been wanting and Swifty has done perfectly. :)
Now, The E's right on the need for an ambient occlusion map (-ao).
As for the merging of this PBR into the main branch, I can't wait to see this.
-
I've tested it with my newly created albedo maps, and I feel it's not consistent with what the MGS5's FOX engine displays on physically based diffuse albedo maps. I need guidance on how to create them, because I do not intend to use the base map w/o albedo for diffuse.
This is the feature I've been wanting and Swifty has done perfectly. :)
Now, The E's right on the need for an ambient occlusion map (-ao).
As for the merging of this PBR into the main branch, I can't wait to see this.
Albedo should not have any lighting information in them whatsoever. Most albedo maps tend to be dark for metals, with non-metals having pastelish colors. As for why it's not consistent with FOX engine, that's because they're implemented differently, iirc FOX engine uses the same metalness/roughness setup as UE4, so using the processes for that will yield poor results in FSO.
As I side, videos are being made, they will be finished eventually, just give me some time.
Edit: It's also not really your decision to decide which assets get converted, it's up to whoever decides to take the time to convert them. Many of us have important things irl, like work and school. While I'd personally like to spend more time working on stuff for modding, I have a metric ****ton of classes (21 hours every week, and that's without taking into account homework and study time).
-
Should the colour of the albedo map be affected by the paint? I don't think the reflection map should have the paint colours, because that means that the reflection will be the same colour as the paint. Think of a car (http://www.2015bestcar.com/wp-content/uploads/2014/07/2016-Volkswagen-Jetta-v4.jpg), for example.
I've been doing some experimentation (http://www.hard-light.net/forums/index.php?topic=88814.msg1802510#msg1802510) with the PBR builds myself.
-
Reflection color depends on the environment and the material, For example, the reason that car reflects mostly white is because it is in a white room with a high gloss value on the paint, but not all paints are glossy and we aren't always in a flat colored room.
Painted metals in particular can actually vary by a large margin, but the paint generally reflects less of the world color than the metal itself.
Example with point lighting, a good approximation of a flat colored room:
(http://i.imgur.com/XqzKu7g.png)
Example using image based light:
(http://i.imgur.com/5jvg2Zr.jpg)
Zero specular:
(http://i.imgur.com/F5Qnjwx.jpg)
Zero gloss:
(http://i.imgur.com/931mdfO.jpg)
HDR with lens flares:
(http://i.imgur.com/RWXSFee.jpg)
As you can see, the metal and paint have similar albedo values, with the metal being slightly darker, however the metal has a very light gray specular color, while the paint has a dark black color. The gloss shows similar values for the metal and the paint, with the metal being slightly lighter overall. Using the HDR with lens flares, we can see that the metal tends to reflect more light than the paint.
Just some interesting insight into how PBR should look.
-
I've tested the PBR build with cockpits, such as one in the Shattered Stars campaign (http://www.hard-light.net/forums/index.php?topic=88909.msg1803461#new) thread. Although it looked awesome, it would be better to integrate with deferred lighting and soft shadows?
-
You cannot get PBR without also getting deferred lighting and shadows.
-
You cannot get PBR without also getting deferred lighting and shadows.
You are right. Without deferred lighting and shadows, we can't get PBR.
I don't understand why the cockpit POF model doesn't have any shadows cast onto it.
Swifty, I hope you make it so by committing the PBR features into the main branch, provided after you added the -ao map support for ambient occlusion.
-
The way cockpits are implemented, they are not a part of the world, but are rather drawn onto the frame separately, therefore cannot share the same shadowmap IIRC. Makes sense as they are not the same model as the ship model.
-
I see. Thanks for the head's up, Kobrar44.
-
I've opened an issue on your Github (https://github.com/SamuelCho/Freespace-Open-Swifty/issues/5), Swifty. You may want to check it out.
A few things I've seen:
damage glowmap applied for no apparent reason:
(http://i.imgur.com/RGYZmDf.png)
(http://i.imgur.com/7Qt1GzU.png)
cockpit glowmap applied to glas geometry for no apparent reason:
(http://i.imgur.com/uZDdfMq.png)
(http://i.imgur.com/jENhYU2.png)
This latter issue is also visible in the F3 lab, and seems to be fairly universal for any model with transparencies.
None of these assets have been converted to PBR.
Also note how much time is spent in page_flip, I am not sure whether that's indicative of anything.
Finally, FXAA seems to not work anymore on my end.
EDIT:
There's also an issue where after playing a cutscene like Icarus, performance seems to tank absolutely. After exiting the cutscene, I got 8 FPS in the lab on something as simple as the MVP Ulysses model, this is clearly indicative of some rather heavy weirdness going on.
These issues can be reproduced using the 2014 MVPs. The Loki is an especially visible example.
The problem is more or less the same.
-
I'm already aware of the issue.
And you reported it on the Git repo I'm no longer using.
-
I'm sorry, Swifty. I should have reported it on your working Git branch.
You might want to check this out:
Physically-Based HDR Rendering
There's an article on Physically-Based Camera Rendering (https://extremeistan.wordpress.com/2014/09/24/physically-based-camera-rendering/). It depends on HDR rendering.
-
Interesting article, but if we are trying to achieve immersion in games, wouldn't that be better served by replicating what the human eye itself sees in real life, and not what a camera sees?
-
Indeed. It's a question of what kind of look you wish to achieve, whether you're going for something filmic or something naturalistic.
-
We're going for both: filmic and naturalistic. These depend on what the shader designer wants.
The camera sees depth of field, motion blur, and lens effects.
-
We're going for both: filmic and naturalistic. These depend on what the shader designer wants.
The camera sees depth of field, motion blur, and lens effects.
...But we don't have depth of field, motion blur, or lens effects...?
-
We totally have lens flares as a post-processing effect atm.
(http://i64.tinypic.com/6dznme.jpg)
-
We totally have lens flares as a post-processing effect atm.
Actually, turn off post-processing and you should still see it; it's just part of drawing the sun, with graphics defined in stars.tbl. The reason I missed it at first is because I was checking the post-processing code. ¯\_(ツ)_/¯
-
And what about lightshafts, which has been shown in the recent screenshot?
(http://image.slidesharecdn.com/frostbitepbandunifiedvolumetrics-150820015056-lva1-app6891/95/physically-based-and-unified-volumetric-rendering-in-frostbite-5-638.jpg?cb=1440035628)
Actually, turn off post-processing and you should still see it; it's just part of drawing the sun, with graphics defined in stars.tbl. The reason I missed it at first is because I was checking the post-processing code. ¯\_(ツ)_/¯
Have you done? Are there changes needed to support physically-based HDR post-processing effects?
-
Wrong question to ask. There are always changes needed.
In PBR builds, post processing only happens after tonemapping. I don't think there are any post effects that actually benefit from working on HDR buffers.
-
Swifty, how is going on your PBR builds? Any progress on solving the glowmap applied to models for weird reason problem?
-
I've heard that you started committing your changes (including PBR) to the main branch.
http://www.hard-light.net/forums/index.php?topic=91220.0 (http://www.hard-light.net/forums/index.php?topic=91220.0)
-
Those changes aren't related to the PBR branch at all. As far as I can tell, the PBR branch is nowhere near being ready to merge into master.
-
Yeah, team glow maps have nothing (or very little, anyway) to do with PBR.
-
Sorry about the late update guys. Being the lead programmer of a certain game (http://store.steampowered.com/app/323060/) takes up a lot of your time when you're trying to get it shipped. :P
Anyway, new build. Fixed all the weird issues with glow maps being accumulated on certain materials.
I got rid of "-albedo". I replaced it with "-unlit". It got really confusing in the code trying to keep track of two different diffuse maps that would be used in lieu of each other's presence, especially when it came to transparent surfaces. Keeping track of transparent vertices for different diffuse maps would have made a mess of the code. Unlit maps seem like a better solution. Basically it's a diffuse map that will be used when the model has no lighting applied. I don't keep track of transparent triangles for unlit maps since they're usually rendered in special situations and by the very nature of them being unlit, don't need deferred lighting applied to them.
This update also introduces "-ao" maps. "-ao" maps or ambient occlusion maps will darken certain components of lighting. The red channel of this map is ambient occlusion and will darken ambient lighting. The green channel is cavity occlusion and will darken diffuse and specular lighting. Try it out. Let me know if there are any issues or feedback.
http://www.mediafire.com/download/kiasjgzk5bwpsj0/pbr_ed2bbc35.zip
This build is based off of the latest revision on Github. (ed2bbc35ebefb4b91822fb2d267fefa55b136ff8 (https://github.com/scp-fs2open/fs2open.github.com/commit/ed2bbc35ebefb4b91822fb2d267fefa55b136ff8))
-
so, can i use traditional black and white ao maps too? will it automatically use the single channel for both?
-
A black and white AO map should work out of the box. I assume red, green, and blue channels are sharing the same values. So in that case, ambient and cavity, taken from the red and the green channels, will have apply the same amount of darkening on ambient, diffuse, and specular lighting.
-
I got rid of "-albedo". I replaced it with "-unlit". It got really confusing in the code trying to keep track of two different diffuse maps that would be used in lieu of each other's presence, especially when it came to transparent surfaces. Keeping track of transparent vertices for different diffuse maps would have made a mess of the code. Unlit maps seem like a better solution. Basically it's a diffuse map that will be used when the model has no lighting applied. I don't keep track of transparent triangles for unlit maps since they're usually rendered in special situations and by the very nature of them being unlit, don't need deferred lighting applied to them.
So... I'm not sure I understand how -unlit maps work. Also, I take it this means you can't use the same textures for PBR and non-PBR builds again?
-
So... I'm not sure I understand how -unlit maps work. Also, I take it this means you can't use the same textures for PBR and non-PBR builds again?
Any assets that worked on a previous build of Freespace Open should look generally okay in a build with PBR. But a texture that's specifically built for PBR won't look good in a previous build with Freespace Open with the old lighting model.
Unlit maps are optional and are used as the diffuse map of a model if the model is rendered without any lighting. AKA, if the model is being rendered in the targetbox or being rendered in the ship preview window in the mission briefing map.
So if you have base map that doesn't look good when being rendered with no lighting, probably because you chose to have a near black diffuse to simulate metallic materials, then you would have to use an unlit map with the desired colors.
But honestly, if this is all too cumbersome, I'd rather just indiscriminately enable lighting in the targetbox and briefing ship preview windows so we don't have to deal with this black diffuse problem.
-
AFAIK you can switch between wireframe, no lighting, and normal lighting for the targetbox with Alt-shift-Q so that should be a non-issue.
-
I tested out this latest PBR build, and it looks fine. Though any issues on team glowmaps have yet to be reported, glowmaps are no longer being applied for no reason.
By the way, will this AO maps work well with heightmaps? I think so, but all we need right now is the height map support. Kobrar has written some custom (http://www.hard-light.net/forums/index.php?topic=85580.0) shaders, so you may want to look into it before integrating it, along with new effects such as self shadowing in normal and height maps. It also makes the model gloss/reflectance more accurate and physically.
-
A black and white AO map should work out of the box. I assume red, green, and blue channels are sharing the same values. So in that case, ambient and cavity, taken from the red and the green channels, will have apply the same amount of darkening on ambient, diffuse, and specular lighting.
well, actually, i am talking about about images with only a grey channel, not quite sure if we are talking about the same thing right now - if you handle those like you just described, than everything is fine
-
Oh, I get what you're saying. I think if this texture only has one channel, OpenGL will just place that channel into the red while setting the rest of the channels to 1.0. So your map will only affect ambient occlusion and not cavity occlusion. So, yes, it'll still work out of the box just a bit more work is needed if you decide you want your map to affect diffuse and specular lighting and not just ambient lighting.
-
Will ambient lighting affect normal/parallax/displacement mapping? I've heard that recent game engines of this generation, such as CryEngine and Unreal Engine 4, support this.
-
Oh, I get what you're saying. I think if this texture only has one channel, OpenGL will just place that channel into the red while setting the rest of the channels to 1.0. So your map will only affect ambient occlusion and not cavity occlusion. So, yes, it'll still work out of the box just a bit more work is needed if you decide you want your map to affect diffuse and specular lighting and not just ambient lighting.
tested it, seems like it is so, which is a waste of memory actually, if you want to have both being the same, like i do
a suggestion: LODs 2 and 3 don't use specularity, thus they are more or less unlit models, it would make sense to use the unlit map for them, right now, they are totally black for a ship with high metal amount
-
I second it, fightermedic.
-
Here's the result of the ambient occlusion test of this PBR build. It's a recently released Raguel, with an AO and unlit maps applied.
(http://www.hard-light.net/wiki/images/thumb/SCRaguelHTL.png/800px-SCRaguelHTL.png)
However, I don't know how to create reflectance/gloss maps using GIMP, which is used as my primary image/texture manipulation program.
-
That's because trying to make PBR reflectance and specular maps by hand is damn near impossible. Look into getting either substance painter or Quixel Suite.
-
As someone who primarily uses Linux now, both Quixel Suite (which requires Photoshop) and Substance Painter are not natively available on my platform. In addition, both products cost more than I'm willing to pay for modding and content creation.
I'm not that good at modelling and texturing, either.
On the other hand, I've heard that AwesomeBump (http://awesomebump.besaba.com/), and a special branch of Blender (http://www.blendernation.com/2016/01/18/blender-pbr-viewport-branch-v0-2/) now support PBR.
-
If modellers can't make good use of PBR without expensive proprietary software I think that's seriously at odds with FSO's ethos.
-
As someone who primarily uses Linux now, both Quixel Suite (which requires Photoshop) and Substance Painter are not natively available on my platform. In addition, both products cost more than I'm willing to pay for modding and content creation.
I'm not that good at modelling and texturing, either.
On the other hand, I've heard that AwesomeBump (http://awesomebump.besaba.com/), and a special branch of Blender (http://www.blendernation.com/2016/01/18/blender-pbr-viewport-branch-v0-2/) now support PBR.
AwesomeBump sounds like it will suffice. As for the PBR viewport in Blender, Cycles itself is a PBR engine, it is capable of exporting PBR textures, it's just difficult to get them to look correctly in FSO due to the differences in calibration, that feature just allows the view-port to use PBR in real-time as well.
It is possible to make PBR textures using GIMP, you just have to know your way around the mask system very well. It also requires knowledge on the sRGB values of the material(metal, plastic, etc.) you want to use.
-
I tried using AwesomeBump, but... when I tried opening textures larger than 2048x2048, not only it hang, but also causes my AMD laptop display driver to stop working, only to be recovered instantly.
As I say, I prefer using GIMP for texture manipulation, for the time being. I intend to use it for creating PBR assets.
-
Hey, Swifty. I've got a problem here. It seems that the PBR build has encountered an access violation when turning on the ship thrusters in the Ship Lab while viewing the PBR-enabled ships such as my Raguel. Then, my AMD laptop display driver amdkmdap stopped responding and successfully recovered.
Faulting application name: fs2_open_3_7_3_SSE2.exe, version: 3.7.3.0, time stamp: 0x569afefa
Faulting module name: atioglxx.dll, version: 6.14.10.13417, time stamp: 0x567abfba
Exception code: 0xc0000005
Fault offset: 0x00e493e7
Faulting process id: 0x20a0
Faulting application start time: 0x01d15cb0a78a3038
Faulting application path: C:\Games\FreeSpace2\fs2_open_3_7_3_SSE2.exe
Faulting module path: C:\WINDOWS\SYSTEM32\atioglxx.dll
Report Id: a3efb925-ff50-4173-8de0-f453ddf9b4b1
Faulting package full name:
Faulting package-relative application ID:
Checking with the debug build, this problem doesn't happen. I think it's due to the driver. Regardless of that, optimizations and preventive measures must be implemented.
-
Okay, Mr "Visionary Coder", please tell us how we're supposed to prevent driver errors.
-
Updating the display drivers to the very latest version should solve that problem. Lacking that, filing a feedback is appropriate, given that Windows 10 has a feedback app that allows suggestions and problems be reported, and Microsoft takes these to improve it.
I am a Windows insider since November last year, and I'm not the only one. Looking into the "Display Drivers" subsection of the Hardware section, there are many people complaining about display drivers stopped working, even on Insider builds.
-
Updating the display drivers to the very latest version should solve that problem.
So... did updating your drivers fix the problem, or not?
Are... are you asking that FSO somehow update your drivers for you?
-
you most make an update
-
AdmiralRalwood, are you referring to Swifty or me?
-
He's referring to you.
-
Me. Generally, I agree that changing settings via the AMD Radeon settings could be a workaround, until at least it's fixed in newer builds.
-
...Updating your drivers isn't "changing settings", nor is it a "workaround". In fact, it should be the first thing you try when you get a driver crash.
-
Me. Generally, I agree that changing settings via the AMD Radeon settings could be a workaround, until at least it's fixed in newer builds.
Could you please answer the question that was posted? Noone asked anything about "changing settings" (which doesn't help in fixing driver crashes in my experience), you were asked whether or not updating drivers fixed the crash you experienced.
-
Me. Generally, I agree that changing settings via the AMD Radeon settings could be a workaround, until at least it's fixed in newer builds.
Could you please answer the question that was posted? Noone asked anything about "changing settings" (which doesn't help in fixing driver crashes in my experience), you were asked whether or not updating drivers fixed the crash you experienced.
Yes, along with updates to the operating system themselves. I did not experience crashes when no other applications running in hardware acceleration mode.
And, I've tested this PBR build. While it looks flawless, there's only one problem. The transparencies of HUD gauges (both LUA and non-LUA). They seem to be nearly opague (see attachment below).
[attachment DELETED!! by Strong Bad]
-
New build. I didn't really change much other than increaseing the threshold for the brightpass and made specular maps render at all detail levels.
http://www.mediafire.com/download/sa5kj9l84n81jzy/pbr_pbr_ed2bbc35_r2.zip
-
Wow. Trying on it now.
-
There's now an official pull request. https://github.com/scp-fs2open/fs2open.github.com/pull/536
Please continue submitting feedback if you have any.
-
The transparencies of HUD gauges (both LUA and non-LUA). They seem to be nearly opague (see attachment below).
Yeah, this is still an issue. Hud gauges are now always full bright, which I guess isn't a bad thing by itself (certainly more visible) but it does cause this (http://ibin.co/2X7OZR9UNTm7) to happen to me with my scripted message gauge. The problem here is I draw 2 monochrome images on top of each other, a dark gray one and then a colored one on top so it stands out more and is easier to read. (Now it stands out a little too much.)
Also subtitles don't fade in or out. They just... appear!
Thinking about it a bit more, it seems all these graphics seem to have max alpha all the time, whether they should or not.
(Also the washout glare from the sun seems to have a wider effect. This one cutscene I had is washed out for a lot longer than I was anticipating)
Other than that, very pretty, very shiney. Much bloom. Such HDR. Wow.
-
Okay, I got a better idea of the HUD issue. It looks like the constant alpha defined in the passthrough shader wasn't being applied. I committed a fix to the branch.
I don't know what to do about the washout glare from the sun. I'm not sure if it's part of the brightpass for the bloom or not. Maybe the fixes to the passthrough shader may have fixed it but who knows.
-
I don't know what to do about the washout glare from the sun. I'm not sure if it's part of the brightpass for the bloom or not. Maybe the fixes to the passthrough shader may have fixed it but who knows.
Reduce a washout glare intensity into a narrower effect - this means the sun gets brighter and covers the screen in white when the sun is ONLY at the center of the screen. I think you should make changes to the lightshaft shader.
-
The latest fixes fixes the hud and the subtitle fades, but this (http://ibin.co/2X7OZR9UNTm7) still happens. :(
-
Per Axem, I've been encountering more or less the same issues.
-
There's now an official pull request. https://github.com/scp-fs2open/fs2open.github.com/pull/536
Please continue submitting feedback if you have any.
Is PBR going to be forced onto people? We've been working with the "traditional" lighting model for so long that it isn't practically feasible to create PBR assets or convert non-PBR assets to PBR for everything that's been released. :(
-
You won't be forced, all the old texture types still work. I've been running some mods without any special PBR textures and it works fine (aside from a few image scripting problems that Swifty is working on). Even without PBR textures, you'll still get some amazing bloom effects to pretty up everything. :)
-
You won't be forced, all the old texture types still work.
I'm pretty sure that at least half of all existing screenshots that have been taken of the PBR branch involve non-PBR assets, for that matter...
-
The thing is, specular maps created for use with the old lighting model don't look very good in PBR builds.
No PBR:
(http://www.ciinet.org/kevin/myimages/WCAG/Bengal.png)
PBR:
(http://www.ciinet.org/kevin/myimages/WCAG/BengalPBR.png)
-
Can you redo one of those with the same bloom settings as the other? I think at least some differences I see there are directly bloom related.
-
It seems to me that the bloom scale has somewhat changed. Setting smaller values there is probably a good idea.
-
I don't think it's the lighting model. It's likely the HDR and how we're now doing gamma correction. Try and see if the models look the same in a non-PBR build vs a PBR build with post processing turned off in the command line arguments.
-
I don't think it's the lighting model. It's likely the HDR and how we're now doing gamma correction. Try and see if the models look the same in a non-PBR build vs a PBR build with post processing turned off in the command line arguments.
OK.
No post-processing, using a non-PBR build.
EDIT: I apparently had post-processing hidden when I took that previous screenshot with the non-PBR build. I've replaced the previous screenshot with a new one with post-processing turned on.
(http://www.ciinet.org/kevin/myimages/WCAG/NoPBRnoPP.png)
No post-processing, using a PBR build
(http://www.ciinet.org/kevin/myimages/WCAG/PBRnoPP.png)
-
Aren't bloom and FXAA post-proc features?
-
Oh it looks like he doesn't have a build with the latest PBR commits. Turning post processing off is going to look funky in the build that's currently present, never mind.
-
Here's a screenshot, without post-processing, from a newer PBR build (commit 3849be2).
(http://www.ciinet.org/kevin/myimages/WCAG/PBRnoPP2.png)
-
So, is the picture still unsatisfactory? Do you still have problems with the render?
-
The problem is the PBR renderer itself. It doesn't work well with post-processing, even if it's optimized.
-
The problem is the PBR renderer itself. It doesn't work well with post-processing, even if it's optimized.
This post is gibberish. It does not contain anything remotely resembling a description of a bug. If you have found an issue not already mentioned in this thread, describe it in detail, with screenshots and steps to reproduce the issue at the very least.
Bryan, I want this to be absolutely clear. Posts like the one above accomplish exactly two things: They make people like me (who you expect to fix your problems) ignore you, and they make your repeated statements of coding or modding ability questionable. What they do not do is lead to your issues getting fixed.
-
The thing is, specular maps created for use with the old lighting model don't look very good in PBR builds.
this statement, i dare say, holds truth to it
with the hippocrates i ran into that problem somewhat, i provided screenshots here: http://www.hard-light.net/forums/index.php?topic=57547.msg1808736#msg1808736
the first 4 screens are with non-pbr textures, and show how some of the default values responsible for reflection are just too high in my opinion - especially on supposed to be dark, barely reflective surfaces! - just have a look and judge yourself
-
Can you redo that test with the current builds?
-
Can you redo that test with the current builds?
i will, as soon as i am at home, but if memory doesn't delude me, nothing has changed in that regard
-
That post isn't very helpful. I need specific specular color and gloss values you used in those maps in order to isolate which parameter you have problems with, especially if it's a discrepancy between how textures are being read vs how the materials overrides are working. Saying that you used low specular and gloss and saying it looks to bright compared to the materials overrides set to zero doesn't give me enough actionable feedback. A better comparison would have been to take the spec color and gloss value of the texel and compare it using the exact same numbers in the overrides.
-
That post isn't very helpful. I need specific specular color and gloss values you used in those maps in order to isolate which parameter you have problems with, especially if it's a discrepancy between how textures are being read vs how the materials overrides are working. Saying that you used low specular and gloss and saying it looks to bright compared to the materials overrides set to zero doesn't give me enough actionable feedback. A better comparison would have been to take the spec color and gloss value of the texel and compare it using the exact same numbers in the overrides.
Specific specular color and gloss values can be related to specific model.
And, as for EXT_FRAMEBUFFER_OBJECT, you should check this.
-
And, as for EXT_FRAMEBUFFER_OBJECT, you should check this.
Why? What for?
-
finally got around to test it with the newest build, everything is still exactly as on my screenshots
@swifty
i think it might be possible you misunderstood my post entierly
in no word did i mention anything about discrepancis between the material override and texture values, in fact those work quite fine!
the problems that I tried to SHOW using appropriate override settings are those:
- on NON-pbr textures, the default value you use for gloss (since non pbr textures don't have gloss values, this IS what you are doing, right? ) is way too high... I think non-pbr textures should be much more matt by default
as they are currently those textures are a lot more shiny than in the pre pbr builds
- on PBR textures, if you have a completely matt material ( 0 gloss ) and a completely black diffuse and spec texture, there is still a lot of reflection going on - it is absolutely imposible right now to make a really dark and non reflective surface
-
The minimum is, IIRC, capped at 0.02, which should be pretty darn hard to see; can you take a screenshot of that problem?
-
i did, they are linked a few posts above
-
- on NON-pbr textures, the default value you use for gloss (since non pbr textures don't have gloss values, this IS what you are doing, right? ) is way too high... I think non-pbr textures should be much more matt by default
as they are currently those textures are a lot more shiny than in the pre pbr builds
That's because non-PBR textures are still treated as before, the gloss comes from your ogl_spec parameter in the launcher.
- on PBR textures, if you have a completely matt material ( 0 gloss ) and a completely black diffuse and spec texture, there is still a lot of reflection going on - it is absolutely imposible right now to make a really dark and non reflective surface
This narrowed down the possible issues.
Would you mind sending me copies of your PBR texture files for the Hippocrates so I could troubleshoot them? Preferably either XCF or PSD.
Edit:
This is probably closer to what you wanted.
(http://puu.sh/nl89z/c096f99a85.png)
Yes the colors are still washing out, that isn't due to the gloss, that's the specular coloring itself that needs to be fixed.
-
i did, they are linked a few posts above
That's not from a recent build, though; still, I'll let someone with more experience in this area try to figure it out.
-
The apparent issue is that Cycles doesn't seem to account for gamma correction when generating textures, so it produces specular values that are way off. With the textures for the Hippocrates, the final colors were getting pushed way towards black, making the entire surface matte.
-
And, as for EXT_FRAMEBUFFER_OBJECT, you should check this.
Why? What for?
To answer this question, for handling frames rendered. I think it's more or less resolved by Swifty.
-
To answer this question, for handling frames rendered. I think it's more or less resolved by Swifty.
Bryan, in threads like this one, we are looking for three things. One, ideas to make a feature better. Two, bug reports for issues found with a feature. Three, help and advice on how to fix bugs. In all cases, what we need is a certain level of elaboration on the poster's part. The best feedback is unambiguous and complete. Yours frequently is neither. Anytime you post something, we have to spend time trying to puzzle out whether you've actually found something interesting or whether you've once more demonstrated your utter lack of understanding of the problem. This is time we'd rather not spend, and as a result, you will be ignored or worse.
Now, you claim to be a visionary coder in that sidebar there. So please, at least try to act like one. Right now, you come across as someone who does not know what he's talking about, has a limited capacity to understand problems or see the big picture, and is utterly incapable of communicating with other coders. That, dear Bryan, is the opposite of "visionary".
-
I've started to give the old GTB Medusa some PBR love.
(http://puu.sh/nw9Kp/531c7f3d8a.png)
(http://puu.sh/nwbFq/a24354d489.png)
To show how the gloss is masked:
(http://puu.sh/nwbNH/2455428d4d.png)
-
Is this the first set of PBR assets done since the new texture types were added?
-
Afaik, yes. I haven't gotten around to making an -unlit map and separating the AO from the diffuse, but that's fairly simple compared to all the work involved in converting the old -shine maps to proper -reflect maps. I have to include every bit of detail that should have a different gloss value in the alpha channel or else it won't look right.
Update: More work, the reflections now accurately take into account the color and material of the surface, also did more work on the gloss mask.
(http://puu.sh/nx530/c6250b6518.png)
Update 2: Have a vidya.
-
Looking awesome... nice pick using one of the best looking models in the game to do this.
-
Hades asked me to recolor the Medusa a bit. Now it's a metallic blue instead of the greenish gray it was before.
(http://puu.sh/nyuNj/ff187e3017.png)
-
niiiiice, this should be reposted to Celebration of Freespace :)
-
Soooo pretty, and only 50$!
-
That's looking real good.
-
Hades asked me to recolor the Medusa a bit. Now it's a metallic blue instead of the greenish gray it was before.
(http://puu.sh/nyuNj/ff187e3017.png)
I have the most awkward boner right now.
-
Trying to compile the latest PBR builds (since the ones in this thread seem to be out of date). Do I need MSVC 2010 to compile from Swifty's branch (that's the latest version I see), or am I just missing the pabst_bleu_ribbon branch somewhere?
Context: I downloaded MSVC 2015 several hours ago, and successfully compiled a build from master for the first time about 30 minutes ago. Google is answering most of my questions about visual studio, but this is so specific to FSO that I can't find a solution.
Badass bomber by the way. I want to like the canon color better, but damn that blue looks sexy.
-
You don't need MSVC2010; I'd recommend using 2015 Community edition since it's the most recent and it'll allow you to compile FRED as well.
To compile a PBR build, you need to get this branch: https://github.com/SamuelCho/fs2open.github.com/tree/physically_based_rendering
In general git terms; you need to:
1) Add Swifty's fork as a remote
2) Checkout the branch
3) Compile per normal
(both are quite easy to do with SourceTree (https://www.sourcetreeapp.com/); which is the git tool I use most on Windows)
-
I was looking in scp-fs2open for a pbr branch, which explains why I didn't find it. :nervous: Thanks for the link to the fork, I didn't know that existed. Worked perfectly in 2015 Community Edition; super easy. Thanks!
-
Has the PBR merged into the nightly builds already?
-
No it hasn't.
-
At this point I'm just waiting for the RC cycle to finish so someone will finally give it approval to merge in. At the moment I'm currently just working on bringing FSO to OpenGL Core compliance.
-
And what of Vulkan API support?
-
And what of Vulkan API support?
Nobody's written it yet.
-
We're in no position to even consider Vulkan right now when we don't even have OpenGL Core working.
-
Umm, so, coming into this blind. All I know is these screen shots are really cool.
Is this an extra modification to Freespace Media VPS 2014? Some new lighting setting? What is the secret ingredient?
-
It's a separate build of FSO. Download it from the 1st post, and run it like any other build.
-
Firstly, now I can't imagine playing Freespace without PBR. Thanks!
Secondly, about that bug (http://www.hard-light.net/forums/index.php?topic=89550.msg1813061#msg1813061): it also tends to screw up shield gauges, and having binary shield indicators is... at least annoying. Since it was been fixed (http://www.hard-light.net/forums/index.php?topic=89550.msg1814166#msg1814166)... When do we, mortals who don't know how to compile FSO, get a nice and pretty upload of the fixed version?
That bug happens on ed2bbc35 build.
-
Probably not for some time unfortunately. There are some things I don't believe I can expound upon at the moment, but I do know that the PBR repo no longer exists separately from another experimental build, so it may or may not work even with a successful merging of trunk into it.
-
Alright, I've miraculously found myself an old build based on 3.7.1 somewhere on my HDD... problem solved.
-
This feature has officially been merged (https://github.com/scp-fs2open/fs2open.github.com/pull/640) into the master branch and will start appearing in nightly builds.
-
Exciting times :)
-
Me too :)
I would also like to see HDR + Post-processing + Motion blur + Non-excessive lens-flares effects + Image-based rendering (a technique in which 2D elements are manipulated to appear in a 3D world - delivering a significant performance boost by replacing 3D geometry that is far enough away for the transition to be imperceptible with a 2D image) in Freespace, though.
-
Me too :)
I would also like to see HDR + Post-processing + Motion blur + Non-excessive lens-flares effects + Image-based rendering (a technique in which 2D elements are manipulated to appear in a 3D world - delivering a significant performance boost by replacing 3D geometry that is far enough away for the transition to be imperceptible with a 2D image) in Freespace, though.
Bryan, you really need to get into the habit of watching the various threads more closely. If you did, you would have known that HDR is already in, and we've had postprocessing for years.
As for the rest of your wish-list, Motion blur will never happen, lens flares are a thing I am investigating, and Image-based rendering seems like a far-off goal without a real use-case right now.
-
Image based rendering seems only interesting in so far as rendering a huge number of asteroids far far away. But that implies a lot of code changes in other important aspects of those things too (don't rotate too much, increase number of possible asteroids, have better algorithms to solve collision detection, etc.).
Perhaps I could see some usage in rendering missiles? Basically turn them into dynamic sprites? Then again, LODding is so effective and the poly cost is so low...
... Nah. I just don't see the usage.
Excited for the lens flares thing though! Can't wait to make a JJ Mod of Freespace2!
-
Excited for the lens flares thing though! Can't wait to make a JJ Mod of Freespace2!
the branch is named "jjabrams" :P
-
IIRC, JJAbrams was the excuse people used a while back for not adding any lens flare features...
-
I don't know, if I ever argued for such a position, I would like to smack my past self :P
What I'm looking for is a configurable lens flare solution that works as a post processing effect (so that any bright things, not just suns, can trigger lens flare action) and that can be adjusted on a per-mission basis by the mission designers.
-
What I'm looking for is a configurable lens flare solution that works as a post processing effect (so that any bright things, not just suns, can trigger lens flare action) and that can be adjusted on a per-mission basis by the mission designers.
*Swoon*
-
Motion blur will never happen
Awww :(
-
And no mention of Geomod whatsoever in this thread.
What has HLP come down to?
-
I'd actually really appreciate some clarity on the maps involved in PBR. What maps are now a thing? How do I go about making these maps? What maps are now no longer a thing? Why do half my ship models look like they are plastic wrapped and how do I fix that? Do I really have to go make 100+ reflect maps to make everything look proper? This prospect does not exactly thrill me.
Documentation plox
And no mention of Geomod whatsoever in this thread.
What has HLP come down to?
The Geomod question was solved when soft particles were added.