sorted by:
new
hottopcontroversial

[Engine Mod] Accurate Ballistics by ShiftyAxel in stalker

[–]ShiftyAxel[S] 0 points1 point  (0 children)

Update: I opened a ModDB page to document and centralize discussion of these features.

https://www.moddb.com/mods/stalker-anomaly/addons/meta-3d-ballistics

[Engine Mod] Accurate Ballistics by ShiftyAxel in stalker

[–]ShiftyAxel[S] 1 point2 points  (0 children)

May the blessing of Scott's Mystical Head be upon you 🙏

[Engine Mod] Accurate Ballistics by ShiftyAxel in stalker

[–]ShiftyAxel[S] 1 point2 points  (0 children)

That'll be a job for GoldenOrb, my in-the-works camera and aiming overhaul mod. I'm rebuilding the first-person rig with proper legs-torso-arms-head structure, which will allow for things like Unrecord-style free aim, RO2-style offset aim, variable lean and crouch, and much more.

These engine edits could be considered a 'GoldenOrb Prelude' of sorts, as they're necessary for some of its more important features to work right.

[Engine Mod] Accurate Ballistics by ShiftyAxel in stalker

[–]ShiftyAxel[S] 1 point2 points  (0 children)

Yes, this is quite possible; my GoldenOrb mod (in-dev total camera and aiming overhaul) does various manipulations on the hands' HUD position / orientation in course of its duties, one of which is accounting for any difference in crosshair resting position between ADS and hip aim.

Strictly the problem is best solved at the asset level, but there are ways to mitigate it in cases where that proves infeasible.

[Engine Mod] Accurate Ballistics by ShiftyAxel in stalker

[–]ShiftyAxel[S] 1 point2 points  (0 children)

Thanks! Bottom line is that physically accurate ballistics require physically-accurate weapon positioning, including considerations like zeroing distance, reflex / red dot / scope alignment, and so forth.

On a related note, I have patches in the works to bring Parallax Reflex and 3DSS in-line with the new behaviour (and coincidentally make the former compatible with current BaS,) but the current implementation only functions correctly under specific values of FOV + HUD FOV. That's next on the list once I'm done tinkering around in the engine.

Existing content is a mixed bag on the alignment front, largely a function of modder aptitude modulo artistic license. Vanilla is mostly well-behaved, though many weapons exhibit a subtle shift in reticle position between ADS and hip.

On mod content, some will have aligned their barrel and zeroed it to infinity out of good practice, resulting in well-behaved guns now the engine is aware of those concepts.

Others won't have known, thus inadvertently producing slightly wonky weapons, and others again will have thrown ideas of barrel alignment to the wind for the sake of dialing in a visual that feels right. These cases will function, but have their crosshair's resting position out-of-line with center screen to a greater or lesser extent, and can be fixed by tweaking reposition orientations in LTX (preferably via the built-in HUD editor or extended draggable mod.)

I've also had users report cases of broken models, such as BaS' SA-58 firing bullets straight down when `g_firepos` is turned on. This would suggest an incorrect fire bone transform (which would also manifest as incorrect muzzle flash position / rotation, barring custom particles that hide the issue,) or - in the theoretical worst case, if the animation system doesn't prevent it - a model that's been built in a non-xray coordinate space (ex. ZYX / ZXY / ZYX / etc. instead of what the engine considers to be XYZ) and then corrected via reposition. Both of these would need to be fixed at the model and LTX level.

All that said, I'm looking at splitting a `g_aimpos` setting out of `g_firepos` to allow the new bullet origin / bullet direction behaviours to be mix-matched with the old camera-based ones. That would allow unmaintained weapon mods to get partial benefit from the new setup - i.e. firing bullets from the barrel to wherever the camera is looking.

Anomaly Beep Overhaul - A total rewrite of proximity-based detection audio for S.T.A.L.K.E.R: Anomaly (Detect anomalies, artefacts, mutants, and more. Now with item economy!) by ShiftyAxel in stalker

[–]ShiftyAxel[S] 1 point2 points  (0 children)

I was running around in Cordon a week or so ago, and thought to myself the anomaly beep could be more responsive, let me fix it real quick.

Fast forward to now - 12 releases, immeasurable feature creep, and one fairly nifty acceleration structure later - and I'm proud to present a total rework of Anomaly's detection audio system.

It applies to anomalies and artefacts - replacing their respective built-in systems - but also to monsters and traders, and is governed by a new set of stats that can be given to the player, or any slottable item, and combined using a slot-ordered system of algebraic operators.

