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

Title: Physically-Based Rendering Builds
Post 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
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 05:17:23 am
ban this sick filth(http://i.imgur.com/jFs1VhE.png)
Title: Re: Physically-Based Rendering Builds
Post by: BritishShivans on April 16, 2015, 10:36:02 am
jesus christ it's an angry manta ray

get in the aeolus
Title: Re: Physically-Based Rendering Builds
Post by: zookeeper on April 16, 2015, 02:31:10 pm
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?
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 16, 2015, 04:02:21 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: zookeeper on April 16, 2015, 04:05:56 pm
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?
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 16, 2015, 05:23:06 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 05:40:38 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 16, 2015, 05:58:28 pm
yes, otherwise there's no point in having a gloss parameter if specular can be zero.
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 06:02:58 pm
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?
Title: Re: Physically-Based Rendering Builds
Post by: Spoon on April 16, 2015, 06:10:03 pm
Can you just let Swifty work his magic, instead of *****ing about tiny things you probably don't even fully understand?
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 06:17:19 pm
'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.
Title: Re: Physically-Based Rendering Builds
Post by: Axem on April 16, 2015, 07:07:35 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 07:23:57 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: Axem on April 16, 2015, 07:24:50 pm
Ok, I concede there is a difference.
Title: Re: Physically-Based Rendering Builds
Post by: niffiwan on April 16, 2015, 07:42:25 pm
 :confused:

You're joking, right?  They look identical to me...
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 07:45:15 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 16, 2015, 07:50:07 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: niffiwan on April 16, 2015, 07:55:44 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 08:00:44 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: z64555 on April 16, 2015, 08:06:30 pm
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. :(
Title: Re: Physically-Based Rendering Builds
Post by: Shivan Hunter on April 16, 2015, 08:27:24 pm
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?
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 16, 2015, 08:32:17 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on April 16, 2015, 08:37:36 pm
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.)
Title: Re: Physically-Based Rendering Builds
Post by: Shivan Hunter on April 16, 2015, 08:44:16 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 16, 2015, 08:55:09 pm
Okay I'll lower it to 0.02.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 17, 2015, 01:56:13 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Colonol Dekker on April 17, 2015, 02:49:29 am
Sweet galloping gypsies. This made my eyes bleed as I beheld the awesomeness of the render Gods.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 17, 2015, 02:53:50 am
Sweet galloping gypsies. This made my eyes bleed as I beheld the awesomeness of the render Gods.

 :lol: :lol: :lol: :lol:
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on April 18, 2015, 06:57:20 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 18, 2015, 07:06:34 pm
what's your system specs?
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on April 18, 2015, 07:14:37 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 18, 2015, 07:27:57 pm
Turn off shadows and see how that runs. Then turn off deferred lighting if that doesn't work.
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on April 18, 2015, 07:41:36 pm
I already had shadows and deferred lighting, as well as sunshafts turned off. Speaking of which, have those features been optimized yet?
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 18, 2015, 07:51:20 pm
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
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on April 18, 2015, 10:09:50 pm
Using the FSPort mission "Eve of Destruction" and playing on AdmiralRalwood's April 8 builds, with the FSPort 3.5 MediaVPs 2014:
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on April 19, 2015, 01:28:02 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on May 06, 2015, 02:02:27 pm
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]
Title: Re: Physically-Based Rendering Builds
Post by: Zacam on June 08, 2015, 12:42:11 am
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).
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on June 22, 2015, 01:24:59 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on July 08, 2015, 11:06:08 am
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)?
Title: Re: Physically-Based Rendering Builds
Post by: z64555 on July 10, 2015, 10:43:09 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: ngld on July 11, 2015, 04:03:00 am
Hmmm, yt doesn't work on this one.


FTFY
Title: Re: Physically-Based Rendering Builds
Post by: z64555 on July 11, 2015, 07:42:52 am
Hmmm, yt doesn't work on this one.

[snip]

FTFY

oh, thats how it works, thx
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on July 11, 2015, 10:05:31 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Echelon9 on July 11, 2015, 11:59:18 pm
... 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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on October 28, 2015, 10:56:42 pm
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.


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
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on October 29, 2015, 03:38:55 am
  • 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?
