[Swifty]

Yes, I'm aware that even a specular power of 2048 will still blur a cube map. However, I doubt we need specular power greater than 2048. Gloss is only 8-bits in the reflectance map which means 2^(n*gloss + 1) will start getting a lot of quantization if n is too high.

If artists want to prefilter the the MIPs of their cube maps, they're more than welcome. I tried to make PBR easier to adopt by automatically generating the MIP maps albeit it's done using downsampling. It's of course not 100% accurate but the results seem good enough for people to at least start iterating with it.

Most game engines tend to fudge the cube map filtering anyway. Very rarely is cube map matching done with 100% accuracy and most of the discretion is left to the artists how they prefilter the cube map.

Ideally I'll look into prefiltering cube maps in engine using importance sampling (which doesn't take as long as the brute force method in cube map gen), but it's not a high priority as other things.

[Scooby_Doo]

Excellent! Since I'm doing work in Unreal 4, the material conversion to FS2 should be much easier.

[Nemesis6]

Just a slight bug I noticed -- In the target view, ships that have reflection maps will appear completely black. Ships without them will look normal.

[Echelon9]

Just a slight bug I noticed -- In the target view, ships that have reflection maps will appear completely black. Ships without them will look normal.

Do you mind registering this as an issue on the project's GitHub Issues tracker (https://github.com/scp-fs2open/fs2open.github.com/issues), including details of your graphics card and OS. Swifty or one of us will take a look at it reasonably soon I'm sure. Thanks for the bug report.

[AdmiralRalwood]

It's a known problem, actually; the target box doesn't do any lighting. It also shouldn't go on the main FSO repo's issue tracker when it's a problem with a fork's branch that hasn't had a pull request issued for merging it with master.

[Echelon9]

Fair enough.

[Bryan See]

Excuse me, Swifty. What about ambient occlusion? Do you have plans to integrate some modern form of dynamic screen-space ambient occlusion shading into the physically-based rendering pipeline? I hope this frees modelers such as myself from the burden of baking AO maps and mixing them to diffuse maps, thus saving model-making time.

Depending on what type of shaders you'll implement in the near future, ambient occlusion maps are either generated by the engine on the fly or perhaps a new texture format, which involves the appending of "-ambient" to the filenames of texture images.

[The E]

Excuse me, Swifty. What about ambient occlusion? Do you have plans to integrate some modern form of dynamic screen-space ambient occlusion shading into the physically-based rendering pipeline? I hope this frees modelers such as myself from the burden of baking AO maps and mixing them to diffuse maps, thus saving model-making time.

Depending on what type of shaders you'll implement in the near future, ambient occlusion maps are either generated by the engine on the fly or perhaps a new texture format, which involves the appending of "-ambient" to the filenames of texture images.

There are no plans to implement screen-space AO. What's probably going to happen is that we're going to add support for ambient occlusion maps similar to the way glow and normal maps are handled.

[Bryan See]

There are no plans to implement screen-space AO. What's probably going to happen is that we're going to add support for ambient occlusion maps similar to the way glow and normal maps are handled.

That's cool. I will try to find ways to implement screen-space AO while you plan to add support for ambient occlusion maps similar to the way glow and normal maps are handled. By the way, I've added you as a friend on Twitter and I hope you can follow me.

[The E]

That's cool. I will try to find ways to implement screen-space AO while you plan to add support for ambient occlusion maps similar to the way glow and normal maps are handled. By the way, I've added you as a friend on Twitter and I hope you can follow me.

Screen space AO is a bad fit for FreeSpace.

The problem is that SSAO works best when the player camera is close to a lot of geometry, this is always the case for first- or third-person shooters for example. In these cases, you have lots of geometry that interacts dynamically, in which case the gain for visual quality makes the investment in render time worth it.
In FSO, you have a bunch of mostly static models which mostly keep their distance from each other. SSAO doesn't offer much of a benefit in these cases, AO maps provided by the artists will always be of higher quality than what a shader can provide (Not to mention that an AO map lookup is orders of magnitude faster than a shader invocation).

In short: Do not waste your time implementing SSAO.

(As for Twitter, I'm sorry, but I only follow people who I know have interesting/funny things to say on there. Since your profile is protected, I was unable to check whether my Feed would be improved by adding you to it.)

[Luis Dias]

The_E, would it be possible to integrate ambient occlusion in a manner that would allow for easy intensity tweaking in FRED?

I say this because, while I do love ambient occlusion, it's incredibly un-realistic in deep dark space, where light in any object should go from extremely lit to absolute darkness. It is far more realistic in two scenarios: nebulas and well lit skyboxes (thinking about that particular mission in AoA where you meet the Vishnans, for instance).

Now, perhaps other modders would disagree and would just love to paint their ships in their mods and campaigns with a ton of ambient occlusion to get a different aesthetic, so that's why I ask if it would be possible to have a lever to its intensity right there on FRED.


e: I'm being an idiot, am I not? The lever already exists and it's called "ambient". **** me.

[The E]

I don't see any particular difficulty in doing that. After all, it would just mean we'd have to pass another parameter into the shader; nothing really complex about it (And the move to PBR means we have to give mission designers more granular tools to affect lighting anyway)

[Luis Dias]

no no no no the lever already exists it's right there on FRED, I was being a dumbass

[attachment deleted by nobody]

[The E]

Oh, right, that one. I didn't even think of how those would interact with AO, but you're completely right.

[fightermedic]

so, there are actually plans to support AO maps? in this case i guess it is time to stop to bake AO into the diffuse

[mjn.mixael]

I'm going to miss the days of showing off in-progress model textures and having people only respond by asking where the ao bake is....

[Kolgena]

ao bake on the thick cables is too light, make it more like retail please

[Bryan See]

And what about -albedo and -ao maps?

[Scooby_Doo]

Albedo can be placed in the diffuse channel (I see no real difference game-wise)
We still need the AO map and an Emissive map.

However what we really could use is  a Metal-Roughness/Gloss-AO-Opacity merged map.  Since each of those channels are greyscale it would be more memory effective to merge all 4 into one nice little RGBA file.

[DahBlount]

We have already have AO maps which channel pack Ambient Occlusion and Cavity Occlusion. With respect to emissive, we either already have that with glow maps, or you're talking about a feature that would be very out of place performance-wise in FSO at the moment. We're most likely not going to move to a Metalness workflow as the Specular workflow is already established and changing it now would throw modders into even more of a tailspin.