Some way for sector skies to avoid being affected by SSAO

[Rachael]

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.

[Enjay]

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 [wiki]Static_Init[/wiki] 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?

[Tormentor667]

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

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

[Ozymandias81]

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

[Marisa the Magician]

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.

[Tormentor667]

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?

[Marisa the Magician]

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.

[dpJudas]

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.

[Graf Zahl]

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.

[Rachael]

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)

[Nash]

In my experience, SSAO on extremely zoomed scenes (the typical kind you'd see in a skybox) don't really look that good anyway.

[Marisa the Magician]

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...

[Graf Zahl]

Most skyboxes I have seen over the years do not work with AO anyway.

[Nash]

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... ;)

[Enjay]

About 50% of the skyboxes I have made intend to use SSAO. 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.