graphics
Sunny, Kuowen, Yoway, John Friday, June 01, 2001 at 18:39:17 (PDT)new screenshots up
Craig Tuesday, May 22, 2001 at 10:53:44 (PDT) screeshots work fine now, or at least on the graphics only side. here's some (yay screenshots):
muiltitexturing
new loading screen
procedural textures
segmented animations work. that means you can play the right animation at the right time, for an example see kokoro_graphics.cpp in animate(). thats how to change a weapon animation. ill add a function into kokoro later. to play monkey anims, use model->setCurrentAnimation(int i), where i is the seq_id (set in the keyframe file) of the animation. the screenshot above with the railgun is actually playing the shoot animation when you click the left button@!#$
SERVER PPL: add that to the server stuff =b.
you can see from the multitex screenshot that multexing looks awesome, and can really give the illusion of high detal.
procedural textures looks a helluva lot better too.
Craig Saturday, May 19, 2001 at 16:35:04 (PDT) no screenshots til i get a few more changes to the kokoro engine. not much has changed visually, most of the changes have been integrating with other things like chat, WMS, and structural changes to the octree, model loading, etc. we DO have really kewl weapon models tho (thanks to Yoway and Sunny).
collision detection against the octree is pretty much done, it seems to be pretty fast and i think i fixed the sinking problem.
i added in some code to draw objects from the WMSC, tho it can only do the monkey model right now, i still need models for the coconut (in the world, not as a weapon) and rockets.
that brings me to the next thing.
Yoway and Sunny: the keyframe file spec is in keyframe_file.txt, and note that the numbers are KEYFRAMES, not frames.
in 3rd person mode you can see a monkey at the correct orientation at the camera position.
i added some preliminary code to do animation segments from the milkshape models, ill be able to test it when i get the keyframe data from Yoway and Sunny.
next up (when i have time): new world, procedural textures for the world (and maybe trees), getting Sunny's tree data into the octree.
J.J. Tuesday, May 15, 2001 at 14:48:41 (PDT) Hey, how about some screenshots for all of us "outsiders" who like to keep up on Monkey-dev.
Anyway, I'm looking forward to seeing the final product at the "showcase".
Craig Monday, May 14, 2001 at 16:13:22 (PDT) ive been fooling around with bryce and i can make better worlds with its terrain meshes, but havent yet. i do have a really bad tree that i made in TreeDesigner (ugh) and i added it to the octree. basically i load it as a milkshape model (no textures) and then insert it in, but there's too many polys in it, it slows things waaay down.
yesterday and today ive been working on collision detection with the octree, its almost done, im just fixing the moving sphere/triangle detection stuff now.
after this will be animation keyframing, and procedural textures for the world and trees (once i get those finalized).
Craig Saturday, May 12, 2001 at 02:55:04 (PDT) ok... finally (after working on this like 10 hours straight) i think i have something that will make decent enuf trees for our purposes. it wont texture them, tho... might have to do that in milkshape, or do procedural textures like ive wanted to do all along (but i have to pore over some code to do that). anyway...
tomorrow ill get the tree tris into the octree and see how performance goes, just drawing it straight out in a vertex array give pretty much no change, hope it stays that way. ill also see if i can get down to the polygon level in the octree, probably using some bastard form of a bsp tree (without splitting the tris).
anyone want to finish the weapon models? we need the animations for em all, and final models. all i need is a milkshape model with the animations included, and the textures, thats it.
another thing ill try to look at tomorrow is playing only selected keyframe segments of the total animation, that way all the keys are in the same file, and as long as each animation stops in the same position it starts in things should be very smooth. should.
Craig Monday, May 07, 2001 at 16:21:04 (PDT) I think everyone was kinda busy this past week... I know I was with compilers and other things.
The big problem has been how to represent the world, or even how to MAKE a world, period. You cant do correct HSV and colission detection without resolving this issue, and I think we've finally done that (hope).
It looks like Bryce is our best bet for making a world (at least the terrain anyway). I've read a few things that tell how to make trees with it, and if it can export texture coordinates, we're set. Then the only hard part is doing colission detection on a bounding-box to triangle basis, which is a bit more complex than John's version which uses a heightmap. I still think it could be done fast, tho.
In the meantime, I've put in code that will load the cool milkshape models Sunny has been putting together directly, so no more conversion into vertex files, or even md2s. You can also use the keyframes in the file to do the animation on the fly at the correct framerate (using highperformancecounter). Yay.
I basically stole someone else's base code and hacked it into something useful. I also moved it from drawing verticies every frame to vertex arrays (much faster). I was getting about 5fps faster than with my old display lists. Plus, with milkshape you can position models (i.e. all the HUD models) directly in their correct position, meaning you dont have to make any transformation calls to OpenGL. The weapon fidget animations can be done this way too.
With this we can put the monkey and HUD stuff in REALLY easily. And with a list of what keyframes correspond to what animation, we can play the right anim at the right time.
Craig Tuesday, May 01, 2001 at
02:36:34 (PDT) Ok i couldnt keep myself away from it. So I finally got lens flare going. Check it out here. Next up... compiler!@#!@#!
Craig Monday, April 30, 2001 at 17:46:56 (PDT) This is going to be fast.
Goals: Environment rendering, map textures, finalize world space.
Morale: need sleep.
Here's some more screenshots, ignore the frame rate, it was on
non-acellerated machines in OSLT.
SS1 - the octree on a VERY small
heightmap
SS2 - without the octs
SS3 - the entire world (and me
alt-tabbing)
SS4 - first person view of the world
SS5 - fpv with octs
SS6 - video menu overlaid
Most of the changes in the past week were behind the scenes, like porting over to all windows code (no more glut), and getting things integrated with network and inout.
Text messaging also works now, and the text is properly formatted when it displays on the screen. I also added John's "time-to-live" feature to the chat lines.
The video menu is also functional, you can change resolution and color-depth (if in fullscreen mode) on the fly.
Thats all I can think of.
Oh, I've added lens flare code but it doesnt work yet, still kinda buggy.
Craig Thursday, April 26, 2001 at 10:13:13 (PDT) ok, so i said id do it yesterday... but i got hung up fixing a couple bugs and getting some new stuff in, like a better fps counter, fog/person/cam drawing/box drawing options and other fun stuff in there. ANYway... here's what you came for.
Craig Monday, April 23, 2001 at 03:31:49 (PDT) A few things I forgot to mention.
The octree is sparse, i.e. any octs that have no polygons are removed from the tree. The polys themselves can be marked with a "type" like "ground" or "tree" if we need to do that for moving (and I think we will). They also have space for texture and normal information, and even a color.
Something I'm gonna implement now before I go to bed (shouldn't take too long) is having the leaf octs point to each other, so that you can always get to the oct that renders the polygon next to you. This will be REALLY useful in colission detection and movement (I hope).
Craig Monday, April 23, 2001 at 03:16:15 (PDT)
Week 3 Graphics goals: Basic Model Animation.
Quick stuff:
Well... it may be that its best to animate entities on the fly rather than use display lists for each frame (memory IS going to be an issue after all), and we wont be animating that much. Besides, display lists really aren't THAT fast if you code right.
I also sort of need Kuo to work with Lightwave to finalize the monkey model, but it shouldnt be too much trouble to work with it when he's done.
Not sure I mentioned this last time. 2 Weapons are selectable (vie numbers). Right now I've got a shotgun and a rocket launcher. Later we can edit the rocket launcher model and make it fire bananas. Also the health/shields indicator is fixed. I've been trying to get a crosshair up but the damn texture wont load (which is whacked since every other tex does).
Weapon animation happens now, too... well.. the walking stuff does at least. For now it just loops forever (like the health/shields indicator), but its easy to implement.
Detailed stuff (screenshot at bottom!):
I've spent the week figuring out ways to represent the world. Started with quake models... read lots and lots and lots and lots of papers/websites about loading and working with bsp files, and even had some code working that would load a bsp and let you run around in it. But, our world isnt angular enough, its too landscapey and outdoorish to use the portal/bsp-tree structure that Quake uses. BSP trees are really good for worlds with rooms and such, where space partitioning is easy. Our world is just a big empty space (well mostly anyway), so there's no good place to say "ok lets cut it here."
Unreal's map format can only be licenced for a fee (bastards).
The deal is, you dont want to try and draw every polygon in the world EVERY frame, since you cant SEE them all every frame. Sure, you can try to draw them and OpenGL will happily cull each one for you, but the culling algorithm is pretty expensive. The purpose of these partitioning structures (BSP, kd, oct, quad - trees) is to just toss out tons of
After lots of reading, I came up with an octree for the basic structure, and then maybe a mini-bsp within each leaf-oct to hold the polygons that will get rendered.
I tried stealing code from CrystalSpace and a couple other places (talk about madness), but ended up just writing my own in most cases. Some stuff is taken from examples on the web (like the intersection test stuff).
I made a few test worlds with Lightwave, that have varying polygon counts. ~1000, ~3000, and ~10,000. There's no textures or lightmaps... but that can be added easily later.
Anyway, so now we have an octree that holds the world, and on average, even when looking full on at the bottom of the valley you still end up only rendering about half the polys in the scene, which is pretty good for a first pass. The next step is to actually check if each poly needs to be drawn using a c-buffer. That's kinda like a z-buffer but its in software. And its faster than the z-buffer. Or at least thats what all the papers say.
After that I'll work on good collission detection with this thing. It's supposed to be easy to do with an octree....
Here's a screenshot.
Note its only displaying half the polys in the scene. Dont worry about
the 25fps, its on my laptop... which has a lousy fill rate.
04/15/01, Craig Donner
Although staying with only GLUT/OpenGL code, I can now load almost
any kind
of 3D model into an OpenGL context, along with the correct textures
and
texture coordinates. I also came up with a computationally fast,
but memory
intensive, way of doing the object animations, i.e. each frame is
a seperate
list. Considering the size of the models I've been using so far,
I don't
think it will be a big problem, but we'll find out.
I've also been working on parts of the UI. I started with a simple
2D text
menu that comes up on an esc hit, and have moved to animating 3D
text.
There are submenus, and though they don't really do anything useful
right
now, the functionality is there to add more submenus (its really
easy to
change them) and assign actions to each menu, like if the user presses
right
or left (or + or - for that matter) while a volume option is hilighted,
the
volume changes. I can do that fairly easily, but I'll wait til we
integrate
with DirectInput before I go any further with that.
Today I'm gonna see if I can get a basic HUD going, and think about
some
models for weapons (in the HUD) and things like that. I figure anything
I
do right now is ahead of schedule... so....
The next real thing on my list is fog and stuff, but until we decide
on a
map format (and a way to load it, BSP tree, etc.) there's not much
I can do.
|
