Milestone 3

[RonHiler]

I've put up a draft M3 list.

http://www.rjcyberware.com/GameEngine/EnginePlan.html

It's much longer than I really like, but the goal of M3 was to be able to put up walls A lot of groundwork had to be covered to get it to that point, so it's a long list (47 items). I knew it would be, and a lot of it is less trivial than the stuff that's been done so far.

The list is still a bit preliminary, and won't be finalized until I finish M2. I'm very close to that, however (working on M2 items 16-18 right now, which are quite simple actually (just some basic text file handling), then doing a little bug killing and we're done). In the meantime, I know some of you have more experience with level editors than I do (mine is limited to some playing around I did for a couple of weeks with the Doom 3 level editor), so if you have suggestions, please let me know as soon as you can.

Shane, that especially includes you Since you are, at the moment, the single volunteer level editor we have, and this is going to be the tool you will be spending a lot of time in, presumably, hehe, you should definitely go over this list and make sure you like where it's going (and just a note, the level editor stuff doesn't start until M3 item 8, the first 7 being improvements to the existing project screen).

Don't expect the editor to do much, even after M3 it will be quite primitive. I expect the majority (if not all) of M4 will be improving this same editor rather than moving on to a new editor. The M3 level editor won't even have a save function, so you won't be able to save your levels yet, heh.

Ron

[RonHiler]

Yeah, late night here. Insomnia is fun

M3 list updated. The first 7 are done, so I'm about to move on to the level editor screen (finally an editor, yay!). The only one that really gave me any trouble was the first item. Amazing how much memory you can bleed very quickly when you forget to release even a single control. I had a test edit box on the first screen (it's not even a real control, just one I stuck there for debugging purposes) and I forgot to release it on shutdown. When you resize the screen, it essentially dumps everything and rebuilds the graphics for that screen. Well, after about 5 resizes the program would crash just because of the video memory eaten by that one control. Sheesh.

I've run across a couple of bugs that snuck through the M2 build, so I'm going to go back and fix those before moving on, but nothing major. For some reason, the Directory Crawler filter stopped working. It was working at one point, honestly Also, the Recent Files list is sometimes saving the .prj extension as part of the name in the configuration file, which it oughtn't do. Silly Recent Files list.

[RonHiler]

M3 list updated again. I've been going through the list pretty quickly so far, though it may slow down a bit from here on out. The immediate stuff coming up will have a lot to do with 3D camera manipulation, and while I've already done a fair bit of that sort of work, this is going to involve multiple cameras, so it may get a little more complex than usual

[Strike]

Multiple cameras? ( Or should I just go RTFList? )

[RonHiler]

LOL, "RTFList", that's pretty funny

In this case it actually wouldn't help you. I try to keep all the technical details off that list as much as I can. It's not meant to be a technical document, just a guideline (primarily for me) on what to do next. I keep it online on the off chance anyone is interested in what is going on with Enzyme at any given time [Plus it's a fairly convienient place for me, as long as I have internet access, I can always check the list no matter what computer I'm on].

The reason for multiple cameras is to allow the design area (where walls will be put in among other things) to accomodate multiple areas. If you've ever used a level editor or a 3D modelling package (or even taken drafting in high school, heh) you will be familiar with this concept. You set up a four panel design area, setting each panel to a particular view (typically top, front, left, and 3D). Each of these design areas get it's own camera, which just provides a vantage point to the scene. All of these cameras point at the same scene, just from different viewpoints. Using these views, you can easily adjust/move/rotate vertices or polygons or splines or models )or whatever it is you're tweaking) in 3D space.

Sovereignty uses a camera, as does Manifest Destiny (as does any 3D game for that matter) to simulate your perspective in the world. However, in most games you usually don't encounter more than one camera (there are notable exceptions, for example, in a driving game if you have a rear view mirror, this is almost certainly done with the use of a second camera).

I was going to say that I've never had more than one active camera going at once, but I take that back now! The avatar view in Soveriegnty (the one where the legs spin in a circle) was done with a second camera. I had just about forgotten about that There's nothing inherently difficult about more than one camera. For each camera, you just tell it where to be and where to point, and what area of the screen it's responsible for updating, and there you go, hehe.

