# elanthis

Member

9

126 Neutral

• Rank
Newbie
1. ## Questions about collision detection

3D collision detection is fairly complicated. 3D collision response (fixing the collision after detected) is very complicated. Doing interesting physics with these events (from bouncing balls to complex constraint-based physics) is insanely complex. There are a number of books on the topic. There are also Open Source libraries to learn from, such as Bullet. If you're looking to use physics without digging into the details and writing it all from scratch yourself, you are far better off using an existing physics library. Bullet is quite serviceable. There are others. If the game is a free/hobby project, I believe you can even use Havok or PhysX freely.
2. ## Sending thousands of uniforms to a shader. (3.2 -4.0)

Texture buffer objects exist specifically to solve this problem. They're pretty straight forward to use and easy to look up on the OpenGL wiki.
3. ## Bounding Box Calculations

To transform an AABB the simple way, there's only a few simple steps. First of course generate the untransformed AABB from the model's untransformed vertices by calculating the max/min values for each axis. Then, for any transformation matrix you wish to apply to the model, you will apply that matrix to the eight corners of the AABB, and find the new max/min values for each axis. If you have more constrained transformations you can simplify this somewhat. Constraining rotations can do a lot. If you represent your AABBs as a point and a vector of half lengths, you only need to do 2 matrix multiplications instead of 8, but remember that you still need to decompose the half length vector and calculate a new one after transformation.
4. ## OpenGL 2D OpenGL ES wrapper with emulation on Windows?

SDL or SFML probably do what you want. There are a ton of 2D rendering libraries that can use GL/D3D, but that all have various caveats. Note that "blitting" over modern graphics APIs is not necessarily what you want to be doing. You're much better off with a simple scene graph that can probably batch draw calls and offer an automatic texture atlas. Old-style 2D rendering is simply not the right way to get proper use of modern graphics hardware, and in some cases it's just faster to do that kind of rendering completely on the CPU.
5. ## What is the best solution for 3d animation in games ?

In terms of best use of time, an existing engine is the way to go. For someone who finds C++ to be a little overwhelming or requiring too much boilerplate, I would recommend trying Unity, which is a very popular AAA level game engine that uses C# (as one option) for coding custom game logic (Unity's core is all in C++, of course). Note that I do not believe that a programmer can simply take an engine like that and make the most efficient use of it. If you don't understand how to code 3D animations in C++ yourself then that strongly indicates that you just don't understand 3D animations, and you need to understand them at a decent level to be able to use them in any effective, interesting ways. If you're looking to teach students about game programming, premade engines are not the way to go. Again because a game programmer has to understand the core techniques of an engine to use an engine effectively. Students will be best served by building their own simple engines. Yes, it's a lot of work, but it's worth it. Otherwise you'll be educating the game industry equivalent of script kiddies: a bunch of young clueless people who know how to use a specific tool but are utterly lost as soon as they need to do something new, different, or innovative. Specifically regarding 3D animations, there's not a lot to it. Students should have prior knowledge of GPU shader programming (D3D or GL, doesn't matter which) and a solid understanding of linear algebra (particularly vector spaces, changes of basis, and the usual 3D affine transformations). A primary on quaternions can be useful but given in the same class that animations are taught. With those foundations, writing a complete animation and rendering system is not that difficult at all. It's practically trivial, really, if you start out with key-framed skeletal animations and build up from there.
6. ## When and where is it appropriate to use smart pointers in an engine?

In general, the rules for use of a smart pointer in a game engine are no different than for any other software. Which kinds of smart pointers you use may change a bit, however. For example, in my engine and a dozen other AAA engines I've worked with, smart pointers to game objects acted a lot like std::weak_ptr. The handles were implemented quite a bit differently (generally via a slot map, but sometimes as object ids and a map of some kind), but the usage is similar. You can call a ptr() method which either returns a pointer to the object or nullptr, depending on whether the object is still alive. For game resources (textures, shaders, sounds, etc.) it can be handy to use a similar system. However, I find it is even easier, safer, and more efficient to use a package system. A particular set of assets all reside in a package, which depends on other packages. Loading a new level will open up any packages the new level requires and unload the packed that it does not (also taking into account the UI packages and such). You can then safely use raw pointers to resources will no worry that the resource will disappear while the logic using the resource is still be executed. You can combine this with smart pointers for extra checking, potentially making those smart pointers just thin wrappers around pointers in a release mode build. For a lot of the miscellaneous stuff, again, the rules are the same for games and other software. Prefer smart pointers for any "owning" pointer, with std::unique_ptr being your primary smart pointer. Only use std::shared_ptr where you truly need shared ownership. Temporary pointers that will outlast owning handles can be raw pointers. Never create any smart pointer from a raw pointer without utmost care (too easy to end up with two different owners of a resource that will both try to free it).
7. ## Fading a texture with alpha channel (i.e. "double transparency")

Easily done with a shader. Pass in a uniform or vertex attribute for your display factor. Multiply the alpha component of the sampled texture color by this factor. Write result (possibly discarding fully transparent pixels of you don't want z-writes on transparency) to the fragment color. Sorry for not posting sample code; using my phone to type this and typing code on this thing is not pleasant. However, this is basically a trivial two line change to the simplest textured fragment shader.