Courses/CS 491ab/Winter 2008/Sassja Ceballos

From CSWiki

Jump to: navigation, search

Sassja Ceballos


Contents

[edit] Week 1 - January 4, 2008

Introduction to CS491a.

[edit] Week 2 - January 11, 2008

Presenting Makehuman 0.9.1 RC1 At the moment, the specifics are up in the air; however, I am strongly leaning toward a procedural animation system for human models. Examples: sumotori, euphoria, ?

[edit] Week 3 - January 18, 2008

Brief Overview of Lightfeather 0.6.0

[edit] Week 4 - January 25, 2008

ODE for game physics

[edit] Week 5 - February 1, 2008

Example project demonstrating ODE physics built with Lightfeather

[edit] Week 6 - February 8, 2008

Switched from Lightfeather to Horde3D

The best way to describe what I will be making is by describing what it is NOT. Modern RPGs produced by major companies, while well accepted by the general public, are seen by many as being shallow and not evolutionary. An great example of this is Bethesda's 'The Elder Scrolls IV: Oblivion'. This game, while graphically stunning is very bland as a roleplaying experience. It has: linear plot line, dead non-player characters(personality), and unfulfilling character development.

Linear plot line: play a clichéd plot line, with no effect on the outcome Dead NPCs: lack reaction to events; very few in towns; don't seem 'lively' Character dev.: artificial difficulty (becomes hard, but with no compensating feeling of achievement); lacks tactical and strategic depth (which taints combat; repetitive)

Anything good? Expansive world, GRAPHICS!!!111!!1, immersion (while freely exploring/wandering aimlessly AND while not riding on a horse)

Even more recently, there has been a trend for diablo-esque (dark? fantasy, hack-and-slash, action RPG) games, such as 'Loki' and 'Hellgate: London'. I emphasize hack-and-slash, which basically equates to 'click for your life'. Even though this is standard for RPGs of all types, to varying degrees, I feel that it lacks depth. While I do not propose to use Turn-Based gameplay, in the like of such masterpieces as 'Fallout I' and 'Fallout II', I think that a system of slowing motion for gameplay (to queue commands, for example) would be very effective in making the hack-and-slash elements more tactical, while maintaining, or even emphasizing, the 'action' elements.

[edit] Week 7 - February 15, 2008

[edit] Week 8 - February 22, 2008

Evaluating OGRE3D and Irrlicht

Currently I'm confused what I should use. They all have their plus sides, so I'm thinking more about usability now. After working with the demos, OGRE seems like it is the easiest, though I am not sure how well it does against the others in performance. Since procedural animation is a very expensive set of operations (using physics, inverse kinematics and tetrahedral meshes, for my purposes, among other things), I wanted to put performance at a priority; however, now I'm am considering usability to be most important, especially GUI features. I was considering C# for a time, but since I am not proficient with it, C++ is probably better.

As far as work goes, I've been reading papers/books on physics, deformation and animation, and working out how I will combine them. One of the main problems is that physics engines maintain completely separate world-spaces from the rendering engine. Although this is good for performance of the physics engine, it makes combining it with animation (specifically, animation that must be able to be freely interacted with within it).

[edit] Week 9 - February 29, 2008

Because of time constraints, I've chosen to focus on the physics modelling aspects of a game engine. I will take preconstructed code, from libraries such as Bullet, ODE, and IBDS, and apply it to a tetrahedron based physics model, instead of using triangle meshes or discrete solids. I also plan on building the underlying data structures to support procedural skeletal animation, though I won't be working on the implementation of that just yet.

[edit] Week 10 - March 7, 2008

[edit] Final Report

[edit] Brief Project Description

To modify a physics backend (Bullet) to support: mesh deformation and mesh fracture. This consists mostly of translating and combining algorithms from in various research papers into useable code and making a data structure that is compatible with Bullet. I hope to be able to make the models embeddable within each other (efficiently), to represent 'skin covering muscle covering bone' and other similar layered materials, to further demonstrate the potential of this simulator.

[edit] Anticipated Users

This project will be directed at game developers who want to portray greater perceived realism in their games through complex, freeform environments.

[edit] Main Conceptual (i.e., user-level) Objects

Internal model description (used for animation, collison, physics simulation)
Point index, tetrahedron list, and adjacency info of neighboring tetrahedrons.
External model description (used for game logic, AI, rendering)
Subset of internal point index, triangle list(s), stressed-area list.
Level-of-Detail meshes (user can define quantity)
Simplified version of model
Material properties (user controlled) Strength of Materials
Elasticity
Plasticity
Strength
Yield strength
Compressive strength
Tensile strength
Fatigue strength
Impact strength
Forces (applied by scripting, input, ai, animation, collision, within physics sim)
Shear stress
Compressive stress
Tensile stress
These meshes will be assigned properties based on user defined materials, such as wood, metal, plastic, perhaps even rubber and skin. The physics loop will then be run on these objects, which will be deformed on impact with other objects. The force of the deformations will be returned to the user to be used for metrics (keeping track of damage done, etc).

[edit] Primary Conceptual (i.e., user-level) Operations

During:

Load
Models will be preprocessed into a compatible mesh format prior to loading.
Simulation
Set position
Apply forces
Direct impulse application
motors, thrust, collisions (real or imaginary)
Indirect force application
muscle tension
tethers attached to the model (for puppet-like control)

[edit] Interest in This Project

Animation in modern games still seems far too fixed/canned/discrete. Developers make up partially for games' lack of dynamic animation with keyframing, AI, and entertaining gameplay, but it would be very useful to have a less manual method of adding dynamic behavior to games. Having a physics model that supports procedural deformation will help alleviate this. Although many recent, major games have [or will have] this support (Aegia PhysX and Havok are developing it for mainstream use, but the only real mainstream simulator is Digital Molecular Matter), there is nothing for indie or open-source developers. I am aware that the mathematics can be complex/daunting/disheartening/etc, but will be able to deal with it; for what I don't already know, I will learn.

[edit] Project Status

[edit] Model Format

Research 9%
.25 tetrahedral mesh (Papers by Ronald Fedkiw)
.05 meshless point model (Point-Based Animation; Point-Based Graphics)
.00 finite element analysis & method (FEA; FEM)
.01 combination of above techniques
Code 0%

[edit] Bullet

Research 10%
.15 general use of library
.05 inner workings
.05 world representation
.05 world simulation
.30 collision detection
.30 collision evaluation
Code 0%

[edit] Simulation

Research 14%
.20 force and impulse
.30 collision
.05 fracture
.10 core concepts
.01 evaluation
.01 deformation
.02 core concepts
.00 evaluation
Code 0%

[edit] Test Environment

Research 53%
.75 decide between Irrlicht or Horde3D or LightFeather
.32 test environment
.25 contents (models contained in it)
.40 user-input
.20 user capabilities
.60 user control scheme
Code 0%


Note: I am using a weighted measure for progress percentage where the sum of percentages of a subset divided by the quantity of items in the subset (rounded down) gives the percentage complete for the parent. This has the effect of making the project seem less complete in total as more items to do are added, since they are given equal weight; however, with careful grouping, this should become less of a problem as the project progresses.