Title: Re: Physically-Based Rendering Builds
Post by: The E on October 29, 2015, 03:42:29 am
Yeah, now all that's needed is support for a -ao map.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on October 29, 2015, 04:10:36 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on October 29, 2015, 04:24:40 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on October 29, 2015, 04:28:05 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on October 29, 2015, 04:32:36 am
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)
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on October 29, 2015, 04:36:41 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on October 29, 2015, 12:07:32 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: mjn.mixael on October 29, 2015, 12:31:17 pm
Man... I'm going to have a lot to learn when this is complete in regards to creating textures.
Title: Re: Physically-Based Rendering Builds
Post by: The E on October 29, 2015, 02:01:48 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on October 29, 2015, 02:42:44 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on October 31, 2015, 12:21:55 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: mjn.mixael on October 31, 2015, 04:39:00 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on November 03, 2015, 03:01:41 pm
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
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on November 03, 2015, 04:42:47 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: mjn.mixael on November 03, 2015, 05:23:38 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on November 03, 2015, 05:35:45 pm
I have a selfish concern: due to some input bug I have to use antipodes builds. How easily can PBR be merged into those?
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on November 03, 2015, 05:40:06 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: mjn.mixael on November 03, 2015, 06:19:39 pm
Once things start to move along, I'll make a comprehensive guide specifically for FSO use.

:yes: Much appreciated
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 10, 2015, 10:31:48 am
And what about height/parallax occlusion/displacement maps? What does have to do with physically-based rendering?
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on November 10, 2015, 11:07:06 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: chief1983 on November 10, 2015, 12:01:03 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 10, 2015, 12:29:37 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 11, 2015, 10:36:15 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on November 11, 2015, 11:23:13 am
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).
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on November 11, 2015, 12:46:08 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on November 11, 2015, 02:03:05 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 15, 2015, 12:38:58 pm
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?
Title: Re: Physically-Based Rendering Builds
Post by: The E on November 15, 2015, 12:53:52 pm
You cannot get PBR without also getting deferred lighting and shadows.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 15, 2015, 08:36:37 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Kobrar44 on November 15, 2015, 09:38:25 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 15, 2015, 09:44:45 pm
I see. Thanks for the head's up, Kobrar44.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 17, 2015, 01:29:35 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on November 17, 2015, 01:58:00 pm
I'm already aware of the issue.

And you reported it on the Git repo I'm no longer using.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 19, 2015, 11:13:29 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: chief1983 on November 19, 2015, 11:21:58 am
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?
Title: Re: Physically-Based Rendering Builds
Post by: The E on November 19, 2015, 11:27:10 am
Indeed. It's a question of what kind of look you wish to achieve, whether you're going for something filmic or something naturalistic.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 19, 2015, 11:35:46 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on November 19, 2015, 02:55:17 pm
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...?
Title: Re: Physically-Based Rendering Builds
Post by: FrikgFeek on November 19, 2015, 05:06:11 pm
We totally have lens flares as a post-processing effect atm.

(http://i64.tinypic.com/6dznme.jpg)
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on November 19, 2015, 06:22:04 pm
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. ¯\_(ツ)_/¯
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 23, 2015, 08:35:18 am
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?
Title: Re: Physically-Based Rendering Builds
Post by: The E on November 23, 2015, 09:21:26 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on November 30, 2015, 10:34:37 pm
Swifty, how is going on your PBR builds? Any progress on solving the glowmap applied to models for weird reason problem?
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on December 19, 2015, 11:09:58 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on December 19, 2015, 11:27:02 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on December 19, 2015, 11:28:01 pm
Yeah, team glow maps have nothing (or very little, anyway) to do with PBR.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on January 16, 2016, 09:54:19 pm
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))
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on January 17, 2016, 03:07:40 am
so, can i use traditional black and white ao maps too? will it automatically use the single channel for both?
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on January 17, 2016, 03:31:55 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on January 17, 2016, 03:42:40 am
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?
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on January 17, 2016, 04:16:11 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: FrikgFeek on January 17, 2016, 04:49:16 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on January 17, 2016, 05:43:00 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on January 17, 2016, 10:46:30 am
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
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on January 17, 2016, 02:53:24 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on January 18, 2016, 12:35:07 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on January 18, 2016, 02:17:24 am
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
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on January 19, 2016, 03:00:16 am
I second it, fightermedic.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on January 29, 2016, 12:04:58 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on January 29, 2016, 12:51:27 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on January 29, 2016, 01:17:48 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on January 29, 2016, 01:36:51 pm
If modellers can't make good use of PBR without expensive proprietary software I think that's seriously at odds with FSO's ethos.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on January 29, 2016, 06:22:29 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on January 31, 2016, 07:57:53 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 01, 2016, 12:28:28 am
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.

