Alex Goldring

Building Shade — next-gen Web graphics engine | Graphics engineer | consultant

[Alex Goldring @SoftEngineer]

@AmyNoteApp Yep, can't do much about that though. Physics engines are a fascinating field of research with really interesting performance characteristics. Totally different from the field of graphics, yet they look like they should have a lot in common at a first glance.

[Alex Goldring @SoftEngineer]

A new JavaScript physics engine. Testing settling stability.

Most physics engines struggle when you place a bunch of blocks tightly packed like this.

They want to jiggle and bounce.

Engine: https://t.co/7a4ZqZ0XVM

[Alex Goldring @SoftEngineer]

@isaac_mason_ absolutely, go ahead, great engine by the way. loved the the infinite cat drive

[Alex Goldring @SoftEngineer]

@DataDeLaurier Is this not how they usually spin?

[Alex Goldring @SoftEngineer]

Something's not quite right here...

[Alex Goldring @SoftEngineer]

@AmyNoteApp island-grouping

[Alex Goldring @SoftEngineer]

Forward+ decals. Done using @threejs

live link: https://t.co/FexmvC2xlr

The example is simple, there is a pool of 75 images, and a decal placed is chosen at random.

Technically it scaled to 1000s of decals, I haven't tried with more than a million.

The decal images are automatically atlased, so if you have a 1000 images instead of 75 - it will work just as well

[Alex Goldring @SoftEngineer]

Didn't measure, but based on some stress benchmarks probably ~150, or just over 500ms which is the sleep timeout. Might be closer to a second or two. It does sleep.

I have a Keva tower benchmark which has 5000+ pieces, and that thing sleeps eventually😅

The basics are probably very standard, we have islands, and (probably) each stack is going to be an island, which will settle quite fast.

[Alex Goldring @SoftEngineer]

@adelbucetta Yeah, economics and stuff, very important... and stuff

[Alex Goldring @SoftEngineer]

Added vehicle physics to my JavaScript physics engine

This is the raycast variant. Some boxes for a bit of extra interactivity and large heightmap terrain to demonstrate stability.

Live demo: https://t.co/vrqjPl0sX0

[Alex Goldring @SoftEngineer]

@macdonaldncode Yeah, took a while to figure that specific part out😅

[Alex Goldring @SoftEngineer]

@azrhyga Thanks!

[Alex Goldring @SoftEngineer]

First person character controller.

https://t.co/xcIkOvc36Z

Controls: ASWD, space, C, B

Features:
- jumping
- crouching
- sliding
- wall run
- wall jump
- mantling

But it's mostly about the camera control, mimicking human biomechanics with a fairly large bias towards dynamics - i.e. making it feel fun.

[Alex Goldring @SoftEngineer]

@AmyNoteApp it's SI, the solver is TGS

[Alex Goldring @SoftEngineer]

@AltRealityGameX Thanks for the feedback!

[Alex Goldring @SoftEngineer]

@SurajChawh79862 No relation to Unity, it's my own engine designed to run in the browser

[Alex Goldring @SoftEngineer]

@JoymFL Thanks, I did skim the paper when it came out, but most of the modern physics simulation research is above my head 😅

[Alex Goldring @SoftEngineer]

Making chains.

Meep physics engine (JavaScript, Browser).
This is an example showing position constraints. All element on the screen are physics-enabled. Each link runs full collision against every other link and the rest of the scene.

Solver runs 5 sub-steps at 60Hz, TGS

engine: https://t.co/4WYxE8rtBa

[Alex Goldring @SoftEngineer]

@JoymFL Not at all, but it's an interesting though!

This is a primarily real-time engine, so a lot of high-end features are not in scope. It's also a single-threaded CPU engine, so the solver architecture is not driven by parallelism.

But it would be amazing... :)

[Alex Goldring @SoftEngineer]

Very different architectural approach to cannon, and significantly faster and more accurate.

The crashcat - didn't know about it, so thanks a lot for putting it on my radar. I can confirm that based on examples my solver is a lot more accurate and about an order of magnitude faster, but it does look like an amazing engine.

[Alex Goldring @SoftEngineer]

A couple of reasons:
* PhysX does not run natively in the browser. It has to be cross-compiled to WASM, which you can't debug in the browser and you can't communicate with from JS directly, you have to go via a bridge.
* PhysX is not built for my engine. Or any engine really, this means that you have to have a glue layer. This is super common and pretty much every game engine that doesn't have it's own physics has this. It's a small overhead, but it does exist.
* Counterintuitively, my solver in pure JS appears to be faster on a few inexact benchmarks against PhysX 5.6 wasm build when it comes to large object counts.