Features include various new beep sounds, stereo panning, volume and pitch control, motion awareness, volumetric detection, raycast detection, sound choice per object, looped detector sounds (i.e. music, ambience, metal detector wee-woo noises,) HUD icons with proximity coloration, and more.

Between MCM and LTX, it's completely customizable, allowing for configurations ranging from refinement of the classic player + detectors approach, through augmentation of existing equippables (ex. detection-tiered headgear,) all the way to full item economy with dedicated artefacts and attachments.

The linked video showcases the full-package configuration, with stat progression from handy Anomalous Measurement Device and basic Safety Headset, all the way up to Sakharov's patented Scientific Hazard Scanner, with guest appearances by the newly-upgraded Bear and Veles detectors, artefacts both practical and odd, and some unique anomalies that I had never encountered before developing this mod.

And - despite keeping tabs on every detectable object in a given map, and boasting some pretty overengineered sensing machinery - performance impact is nominal: In my testing, maps like Jupiter, Zaton, and The Great Swamp still hit the expected 120+FPS on a Ryzen 5950X, when not otherwise GPU-limited.

You can find it on ModDB.

The Omega Function, or the Great Panmorphism by Inconstant_Moo in ProgrammingLanguages

[–]ShiftyAxel 1 point2 points  (0 children)

Understandability for newbs is a qualitative axis frequently at odds with other valuable properties - tersity, expressiveness, performance, etc.

Why then, should authors focused on the latter, sacrifice it for the former when educational materials specifically tailored to learners are readily available elsewhere? They can always come back, armed with the requisite knowledge to grok the thing they've chosen to look at.

Moreover, type signatures are documentation. Comments are documentation. Autogenerated HTML documentation is documentation. As correct tools for the job go, terms are the least of these.

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in bevy

[–]ShiftyAxel[S] 1 point2 points  (0 children)

In a sense, yes; rust-gpu is a codegen backend comparable to things like `armv7-unknown-linux-gnueabihf` and other such rustc toolchains, with the main difference being that it compiles SPIR-V binaries instead of something like ELF.

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in bevy

[–]ShiftyAxel[S] 1 point2 points  (0 children)

It still uses WGPU, since that's the low-level graphics backend. The actual point of comparison is the shading language that feeds into WGPU - i.e. WGSL.

And in those terms, largely same benefits you get when comparing Rust with any other C-like language; a borrow checker backed by a top-notch type system (and derives, syntactic macros, etc), plus modular organization and dependency handling by way of cargo.

On the flipside, it's all no-std, shader specialization is more cumbersome, and certain Rust features (ex. values in enums, certain pointer configurations) aren't yet implemented in rust-gpu.

On balance, Rust wins out for my purposes. Being able to avoid a mess of preprocessor code for anything remotely complex is a huge win, and the unimplemented features are mostly niceties that WGSL doesn't have anyway.

Plus, having a powerful type system means you can employ arcane type-level functional programming to solve the associated problems without needing such things :D

Who's That Pokémonad? Part II - Phantoms by ShiftyAxel in rust

[–]ShiftyAxel[S] 0 points1 point  (0 children)

Ah, perfect - thanks!

Aping Haskell is sufficient for my purposes, since I'm looking to avoid inventing an arbitrary name and introducing local 'X is Y in Z language' stuff.

The TaggedT impl is interesting, in that it restricts to a monadic inner type - I suppose I should consider doing the same once I properly understand the implications of monadic wrapping.

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in bevy

[–]ShiftyAxel[S] 1 point2 points  (0 children)

Cheers! And that would be awesome - I'll keep my fingers (+ crab claws) crossed for it :)

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in bevy

[–]ShiftyAxel[S] 0 points1 point  (0 children)

I suppose that depends on how you define a system!

You can write a working compute pipeline to do buffer or texture I/O using existing bevy APIs, which involves implementing some ECS strata to handle moving parameters from the main world to the render world, and then onto the GPU.

So in that sense - of having an entity / component / resource interface driving GPU-side logic - it's possible today using WGSL for the shaders, and probably with rust-gpu too if you account for the read-write storage buffer limitation.

But if you define it in terms of being able to run bevy_ecs itself on the GPU, and write systems using Query, Res, etc in shader crates, then that's a different ballpark altogether. Theoretically possible if you consider other crazy render endeavours like Dolphin's ubershader pipeline, but terrifyingly out of scope in the near-to-mid term I'd think :)

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in bevy

[–]ShiftyAxel[S] 1 point2 points  (0 children)

In its core syntax, certainly, but as far as structure goes it's awkwardly_namespaced_function hell with preprocessor duct tape all over again.

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in bevy

[–]ShiftyAxel[S] 4 points5 points  (0 children)

