#prjz notes

Character Speed: Speed is defined as magnitude of the vector velocity. The direction of the vector velocity is in the forward direction of the model. The forward direction is defined as the local Z axis of the model.  It’s unit is meter per second squared. where does it come from? We can think about speed in terms of mechanical work and mechanical power. From these we can derive a sensible speed value which works in our game. Conversely we can reverse this process and derive mechanical work and mechanical power given speed. Or we can think speed in terms of power and thrust. For example, we can add a module which defines some power and produces certain thrust force (or just conceptually think about the power and go directly to thrust, a force). With this thrust force we can derive the velocity and thus the speed. Example: A sprinter can run forward with a speed of 10m/s^2. Character Jump Speed: The same  except it’s it’s the magnitude of the vector velocity quantity in an upward direction. This upward direction is currently defined as the Y axis of the model. System Design or how the system works currently: -Uses a Kinematic Controller from bullet physics. Here is a good reference on what they are and why they are: http://www.digitalrune.com/Support/Blog/tabid/719/EntryId/40/Kinematic-vs-Dynamic-Character-Controllers.aspx why use capsule shapes, does that mean I can’t do precise collision detections? The capsule shape used to model the character has nothing to do with precise collision detection. You can view the CC (Character Controller) as the top level controller for the character. Later on, if we want to have precise collision detects--to be used in a fighting engine for example-- we can implement that separately--mostly like on top of the CC by delegating specific actions--which uses either convex hull or triangular mesh. This blurb from the above link goes into more detail on why it’s better to have a separate CC: If you already use a physics engine, it sounds tempting to use it for the character controller because many things come for free: non-penetration, gravity, pushing objects and being pushed. But: physics engines compute "rigid body dynamics". And a moving human does not behave like a rigid body! Rigid body dynamics supports restitution, friction, inertia - things that have a different meaning for a character. And a character controller supports arbitrary slope limits, stepping up/down, etc. - things that have no natural counterpart in rigid body dynamics. In the end, in a Dynamic Character Controller a lot of time is spent disabling features of the physics library and adding artificial non-physical behavior. What does that mean exactly? To get get any behavior out of the CC, we have to modify it’s code to get the behavior we want. If you don’t like the current jumping behavior? We can change it. (On a side-note, why does it continuously jump like that? Because the instance it finds the ground and if you have the jump key held down, it re-executes jump again off the that ground. Thus one fix the key control which controls jump to do one off hits. See a lot of things are just minor tweaks like this which I haven’t found the time for.) Stepping and Animation Stepping, forward, and Sliding. The CC works like any other CC since days of Quake2. It implements stepping, forward, and strafing functions. It sweeps out a certain distance into the world and attempts do collision detection. If a detection is hit, it uses the information from the detection point (hit location and normal) to implement stepping and sliding. For stepping, it attempts to slide a certain height in the air until the targeted spot is reached, if it fails to reach a targeted spot it will fall. To adjust the stepping behavior, one adjusts the stepping height. I have adjusted the stepping height to be 0.5 from a previous value of 2.0. Sliding and stepping as implemented by Bullet Physics works best with sloping environment, i.e. normally it treats vertical surfaces as walls, something that is not intended to be climbable. One can achieve climbing behavior--sliding up vertical walls-- by setting the slope angle to be 90 degrees. Stepping height After tweaking some values, you can no longer step up blocks of height two. More precise stepping It’s possible to modify the CC code to get better stepping, sliding, and strafing behavior given the assumption that environment is cubic. One way to do this is to adjust CC code relating to stepping parameters in order to achieve a better behavior from the parameters. Another route is to use the collision point to get slices of voxel from the world. Given a collision point, it’s possible to return a neighbor hood of voxels. With this extra information, one can determine the behavior of the CC much more precisely. Another thing to consider is the collision behavior is between a convex shape and a triangle mesh. In the game we turn the voxel world into triangle surfaces. A while back I looked into the possibility of using convex cubes for the environment rather than triangle mesh. Doing so will also make the collision much more precise. Animation with out IK. There are a couple different types of animation in games. In most older, and simpler games, the animation is decoupled from the physical game world--meaning the animation are simple event driven playbacks without physical feed-backs. Newer animation packages such as Natural Motion are combinations of physical feed-backs and animation playback. The original plan was to implement a trigger based event driven playbacks of animation. Imagine Prince of Persia. The CC would trigger an event, the event which is mapped to a particular animation state in Alienmotion (see Alienmotion) and thus begin playback. If say the animation was designed to have a speed of S, that is we can correspond the playback of the animation to a certain distance D (relationship between speed S and distance D), then we can set up the point at which the event is generated, i.e. at distance D from a block we trigger animation play back given speed S. This automatically implies that as we play the animation, it will slide forward because we associate the animation to a given distance D. So if the animation is precise enough, it will look good. If it doesn’t, it will still ok because of this association of speed and distance. Animation and Sliding How does these two work together? Because of sliding and all that, the above relationship S and D won’t be exact but it will still look fine. When unable to step up then trigger a different animation or don’t trigger any. Jump Animation Jump animation works the same way. Associate S with D. I think it won’t work Well if it don’t work it don’t work. BUT I say it still work look like 100% shit. It will just look like most of the games that went before this. You just have an animation play while you slide and jump. May look silly but it won’t look like shit. what about fancier shit? IK. Maybe IK would do it. Mentioned above in the stepping section, we can get a bunch of voxels so we know precisely the configuration of the world. So we know precisely where to place the pivot point. Then just do some fancy IK stuff and tie it to the animation.

-Ogre HDR Compositor NaN values For some reason if your shader output NaN values, the HDR shader will not work. Because garbage in garbage out when it comes to NaN, in that everything touching NaN will become NaN. So I added a check for isNaN in the shader and it fixes it. It's a temp. fix since I still need to figure out why some pixels are NaN. But it works for now. -Depth Buffer Sharing: Depth Buffer Sharing works but you have to do setClearEveryFrame(false) on your render target because if this is true, instead of clearing every frame, it clears on every render. So previously while I was sharing the depth buffer, the depth buffer gets cleared every time the depth buffer is rendered.

Also the example doesn't load mip maps. I ended up loading a uncompressed dds with mip maps and load each individual mips into the texture. Works for now. But we're going to need the ability to load compressed dds later on. 

I noticed mElementList of VertexDeclaration contains and weird 0th entry for VertexElement, in that all of it's enum values contain values out of range of the enum defines. Maybe this has something to do with a bug in ManualObject? Why ManualObject? I use them. So perhaps it creates an invalid VertexElement entry.

For saving, my initial implementation involves saving the data out when it's been dirtied. My setup already supports the concept of dirty pages, so everything just fits. Now I need to add a step during page dirties which serialize the data out to disk, both volume and height data.

So I decide to workaround the issue. I don't really want to implement a custom terraintoolwidget. I rather get the feature working first then make it look right, so I will still be reusing the widget. The workaround is a single line modification in qtOgitors mainwindow.cpp, where the terraintoolwidget is added to the default terrain editor factories. I just grab my own terrain editor factory and attach the widget to it. It's that simple. In the future I may write a patch and let plugins have the ability to register themselves and have it so in mainwindow.cpp we iterate all the registered factories and attach the custom widget to it. Although I have to ask the forums to see if this is indeed necessary.

Gonna ask on the forum and call it a day. 

The EngineEditor corresponds to PRJZ engine's EngineController.