The only reason I made a big deal out of it is that I have to make each camera pretty configurable. Each viewport will be selectable for the type of view (top, bottom, left, right, front, back, 3D), and each view type will have movement constraints (for example, if I make the mouse wheel cause the active camera to zoom along it's primary axis (a reasonable thing for it to do) a left camera should move along the x axis on a mouse wheel, while a top camera ought to move along the y axis, and so on). It isn't really THAT big of a deal (you can actually just tell the camera to move along it's viewpoint axis in a general manner) but it's less trivial than most of the stuff I've been doing so far.

Ron

[Strike]

Ah. I'd always assumed that camera-switching was moving the camera itself, not using another one.

I guess having a second camera makes switching views faster, and easier to track where its at if its mobile.

[RonHiler]

Ah. I'd always assumed that camera-switching was moving the camera itself, not using another one.

Depends. If you're only showing a single sceen at once, it's probably just one camera that's been moved. Less calculations that way The only time you want more than a single camera active is when you have to show more than one viewpoint of a scene or more than one scene at the same time.

I guess having a second camera makes switching views faster, and easier to track where its at if its mobile.

It helps when you realize that, unlike TV, a camera does NOT have to update the entire screen. Often, it does, but not always. I can set a camera to render to just a portion of the screen. The portions each camera is responsible for can even overlap. This is what happened in Sov, where the first camera updated the entire screen and the second just updated a small portion in the upper right corner to show the rotating avatar. The results from camera 1 were rendered first, then the results of camera 2 were rendered on top of that (with transparency), which gave the effect of you seeing the world, and then the rotating avatar (aka the paper doll) floating along the top right side.

That's similar to what is going to happen in the Enzyme design screen, where there will be four cameras at once, all pointing at the same scene from different viewpoints, but each one will update (roughly) one quarter of the design area. There won't be any overlap of screen real-estate in that case.

I could really confuse you if I tell you the cameras actually never move, heh. In fact, all cameras are always at the origin pointing in the same direction (it's a calculation simplification thing, and less calculations means more speed). When you "move" a camera, what actually happens is the world moves (if you are playing a WASD game and hit A to turn to the left, you actually stay put and the world shiftsto the right). Meditate on that for a while But then forget I said anything about it, for all intents and purposes, you can think of cameras as moving around the world just like they would on a movie set.

Ron

[Strike]

Ah, right. It's been a *long* time since I've poked at CAD-style programs.. Never got the hang of the POV-Ray modeler one, so I had fun writing scenes by hand

I'm learning lots of stuff here, thanks! And remembering a little bit, too.. There's a reason I only took one Comp Gfx class in college.

I can understand/beleive that the cameras never move, it's just not intuitive, so I try to ignore it Transformations are nice so long as you keep them in the right order... (blasted matrices)

So what calculations get simplified if you're not moving the camera?

(This is what I get for reading this at my bedtime -- I'm asking questions first, then thinking about the answers instead of thinking first & volunteering answers)

[RonHiler]

I can understand/beleive that the cameras never move, it's just not intuitive, so I try to ignore it Transformations are nice so long as you keep them in the right order... (blasted matrices)

Good plan

So what calculations get simplified if you're not moving the camera?

You touched on them, the transformation matrices. There are (usually) three of them (World, View, and Projection transformation). The components of the matrices get filled in with various equations, dependent on position and orientation of what is being transformed. By keeping the cameras at 0,0,0, a lot of the matrix terms and/or the values in the equations that go into the matrices fall to 0.

Since every vertex of every model in a scene has to go through all three of these matrices at least 30 times a second (and hopefully more), you can imagine that reducing the complexity of the matrices (and thus the resulting calculations) is of paramount importance

It also helps with other things. The example that pops into my head are pick rays. When you click on the screen, a whole series of calculations have to be made in order to determine what you've clicked on (if you are clicking on a 3D scene). Essentially, this is a reverse order matrix transformation, because you are clicking in screen space and ultimately, you have to convert the x,y of screen space into world space and then into model space. Once again, by having the cameras at 0,0,0, a lot of the terms of the various equations drop out.

[RonHiler]

Milestone 3 list updated again. Polished off another 4 items on the list

Item 16 is now at 90%. It's essentially done, just have to change the order the screen is drawn in so that the sep lines don't overdraw the control panels. No big deal there. Otherwise, it works. For some strange reason, I find it very cool that I can drag the sep line around, hehe.

I moved what was item 19 up to item 17. Normally I wouldn't change a list once it's set up, but this was just an oversight on my part when I made the list. Can't change the background color of a camera viewport before the cameras even exist