NEWS
This is the news page where you will read about the development
of the project. You will read it and you will love it. It will change your life
forever. You'll see...
New: News Lite™: your source
for all the news on Eric's project without all the BS!!!
4/30/2002:
I didn't feel like writing an entry yesterday, but
I merged the three action keys (pick up/put down, load, and fire) into one
context-sensitive action key. If you are near the cannon and it is loaded,
pressing Z will fire it. If you are not near it, pressing Z will pick up or
put down stuff. If you are near the cannon and it is unloaded and you have
ammo in your hands, it will load the cannon. I basically tried to make it
do whatever you'd probably want it to at the time.
I also tried fixing the pesky collision detection
problem with the walls. It is now extremely hard to break through the wall
:^) But you can easily see through it if you run really close and parallel
to the walls or jam yourself into a corner. Today while I was working on the
cannon collision detection I figured out why my technique is not working!!!
It's very frustrating to realize this at the end of the project, but I may
have time before the public release to fix it. Here's an explanation of how
my technique works, followed by the reason it doesn't work perfectly.
Every frame, each object's motion vector is tested
for intersection with the plane of every wall segment. If they intersect and
the distance between the object and the wall plane is less than the object's
radius (pretend it is a sphere) plus the distance it will travel next frame,
then it tests for collision in a more detailed fashion to ensure that it actually
hits the wall segment (the previous test tells if it collides with the infinite
plane of the wall). Did you catch the mistake? I hope not because it took
me forever! Here is the killer: If the object is very close to the wall and
is moving almost parallel to the wall but slightly towards it, the motion
vector will intersect with the wall's infinite plane, but really far away.
Because this test fails, the object is allowed to continue moving. Therefore
it moves closer and closer to the wall until finally the object's center is
so close to the wall that it can't escape detection. You can break through
the corners because each time you 'collide' with the corner, it displaces
you so that you slide instead of move forward into the wall. This displacement
should not allow you to ever break through the wall, but because of the first
problem, it happens.
The solution (I think) is to measure the shortest
distance from you to every wall and not just the one that is in a straight
line ahead of you! If any collisions are found in this manner, the 'sliding'
technique should be applied and the detection continued. It is very important
to me to be able to slide along the walls :^) It makes things much more comfortable.
Unfortunately I used the 'stop on contact' technique when dealing with object
collisions. You cannot slide around an object.
You can download this version of the project here.
May 1st is the deadline and I am presenting the project to the advisory board.
Hopefully I can nail the problem between then and the public show.
4/28/2002:
Today I spent a lot of time tweaking and testing
the program. Unfortunately I didn't get to that part I've been saying I'd
get to for the past while, but I felt the need to push a new release out the
door. This one is called "Funland Alpha".
The most noticeable difference is that the spring is gone and the turbofan
is behind the barrier near the target. I guess it's no surprise now that the
fan works and you can't walk through walls, etc. :^) I tried to find ways
to hit the target by bouncing the fruit off the walls first, but it's REALLY
hard. I couldn't do it a single time. I tried numerous positions but nothing
really worked.
Also, now that the barrier blocks you from walking
across, you either need to reset the game after all the ammo has been fired
onto the unreachable area, or cheat and get the ammo. Unfortunately it is
possible to cross the barrier and it is possible to break through the walls,
but it takes some effort and isn't immediately obvious. This is the kind of
thing that would take hours to iron out and at this point it isn't worth it
to me.
4/24/2002:
I got one of my enormous programming assignments done, so I decided to celebrate by making the turbofan functional. Objects that pass above it will be blown upwards. The amount which they are influenced decreases with their distance from the fan.
Like I said last time... next will be the routine that prevents you from
moving the cannon through the walls.
4/23/2002:
I've been too busy with other projects to get anything
done on this. Ironic that it is due Monday... Anyway, I implemented camera-object
collision detection today. It is probably the easiest and most efficient of
the CD algorithms I've done so far. It simply uses 2d circle-intersection
to test if your 'bounding cylinder' collides with the 'bounding cylinder'
of the object. I actually thought this one through myself an I even used a
dot-product to determine if you are heading in the direction of the object.
I've decided there will be no camera-ammo collision.
It is completely unnecessary. Next will be the routine that prevents you from
moving the cannon through the walls.
4/21/2002:
I took almost a week off from the project! I needed
a break and I needed to work on other assignments. Today I implemented camera-wall
collision detection. I even made it so you slide against the wall instead
of stopping on contact! However, if you slide back and forth along a concave
wall surface, you will get closer and closer to the wall and eventually be
able to break through it! This is not good, but it also requires you go out
of your way. I tried a couple of easy no-brainer techniques to beat this problem
but they resulted in choppy motion when you slide along the wall and it looked
bad. Anyway, I'm happy I got it working. I used a different method from the
ammo-wall collision. This one only requires two dimensional collision detection
since you never leave the ground and therefore it is less processor-intensive.
I kind of adapted this method myself from a method I had seen for sphere-sphere
detection in combination with the bouncing algorithm to get the sliding effect.
The sliding effect was surprisingly easy!
4/14/2002:
Decided to release the current state of the project.
Check it out! Things bounce off
the walls and floor and I think I nailed the problem I mentioned last time
without resorting to incremental testing. Ammo passes over the walls if you
aim it there. I made a brick texture and put it on the walls. There is a wacky
problem with the orientation of the texture at two places along the wall and
I've tried a few ways to eliminate it, but the only possible way I can see
would be extremely tedious and not worth it.
Things have come so far since I started (obviously)
and I can't believe how much I've learned. The next things to be implemented:
camera-wall collision, object collision. This stuff isn't fun.
4/12/2002:
I've been trying to get wall-plane detection to
work and ran into an interesting problem. It worked on some walls, but others
it passed through the wall and detected the hit way after. My debugging technique
was to have the object freeze instantly when it hit a wall-plane (the infinite
plane of a wall) and to play a sound. The objects would stick in mid-air in
the middle of the level, but on the sides they would mostly stick in about
the right place. Things were very odd and I was confused. I kept testing,
trying to draw a pattern from where the fruit would stick. They were clearly
sticking to some invisible plane, but this plane was not an extension of any
of the walls. After some time I noticed that they seemed to be sticking to
where the walls would be if the level were flipped around in a mirror image.
Some testing confirmed this suspicion and
I fixed it rather easily. It appears that my entire coordinate system is reversed
:^) I'm amazed that I haven't noticed this before. I suspected it may be the
case, but it was never an issue or a problem until now!
There is still a problem with the sensitivity of
the detection. If the fruit happens to pass through the wall at a fast speed
and at just the right time, it will not be detected, so I may need some kind
of incremental testing to track the path of the object between frames. Otherwise,
it seems to be in order. The next step is to add the 'inside the polygon'
test to see if it actually hits the wall, not just an infinite extension of
the wall.
Thanks to Professor Perry Susskind for answering
my linear algebra question. Your name will be in the credits, I promise :^)
4/10/2002:
I implemented some collision detection FINALLY.
As of now, there is gravity and things bounce off the ground in a fairly convincing
manner. It's fun to watch :^) I figured because there are walls on all sides,
it would be okay to make the objects bounce when they hit the (infinite) plane
of the ground. Also, when you pick up a fruit and the drop it, it falls to
the floor and bounces :^) It even has some unintended random rotation when
that happens. Cool stuff.
I'm currently working on making stuff bounce off
the walls, but I ran into a linear algebra roadblock.
4/09/2002:
Despite the fact that it was not so important, it
was really bugging me that the cannon looked so soft and fluffy. I thought
of a great way to fix that when I was in the shower this morning, however,
and I did it in about an hour. I simply seperated the inside of the cannon
barrel from the rest of the barrel and made them seperate meshes. Seperate
meshes will not smooth together, so it looks perfect now. I also made a neat
grainy texture that looks great stretched. Check
it out!
I've also been creeping towards implementing collision
detection. Last night I found a great
website with a simple C-D routine and explanation, and I have copied the
code and repurposed it. The site belongs to Amir Shavit who seems to be a
pretty talented guy. I've been researching C-D on and off for several months
and so far everything has been either too vague or too difficult to understand,
so this is a godsend. According to Amir himself, this code is extremely inefficient,
so I plan to optimize it for my game.
I decided it was time to distribute the code a bit
more, so I copied a bunch of code into a 'utilities' file and a new header
file. The 'catproject.cpp' file was well over a thousand lines long, so compile
times were getting ridiculously long. Managing a project with several files
is really stressful. Linker errors are completely unhelpful :^)
4/08/2002:
Wow, has it really been so long since my last update? I pretty much relaxed and partied this weekend. I've been philosophizing about collision detection and I wrote up a list of which technique to use for each type of collision. Not all collisions are the same. In order to optimize, it's best to do the simplest type of collision calculation possible. Sphere-sphere is the easiest, followed by sphere-plane, sphere-polygon, and finally polygon-polygon. I am still a bit foggy on the specifics of all except sphere-sphere unfortunately. It is extremely difficult for me to think it through.
As a result of this difficulty, I've put it off
yet again! I was close, though! I built some walls and I want to start doing
sphere-wall collision, and maybe sphere-ground, but I just didn't. Instead,
I implemented vertex-shading!
At first, I was so shocked at how different it looked that I hated it, but
I quickly warmed up to it and now I think it's pretty much great. My only
problem with it is that it makes the cannon
barrel look like a big pillow instead of a mean cannon barrel. I may re-texture
it to add the illusion of edge-sharpness, but that's really not important.
4/03/2002:
Come and get
it! The playable "Funland alpha preview" has been released.
Features not mentioned in the previous news entry: sound effects! They really
bring the game to life. Also, the controls have been changed and simplified.
Read the readme for instructions. This is so exciting I'm thinking about calling
it quits... ha ha ha. Wouldn't that be nice?
I plan on implementing collision detection next
so I can add gravity. After collision detection works, I can probably make
use of the spring and turbofan. After that, I'm going to add a title screen
and different levels. I'll keep you posted.
3/31/2002:
MAJOR DEVELOPMENT!!! You can finally interact with
things! You can pick up ammo, drop it into the cannon, aim the cannon, and
fire it! There is no gravity, so the ammo goes flying in a straight line forever
after you launch it. Also, I re-organized the object movement function so
it takes place before things are drawn, and takes time into account. Therefore,
things should move at the same speed on all systems. Problem: when picking
up ammo, you will pick up the closest ammo in a certain range, including what's
behind you! Maybe I'll change this, but it seems pretty unimportant.
It seems like I may finally be forced to implement
collision detection. I've been putting it off for a long time, but there's
no avoiding it. I'll polish this cannon-launching demo soon and then release
it. Then I'll work on collision detection. Without it, you'll never know if
you actually hit that target!
3/29/2002:
Okay, I've decided to release the
current state of the project. Major changes include First-person perspective
with time-based (monitor-independent) camera motion, the tree, the target,
the spring. Please note that object movement is still monitor-dependent and
may run faster on some monitors than others. Check your FPS to verify this.
Mine is usually about 63. Please read the readme, as some controls have changed.
The reason I'm releasing this is to test whether
or not it gives smooth camera motion on all monitors. Please check the number
on the bottom left of the screen. It should be a number that flickers when
you walk and the range of variation should not be more than 3 or 4. If it
is, then I need to find another way of fixing the framerate synchronization.
The excitement of releasing this has been marred by the difficulty of making
things run fluidly! It's really a drag to waste all this time on something
I thought would be simple.
3/27/2002:
Spring break was good. It was nice not having to
work on this project all the time. Since I got back, I've had a lot of work
for other classes, so all I've done was make a new grass texture for the ground
and changed the sky to a more cheery blue sky.
I decided it would be cool if I scanned the doodles
I used to design the objects. They were all done during networks class, so
you will see various techno-babble along the sides of the doodles.
The first one contains the evolution of the cannon
(more or less top-to-bottom). The second one contains my thoughts on how to
make the cannon in a low-polygon form. It also contains my first idea for
the trampoline (now a spring). The third picture contains the evolution of
the spring. It continues in the fourth picture. The fourth picture also contains
a funny idea that I may or may not implement. The final picture has my doodles
for the ammo tree. To the right is a 'guided missile' that I may use.
3/13/2002:
I was not in a programming mood, so what I did today
was mostly artistic stuff. The only technological changes to the project was
the ability to read in starting rotation coords for each object. Position
is not enough :^) Also, I seem to have no choice but to revert to 800x600
resolution unless I can somehow beat this polygon fill-rate problem I'm having.
The first model I did was the target! It is a stellated
icosahedron with a cool pearlized texture. Along with this new model, I also
made the ammo tree! This tree has ammo growing from it, such as apples and
oranges. See both of them in this
screenshot. Oh, you want another
screenshot? There, wasn't that nice? Today was fun because the art stuff
is always more fun than the programming :^) On the other hand, there is nothing
more satisfying than getting a major new feature in the program to work correctly!
I will be going back home for a week and a half
now, so that's about it until later. Sorry I'm not releasing the current demo,
but I want to add collision detection or something, and then I will release
a new one.
3/11/2002:
So lonely here at school! Spring break is
supposed to be for fun, not work! Oh well.
I have plenty to show, and it's all in this
screenshot. I am having issues with the framerate dropping to 30 fps at
times. Very frustrating! I'm hoping someone at the NeHe Gamedev forum can
help me. By the way, I discovered while sorting through random forum posts
that the reason my friend was getting 200 FPS was because he has his video
card disabling vertical-sync automatically. With this feature disabled, my
program will swap frame buffers (update the screen) as fast as possible, ignoring
the monitor refresh rate. With v-sync enabled, it refreshes in sync with the
monitor. That's why my framerates have been constantly 60 or 30.
I have implemented first-person perspective, which
was not as hard as I had thought. Thanks to Ben "DigiBen" Humphrey
for the camera tutorial on www.GameTutorials.com. My big problem was getting
the sky to look nice! I spent HOURS trying to get DigiBen's skybox thing to
work with my project, but it looked like crap! It's basically a giant cube
hovering around you at all times to simulate a sky. Unfortunately, a cube
has CORNERS! So I went and made my own sky sphere! No corners, but there was
a strange (but understandable) texture effect where the sphere's poles are.
I simply painted that area of the texture black to cover it up :^) I could
have rotated the sphere, but I kind of like the effect.
The spring is now a part of the landscape! I couldn't
figure out a way to make it look nice for a while. I played around with different
ideas, but decided on the one you see in the above screenshot. The ground
is 100% temporary and I am aware that it looks like crap. I will make the
grass look better, too.
3/10/2002:
First thing I'd like to say: NeHe has posted
my web site! I had no clue because I thought he was going to e-mail me and ask
me to change something before he posted it. Check
it out and look for the March 5th news entry (I didn't notice until today).
I decided that, after all that collision preparation,
I want to work on converting to a first-person perpective first. So I am stealing
code from www.GameTutorials.com
for the camera class and adapting it for my project. It's a good web site
for learning OpenGL, but I felt more at home using NeHe's format.
3/6/2002:
I worked about 3 hours today. Some of that time
was spent deciding on the technical implementation for collision detection.
Because it is such an expensive procedure in terms of processor time, I think
it will be best to optimize the detection so that as little time as possible
is spent on it. To aid this optimization, every object in the scene will have
a collision 'type' assigned to it. The ammo flying around is the only type
that needs to have rebounds calculated. Also, the ammo uses spherical boundary
detection which is far less processor-intensive than per-face collision detection.
If you'd like to read about how I plan to implement per-face collision detection,
this is an excerpt from a Gamasutra
column:
Detecting whether a point is inside a convex polygon can be determined
very easily. Figure 1 shows a point inside a simple four-sided
polygon. Our first step is to create perpendicular vectors for each of the
polygon edges and a vector from the test point to the first vertex of each
edge. The perpendicular of a 2D vector can be created by simply creating the
vector, swap the X and Y components, and then negate the X. As you may recall
from previous columns, the dot product of two vectors defines the cosine of
the angle between those vectors. If the dot product for each of the edges
is positive, all the angles are less than 90 degrees and the point is inside
the polygon.
Note the part I highlighted: very easy?!?!? It took
me a good 20-30 minutes to thoroughly understand and verify this procedure.
Did I mention that I never took Linear Algebra? Anyway, objects that are on
the ground and are generally not in constant motion (cannon, fans, springs)
will have "collision meshes" which are ultra-low polygon meshes
that vaguely resemble the object they surround. These meshes are invisible
and are used for collision detection only.
I upgraded parseAse to accomodate for these meshes,
and I upgraded the object initialization code to read the collision type of
each object from a file. I also extended the Thing class to allow for a collision
mesh and a collision type. The 'createInstance' function also needed a tune-up
to produce unique Thing names for the instances.
On a side note, the apple_orange demo runs at 200
frames per second on a friend's computer (vs 61 on most people's), so I will
have to implement a 'performance limiter' at some point.
3/5/2002:
It's only 11:00, but I'm going to post my current
thoughts so I don't forget them. Right now I'm brainstorming options for two
things: explosions and collision-detection
The dillema is what kind of collision-detection
to use? Usually, axis-aligned bounding boxes are fine for detection, but what
about objects that not only need to collide, but to bounce off? This requires
collision-detection for EACH face of every collision-sensitive object in the
entire scene! Not going to happen! I've decided that the type of detection
will depend on what is involved. The stuff that will be launched out of the
cannon will be represented by a sphere. When they hit most things, they will
simply explode. However, I wanted the possibility for certain ammo to bounce!
Because of technical limitations, it will only be able to bounce off of certain
things. These things include: walls, springs (everything bounces off springs),
the floor, and other ammo. If it hits something like the cannon, it will explode.
That brings me to my next decision...
Explosions are incredibly hard to display realistically
in a 3D simulation. There are a few options, though: use particles,
shatter
the object, use an expanding texture-mapped sphere (or group of spheres),
play an animation,
or use a combination of these effects. A very realistic explosion in a 3d
environment is that used in Counterstrike. They use a combination of multiple
"billboarded" animations, animated sparkler particles, and a smoke
animation! They look so real, I never even noticed how complex they are! Also
another excellent explosion animation can be found in "Max Payne".
This one is actually far more realistic than the Counterstrike one because
the fire takes some time to go away. Really a top-notch job.
Screenshots for the Counterstrike
explosion and Max Payne explosion.
These were fun screenshots to make :^)
After all this "research", I've decided
to simply shatter the object on impact. One of the reasons for this is because
it seems like I can do this without having to do any more research on incorporating
animation into OpenGL. I can justify the 'no explosion' choice because the
things you launch out of the cannon aren't explosive! When was the last time
you saw an apple or an orange burst into flames? I think I will have some
room set aside in memory for the exploding object. When it explodes, I will
copy all the triangles into the new memory (this will require many new vertices
be created) and then give all these triangles motion vectors originating from
the center of the object so it flies apart. The pieces will not have collision
detection and they will vanish after a second. Because this feature is mostly
just a jazzy effect, I will save it for later!!! Collision detection will
be the next thing implimented!
3/4/2002:
Without warning! A new demo comes from out of nowhere!
Grab it while you can, it's the Apple
and Orange Special Edition! Contrary to my statement in the last news
entry, things continued to go smoothly and this demo didn't take long to make.
I modelled the apple and orange, which was fun. It may seem like nothing special
to have multiple copies of the same object, but it took a bit of engineering
to add this functionality. Only one copy of the geometry is stored, but there
are several instances of the 'Thing'. This is more efficient than reading
in several identical files and storing them all.
Also, this new demo uses 1024x768 resolution! If
your monitor doesn't go that high, then get a new computer!
On that note, a 'beta tester' of my project found
that his computer crashed when he switched out of fullscreen mode, so I decided
to transplant the project into a newer framework code. I'd like to make it
clear that I did not write the framework code! This is the windows code required
to use fullscreen mode, opening a window, closing a window, etc. Very boring
and uninteresting junk. Jeff Molofee gets all the credit for that part. His
web site is a great place to learn OpenGL!
I haven't worked any incredible amount on this thing
over the last few days. I'm not even going to estimate the amount of hours
spent since the last update because I don't have a clue. I've also been working
on the spring's textures, trying to make it look better.
2/27/2002:
Okay, as promised I have a new demo released! Check
it out! It allows you to control objects as well as their parts. It also
has the FPS-meter and a timer. Things are really going smoothly now, but I'm
sure that will change soon.
I'm not feeling very verbose right now.
I worked 3 hours today.
2/26/2002:
Today I got some nice stuff accomplished. I can
use fonts now, so I have a frames per second counter on the screen. I also
developed a new class called GameTimer and it is a timer that can be paused
and resumed and reset. It displays the time like 00:00:00 on the top of the
screen. I am very happy with it. I wasted a lot of time trying to figure out
the stencil buffer to make the text appear on top of the screen, but it seems
as though this slows everything down to literally 8 frames per second! If
I simply turn off depth testing and don't use the stencil buffer, I get a
blazing 62 FPS rate.
I was hoping to have a demo ready for today, but
I don't have time. Tomorrow probably I will have a cool demo.
I worked 4.5 hours today.
2/25/2002:
I was really sick last weekend and so I could not
do work on the project. A bit of a setback, but a much needed mental break
from this project. Anyway, my most recent accomplishment is creating a function
called 'thingLoader' that assigns each mesh to its appropriate 'thing' and
assigns each 'thing' to its appropriate 'master'. It knows this information
from the name of each mesh that complies with a simple naming convention.
Confused?
Each mesh has a name that it is given in 3D Studio
Max. The mesh needs to be named like this: 'mastername_thingname-meshname'.
That way it knows where it belongs in the hierarchy and can create every master
and thing as it goes. The 'Thing' class was the major breakthrough that allowed
a user to control groups of meshes together (as seen in the cannon_fan
demo). The Thing class has been extended to include 'masters' which so not
contain meshes, but they are groupings of things that move together. The end
result of these two classifications working together is a hierarchical system
of organization wherein all meshes move with their 'thing' and all things
move with their master. This allows for objects with moving pieces such as
a fan with moving blades and a cannon with a tiltable barrel.
I plan to release a new demo shortly in which the
user can move each object as before, but this time they will also be able
to move the pieces of the object seperately! I am going to add font support
for this next one so I can display some kind of readout on the screen indicating
what is currently being controlled.
From now on I will try to post the number of hours
per day spent on this project so everyone (my advisor) knows how much effort
I'm putting into this! Today I only spent a meager 3 hours on the project
:^) I think my record is 6+ hours in one day when I was working on the ASE
parser.
I also made a logo for the game and I decided that
I will name my 3d graphics engine "Whisk" in the spirit of my previous
independent study "Spork".
2/18/2002:
It's been a while since the last update and this
is because I needed to catch up on work I had neglected while I was spending
every moment of my free time on this project. Now that I've done all that,
I'm back to spending every moment of my free time on the project!
I decided it would be a good idea to write up a
vague to-do list for my project, so I'm getting one together. I will not post
it, however, because I do not want it to fall into the hands of any Taliban
programmers. Yes, my project is that powerful! ;^)
I couldn't get to sleep Sunday night, so I designed
and modelled the 'spring' (formally referred to as a 'trampoline'). It rocks
bigtime and here is
a screenshot of it's current look. I also gave the turbofan a renovation,
changing the coloring pattern on the sides (it has a neato spiral look now),
adding detail to the texture for the top border, and making the fan blades
independent of the fan body. It has also been 'shortened' by 20% so it is
closer to the ground. It also says "HI MOM" underneath the fan blades
(not a joke) but nobody will ever be able to see that unless you look in the
texture file itself. I have to give her credit somewhere! ;^)
2/13/2002:
Happy happy joy joy! The project is ready for showing
off! Control both the cannon and the turbofan independent of eachother! The
lighting is great, the files load fine, and everything works! What else can
I say? Download it! Read the readme
for a couple of new features.
2/11/2002 at 3:22 AM:
I decided to normalize the normals myself. It worked
better than I could have ever hoped! I'm really happy. I've packaged a model
show-off exe just for the cannon and uploaded it to the server. If you can
guess where it is, you can download it :^) The next upload will be cooler.
2/10/2002:
I'm wrestling with a problem I just noticed with
the face normals of the models that get loaded. There is definitely some sort
of problem with their direction. Flipping the normals on half of the model
fixed the problem, but this is an unrealistic solution because it would be
stupid to cut everything in half and flip half the normals. I suspect it has
something to do with the positioning of the coords and the normals? I don't
know. I have a normal-calculator but I need to add a 'normalizer' that normalizes
the vector it produces. I would rather read the normals from the file, but
I wouldn't mind using my own stupid normal-calculator.
I've set up the 'Thing' class which will be used
for organizing objects. Objects consist of multiple meshes, so a 'Thing' will
move all of it's meshes together. I was all
set to make the demo for Thursday's presentation but then I noticed the lighting
was definitely strange and discovered the aforementioned problem with normals.
If nobody answers the post I put on gamedev.net's forum then I will forget
about the normal problem until after Thursday.
In related news, I'm using this whole 3D engine
thing for a project in my 'computational intelligence' class. It should be
semi-cool.
2/10/2002:
MAJOR milestone reached today! The ASE Parser is
now FULLY operational and prepared to kick serious ass. Here's what is does:
It reads your ASE file, loads texture info into an array, then loads each
mesh into a data structure and assigns each mesh the correct texture automatically!
No more tweaking the program in five different places every time I want to
change something! The textures are correctly aligned and everything. It's
so exciting! Now I am brainstorming a way to organize how objects will be
stored.
I have made more progress on the cannon. So far
it looks awesome, but not awesome enough. Maybe I shouldn't waste too much
time tweaking this thing...
2/6/2002:
Today was kind of a break from the rigorous hard
work that has characterized my last seven days. I had some fun and slapped
a cool texture onto what I have of the cannon. I know you (the person reading
this) check this journal every day first thing in the morning in anticipation
of the next cool screenshot or download, so I'm going to TEASE YOU! I can
assure you that this cannon will be the coolest-looking thing EVER! And I
will not post a picture of it until it is completely finished! Have I got
you drooling? Good! Hee hee hee...
2/5/2002:
I must say that I have never worked so hard on anything
in my whole life as I have been recently with this ASE parser. I decided it
would be nice if I split my project into multiple files. I had no idea what
the guidelines were for doing this, I thought that the compiler just magically
put everything together for you. OVER TWO HOURS LATER I finally got my project
to compile and build :^) It's an understatement to say that I'm learning everything
the hard way! Of course after I execute the program it produces strage errors
during runtime and doesn't function. I spent the rest of the night debugging
and came up with a few little fixes here and there, but it still wouldn't
run.
The next day (today) I spent some time doing more
debugging and I pinpointed the problem, but couldn't understand why it was
happening. I picked up the phone and called my talented advisor Ozgur Izmirli
and he tells me that it is a big mistake trying to 'reconstruct' an object
that has already been constructed. I changed my implementation and I saw graphics!
It worked! Of course everything was ten thousand times too large and way off
center and with jaggy edges, but it was a start! I discovered that if I centered
the object on the origin and shrunk it way down in 3D Studio Max, then selecting
it and doing "Export Selection", then the model would come out properly
centered and at a reasonable size.
A couple of days ago, I had sent an e-mail to Jeff
Molofee from NeHe Productions enquiring
if he would be interested in my ASE parser when I finished it. Today I heard
from him! He said he would love to have it! I was really excited to hear this
because this is the site where I and many other people learned OpenGL for
the first time and it would be an honor to have something of mine up there.
So at 1:45 AM when I couldn't go to sleep I decided
to see if I could squeeze some texture data out of the model I had made for
the turbofan (yes, I remodelled it. This time in 3D Studio MAX). I had already
done the code for extracting the texture vertices, but for some reason the
texture coords weren't being exported into the ASE file. After some quick
research I found out about the UVW Mapping modifier and... BAM! Check out
this partially textured but oh so beautiful turbofan!
That's enough for tonight.
2/3/2002:
This weekend was both awesome and terrible at the
same time. It was awesome because I wrote a parser for the 3D Studio Max ASCII
Object Export (asc format) and it actually worked! Unfortunately, during the
development of this parser, the power in my dorm went out mid-debugging execution
and I LOST THE ENTIRE PROJECT!!! Ladies and gentlemen, I had NO BACKUP of
my project. All I had was the source for DoubleCube version 1.0! Furthermore,
Visual C++ was no longer able to compile anything. I thought I had lost weeks
of work! I was all geared up and ready to start from where I was way back
when DoubleCubes was actually cool and re-write everything, and then I stumbled
upon... A COPY OF THE PROJECT THAT I FORGOT ABOUT! Yes! I made a copy of the
project on wednesday or thursday and then kind of forgot about it! This code
contained both the turbofan and one of the 'cubes' from DoubleCubes 2. I had
to rewrite the parser, but I was going to have to do that anyway!
I found out shortly before the terrible crash that
mapping the textures on the triangles manually would be nearly impossible.
I therefore planned to use the 3D Studio Max ASCII Scene Export (ASE format)
instead of the other one. The ASE format contains significantly more info
than the asc format. It stores into about textures, texture-mapping, and it
can store multiple objects in one file. Because my compiler was now out of
commission, I could not compile anything until I re-installed it. Since I
was (and still am) pretty sure that something really bad has happened to my
computer, I am not re-installing VC until I run Norton disk doctor on my hard
drive, which I plan to do on Monday when I can borrow it from the help desk.
Undaunted, I decided to write all the parsing code and all the display code
compiler-less! I wrote about 240 lines of code this weekend and I have no
clue if it works or not!
Either way, I am extremely proud of my parser and
I have dubbed it "ParseASE" accordingly. I plan to offer it to the
world free-of-charge as soon as it is functional. During my research I've
come across a lot of cool stuff that people wrote for themselves and then
posted for download on their website. I have seen very few ASE parsers out
there, and they didn't really have what I wanted. I would probably have spent
just as much time re-working their code as it took me to write it myself.
So anyway, I want to make my parser available to the public and I will as
soon as it works :^)
1/28/2002:
What I have been wrestling with for quite sometime
is the issue of how I am going to get these models into OpenGL format. The
problem is that OpenGL isn't really a format, it's an API for the graphics
card. Therefore one cannot simply 'export' a model into 'OpenGL format'. What
has to happen is the model must be in some other format which is then parsed
by one's program and then the data from the file is used to create an object
for OpenGL. I bypassed this problem for the fan by using a ridiculous method
of hand-extracting vertices from the Maya Ascii format and then plotting
them on a post-it note and figuring out the vertex order for each polygon
myself. It was kind of amusing, but doing this for more complicated objects
is out of the question.
I have discovered that 3D Studio Max has a great
ascii exporter that creates a text file that is beautifully formatted in nearly
plain English. I think I will take advantage of this nifty feature and maybe
write a procedure that parses the file. If this proves to be too hard I may
end up hand-extracting them from this format, but it will be significantly
more easy than the Maya Ascii extraction. I found a couple of DXF converters
that can read DXF and display it in OpenGL, but repurposing these procedures
will be an incredible headache that I would rather avoid. Plus, I'd like to
keep code-stealing to a minimum.
I downloaded the Quake 2 source code today in the
hopes that I could both get a free copy of Quake 2 and could learn a thing
or two about programming a 3D game. Unfortunately both hopes were destroyed:
The code did not include the graphics for the game, so of course I could not
use it to play Quake 2; and also, the code is so hideously long that it took
me about an hour to even have the most basic understanding of the framework
for the game. It did lend me a new respect for hardcore programmers, however
:^)
12/13/2001:
I've been busy recently, but I actually got back
to programming and I found I had forgotted a lot of stuff! I am going to be
in trouble when I try to start this up again after winter break! Anyway, I
decided to make my turbofan model using Maya 3d modeling software. I made
it and I liked it, so I went to export it and ... what's this? The only export
options are MayaBinary and MayaAscii? What am I supposed to do with those???
So basically I decided it would be fun to do this the hardest way possible.
I saved it as MayaAscii and opened the file with
Notepad. Using my amazing powers of deduction, I found the coordinates for
the vertices and copied them into another text file. Then I rounded off the
numbers and figured out which vertex was which. I then figured out how to
make all the polygons using these vertices, and decided to give it a shot!
After some difficulty in the code due to a careless mistake, I did it! The
surface normals are not correct, but I doubt anyone will notice (oops, I just
told you, didn't I?). Just for this I created a vertex class. I also needed
to calculate the texture coordinates myself! I will probably add some stuff
to it later if I need to. This fan will not be in the same format as the models
to come, but it was a good exercise. I want to scan in the post-it notes I
used for this process because it's ridiculous how long it took and how much
work was involved! Anyway, DOWNLOAD
the fan demo!!!
***NOTE added 2/3/02: I actually just reconstructed
the turbofan in 3D Studio Max. I will use my cool ASE parser to parse the
fan and all the work I just referred to will have been for naught :^)
12/04/2001:
I drew a picture (using Microsoft Paint, so spare
me any criticism) of some of the elements of the world previously referred
to in the last news entry. Enjoy.
12/04/2001:
I've run into some difficulty deciding what I want
to do. Time constraints as well as difficulty constraints will not allow me
to do what I really would like to do, which is make an interactive environment
with true-to-life physics, but this just can't happen. I have been thinking
about ways to limit the possibilities of what can happen so as to make collision
detection simpler.
One thing I thought of was to give the user the
ability to construct a series of poles and platforms on which there would
be spheres balanced at the ends. The platforms would spin on the pole like
levers and everything would be really cool. Unfortunately this introduces
new physics problems which I honestly don't feel like learning. I then remembered
that this project was supposed to be artistic. Another idea on the same lines
was to encourage the user to build a 'mobile' out of these platforms, strings,
and balls. Same issues apply: too complex. I then remembered that this project
was supposed to be fun to use, not a math problem. So now I'm thinking that
this environment should be loaded with spheres or sphere-like objects, and
the user can fire them from cannons and watch them bounce off of walls and
bounce off of eachother. There can be trampolines or air-jets and other crazy
stuff to add to the mayhem. I've done the research and I think I can handle
that.
One major dilemma for me is figuring out how to
project a texture onto a wall that is already textured. For example, let's
say the wall has a brick texture. I want the spheres to leave a mark on the
wall, but I can't figure out how to add the 'mark' texture to the exact place
it hits the brick wall. I will look into it further.
I would like to acknowledge that my project has
changed in focus from the original 'vague' description, but I think it is
for the better. The original idea of making half the challenge learning the
controls may still be an interesting idea. I'll see what I can do. There will
definitely be an upper bound on the number of spheres which can be in the
environment at once because collision detection is extremely processor-intensive.
I plan on finding a decent algorithm and optimising it for this particular
environment.
11/28/2001:
Wow, collision detection is REALLY hard! It took
me a while to understand how to compute the reflection vector of an object
after it collides, but I am now confident in my understanding. It is really
brilliant. I am amazed at how much can be computed in between two frames which
are 1/30 of a second apart! Games like Half-Life can run at 60 frames per
second! I wish I took linear algebra because vector math is inseperable from
any game with a physics model.
I am disappointed at my lack of actual progress
as far as the project is concerned, but I am learning a lot of extremely complex
stuff at a very fast pace. I should be ready to put something together soon.
I tried adjusting the collision detection demo code so that the balls lose
energy after bouncing off a surface (to add realism), but the way the author
implemented vectors makes it hard to easily add such a tweak. All it involves
is subtracting .... wait a sec, I just figured it out. I did it. I just scaled
the velocity vector down to 0.8 of its original intensity. I thought of that
before, but thought it wouldn't work. Silly me. An algorithm which is kind
to the processor would round extremely low velocities to zero when a collision
occurs to the slow-moving object. That way the ball won't bounce an infinite
number of times.
11/27/2001:
Wow, collision detection is REALLY COMPLICATED!!
I tried reading the explanation
(by the author) of his collision detection demo and ran into some LARGE knowledge
gaps regarding vector math. I spent a long time at this
great site learning about dot-products, cross-products, finding angles
between vectors, finding plane normals, defining planes in vector coordinates,
etc. until I finally understood everything in the demo explanation. By that
time I needed to rest. Next comes learning how to make things 'bounce' after
the collision.
Regarding the whole "ball rolling down a plank"
problem, the solution is definitely to have the plank be represented by a
clipped plane and the ball can simply be a sphere. Computing whether or not
two spheres intersect is extremely easy, by the way. Just see if the distance
between their centers is less than the sum of their radii. Think about it!
The harder part is finguring out exactly when and where they collided and
then moving them appropriately.
11/26/2001:
Back from Thanksgiving break today. I am deciding
to forbid myself from playing any computer games until the weekend. I did
more research tonight. I found a matrix/vector/quaternion
FAQ and after browsing through it, I thanked God that I am using OpenGL
which does all of that dirty-work for me! I still feel that it is important
to understand what is going on behind the scenes, so I read the important
parts about transformation matricies and vector transformation. I don't need
to use quaternions because OpenGL will take care of any difficulties with
rotation that the use of quaternions would be needed for. What are quaternions
you ask? Read the FAQ! Here is another
one just for you! Like I said before, I do not see a need to use this
in my program and I will never use the word 'quaternion' again.
I also found a site on oreillynet.com for the book
"Physics
for Game Developers" and downloaded all the code examples. Because
O'Reilly is hardcore, they have implemented all of the mathematical operations
themselves with their own code and seem to leave almost nothing up to the
graphics API. I think that I will definitely need to implement a class of
vectors, but I don't see why I would need a matrix class because OpenGL has
every matrix operation imaginable already implemented. I have begun fleshing
out my class definitions. I will need a 'thing' class for the objects in the
environment and these things will need position vectors, movement vectors,
friction coefficients and other things I have yet to figure out. I really
need to learn collision-detection now. I don't think bounding-box will cut
it because if I have (for example) a long plank of wood, and it is rotated
at a 45 degree angle, then obviously the bounding box method will be a horrendous
solution if I wanted to have a ball roll down the plank. More research to
come...
11/19/2001:
Okay, I've been very lazy/busy recently and haven't
done very much since last time. However, I am getting a clearer idea of what
will be needed for this project as well as developing a firmer idea of the
project. I've decided that the original idea was frustratingly dull and too
open-ended. Therefore I want to make it more of a game. I will try to somehow
encourage the user to create some kind of Rube
Goldberg-esque contraption, but still nothing is forced. This will require
a primitive physics model as well as collision-detection.
The tutorials on the NeHe site are becoming more
advanced, but the tutorials are complete entities on their own and contain
lots of details that are of no use to me. Therefore I've been forcing myself
to skip to the parts which contain the meat. It is also frustrating that the
author of that site explains simple, obvious things (e.g. "'Vertices'
is the plural of vertex") but fails to explain syntax behind much
more complex things (e.g. "if(!QueryPerformanceFrequency((LARGE_INTEGER
*) &timer.frequency))"!!!!!!!!). Next on my "to-learn"
list are DirectInput
and collision-detection.
10/31/2001:
Happy Haloween! This is the debut of the site. Up
until now I have been reading textbooks and browsing the internet so that
I can familiarize myself with both C++ and OpenGL. Quality OpenGL tutorials
on the internet are scarse, but I've been using what appears to be the best:
http://nehe.gamedev.net.
This site is maintained by a hard-working guy named Jeff and it contains examples
and heavy commenting that have been put together by him or other people. I
have worked with all the tutorials up to and including number eight: "blending".
In order to learn rather than simply observe the
examples, I forced myself to build up lesson one incorporating each element
learned in the successive lessons. In other words, I copy and paste and modify
code from the lessons into my project experiment. So after the solid shapes
tutorial, I made an octohedron and added it to my existing square and pyramid.
After I learned texturing, I applied multiple textures to the cube. I made
a couple of lights, too. At this point I ran into heavy confusion. When I
enabled lighting, the non-textured shapes were lit incorrectly and looked
completely wrong. I still haven't quite nailed down the problem. The blending
tutorial (lesson 8) was truly awful. Even the author himself admits that it
is "the wrong way" to do blending, but it looks cool for the tutorial.
I searched for hours on how to do it correctly and finally found it and implemented
it. While doing this I found some really nice reference sites on the OpenGL
API, including the official "Red Book". Download
my project up to this point. By the way, this is not my real project,
it is merely a learning exercise.