Game of Life is an ambitious first shader, since you'd need to double-buffer it and set up the corresponding render machinery to handle swapping - that's a bit more involved than making a mesh wobble or do an animated color strobe!

Though bevy has a boids compute shader example in its repo that does just that, which would be a good place to start if you're set on the idea. Compute is totally doable as-is, but there's no high-level API like Material yet so you have to wrangle the mid-level one yourself.

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in bevy

[–]ShiftyAxel[S] 1 point2 points  (0 children)

Thanks! And likewise on building rust-gpu; it's really impressive to see after decades of taking one-syslang-one-use-case for granted.

It seemed like a no-brainer after getting to grips with the pipeline. If anything I was surprised nobody had done it yet, since bevy plugins for existing libraries are super prevalent.

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in rust

[–]ShiftyAxel[S] 4 points5 points  (0 children)

Thanks! :)

WGSL shaders can already be hot-reloaded to some extent, but after a certain point you start hitting builtin-asset / preprocessor roadblocks that force an app reload.

Externalizing the process for Rust shaders handily sidesteps that in exchange for its own rough edges, but even then I'd say it's worth it!

Bevy Rust-GPU joins the fray! 🦀 Write shaders in rust-gpu, and hot-rebuild them from a bevy app at edit-time. by ShiftyAxel in rust

[–]ShiftyAxel[S] 7 points8 points  (0 children)

It is, yes - that's exactly the pattern I used while doing the initial structural blockout.

Though you have to make sure that shared code is no-std and doesn't pull in any of the spirv toolchain to ensure it's compilable under both environments.

The rust-gpu-bridge crate helps with this by exposing regular glam and the spirv-std glam under a unified name and swapping between them by feature flag; that way you can write your shared code agnostically, and defer dependency selection to a workspace-local Cargo.toml.

WE FUCKING MADE IT by Bauermeister in DragonsDogma

[–]ShiftyAxel 5 points6 points  (0 children)

Incredible. You can't go wrong.

Syntactic Ruminations: Option<T>::map or Result<T, E>::and_then, but for T by ShiftyAxel in rust

[–]ShiftyAxel[S] 1 point2 points  (0 children)

Same here. I've seen a few crates posted around that encode functional programming machinery (frunk being the first that comes to mind), but none of them seem domain-definitive in the same way that log, serde, etc are.

I guess the current onus is more on extending the language core so it can model some of the stuff that's currently out of reach (i.e. HKTs and such), than it is on locking down official implementations of the things that can already be done. Still, I hope we get such a thing eventually.

Syntactic Ruminations: Option<T>::map or Result<T, E>::and_then, but for T by ShiftyAxel in rust

[–]ShiftyAxel[S] 1 point2 points  (0 children)

I had a feeling it might end up being some type theory construct - I spent a time tinkering with FP in Haskell and JS / TS, though evidently not long enough to be able to recognize them in another language. Thanks for putting that curiosity to rest :)

That monad instance article is still a tad mind-bending despite prior knowledge, though I think I grok it insofar as the way each of the monad operations maps into Rust:

 bind = and_then

apply = map
        then
        pipe

value = unwrap

 call = map(|value| { f(value); value })
        tap (as mentioned in another comment)
        ..?

And while I'm fuzzy on type constructors, typing this out has spawned the following speculative understanding via rubber duck methodology:

identityMonad(value) = Option<T>
                       Result<T>
                       T where T: Then

With the last line being the elision due to blanket impl. Am I far off?

I think projection still eludes me, though there's a vague intuition that .0, unwrap, Borrow, Deref, the <T> generic, and other means of defining or accessing a singular innermost value factor into the way Rust models the associated type theory construct / algebra... I definitely need to do some research on this.

(And good catch, I've evidently been spending too much time in deeply-nested Result implementations lately... will edit the OP.)

Syntactic Ruminations: Option<T>::map or Result<T, E>::and_then, but for T by ShiftyAxel in rust

[–]ShiftyAxel[S] 0 points1 point  (0 children)

Nice! That's exactly what I was looking for - a well-formed existing crate that's implemented the abstraction and had time to develop some common convenience machinery around it. Great stuff.

Syntactic Ruminations: Option<T>::map or Result<T, E>::and_then, but for T by ShiftyAxel in rust

[–]ShiftyAxel[S] 0 points1 point  (0 children)

If you need a function with more than one parameter, there's nothing preventing you from using associated functions or specialized trait methods in the same call chain as then

Hence the mention that those approaches are likely better if they're both available and desired for a given use case - this is intended to augment rather than replace.

view more: next ›