31–40 of 64 posts
Things have come quite a long way :)
Edit: still has problems with squishiness of stacked solid objects though :\
I wonder how it compares with P2.js. Another nice pure JavaScript 2D physics library. https://schteppe.github.io/p2.js/
Your functional spaghetti style is a bit weird though. I hate using the "find in file" function in my editor. I wanted to "rip" some of the functionality, but it's so entangled I would probably need all your other functions too to make it work. But maybe that's intended :P
Many people, me included, would be willing to pay for an engine like this. I tried your "Game physics for beginners" but I'm too stupid to understand all the articles from math professors. I could probably learn, but I rather pay someone who understands.
But for me to use your engine, the API needs to be much easier! Something like this:
var box1 = new Body(size, position);
var world = new World({gravity: 9.8});
world.add(box1);
world.render();
console.log('New position: ' + box1.position);Those kinds of approximations are the source of some of the most hilarious bugs in games over last deacade or so.
Please don't read this as a critique of this particular project which is pretty good at what it's trying to do.
I just wonder why AAA games use pretty much the same math? Are there no better math?
I mean CAD systems obviously do something better... Is that the same thing as with drawing triangles vs. raytracing?
Earlier quoted context omitted.
Have you seen PixiJS? http://www.pixijs.com/ It's used by PhaserJS, a very promising JS Game Framework
Pixi is the rendering engine used by Phaser. More relevant is the different physics engine Phaser supports (Box2D, P2 and its own lightweight arcade physics engine). Also Phaser is Typescript but distributed as JS. You can link it directly with Typescript too though which is why I like it a lot.
Earlier quoted context omitted.
I mean, this is what I'm looking for. Sure it would be madness, but if you have 450 bodies represented by, say, 10 floats each (random number), that comes to about 4500 pixels of values- something a GPU is fine at.
in 3d you normally represent by a 4x4 matrix, which can be easily reduced to 6 floats (x y z translation, and x y z rotations). The problem with doing that little work is you'll very quickly be bottlenecked by copying memory to/from the GPU. If you want to do any raycasts for instance, or query for occlusion/bounds testing, you need to upload data to the GPU, run a (potentialy very slow, serial) query, then copy the…
I agree that normally (small examples) it wouldn't be worth it, but for any large simulations, and say, video games of the future, I have yet to see someone attempt to do this. Perhaps it truly isn't beneficial enough... but who knows.
Earlier quoted context omitted.
in 3d you normally represent by a 4x4 matrix, which can be easily reduced to 6 floats (x y z translation, and x y z rotations). The problem with doing that little work is you'll very quickly be bottlenecked by copying memory to/from the GPU. If you want to do any raycasts for instance, or query for occlusion/bounds testing, you need to upload data to the GPU, run a (potentialy very slow, serial) query, then copy the…
The question then becomes how slow is copying to/from the GPU versus doing the computation on the CPU when it comes to 100s/1000s of active bodies. I agree that normally (small examples) it wouldn't be worth it, but for any large simulations, and say, video games of the future, I have yet to see someone attempt to do this. Perhaps it truly isn't beneficial enough... but who knows.
The amount of time spent inside a GPGPU kernel for updating 1000 rigid bodies wouldn't even be as much as the length of time to copy the data back and forth. You've also got to consider the acceleration structure used for the collision detection. If you have a hierarchical tree-like structure (BVH, BSP tree) then how do you update it in parallel. you need to spin off thousands of tasks for it to be worth running on the GPU. If you have that many dynamic bodies, you're probably going to be draw call limited in trying to render them, unless they're exceptionally simple objects (Particles for example, which are already GPU accelerated in modern Game Engines).
> I agree that normally (small examples) it wouldn't be worth it, but for any large simulations, and say, video games of the future, I have yet to see someone attempt to do this. Perhaps it truly isn't beneficial enough... but who knows.
In modern AAA video games, the active body count in a scene would be no greater than the hundreds. Think of a scene from Assassin's Creed, or Battlefield, and think about how many truly dynamic things there are in the level. Chances are, there's you(the player), a handful of other players, a handful of explosive barrels, maybe 5-10 vehicles, and a few extras for bodies. For something like Assasin's creed, the computation is most likely in the animation, where hundreds of physics raycasts from the players hands to the various "climbable" points are performed, and the updating of the very detailed skeletal mesh. Modern games utilise almost 100% of the GPU time already on rendering for lighting, AA, shadows, ambient occlusion, transparency, reflections. To add more stress to the GPU is unnecessary really, considering that the computations are so short for a few hundred bodies that the bottleneck will be copying the data over and back.
I wrote my masters thesis on GPGPU accelerated Bounding Volume Hierarchies (A common structure used in Raytracing and in Collision Detection). The overhead of a small copy stalling the GPU is quite severe. It's worth it if you can do all your work on the GPU without having to copy back, but that's currently not feasible for interactive simulations.
Why all those "physics engines" are so jittery? Are there no ways to solve such a system with perceptually exact accurancy in realtime? Those kinds of approximations are the source of some of the most hilarious bugs in games over last deacade or so. Please don't read this as a critique of this particular project which is pretty good at what it's trying to do. I just wonder why AAA games use pretty much the same math?…
Why all those "physics engines" are so jittery? Are there no ways to solve such a system with perceptually exact accurancy in realtime? Those kinds of approximations are the source of some of the most hilarious bugs in games over last deacade or so. Please don't read this as a critique of this particular project which is pretty good at what it's trying to do. I just wonder why AAA games use pretty much the same math?…
If you want 60 frames per second for a smooth animation, you have to compute the whole frame less than 1/60th of a second. The more complicated your physics model is, the harder it is to do this.
>I just wonder why AAA games use pretty much the same math? Are there no better math?
The math they use is just standard physics, often using some simplifications or optimizations to speed up the calculation. "Better math" is a curious term. If you want more accuracy, you have to give up speed. You can't have both. You either get jittery/jerky motion or you get unrealistic effects. Of course, running on a faster machine or finding a better optimization will help, but that also requires a ton of expertise and is sometimes plain infeasible.
>I mean CAD systems obviously do something better... Is that the same thing as with drawing triangles vs. raytracing?
CAD systems with physics engines do the same thing as above, and they have to make the same kinds of decisions. Usually, CAD software is meant for design, so it would opt for higher precision. This isn't suitable for games except on very high-end machines, which would exclude a lot of people from buying your game.
As for ray tracing vs rasterization: Yes, it is the same kind of trade-off. Ray tracing can be made very accurate and do some amazing things, but the frame rate is usually so low that you have to pre-render the whole animation beforehand. That is, if you want high quality.
Rasterization gives medium-low quality at very high framerates. It is very common because it is 'good enough looking' for most purposes, where an equivalent quality ray tracer would be very slow. Of course, a physics engine is independent of your rendering method: you will have to compute physics for your scene whether you use ray tracing or rasterization, so you have to take both into account for determining how jittery your animation will look.