[Added] Some way for sector skies to avoid being affected by SSAO

Moderator: GZDoom Developers

Re: Some way for sector skies to avoid being affected by SSA

Postby Rachael » Fri Dec 25, 2020 3:42 pm

Tormentor667 wrote:Well, I don’t want to sound like I don’t appreciate what coders are capable of (and what I am not :)). As far as I understood, the engine checks how many portals are supposed to be affected by the ambient occlusion (there is an option for that in GZDoom). So all I can imagine is telling the engine to “skip” the skybox portal (according if there is a skybox viewpoint) in case a certain flag has been set for the map in the MAPINFO lump for the specific map. No idea if that is doable though.

Theory and practice almost never align when it comes to coding - there's always hurdles you never anticipate and it's because your hand really is not held a whole lot when you are creating content with programming - so sure, it sounds simple, and sometimes it actually is - but that's actually very rare.

Sorry for the on-the-spot nature of that post, but sometimes you do need a little gentle reminder about what you actually said might not being what you meant. :)

At any rate, that same post had another implied point that was pretty easy to miss: that is the kind of thing that, if it were so simple, it would've been done already as evidenced by the very existence of this topic. We no longer have the programmer on our team who was originally responsible for SSAO in the first place. I don't really know how the SSAO thing works internally (I really only know what everyone else already knows), and every time I dive into the weeds of the engine for things like that, it's a nightmare and I get confused, so honestly I am not really too interested in diving into the engine for this one.

If someone figures it out, great, if not, sorry, that's some tough luck.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Some way for sector skies to avoid being affected by SSA

Postby Enjay » Fri Dec 25, 2020 4:28 pm

Tormentor667 wrote:The reason is: It would take ages in Blade of Agony to set up the skybox definitions and add appropriate changes to all of the 30 maps in the mod. :(

Related to the above - is there a quicker and easier way to resolve this editing-wise?

I assume that, at present, the BoA maps generally have a built skybox with a default (no ID) skybox camera that then gets shown from all sectors with F_SKY1 on the ceiling/floor.

Normally, when converting a map like that, I'd just build a new skybox which would use the MAPINFO-defined sky, give the skybox camera an ID and then search for all sectors with F_SKY1 and place a skybox picker in it. (This is one of the reasons why being able to search something (sector flats in this case) in UDB but then switch to another mode (in this case things) while keeping the search box active would be useful - but I understand that this is difficult because search is actually a "mode" in itself.)

The above easy in a small, simple map, or one that I am making from scratch. However, I agree that doing that for 30 existing maps with the levels of complexity of the BoA ones would indeed be a major pain.

So, would there be some quicker way - e.g. is it possible to allocate a different texture sky to the skybox? Perhaps line type 190 Static_Init can be used (setting the property arg to 255 and placing the name of the skybox on the upper side)? Therefore only the actual skybox sector would need to be edited to give it the texture-based sky and all other sectors could remain unchanged. Still a pain but much less of one than have to edit every single F_SKY1 sector in every map.

Some other method?
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Some way for sector skies to avoid being affected by SSA

Postby Tormentor667 » Sun Dec 27, 2020 5:08 am

Rachael wrote:Theory and practice almost never align when it comes to coding - there's always hurdles you never anticipate and it's because your hand really is not held a whole lot when you are creating content with programming - so sure, it sounds simple, and sometimes it actually is - but that's actually very rare.

Yes, I already epxected this :) Not to be disrespectful towards what programmers do - I simply don't understand what's involved mostly :)

Enjay wrote:The above easy in a small, simple map, or one that I am making from scratch. However, I agree that doing that for 30 existing maps with the levels of complexity of the BoA ones would indeed be a major pain.

Placing skybox pickers to 30 maps which in return use a countless number of F_SKY sectors is not the only problem. There are several occasions where I change the look of skybox textures by adding dynamic lights or special effects that interfer with the skybox as a sector based solution. I can't turn these into GLDEF skyboxes without losing the effects that have been added you know.

