I'd like to get an idea what kind of math is typically necessary for 3D game engine programming? Any specific math (such as vector geometry) or calculation algorithms (such as fast fourier transforms), or is this all abstracted away with DirectX/OpenGL so that highly complex math isn't really necessary any more?
Linear Algebra! Lots of lots of Linear Algebra!
Here are just classes and example situations where you need them
Vector - position, velocity, normals
Matrix - transformations
Quaternion - rotations (great for bone animations)
Ray - projectile collision detection
Plane - projectile collision detection
Frustum - render culling
Sphere - render culling, fast collision test
Axis-Align Bounding Box - culling, collision tests, spacial partitioning
Oriented Bounding Box - collision tests
Convex Hull - collision, spacial partitioning
etc.
You should start with Vector and Matrix as they will be used everywhere in the engine (graphics, physics, AI, etc.)
Matrices, trig, geometry mostly and a bit of linear algebra
Take a look here http://www.essentialmath.com/
For the most part linear algebra and computational geometry; Quaternions are used extensively and numerical analysis is necessary if you are working on a physics engine.
How much you'd use the stuff on a daily basis depends on what you are doing. If you are a graphics programmer, and therefore building the 3D graphics engine itself, then you would likely be implementing or maintaining implementations of class libraries and functions that actually do the math, so it would be relatively important to know the gory details. If you are using the library as client or working on another part of the game engine (AI, audio, UI, camera, etc.) then you will need to understand the math conceptually but you can certainly get away with not knowing how to implement a matrix inverse on a whiteboard off the top of your head.
Graphics APIs do not eliminate the need for someone to know this math; they are limited to drawing, so all the scene management and world simulation needs to be implemented outside the graphics API. Of course, there are middleware options there too but many studios roll their own systems.
There are a fair number of resources targeted at this market. For example, on Amazon there are books like 3D Math Primer For Graphics and Game Development, and there's probably a lot of stuff online too.
Complex math comes in to play, but most important is an understanding of the concepts behind such math and often not the math itself. So long as you understand how it all comes together, there are often helper methods for many of the calculations you will need. Of course that depends largely on the development platform you are using as well.
Related
I am looking for ideas for algorithms and data structures for representing volumetric objects. I am working on a sculpting system, like sculptrix or mudbox, and want to find a good implementation strategy.
I currently have a very nice dynamic halfedge mesh system to collapse/subdivide faces. It works very well and is incredibly fast, but since it is a surface algorithm, it is not easy to robustly change topology.
So I want to go back to the drawingboard and implement a proper volumetric system. My first idea was some kind of octtree representation for the volume and marching cubes to polygonise it.
However, I have a few problems with this. First, marching cubes often produces small or thin triangles, something that is highly undesirable (reason why later). Second, I want to polygonise the volume only in the area of editing, and at different levels of detail. For example, I may want a low res sphere, but with a few tiny high res bumps. I can easily get that kind of subdivision behaviour with my current surface based sustem, but I can't envision how I could do it robustly with marching cubes.
Another problem is that the actual trianglular mesh is further subdivided on the gpu for smooth surfaces, so I need neighbourhood information too. Again, I already have this with the current half-edge system, but with a volume polygonisation system, I imagine it taking a lot of extra processing to find the extra connectivity information. This is the reason thin triangles are bad.
So I have a lot of constraints, and I am asking this community for ideas or pertinent papers to read. I was thinking about surfacenets to avoid the small/thin triangle problem. Also, I have a feeling kd-trees may be better for storing multiresolution volumes since they seem more flexible then octtrees.
Anyway, any ideas/suggestions very welcome.
Was somebody trying to implement 4d or n-dimension physics realtime (or not) engine?
What difficulties in this implementation, compare to 3d and 2d physics engines? Of course, one of which is presentation problem. Is's an interesting to look at and to find out more about 4d hyperspheres, hypercubes, springs, joints, liquids and other objects.
I am just curious, and not have a real application using it.
Generalization of my idea is physics in lobachevskian or riemann geometries, distortion spaces (you can go through the needle's eye), looped spaces (returning to the same place), physics paradoxes and other amazing things.
There are numerous research groups using relativistic codes, for all sorts of physics problems; from Relativistic Electrodynamics, Relativistic Fluid Dynamics/Magnetohydrodynamics and for gravitational based simulations etc. Astrophysical applications are the main place you would meet relativistic codes.
A 4D game engine is what you already have in games like FIFA and COD. This is just a 3 + 1 implementation, which incedently is what many relativistic codes are (they use the 3 + 1 formulation of space-time). This splitting of space-time is much easier to handle computationally for many different reasons. Of course as you go from 1D to 2D etc. you complexity increases inline with the simulated physics.
To me it makes no sense to have a physics engine in n-dimensions. We do not experience physical processes in n-diemensions, but four. To ask about hypercubes etc. is not physics but geometrical/mathematical constructs. These are separate from what you would traditionally associate with a physics engine.
An example of a 4D physics engine is 4D Toys, created by Marc ten Bosch.
The author goes into more detail about how it works on their blog (see this post about geometric algebra, for instance).
Their technical paper, N-Dimensional Rigid Body Dynamics, was also accepted to SIGGRAPH 2020.
I also explained a bit how angular velocity works in higher dimensions here.
Does anyone have any good implementation strategies or resources for putting together a b-rep modeling system?
OpenCascade is an apparently good library for b-rep modeling (used by FreeCad and PythonOCC are both very cool) but the library is huge, complicated and may not be a good starting point to learn about b-rep modeling 'engines'.
I've done quite a bit of research paper reading, and while the fundamental math is useful for understanding why everything works, its left me with some implementation questions.
The halfedge data-structure seems to be the preferred way to store information about a body in b-rep implementations.
So a handful of questions in no particular order:
Using the halfedge data-structure how is rendering typically implemented? Triangulation based on the solid's boundaries?
How are circular faces/curved surfaces typically implemented? For instance a cylinder in one basic introduction to b-rep's I read, was internally stored as a prism. IE an extruded triangle and meta-data was stored about the cap faces denoting that they were indeed circular.
How are boolean operations typically implemented? I've read about generating BSP-Tree's along the intersection curves then combining those tree's to generate the new geometry. Are there other ways to implement boolean operations and what sort of pro's/con's do they have?
Thanks!
If you'd like to provide a code example don't worry about the language -- the questions are more about algorithmic/data-structure implementation details
I'm working on a B-Rep modeler in C# (I'm in a very early stage: it's an huge project) so I ask myself the same questions as you. Here is my answers:
Triangulation: I've not done this step, but the strategy I'm thinking about is as follow: project the face boundaries in parameter space to obtain 2D polygons (with holes), triangulate that with the ear clipping algorithm and then reproject triangle vertices in 3D space. For curved surfaces, I need to split the polygons with a grid in order to follow the surface;
For a cylinder, there is 3 edges : two circulars and one line segment. I have classes for each type of curves (Segment3d, Circle3d...) and each half-edge hold an instance of one of theses classes. Each face hold an instance of a surface object (plane, cylinder, sphere...);
There is an interesting project here based on BSP-Tree, but it uses CSG method, not B-rep. I'm still researching how to do this, but I don't think I will need a BSP tree. The difficulty is in computing intersections and topology.
The best books I've found on this subject:
3D CAD - Principles and Applications (old but still relevant)
Geometric Modeling: The mathematics of shapes (more recent than the previous one, but less clear)
Whats the best way to detect collisions in a 2d game sprites? I am currently working in allegro and G++
There are a plethora of ways to detect collision detection. The methods you use will be slightly altered if depending on if your using a 2d or 3d environment. Also remember when instituting a collision detection system, to take into account any physics you may want to implement in the game (needed for most descent 3d games) in order to enhance the reality of it.
The short version is to use bounding boxes. Or in other words, make each entity in the world a box, then check if each of the axises of the box are colliding with other entities.
With large amounts of entities to test for collisions you may want to check into an octree. You would simple divide the world into sectors, then only check for collision between objects in the same sectors.
For more resources, you can go to sourceforge and search for the Bullet dynamics engine which is an open source collision detection and physics engine, or you could check out http://www.gamedev.net which has plenty of resources on copious game development topics.
Any decent 2D graphics library will either provide its own collision detection functions for everything from aligned sprites to polygons to pixels, or have one or more good third party libraries to perform those functions. Your choice of engine/library/framework should dictate your collision detection choices, as they are likely far more optimized than what you could produce alone.
For Allegro there is Collegro. For SDL there is SDL_Collide.h or SDL-Collide. You can use I_COLLIDE with OpenGL. DarkBASIC has a built in collision system, and DarkPhysics for very accurate interactions including collisions.
Use a library, I recommend Box2D
This question is pretty general. There are many ways to go about collision detection in a 2d game. It would help to know what you are trying to do.
As a starting point though, there are pretty simple methods that allow for detection between circles, rectangles, etc. I'm not a huge fan of gamedev.net, but there are some good resources there about this type of detection. One such article is here. It covers some basic material that might help you get started.
Basic 2d games can use rectangles or circles to "enclose" an object on the screen. Detection of when rectangles overlap or when circles overlap is fairly straightfoward math. If you need something more complicated (such as convex artibrary polys), then the solution is more complicated. Again, gamedev.net might be of some help here.
But really to answer your question, we need to know what you are trying to do? What type of game? What type of objects are you trying to collide? Are you trying to collide with screen boundaries, etc.
Checking for collision between two balls in 2D is easy. You can google it but basically you check if the length of the two balls radius combined is larger or equal to the distance between the center of the two balls.
Then you can find the collision point by taking the unit vector between the center of the balls and multiply it with one of the balls radius.
Implementation of a collision detection system is a complicated matter, but you want to consider three points.
World of objects. Space Partitioning.
If you do a collision check against every 2d sprite in your world against everything else, you'll have a slow slow program! You need to prioritize. You need to partition the space. You can use an orthogonal grid system and slice your world up into a 2d grid. Or you could use a BSP tree, using lines as the seperator function.
Broad phase collision detection
This uses bounding volumes such as cylinders or elipses (whichever approximates the shape of your sprites the best) to determine whether or not objects are worth comparing in more detail. The math for this is easy. Learn your 2d matrix transformations. And for 2d intersection, you can even use high powered video cards to do a lot of the work!
Narrow phase collision detection
Now that you've determined that two or more objects are worth comparing, you step into your fine tuned section. The goal of this phase is to determine the collision result. Penetration depth, volume encompassed, etc... And this information will be fed into whatever physics engine you got planned. In 3d this is the realm of GJK distance algs and other neato algorithms that we all love so much!
You can implement all of this generically and specify the broad and narrow resolutions polymorphically, or provide a hook if you're working in a lower level language.
Collisions between what? It depends whether you use sprites, concave polygons, convex polygons, rectangles, squares, circles, points...
I'm not a math guy in the least but I'm interested in learning about rigid body physics (for the purpose of implementing a basic 3d physics engine). In school I only took Maths through Algebra II, but I've done 3d dev for years so I have a fairly decent understanding of vectors, quaternions, matrices, etc. My real problem is reading complex formulas and such, so I'm looking for some decent rigid body dynamics references that will make some sense.
Anyone have any good references?
Physics for Game Programmers I think is better than Physics for Game Developers.
If you want something thick in your bookshelf (like I do), Eberly's 3D Game Engine Design and Erleben's Physics-Based Animation can accompany the above.
Chris Hecker has a nice set of articles on his website which were originally published in Game Developer Magazine. They start with 2D physics and progress to 3D.
Physically Based Modeling by David Baraff is also good, but is a bit heavier on the math.
I guess what you are looking for is Classical Mechanics, which describes motion in one, two, and three dimensions in a generalized manner.
I found a good introductory course on Classical Mechanics from the University of Texas.
I do not guarantee that you will be able to understand all the concepts there, but it will at least give you a basis for your plan. I advise you to consult a Physics professor to help you understand the math.
Good luck!
If you are already familiar (and comfortable) with
linear algebra
basic calculus
Newton's laws of motion
then 6DoF Rigid Body Dynamics is what you are looking for. It's a brief article written [disclaimer: by me] when I once had to develop a helicopter flight simulator.
Using a rotation matrix allows for extremely simple modelling equations, but there exists a simple mapping to and from a quaternion if you prefer that representation for other reasons.
Trying not to get you to rip off your hair with frustration (well, Baraff's/Witkin great math articles with the multi-dimensional matrices would do that sometimes), you can look at the easier online articles such as the ones published in Gamasutra.
Here are two of them:
http://www.gamasutra.com/resource_guide/20030121/kennedy_pfv.htm
http://www.gamasutra.com/features/19990702/data_structures_01.htm
http://www.gamasutra.com/resource_guide/20030121/jacobson_pfv.htm
You'd notice that they point at the mentioned resources as part of their references. I would add that unless you need to solve equations system for multiple particles, articulated characters, or non-rigid complex object, this might be enough to start with.
If however, you do look for more advanced physics and mathematics which involves matrices and equations systems look up Witkin and Baraff's home pages (I think they are both in Pixar if I'm not mistaken), or start with Hecker (that tried more than several practical methods and documented his results).