5/30/12: Physics and Selection
After I added shadows, the next thing I wanted to implement was some editing tools. This turned out to actually be fairly simple, the only complicated was determining which object the mouse was clicking on, which is commonly referred to as picking. The simple way to do object picking is just to render all the objects a different color off-screen, and see what color is under the cursor. Nice and simple, and as a bonus it will work with anything you want to draw. No complicated math needed.
However, since I'm using custom shaders for all my drawing (not to mention having some real complex drawing code to begin with), adding more shaders to render per-object colors, rearranging my code so that I can easily do one off renderings with custom shaders, and keeping yet another shader up to date whenever I change something in another one didn't sound very fun. Instead, I went for Option B: math
Selecting an object using math boils down to making a line from where the camera is outwards for a few thousand feet (I chose 10km, because why not) and seeing which objects it intersects. Luckily, most of the complicated math for seeing which objects the line touches are handled by the physics engine (it even has a special function designed for it!). The trouble is always in the part you overlook, and in this case that was actually calculating the position of the line! I was lucky enough to stumble on some example code that calculated the end point of the line for you, through some complex trigonometry and interpolation, and so I spent about an hour trying to get it working in my engine, to no avail.
Then I remembered one one of my basic rules of programming: never steal code when you don't understand what it's doing. If you're lucky, the code will 'just work' and you'll have some cool new effect in your particle engine without any work on your own part, at least until you need to change something. God help you then. Good luck trying to decipher all that code months later, when whatever bits of understanding you had before are long gone.
So I went back and sat there for a second, and ten minutes later I had some custom code using a completely different math working perfectly. Just put a point at the mouse coordinates, and one unit into the screen, rotate it like the camera is, and then scale it by 10km! Five lines of code which will work with any setup the renderer could use instead of 40 lines that would break if I changed the field of view. From there it was a simple matter to code up a select and move tool and hook them to some fancy buttons (which took longer to whip up in Photoshop than coding the tools themselves did), and now I can pick up stuff and put it in other places.
Physics
Remember way back at the top of this post, where I wrote "Physics and Selection," never guessing that in the end I'd write about selection before physics? Well when I said I was lucky that my physics engine (Bullet Physics) already had a function to test the line against the object, I sorta lied. I actually added the physics engine so I wouldn't have to deal with writing that single function myself. A bit overkill, but like anytime I do stuff the right way instead of the simple way, I'm always glad I did later down the line. As it was, adding physics to the engine was much easier than anticipated, thanks to the severe abstraction I placed on every aspect of development. All I had to do was read out the position of each object and plug it into my code for handling positions (which can also handle positions with quaternions, euler angles, and even ones that orbit another object), and then I was done, no changes to any preexisting code required.

blog comments powered by Disqus