Plans for Barrage

[STIXTheMachine]

Okay - now that we've got the monorepo fixed up, I'd like to discuss some of my plans for what I'd like to contribute. I'm specifically focused on Barrage since that is the portion that provides the most tangible benefit to CoS - having support for full sim/render decoupling via Artillery would be neat, but at this moment is kind of overkill.

The first few things I'd like to try and get working are:

1. Constraint support

• This is 1000% a must have for CoS, and Jolt's numerous and extensible constraint system is the primary reason I am interested in it. Jake and I had a brief chat on how this might work via LinkedIn, but I'll likely have a few questions when I actually start work on this.

2. Make Barrage self-contained

• Barrage (+ SkeletonKey) can be used without the rest of the Artillery ecosystem; I think it would be quite nice to set it up in such a way that it can be a more-or-less drop in replacement for Chaos. The easier it is for someone to pick up and use Barrage, the more likely we are to see people use it and potentially contribute back to it, which is a direct benefit for us. As far as I can tell this would involve:
  • Providing a default executor
  • Detecting the presence (or lack thereof) of Artillery and using either the Artillery executor or the default one
  • Automatically shutting off Chaos
  • (Eventually) wrapping functionality such as constraints into convenient components, providing a familiar-looking API for physics queries such as sweeps/casts/overlaps

I'd likely start with #2 just while I find my feet and get more familiar with the code base, but I can't leave #1 on the table for too long either.

Thoughts?

[JKurzer]

That sounds fabulous! I'm gonna recommend you take Locomo as well. We use Locomo for a lot of datastructure dependency management, along with skeleton key, and as we find parts of artillery you'd end up reproducing, we can defactor as much as possible into Locomo or SK depending on fit.

I have one more big barrage feature planned, and that should be up soon, but it doesn't cause any API changes. It's a new broadphase option. We also have some fast filters that @hasenbas just finished which you will 100% want.

The executor is an interesting one — let's talk specifically about that when you're ready!

[STIXTheMachine]

The executor was probably where I was going to start. I'm going to need to write one anyway if I'm going to use Barrage by itself so to me it just makes sense to do that first. Happy to hear how you think I should approach it.

[JKurzer]

I think that factoring most of the existing executor into a base class makes a ton of sense. That doesn't make a TON of sense to live in barrage, but it's not stupid to put it their either.

…

On Fri, May 23, 2025, 5:08 PM Jake S ***@***.***> wrote: The executor was probably where I was going to start. I'm going to need to write one anyway if I'm going to use Barrage by itself so to me it just makes sense to do that first. Happy to hear how you think I should approach it. — Reply to this email directly, view it on GitHub <#5 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3D7BYIRHZ2C4G5UDQKMTD276E4VAVCNFSM6AAAAAB5RATXHKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMRVGEYTSMA> . You are receiving this because you commented.Message ID: <OversizedSunCoreDev/ArtilleryEco/repo-discussions/5/comments/13251190@ github.com>

[STIXTheMachine]

How would you feel about factoring it out into its own little plugin that both Barrage and Artillery can depend on? That feels slightly overkill to me but it could work.

Personally I do think it makes a decent amount of sense to have it in Barrage in order to make Barrage function as its own entity that Artillery augments the functionality of - but I'm open to all approaches.

[JKurzer]

Let me know if you wanna sit down and chat about this. my discord handle is jpcrc :)

[JKurzer]

Actually, I think factoring the threading machinery into a plugin makes sense. All the threads share a ton with each other, including the cabling thread. Right now, there's no good way to express that.

…

On Fri, May 23, 2025, 8:35 PM Jake S ***@***.***> wrote: How would you feel about factoring it out into its own little plugin that both Barrage and Artillery can depend on? That feels slightly overkill to me but it could work. Personally I do think it makes a decent amount of sense to have it in Barrage in order to make Barrage function as its own entity that Artillery augments the functionality of - but I'm open to all approaches. — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3D7B3K2IRTZV2KH7QIILD2765D5AVCNFSM6AAAAAB5RATXHKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMRVGI4TIOA> . You are receiving this because you commented.Message ID: <OversizedSunCoreDev/ArtilleryEco/repo-discussions/5/comments/13252948@ github.com>

[JKurzer]

Almost done with some major work on the physics system.

[STIXTheMachine]

Awesome! I'd love to hear about what you've done. I've been wanting to work on this but I've been helping my mother move for the past week.

For moving the threading into its own plugin - would you want to move ALL of the threading stuff into its own plugin? Executor, ticklites etc? Essentially isolating the sim/render decoupling into a plugin like we discussed previously. Or would you go for something a bit less complicated?

[JKurzer]

Hey dude! I pushed up a very early preview of what I'm working on at the moment. You can find the broad strokes of it in Embedder and HungryBroadphase. I haven't tested it out much at all yet, just enough to make sure the memory architecture broadly works. It's a spatial hashing approach to the broadphase problem, built on a bunch of different research papers. You'll find my citations dotted through the new code as well as my explanations of what it does.

This is still a couple weeks from even being usable, I think, at my current rate of progress, but if you have thoughts or insights, let me know. Beyond the general design being previewable, we've added two big new things in this update. One is a huge expansion of the tools and tricks available in Locomo. The other is a formalization of the concept of an intra-tick shadow copy as well as a model of a suggested lifecycle for that and an allocator model to go with it. This allocator is kinda sketchy right now, but it is extremely fast. Effectively, it allocates an arena style region but then uses it as a pool for TLSF. This isn't threadsafe, but we have a lot of data that's written once per tick then read repeatedly and eventually destroyed and regenerated rather than ever being modified. Historically, we've called these shadow copies, and we'll be sticking with that language.

Why do we use shadow copies? Well, there are five truly expensive things you can do in a modern computer. In order of severity, these are: Hit disk, wait on IO, hit a lock, hit a page fault, or miss cache. You'll notice that no computational operations are present, and in fact, that allocating and making copies really isn't on the list either. As a result, it is often MUCH more efficient to simply make copies rather than negotiate locking. This is exacerbated when thread contention is very high or for resources that would otherwise be the recipients of random writes from multiple threads.

It has two other major advantages. It is tremendously easier to reason about....
... and in many cases, it is asymptotically more performant. For anything more complex than trivially copiable data structures, destructors can actually be a quite serious performance hurdle, combined with memory fragmentation, in part because they often do not profile easily and can happen at irregular intervals. Worse, the actual cost of free list compaction can be incurred much later than the free.

Historically, arenas and pools offer a solution to this, but assessing WHEN to free a region or destroy a pool is non-trivial. By using an arena region to hold a memory pool and then reusing those arenas, we can simply memset them. This is a variation on a very old trick, but with the addition of the use of shadowcopying, it eliminates entire order n and order n*m operations. Don't free it. Just blast it.

---

Re: would you want to move ALL of the threading stuff into its own plugin? Executor, ticklites etc?
You will need at least the executor timing infra structure. Ticklites offer a lot of advantages but if you're doing interpolation rather than rollback, much of this stuff isn't actually necessary for you. So if you take a look at the cabling runner and the artillery runner, they share most of their actual timing architecture and even a lot of their programming paradigm. It seems like we could probably get this down to three concepts:

Executor: controls timing, wakes executor helpers, can bind executor workloads, provides a definition for shadow now.
Executor Helper: consumes shadow now definitions, can bind executor workloads, separates calculate from apply
Executor Bindable: run by an executor. either separates calculate from apply or generates queued changes.

most of that's already done, it just needs to be regularized and factored out. we're weakly rigorous about refactoring praxis: specifically, we expect no functional change to arise from a refactor and if your refactor get "large" we ask that it be broken into multiple passes.