Compound shapes have been working for a few days now. A rigid body will not always be represented physically with just one shape. This video shows groups of shapes acting as one unbreakable unit. For each compound shape that gets dropped, the physics demo generates a random number of shapes with random types and transforms inside the rigid body.

I added the ability to launch spheres into the scene, too. Other than adding a GUI to show the user what the controls are, the physics demo is back up to the point it was at in previous engine versions.

Next on the to-do list is getting an asset manager working. Up until now, textures and other assets were referred to using paths relative to the Nightshade root folder. This is not a good long-term solution. Paths will be replaced with the concept of packages and asset IDs, which I will post about in the near future.

The physics demo is just about up to the point it was at in previous engine versions. Each shape type is bound to a keyboard key so they can rain down from the sky in response to user input.

There are two more additions I’d like to make. One is mostly done already, compound shapes. Imagine combining a bunch of these shapes into one solid object, with each shape having a random rotation and position inside the object. Those are almost fully working and I’ll probably post a video soon with them in it.

The other addition is the ability to launch shapes into the scene, which will be the first use of directly applying impulses to objects.

Physics work in now underway, which is great since having a physics demo without physics for the past two weeks has been rather silly. It’s nice to have objects moving around in the scene instead of the floating box and sphere that have been in there for ages. There are currently five primitive shape types: box, sphere, cylinder, capsule, and cone.

In a real game, many objects can be represented physically using just these primitives. For objects that require more detail, a mesh physics shape will be added at some point. “Compound” bodies will be added relatively soon; bodies made up of more than one shape that act as a unit.

The next step will be to add an input control for each shape type to drop them from the sky. I’d love to say I came up with something a bit more interesting, but the truth is I didn’t really try. I think dropping shapes work well for the physics demo.

Now that I’ve added directional lighting to Nightshade, the scene looks a little more realistic. Believe it or not, the drawing below is not an actual 3D rendering, it’s my own lovely artwork. A good example of a directional light is the sun. It’s so far away that by the time the rays of light hit the scene, they’re essentially coming from the same direction.

Some faces of the cube are going to be well lit, while others (like the left side) shouldn’t be lit at all. To figure out how well lit each face should be we need to calculate a dot product. Geometrically, the dot product of two vectors is equal to the product of the magnitudes of the two vectors and the cosine of the angle between them. Since we’re dealing with normalized vectors (vectors whose lengths are one), the equation simplifies to the dot product equaling the cosine of the angle between the vectors.

We know the direction to the light and we know the normal vector, a vector that points out perpendicular to the surface. In reality, the shader code is dealing with vertex normals, but for a cube, all vertex normals in the cube faces will point straight out from the face. To figure out the amount of lighting, the shader calculates the dot product of the D and N vectors. In the drawing, the angle is 45 degrees, so the cosine will be sqrt(2) / 2, or about 0.7071. Multiplying this value by the color of each texel (texture pixel) on the right face makes each pixel about 70% lit. If the sun had been directly in front of the face, the angle would have been 0 degrees and cos(0) = 1.0. The face would have been fully lit as we’d expect.

There’s one other bit of fiddling that’s required. If you can imagine the normal vector coming out of the left face, it’s going to be at an angle of 135 degrees to the vector pointing at the sun. The cosine of 135 degrees is -0.7071. Since we don’t want negative color values, the code “saturates” the cosine value to clamp it between 0 and 1. The left face would then correctly receive no light since it’s facing away from the light source.

Now a screenshot of the lighting in action. The light is coming from the upper left of the scene and also pointing towards the back; the effect is most noticeable on the sphere. Click the image to enlarge it.

I’ve knocked off most of the items I mentioned in my previous post. Today I decided to get started on the last remaining item, input handling. I spent the last few hours putting together a DirectInput-based input manager.

