2026-04-26T01:25:36  <OpenMW-bridge> <anyoldname3> We don't have infinite CI time, and even when we did, some people weren't happy about semi-redundant stuff, so for the subset of stuff that we know can't only break on one platform at once so only needs testing on one platform, I think the preference would be to not redundantly test it. There would be things that would benefit from integration testing on multiple platforms, though.
2026-04-26T01:32:28  <OpenMW-bridge> <exalted_sun> I guess I'm thinking we may benefit from running r something that merely verifies that openmw launches on all platforms when building for them—not necessarily a separate step. Like the vcpkg stuff probably doesn't need an integration test (?), but rather needs a pulse check. Mac would benefit from that too. Like otherwise stuff that is only known to break on launch wouldn't be detected. But maybe the build
2026-04-26T01:32:29  <OpenMW-bridge> scripts can include the pulse check after building rather than having a discrete step. Hmmmmm.
2026-04-26T01:33:15  <OpenMW-bridge> <exalted_sun> Like we don't want to ship stuff that immediately crashes due to...whatever. But probably unavoidable to check for all cases so IDK
2026-04-26T12:47:21  <OpenMW-bridge> <the_korben> hi, just quickly wanted to introduce myself here. I raised an issue last week and found and tested a fix and created a merge request (https://gitlab.com/OpenMW/openmw/-/merge_requests/5298). I work as a dev IRL but I'm new to non-self-hosted GitLab and so a bit confused about all these compute limits I seem to run into. Couldn't even CI the fix in my fork because of this. Just wanted to say I hope this is not causing
2026-04-26T12:47:22  <OpenMW-bridge> any trouble with the official repo and I didn't waste anyone's compute time or something. thanks 🙂
2026-04-26T12:54:58  <OpenMW-bridge> <jvoisin> you're not causing any troubles, it's an unfortunately known issue
2026-04-26T12:55:59  <OpenMW-bridge> <jvoisin> thank you for your MR by the way, it's always nice to see people taking enough of an interest in OpenMW to contribute to it!
2026-04-26T13:04:36  <OpenMW-bridge> <valoun_unrealboy> oh fk, you don't use depth prepass.. I thought you are, I need to follow MR space more..
2026-04-26T13:09:56  <OpenMW-bridge> <the_korben> thanks for your reply. and thank you very much for the nice words. yeah, was a ton of fun to figure this out looking at SDL and MyGUI code and so on. I don't take a full sudden shutdown of my system lightly and wanted to find out why it happened 😄 also thanks for your comment on the MR, I just replied.
2026-04-26T13:16:33  <OpenMW-bridge> <Good Eye> huh?
2026-04-26T13:22:04  <OpenMW-bridge> <valoun_unrealboy> I was implementing something and it uses depth prepass because I knew someone is working on clustered implementation.. I made my own prepass so I could continue that work in the meantime but I was thinking it's gonna be there in openmw eventually and now I read your MR and you don't even use the prepass.. tldr -> I am wasting my time even more than usually 😄
2026-04-26T13:35:34  <OpenMW-bridge> <Good Eye> what do you need it for
2026-04-26T13:56:22  <OpenMW-bridge> <jvoisin> you can also take the timeout as an affront to everything that is just and beautiful, and send MR to reduce the build times :>
2026-04-26T14:01:33  <OpenMW-bridge> <anyoldname3> We don't even run the regular tests on all platforms yet, so the integration tests are a distant dream.
2026-04-26T14:05:24  <OpenMW-bridge> <maxyari> Allow me to be annoying a lil
2026-04-26T14:06:30  <OpenMW-bridge> <maxyari> Any news on bone transform getter lua api?
2026-04-26T14:09:44  <OpenMW-bridge> <Capo> No
2026-04-26T18:58:00  <OpenMW-bridge> <exalted_sun> Another CI related question:  we use the build stage for things that include usable packages and not. Should we make a new stage called 'release' (or deploy, or whatever, it doesn't matter to me) and pull out windows, mac, and the future linux tarball™ into it? It seems more sensible to split stages. So the jobs that actually deliver something run last after everything else.
2026-04-26T18:58:26  <OpenMW-bridge> <exalted_sun> so you have a stage that is basically 'build deliverable packages' versus...building for other purposes (i.e. tests, coverage)
2026-04-26T18:59:27  <OpenMW-bridge> <exalted_sun> I'm envisioning this would be easier on random people testing MRs to be able to easily know which job to choose to download artifacts from to get a build
2026-04-26T19:03:01  <OpenMW-bridge> <assumeru> I guess if you can set that up so they still start running at the same time they do now, reorganizing for the sake of clarity makes sense
2026-04-26T19:03:52  <OpenMW-bridge> <exalted_sun> hmm, yeah, that doesn't seem possible with gitlab, they run sequentially
2026-04-26T19:04:12  <OpenMW-bridge> <exalted_sun> but wouldn't that be desirable so we are only burning windows/mac time if the test builds and such pass?
2026-04-26T19:05:00  <OpenMW-bridge> <exalted_sun> I guess hmm
2026-04-26T19:06:05  <OpenMW-bridge> <exalted_sun> like most of the build stuff that isn't windows/mac is like...coverity and linux stuff. What is the point of the linux builds if they aren't delivering builds that can be run? Are they really 'checks' or 'test' stage??
2026-04-26T19:06:05  <OpenMW-bridge> <assumeru> You generally want to know if things compile everywhere. And the Windows builds already take forever so waiting longer to find out something is broken doesn't seem appealing 😛
2026-04-26T19:06:14  <OpenMW-bridge> <exalted_sun> true
2026-04-26T19:06:35  <OpenMW-bridge> <johnnyhostile> You can definitely run jobs in parallel, unless I'm misunderstanding what you're saying
2026-04-26T19:07:05  <OpenMW-bridge> <exalted_sun> https://docs.gitlab.com/ci/yaml/#stages
2026-04-26T19:07:05  <OpenMW-bridge> <exalted_sun> I'm talking about stage grouping in gitlab CI
2026-04-26T19:08:44  <OpenMW-bridge> <johnnyhostile> Oh yeah, stages by definition are essentially sequential
2026-04-26T19:08:59  <OpenMW-bridge> <assumeru> I generally open MRs when the Clang and GCC builds succeed without waiting for the Windows build. I figure for people not compiling Windows locally, doing the reverse makes more sense
2026-04-26T19:20:10  <OpenMW-bridge> <abdu7944> @liammellofarley Thanks for the showcase, that was nice getting it cleared up.
2026-04-26T19:20:45  <OpenMW-bridge> <abdu7944> I can recommend it for my laptop using friends
2026-04-26T19:21:35  <OpenMW-bridge> <liammellofarley> Sweet, I'm gonna keep testing it and try for my own tests to add all the buffers needed for temporal FSR3 if I can, so I can eventually report back on how messy that is and how much better it looks.
2026-04-26T20:40:28  <OpenMW-bridge> <cykboy> its been rebased by a couple of people over a long period of time so wouldnt surprise me if there was issues from that. hopefully wont be too difficult to resolve
2026-04-26T21:48:27  <OpenMW-bridge> <abdu7944> Have you found the reason for the janky collision regression where you get stuck to silly things like in Vanilla
2026-04-26T21:49:44  <OpenMW-bridge> <abdu7944> It used to not happen even in earlier iterations.
2026-04-26T22:00:26  <OpenMW-bridge> <cykboy> i havent but ive narrowed it down to the jolt update branch i think, ill add that to my todo list to investigate further
2026-04-26T22:44:32  <OpenMW-bridge> <cmaugust> Isn't vtastek doing depth prepass in mgexe to get AO working flawlessly with blended materials?
2026-04-26T22:44:58  <OpenMW-bridge> <cmaugust> I get the feeling it's useful for lots of things.
2026-04-26T22:49:45  <OpenMW-bridge> <Good Eye> IDK I don't think it's worth the cost
2026-04-26T22:50:46  <OpenMW-bridge> <Good Eye> Maybe if PBR shaders end up making the object shaders super expensive it would even out, but I don't think even wareyas PBR shaders come close to justifying it.
2026-04-26T22:55:50  <OpenMW-bridge> <Good Eye> With bindless depth prepass should be dirt cheap (even more so if MSOC gets attention), but we're far from that. It wouldn't hurt to have an option for it, but it would effectively be useless unless we shipped it with a feature (like AO) and basically be a button you click which made your fps go down :todd:
2026-04-26T22:59:56  <OpenMW-bridge> <cmaugust> So it becomes properly viable after bindless, noted
2026-04-26T23:00:25  <OpenMW-bridge> <cmaugust> Though I suppose vtastek will be getting an idea of the performance cost himself right now
2026-04-26T23:01:09  <OpenMW-bridge> <Good Eye> I already did it in OpenMW, it was just one scene but it was an extra ms or two..which makes sense. Look at cost of shadow maps, for example
2026-04-26T23:12:19  <OpenMW-bridge> <Good Eye> AON3 gave something to try which requires no additional pass, but I simply never got around to testing it. It's the thing where you output the AO contribution in a separate render target, and then in post you do scene - scene_ao * caluclated_ao (or something like that). @liammellofarley I dunno if you know anything about this
2026-04-26T23:13:20  <OpenMW-bridge> <Good Eye> But that would not fix the problem with blended things.
2026-04-26T23:17:52  <OpenMW-bridge> <anyoldname3> Combined with doing AO between the opaque and translucent passes, it would, but then we hit all the MSAA issues.
2026-04-26T23:26:30  <OpenMW-bridge> <cmaugust> Does the prepass avoid those MSAA issues?
2026-04-26T23:28:32  <OpenMW-bridge> <cmaugust> Personally I would give up a ms or two if it meant the post process AO, sky and fog (which apparently everyone uses) is no longer broke as hell.
2026-04-26T23:34:02  <OpenMW-bridge> <Good Eye> Again, this only helps with AO. Sky and fog have their own issues.
2026-04-26T23:37:17  <OpenMW-bridge> <cmaugust> Really, even the prepass?
2026-04-26T23:37:41  <OpenMW-bridge> <Good Eye> Alpha-blended things still have to be shaded 🙂
2026-04-26T23:40:16  <OpenMW-bridge> <cmaugust> Oh well, I return to my usual position that these things like sky, fog and AO should be forward pass solutions instead of post process whuch have fundamental issues.
2026-04-26T23:43:36  <OpenMW-bridge> <Good Eye> You can already port that fog and see how expensive it is, it doesn't rely on any depth information other then itself
2026-04-26T23:44:17  <OpenMW-bridge> <Good Eye> And skys already use shaders, so there's nothing stopping anyone really.
2026-04-26T23:45:09  <OpenMW-bridge> <cmaugust> Which fog to be ported do you mean?
2026-04-26T23:45:19  <OpenMW-bridge> <Good Eye> The one you're having trouble with
2026-04-26T23:45:53  <OpenMW-bridge> <cmaugust> Oh, it can be put in forward pass almost as-is?
2026-04-26T23:46:23  <OpenMW-bridge> <Good Eye> yes
2026-04-26T23:47:01  <OpenMW-bridge> <Good Eye> but I haven't tried cause rafaels version is 2500 lines and I can't be bothered
2026-04-26T23:48:39  <OpenMW-bridge> <abdu7944> I still don't see any problem with that.
2026-04-26T23:49:30  <OpenMW-bridge> <abdu7944> AO is weird almost all the time then its not weird with that.
2026-04-26T23:52:30  <OpenMW-bridge> <abdu7944> I hope whatever volumetric clouds implementation someone might add would be the one from Rising World.
2026-04-26T23:52:46  <OpenMW-bridge> <abdu7944> Its almost cost free, on my PC at least.
2026-04-26T23:53:17  <OpenMW-bridge> <abdu7944> And looks very convincing.
2026-04-26T23:55:51  <OpenMW-bridge> <cmaugust> Right now the issue for OpenMW users is you either use the post process fog which cause issues or you're stuck with fixed function fog from 2002.
2026-04-26T23:58:18  <OpenMW-bridge> <liammellofarley> I'm a little confused about the ambient contribution thing. What does that change/solve? Does it just mean areas with post AO can have their specular and stuff overridden to get a slightly cleaner look than just darkening? If so I can definitely implement it, that seems ideal for my test fork because it would let me kill PBR specular and stuff in screenspace shadows and for AO.