This video details the development of a new, realistic rigid body physics engine for the Voxal game engine, focusing on significant improvements in collision detection and response to enable more dynamic and accurate object interactions.
Mind Map
Clic para expandir
Haz clic para explorar el mapa mental interactivo completo
hello YouTube I'm Douglas and this is my
voxal game engine it's a video game
project that I'm coding where the entire
world is made out of tiny little fully
editable cubes this month I've been
working on an exciting new feature which
is realistic rigid body physics now
objects that are not part of the terrain
can move around slide bounce and collide
it's possible to drag objects around
using the mouse and interact with them
and if you delete part of the terrain
anything that becomes disconnected will
turn into a separate rigid body and be
simulated by the physics code meaning
that yes it's possible to chop a tree
down and watch it fall unlike another
popular block game those who have been
subscribed to my channel for a while now
you should totally subscribe if you
haven't we'll recall that I did
Implement a physics engine last year but
it was my very first attempt at ever
writing physics code and it was laggy
buggy and worst of all physically
inaccurate the first physics engine that
I wrote did not conserve energy or
momentum as objects hit each other and
moved through the scene which meant that
for example if you tossed one box at
another box the boxes would just hit
each other there would be no response no
momentum would be transferred to the
second box from the first and this made
the game a lot less interesting and fun
because you couldn't say stack one
object on top of another and then knock
it off um using a flying dut the plan
for this video is to describe the
architecture of the new physics engine
and I'll be going into detail about all
of the ways that I've improved the two
core components Collision detection and
response but before we dive into the
details I'd like to say a quick word
about today's sponsor Cod Crafters Cod
Crafters is an online education platform
built by experience software Developers
for experienced software developers it
has a whole bunch of cool project guides
that will walk you through how to build
a ubiquitous piece of software they're
adding new projects all the time too
since I joined for example they've added
a project that teaches you how to build
your own shell and another project that
teaches you how to build your own
scripting language interpreter they're a
really great resource and I'd highly
recommend them if you're say looking to
learn a new programming language but
don't have a project for it yet you can
check out code crafters for free today
by using the link in the description now
let's talk about Collision detection
Collision detection is the first step in
any physics engine and it involves
taking pairs of objects in the scene
figuring out where they overlap and then
producing a list of contact points point
and Associated data which can later be
used to move the objects apart and make
it look like they bounced in order to
make Collision detection fast there are
a couple of things you want to do for
one you want to check as few points as
possible for collisions because doing
less work obviously yields faster
results and in addition you want to
produce the fewest number of contacts
that describe your rigid bodies properly
because the fewer contacts there are the
less work the second step the Collision
solver will need to do in the context of
voxels This Means taking two voxal grids
one of which may be arbitrarily rotated
and translated with respect to the other
and figuring out which foxal touch in my
previous engine I would do this by
literally going through any pair of
voxal that were near one another and
running a precise separating axis test
this was problematic because it
generated a lot of contacts for example
a box sitting on the ground like this
would have contacts for every single
voxel on its bottom surface that meant
taking more time to run extra Collision
detection tests and it meant producing
more contact points to improve this I
turned to the game Tear Down for
inspiration tear Down's Collision
detection system is described in this
public Tech talk that the engine's
author Dennis Gustafson did and it's a
really enlightening talk I would highly
recommend watching it but the core idea
that tear down uses is that if you have
two polygons that are touching one
another either one polygon's Edge will
be touching another polygon's Edge or
one polygon's vertex will be touching
exterior so what this means is that it's
not necessary to include every voxel
during Collision detection let's start
off by defining corner and Edge voxal we
do this by considering the aent voxels
along any particular axis X Y or Z I
call a voxel a corner if it is not
surrounded on both sides by other voxels
for any axis so this would be a corner
but this would not be a corner similarly
I Define a voxel as an edge if it is
surrounded on both sides by others along
exactly one axis so this would be an
edge but this would not be an edge now
that we've defined corners and edges we
can leverage the fact that a corner or
an edge will always be involved in a
collision between two polyhedra to do
this my physics engine generates a
physics acceleration structure whenever
an object spawns and this acceleration
structure tracks the corner and Edge
voxels within the object then when it's
time to do Collision detection I test
the corner voxel of one object against
all the voxel of the other and vice
versa and then I test the the edges of
one object against the edges of the
other and this is great because you end
up testing fewer things and it also
generates far fewer contacts like Dennis
gustavson points out in the tear down
Tech talk a box sitting on the ground
like this only generates contacts
associated with the corner voxels and
this is a huge Improvement another
Improvement the talk mentions involves
figuring out whether voils themselves
are overlapping previously whenever my
engine figured out that two voxal were
closed together it would test them for
an actual Collision using a precise
boxbox separating axis test and this is
something I talk about more in a
previous video but the short of it is
this is an expensive but perfectly
accurate algorithm that will tell you
whether two boxes which are arbitrarily
rotated with respect to one another are
touching and this algorithm was good but
it turns out for voxels that are this
small you don't need that level of
accuracy and so what you can do instead
to test whether two voxal are
intersecting is take a voxel from one
volume transform it into the coordinate
system of the second volume that you're
testing and then check to see whether
any of the eight voxal which are closest
to that original voxel's transformed
Center Point are full if so we consider
a collision to have occurred this
approach skips all the work associated
with separating axis tests so it's much
faster and it does ignore the rotations
of the individual voxal themselves so
voxal end up behaving kind of like tiny
little spheres which isn't even a bad
thing it makes many objects sort of roll
or slide more than they normally
would with the Collision detection
system upgraded I turned my attention to
the Collision solver the point of the
Collision solver is to take all of the
contacts generated in the first step of
the physics code and then move objects
apart so that they're no longer
interpenetrating and ensure that they're
all moving with the correct velocities a
realistic Collision solver allows for
force to be transferred between objects
so if say this box on the left slides
over and hits these two boxes on the
right the other two boxes should start
moving with some amount of momentum that
was transferred during the Collision
this was the part that I really got
wrong in my previous physics engine
because it only simulated one object at
a time so during the simulation I would
take one object I would treat all other
objects in the scene as fixed and
unmoving I would update the position and
velocity of that one object and then I
would continue through one object at a
time and this meant in my previous
engine forces didn't transfer between
objects if you stacked like one box on
top of another it wouldn't be possible
to lift the top box up by applying a
force to the bottom box and this led to
a lot of um buggy and unrealistic
behavior for for example if you just put
a single tiny little voxal object on top
of a big tree the big tree would be sort
of pinned to the ground um you wouldn't
be able to move the big tree or lift it
up because of that one tiny voxel on top
of it so to learn how to do Collision
solving better I went ahead and I read a
book called game physics engine
development by Ian Millington and I'm
not sponsored but this is another really
excellent resource it makes all of the
math um very clear and intuitive and it
even comes with an example physics
engine implementation that you can
reference as you go through the book so
I read this book I figured out its
approach to Collision solving and then I
went ahead and I implemented that the
iterative solver is broken into two
parts position and velocity adjustment
and they both proceed in basically the
same way each algorithm takes a single
contact from the list of contacts that
were generated during Collision
detection and it figures out how to
change the object's position and or
velocities in order to make them no
longer interpenetrate and in order to
ensure momentum is transferred and this
math you can find in the book but it's
the same sort of math you would be doing
in a basic like physics one course it's
just conservation of momentum and energy
as you update the object's velocities
it's not too hard the real problem lies
in the fact that there isn't just one
contact but many when the physics solver
moves two objects apart to resolve one contact
contact
it may change the severity of other
contacts between the two objects since
solving multiple contacts simultaneously
is a very difficult challenge the
physics solver instead proceeds in an
iterative fashion it solves one contact
and then it goes through the list of
contacts and updates all the other ones
based upon however it changed the
position and velocities of the objects
involved then it chooses another contact
to solve usually the next worst contact
changes the objects so that that contact
is no longer a problem and then updates
all of the other contacts in the list
again so that the changes in position
and velocity are reflected in the
contact data the iterative solver
repeats this process looping over the
contact list again and again until all
contacts have been resolved and momentum
has been transferred for every single
one of them and that's an overview of
how my two-phase point based iterative
physics engine works the biggest thing
that was helpful for me in learning how
to do this was really leveraging my
resources using the tear down Tech talk
and millington's book and I also built a
small 2D version of this physics engine
before going into 3D and applying it to
my voxal game and that was a really big
help because 2D is a lot simpler to work
with and I was able to get a feel for
what the math should be like and what
bugs I'd encounter so that'd be my
biggest recommend recommendation if
you're interested in physics engines and
just starting out is to build something
in 2D because it'll be a lot easier and
it's honestly what I should have done uh
the first time I made a physics engine
rather than trying to go to 3D right
away if you want to try the engine out
for yourself there's a demo Linked In
the description you can play it online
in Chrome Edge or opera or you can
download a Native version of the demo
for best performance lastly if you have
any thoughts or questions be sure to
leave a like and a comment down below
I'd be more than happy to discuss your
ideas with you next up I'm planning to
work on a building system for my game to
allow users to finally create some cool
looking scenes so make sure to subscribe
in order to stay tuned for the next
Haz clic en cualquier texto o marca de tiempo para ir directamente a ese momento del video
Compartir:
La mayoría de las transcripciones están listas en menos de 5 segundos
Copia con un clicMás de 125 idiomasBuscar en el contenidoIr a marcas de tiempo
Pega la URL de YouTube
Ingresa el enlace de cualquier video de YouTube para obtener la transcripción completa
Formulario de extracción de transcripción
La mayoría de las transcripciones están listas en menos de 5 segundos
Instala nuestra extensión para Chrome
Obtén transcripciones al instante sin salir de YouTube. Instala nuestra extensión de Chrome y accede con un clic a la transcripción de cualquier video directamente desde la página de reproducción.