Code: [Select]
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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 01, 2016, 01:49:50 am
Okay, Mr "Visionary Coder", please tell us how we're supposed to prevent driver errors.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 01, 2016, 02:12:53 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on February 01, 2016, 04:50:30 am
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?
Title: Re: Physically-Based Rendering Builds
Post by: Phantom Hoover on February 01, 2016, 05:27:36 am
you most make an update
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 01, 2016, 06:45:52 am
AdmiralRalwood, are you referring to Swifty or me?
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 01, 2016, 07:05:02 am
He's referring to you.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 01, 2016, 10:24:23 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on February 01, 2016, 11:14:14 pm
...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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 02, 2016, 01:10:39 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 02, 2016, 06:31:16 am
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]
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on February 12, 2016, 07:32:43 pm
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
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 12, 2016, 07:44:38 pm
Wow. Trying on it now.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on February 15, 2016, 08:19:35 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Axem on February 15, 2016, 08:53:42 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on February 15, 2016, 11:55:47 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 16, 2016, 01:48:37 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Axem on February 16, 2016, 07:03:53 pm
The latest fixes fixes the hud and the subtitle fades, but this (http://ibin.co/2X7OZR9UNTm7) still happens. :(
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 17, 2016, 05:40:40 am
Per Axem, I've been encountering more or less the same issues.
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on February 17, 2016, 07:26:07 pm
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. :(
Title: Re: Physically-Based Rendering Builds
Post by: Axem on February 17, 2016, 08:37:26 pm
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. :)
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on February 18, 2016, 10:44:44 am
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...
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on February 18, 2016, 12:29:34 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: chief1983 on February 18, 2016, 12:33:04 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 18, 2016, 12:44:01 pm
It seems to me that the bloom scale has somewhat changed. Setting smaller values there is probably a good idea.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on February 18, 2016, 12:58:35 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on February 18, 2016, 02:10:34 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: chief1983 on February 18, 2016, 02:12:46 pm
Aren't bloom and FXAA post-proc features?
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on February 18, 2016, 02:28:22 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Talon 1024 on February 18, 2016, 03:01:51 pm
Here's a screenshot, without post-processing, from a newer PBR build (commit 3849be2).

(http://www.ciinet.org/kevin/myimages/WCAG/PBRnoPP2.png)
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on February 18, 2016, 03:13:48 pm
So, is the picture still unsatisfactory? Do you still have problems with the render?
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 19, 2016, 06:01:52 am
The problem is the PBR renderer itself. It doesn't work well with post-processing, even if it's optimized.
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 19, 2016, 06:25:41 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on February 19, 2016, 06:58:37 am
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
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 19, 2016, 07:09:30 am
Can you redo that test with the current builds?
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on February 19, 2016, 07:43:00 am
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
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on February 19, 2016, 11:18:15 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 22, 2016, 09:48:43 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 22, 2016, 09:53:39 am

And, as for EXT_FRAMEBUFFER_OBJECT, you should check this.

Why? What for?
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on February 25, 2016, 07:14:51 am
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
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on February 25, 2016, 09:28:57 am
The minimum is, IIRC, capped at 0.02, which should be pretty darn hard to see; can you take a screenshot of that problem?
Title: Re: Physically-Based Rendering Builds
Post by: fightermedic on February 25, 2016, 10:02:07 am
i did, they are linked a few posts above
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on February 25, 2016, 11:47:06 am
- 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.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on February 25, 2016, 03:42:24 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on February 25, 2016, 04:32:23 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on February 28, 2016, 10:42:59 am

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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on February 28, 2016, 03:08:56 pm
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".
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on March 05, 2016, 05:49:51 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on March 05, 2016, 11:17:09 pm
Is this the first set of PBR assets done since the new texture types were added?
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on March 06, 2016, 02:06:32 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Skarab on March 06, 2016, 11:03:50 pm
Looking awesome... nice pick using one of the best looking models in the game to do this.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on March 08, 2016, 04:49:22 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: niffiwan on March 08, 2016, 04:51:38 pm
niiiiice, this should be reposted to Celebration of Freespace :)
Title: Re: Physically-Based Rendering Builds
Post by: Kobrar44 on March 09, 2016, 06:27:16 am
Soooo pretty, and only 50$!
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on March 10, 2016, 02:28:18 am
That's looking real good.
Title: Re: Physically-Based Rendering Builds
Post by: Cobra on March 11, 2016, 05:12:45 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Solatar on March 12, 2016, 06:17:07 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: niffiwan on March 12, 2016, 07:04:33 pm
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)
Title: Re: Physically-Based Rendering Builds
Post by: Solatar on March 12, 2016, 07:45:27 pm
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!
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on April 30, 2016, 12:53:58 pm
Has the PBR merged into the nightly builds already?
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on April 30, 2016, 02:18:47 pm
No it hasn't.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on April 30, 2016, 02:32:39 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on May 01, 2016, 12:52:28 am
And what of Vulkan API support?
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on May 01, 2016, 02:03:47 am
And what of Vulkan API support?
Nobody's written it yet.
Title: Re: Physically-Based Rendering Builds
Post by: Swifty on May 01, 2016, 02:30:52 am
We're in no position to even consider Vulkan right now when we don't even have OpenGL Core working.
Title: Re: Physically-Based Rendering Builds
Post by: manwiththemachinegun on June 03, 2016, 09:12:07 pm
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?
Title: Re: Physically-Based Rendering Builds
Post by: niffiwan on June 03, 2016, 09:21:01 pm
It's a separate build of FSO. Download it from the 1st post, and run it like any other build.
Title: Re: Physically-Based Rendering Builds
Post by: Mito [PL] on June 24, 2016, 02:06:09 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: DahBlount on June 24, 2016, 06:11:40 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: Mito [PL] on June 25, 2016, 01:44:28 am
Alright, I've miraculously found myself an old build based on 3.7.1 somewhere on my HDD... problem solved.
Title: Re: Physically-Based Rendering Builds
Post by: AdmiralRalwood on July 06, 2016, 07:05:03 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: X3N0-Life-Form on July 06, 2016, 08:15:28 am
Exciting times :)
Title: Re: Physically-Based Rendering Builds
Post by: Bryan See on July 24, 2016, 05:34:11 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: The E on July 24, 2016, 06:29:02 am
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.
Title: Re: Physically-Based Rendering Builds
Post by: Luis Dias on July 25, 2016, 06:17:21 am
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!
Title: Re: Physically-Based Rendering Builds
Post by: The E on July 25, 2016, 06:23:49 am
Excited for the lens flares thing though! Can't wait to make a JJ Mod of Freespace2!

the branch is named "jjabrams" :P
Title: Re: Physically-Based Rendering Builds
Post by: mjn.mixael on July 25, 2016, 12:39:44 pm
IIRC, JJAbrams was the excuse people used a while back for not adding any lens flare features...
Title: Re: Physically-Based Rendering Builds
Post by: The E on July 25, 2016, 02:34:53 pm
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.
Title: Re: Physically-Based Rendering Builds
Post by: mjn.mixael on July 25, 2016, 04:32:01 pm
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*
Title: Re: Physically-Based Rendering Builds
Post by: Mongoose on July 25, 2016, 05:24:08 pm
Motion blur will never happen
Awww :(
Title: Re: Physically-Based Rendering Builds
Post by: Luis Dias on July 25, 2016, 05:27:39 pm
And no mention of Geomod whatsoever in this thread.

What has HLP come down to?
Title: Re: Physically-Based Rendering Builds
Post by: Spoon on July 25, 2016, 09:40:45 pm
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.