One problem: Microsoft does not recommend using DirectInput anymore given the presence of the new XInput system. DirectInput should only be used to handle older input devices (basically anything that’s not an XBox 360 controller). That might come into play down the road, but right now all I care about is keyboard and mouse input. The recommended way to handle those devices is through the regular window message loop, the same way any non-game Windows app handles input. So… I just wasted a couple of hours.

Even so, I should have the new method running very soon. Combined with the fact that lighting is now working, the next video should be a bit more interesting than the previous ones. The video will come soon, but before that a post on lighting mathematics is coming tomorrow.

Today I moved on from my basic demo to what will eventually be a physics demo. Of course, there’s no physics in place yet, so for the moment it’s more like the basic demo with different objects in the scene.

Physics will come along soon, but there’s a bunch of things to get working first. One was started this morning, camera parts. I’ve had camera data hardcoded in the render manager up until now. The render manager now holds a pointer to the “current camera”. Whatever camera is set is used for the next frame. Getting input working soon so I can move the camera around wouldn’t be a bad idea.

As you can tell from the screenshot (if you enlarge it), there are no lighting calculations going on yet – everything appears at full brightness. I plan on adding directional lighting before moving on to physics.

Another major addition will be registering parts. I’ll describe the entity and parts system in greater detail in a future post, but the general idea is that an entity is made up of a collection of parts. Each delivers a specific functionality, such as rendering, camera handling, physics, etc. Because eventually parts will be allowed to be written in Lua, the C++ code may not even know about all possible part types. Parts will need to register themselves to be able to be created from a class name string.

I spent some time over the past few days starting on some basic math classes. Nightshade now has Matrix4 and Vector3 classes. They’re pretty bare-bones at this point, but it’s enough to allow objects to maintain their own transforms. Because of this, I was able to get rid of hardcoded transforms in the render system and I now have the ability to render multiple objects. I added a new shape, a sphere with an Earth texture (thanks NASA).

I suppose there’s no real “up” when drawing the Earth, any orientation is as valid as any other, but the way I have it in the video is certainly not how it normally is displayed. The reason that is happening is because my mesh files store texture coordinates in OpenGL-style. In OpenGL, the texel (0,0) is at the lower-left of the texture. DirectX, however, considers the upper-left to be (0,0). This discrepancy makes textures appear upside down in the DirectX renderer. I’m going to need to flip the y values of texture coordinates after loading.

Creating meshes by hand is extremely tedious. The image below is a screenshot I took of my hex editor while editing the square mesh that appeared in my previous post.

Not exactly the most user-friendly way to create meshes. For the square it wasn’t too bad, but anything more complicated would be very annoying to create. So I added my newly-updated Blender exporter to Nightshade. Instead of messing around with hexadecimal data, I can create meshes in Blender and get them into Nightshade very easily now. The exporter only exports the mesh for now; animation data will come along later. Like the previous post’s square, rotation in the video below was added in the code.

Basic texture mapping is now working. To map a texture onto the geometry, each vertex of a triangle associates itself with a location in the texture. The shader (a program running on the graphics card) samples the texture for each rendered pixel and the result is shown below. This square is comprised of two triangles.

The square rotates mainly to give me an excuse to post a video. The rotation is not coming from any animation associated with the mesh – that won’t happen for awhile. I just threw in a floating point rotation value that gets increased a bit each frame. Instead of rotating in the same direction forever, it swings back and forth because the actual rotation amount I use is the sine of the rotation value. Just a quick and easy way to get something moving in a (slightly) more interesting manner.

Most of the textures I’ve used in any Nightshade version, including this brick texture, have come courtesy of the now-defunct OpenFrag project. Thank you to them for making their textures available under a Creative Commons license.

The next step in the render system is going to be moving away from the hardcoded mesh data I’ve been using to a mesh class that loads data from a file. A few weeks ago I upgraded to the newest version of Blender which required updating the Blender exporter I wrote long ago. Since it’s already working, I should be exporting meshes soon.