For us, the only solution is to get some kind of exception when it comes to the AO setting, everything else is not an option unfortunately :(
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: Some way for sector skies to avoid being affected by SSA

Postby Ozymandias81 » Tue Dec 29, 2020 12:40 am

Atm I tried a workaround setting gl_ssao_portals to 0 under DEFSCVAR, but I do hope one day there will be an additional skybox property which excludes AO
User avatar
Ozymandias81
Doom is a State of Mind... Out of Control.
 
Joined: 04 Jul 2013
Location: Mount Olympus, Mars
Github ID: Ozymandias81
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Some way for sector skies to avoid being affected by SSA

Postby Marisa Kirisame » Tue Dec 29, 2020 4:07 am

OK I think I have a cleaner idea on how to handle this. It was just the implementation that was too naive, but I was on the right track.
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Some way for sector skies to avoid being affected by SSA

Postby Tormentor667 » Tue Dec 29, 2020 4:42 pm

Marisa Kirisame wrote:OK I think I have a cleaner idea on how to handle this. It was just the implementation that was too naive, but I was on the right track.

So are you going to add anything that works? :)
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: Some way for sector skies to avoid being affected by SSA

Postby Marisa Kirisame » Wed Dec 30, 2020 3:03 am

The way I've approached it now is to have an "AllowSSAO" virtual on the HWPortal class, rather than shoddily use the internal GetName function to check it's a "Skybox" type.

The relevant PR is here.

PS: I have to add again one thing, and it's that I'm not a C++ programmer. My expertise lies entirely in pure C, so if I'm doing this wrong again, just tell me. C++'s shoehorned OOP is weird, seriously.
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Some way for sector skies to avoid being affected by SSA

Postby dpJudas » Wed Dec 30, 2020 3:11 am

Marisa Kirisame wrote:C++'s shoehorned OOP is weird, seriously.

Yes, it only works the same way as in any other main stream language: a virtual table as the first entry in the struct and a 'this' pointer to the struct as the implicit first parameter when calling functions. Super weird.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Some way for sector skies to avoid being affected by SSA

Postby Graf Zahl » Wed Dec 30, 2020 3:47 am

The only truly weird OOP is Objective-C because it went out of its way to do it in the most inelegant, fragile and downright dangerous way imaginable.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Some way for sector skies to avoid being affected by SSA

Postby Rachael » Wed Dec 30, 2020 4:04 am

Everything in the PR looks good to me except that I haven't ever tested it.

I have a bit of a minor concern though - disabling SSAO by default in skyboxes may impact maps that actually intend to make use of it. Though honestly I seriously doubt that's really going to cause much of a problem, even if such maps do exist. (but then I am not much of a SSAO user)
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Some way for sector skies to avoid being affected by SSA

Postby Nash » Wed Dec 30, 2020 4:31 am

In my experience, SSAO on extremely zoomed scenes (the typical kind you'd see in a skybox) don't really look that good anyway.
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Some way for sector skies to avoid being affected by SSA

Postby Marisa Kirisame » Wed Dec 30, 2020 4:46 am

I mean, if a map intends to use it, that's what the MAPINFO flag is for.

Though obviously, they'd have to update the maps to use it, so that's a problem...
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Some way for sector skies to avoid being affected by SSA

Postby Graf Zahl » Wed Dec 30, 2020 4:54 am

Most skyboxes I have seen over the years do not work with AO anyway.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Some way for sector skies to avoid being affected by SSA

Postby Nash » Wed Dec 30, 2020 4:54 am

Why not make it the other way around? Opt in. Surely Torm can spare the 2 minutes to edit BoA's MAPINFO to disable SSAO in BoA's skyboxes... ;)
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Some way for sector skies to avoid being affected by SSA

Postby Enjay » Wed Dec 30, 2020 6:08 am

About 50% of the skyboxes I have made intend to use SSAO. :P Possibly more than 50% actually. I don't think I have ever made a sky box of the type in BOA where the sides of a big box are used for placing the cube-types sides of a sky box on. I always use GLDDEFS for that and often combine the GLDEFS sky with geometry in a sky box that should have SSAO. Occasionally I make a box similar to Randi's original example with a cut-out sky texture and a scrolling flat. Sometimes they look better with SSAO and sometimes they don't. It depends what else I am doing with the box.

So, from my perspective, allowing SSAO to be on by default would be better but I'm not going to get all bent out of shape if it stays the other way around.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest