rossnordby

Thanks! XNA and its descendants have definitely had a big impact.

(I remember early on sketching out the development plan for v2 and coming up with like 9 months of work... Things escalated.)

That's a good question. It almost wasn't; there was a period post-WinRT, pre-"microsoft open sources everything" where investing a huge amount of effort in the ecosystem didn't seem like it would make sense. I did consider a more traditional (for the games industry) path of C++, but even simple things like the effort required to keep build times reasonable were... not appealing. And modules kept getting kicked back. Even back then, I was considering rust as a preferred alternative.

And then everything went open source, some fruits of Midori started getting rolled in, and a focus on performance appeared. Stack that on top of the fact that C# has some pretty darn good tools, and I was comfortable jumping in more deeply. Notably, I did not just start making bepuphysics v2 at that point. It's sort of the tip of the iceberg- bepuphysics v2 is C# because all the other private stuff I've built is C#, and it's nice to minimize the developmental and runtime overheads between projects when possible.

To make things a little stranger, it's worth mentioning that I'm not sure if bepuphysics v2 works well with Unity right now. Attempts in the last several months by users trying to upgrade from v1 to v2 had... less than ideal results under that runtime.

The library is .NET Standard 2.0 compliant, though, so in theory it should work. It may require some extra work on the runtime side of things. As time goes on, I'd hope that mono/CoreRT or whatever the AOT story ends up being/CoreCLR converge and Unity can embrace them for all their target platforms. (Burst is also an option, but that would require a massive rework in bepuphysics that I can't really afford to do given that my projects aren't on Unity.)

Unity is in the process of moving more of their codebase into C#, backed by some in-house compiler work, yes. And they did indeed use C# extensively before then for game scripting, even if not exactly 'pure' or high performance in the same sense.

The work in Unity's Burst/HPC# is very recent, though, and the CoreCLR/language features I rely on in bepuphysics are still pretty obscure. I wouldn't expect most people outside of the weird niche I live in to know about the ecosystem's progress.

In other words, I was just trying to get an unaware visitor to raise an eyebrow.

I included that for a couple of reasons: 1) It's unusual. Historically, C# is more of a businessy thing, with a bit of game stuff on the side, mainly in the form of scripting. Extremely high performance C# code is even stranger. 2) It's more easily portable than a mixed library. It's definitely not impossible to make/use a cross platform mixed library (they're all over the place), but depending only on one toolchain is just less complicated.

So not a big deal, just a notable quirk.

I know some people are fiddling with it, but I'm not aware of any public projects using v2 yet. It's pretty darn early still- convex hulls got added only a few weeks ago.

I did build it for a reason, though- over the coming weeks I'll be diving into actually making stuff with it. That'll be a nice change of pace.

I'm glad someone respects newt rights.

I feel a little gross about headlining aggressive benchmarks with other engines, especially since most of them are free and open source just like bepuphysics. Plus, I learned a lot from projects like bullet, box2d and friends. I'd recommend potential users benchmark their use cases for themselves- those are the most trustworthy benchmarks anyway.

Regarding GPGPU, you're correct that bepuphysics v2 is strictly CPU-side, and also that I could likely make a GPGPU version faster. I wrote a blog post about why I chose to go with CPU-only: https://www.bepuentertainment.com/blog/2019/1/16/-but-gpus-a...

The short version is comparative advantage. I have other things to use the GPU on, and the GPU is even better at those things. And driver bugs.

Also, as I've mentioned elsewhere, while I have not done rigorous benchmarking, a casual evaluation showed that bepuphysics v2 on the CPU compares well with physX 4.1 running on a GPU of similar cost. Collision detection heavy scenes tend to favor GPU physX, while solver-heavy scenes tend to favor bepuphysics v2.

(Except for AMD's Threadripper CPUs unclear reasons. I suspect inter-CCX communication kills effective memory bandwidth in the solver. A 1700x is about as fast as a 2950x, and modern Intel cpus with full rate AVX2 can be much faster. Zen 2 should change things significantly.)

I wouldn't exactly consider myself optimistic about safe general AI either, but there are extremely strong incentives in the direction of developing greater generality. Not sure we have the luxury of not having some form of AGI in our future.

The current safety progress certainly isn't ideal (where ideal would be "oh hey we figured it out, boy that was easy"), but it is roughly in line with what I'd expect for a smallish new field trying to lay foundations. No one knows what to do; there may not be any other option than to flounder for a while.

'Safe' AGI is a harder problem than 'any' AGI, so getting started early could be helpful. Especially considering how bad many of the AGIs in the 'any' category could be. Worst case, we don't get a mulligan.

Yup, that's definitely true. It's going to be a fun transition period.

It's true that features of similar or greater complexity do tend to work pretty well already, but those features tend to be the ones that are practically fundamental and used everywhere. (edit: but I have hit bugs with scheduling too- and maybe tessellation and anisotropic filtering, but those cases were weird enough where it was hard to tease out the true cause.)

Ray tracing has a good shot at getting there (and probably in less than 5-10 years), and developers who can afford the suffering will hopefully pave the way, but early adopters should be very wary.

To be clear, I'm not catastrophically pessimistic. I intend to do some work with it, but I'm not under any illusions. I once encountered five distinct blocking driver bugs in the span of a single week. I just assume everything is broken until proven otherwise.

The likelihood of a feature being functional is usually based on two things: its hidden complexity, and how frequently used it is. HW ray tracing suffers on both of these counts (for now). It won't be truly common outside of major engines for years, and it hides a lot.

Any developer who is in the awkward middle ground of building their own technology without the resources of a major engine (both in terms of manpower and in relevance to hardware vendors) should expect everything on the bleeding edge to be partially or fully broken, often with no timely recourse. I'm not faulting the vendors too much- the software x hardware situation is absurdly complicated, and spending limited driver resources on a smaller company's use case instead of, say, Unreal and Unity, doesn't make a lot of sense.

But if you're one of those smaller companies, you pretty much have to build the fallback implementation first using common low level primitives that have been tested a million times across the industry. If you don't, your product simply won't work for many (and sometimes most) users. Even when their hardware is supposed to support it.

And speaking from unfortunate experience, the up-front cost of building the fallbacks is often less than trying to make the fancier things work consistently, even though the fancier thing is ostensibly doing the work for you.

Seeing the intrinsics APIs get filled out- in the open, no less- has been pretty exciting. The fact that something like AES would be implemented competitively in C# is not something I would have predicted even five years ago.

It's remarkable how fast the language and runtime have evolved for performance. It wasn't that long ago that I was manually inlining Vector3 operators to try to get a few extra cycles out of XNA on the Xbox360.