Lanthanide and Actinide

This project:

-Reads and quickly renders Quake3 .BSPs compiled with GTKRadiant 1.2. This is an extremely fast process utilizing Potential Visibility sets and Frustum Culling. What this means is only the potentially visible leaves that have a part of their bounding box in the viewing volume are draw to the screen. On my Geforce2mx 400 64MB card I was hitting 100 fps in 1024 * 768 (with vsync disabled). With my Radeon 9600 PRO it's always above 200FPS on 1280 * 1024.

-Fast but accurate method of extracting view frustum (this was a PAIN to get working because usually I could rotate vectors in relation to the View vector to receive the six plane normals, but the inaccuracies multiplied out, eventually I just extracted the right and bottom plane normals from the OpenGL matrices, then mirrored those over the view vector to receive the other plane normals).

-Collision detection using a 'semi spheroid' algorithm (as opposed to using a bounding box algorithm, which isn't that difficult to be honest. My method basically just means you can perform ray tracing using a sphere for collision detection but also have a HEIGHT which is bigger than RADIUS units...this was a pain in the arse to get working to be honest)

-Sliding across faces: I didn't think this would be as difficult as it was, but when you slide across a face you have to recursively trace along the faces until the direction you want to move in receives an invalid length (meaning you run out of steam).

-stepping up stairs: I didn't know how to go about this so I just detected a collision, and then I pushed the camera up STEP_UP units (STEP_UP was defined as HEIGHT>>2 because I approximated the most you can reasonably step up is 1/4th of your total height) then traces from the newly elevated position forward, and if the fraction of the move that could be travelled was greater than .5 (magic number for now) then it counted as a step. This was also difficult to get working because you could sometimes go and hit a wall and 'jump' up.

-Realistic gravity: This part took me a while to get working properly. As you know gravity is not a velocity, it is an accelerator. I tried using the derivative 32*timeinair to calculate the instantaneous velocity of gravity, but it didn't seem right, so I instead am using 16 * timeinair^2 to calculate that velocity. I'm not entirely sure what I'm doing on this part, but it works.

- capability to shoot the world. Also calculates the angle of reflection off of that surface and draws the normal at the point of collision

- utilizes pre compiled quake3 lightmaps, meaning fast static shadows can be drawn without having to rely on hardware (that would slow things down if the lighting was calculated for every pixel in the scene).

- uses time based movement, so no matter how fast the scene is being rendered you will always move SPEED units per second

-fully functional 3d vector class with a vector operations library. Utilizes DotProducts and Crossproducts, Projects vectors onto planes, finds parallel and perpendiular components between two vectors, and rotates vectors.



All questions, comments, and constructive criticisms welcome.
EDIT: This site is currently working and has no bandwidth limit (as in it wont shut down on me, but it might run slow if you all download at once).
Also, perspective may come through and loan me a site as well (*crosses fingers*), I would like to have two. Anyway this first link is the directory with all of the files necessary to test the engine. You technically don't need textures.zip, but I encourage you to download it if you can (~5MB) because it looks much much nicer with the textures. Everything must be extracted to the same directory, I wrote a detailed explanation of how everything should be laid out if you aren't sure what to do.

http://www.thedevelopersalliance.com/~shadow12345/

Quote:

---

Temporarily Unavailable

The Angelfire site you are trying to reach has been temporarily suspended due to excessive bandwidth consumption.
The site will be available again in approximately 2 hours!

---

I wonder what a 3d engine has to do with those elemental groups....

As for the realistic gravity: If you have t (timeinair) and g (9.81) it's pretty easy to calculate the velocity - unless I misunderstand your problem which is very well possible (I'm a C++ newbie). Its v= g*t (+v0 if you have an initial speed). It's even possible to calculate the speed at the time of impact (maybe for falling damage?) if you don't have t: v=sqr(2*g*s) where s is the distance your object fell.

Btw, if you still need a host, send me a message.

Quote:

---

Originally posted by Silvercord
that 9.81 is meters per second, I have everything in feet so I need 32 ((9.81 * 100)/2.54=CM, CM*2.54=inches, inches/12=feet=~32) , and the instantaneous velocity of the gravity accelerator is 32(timeinair) which is the derivative of 16(timeinair^2), and that works fine now

---

You mean you use... :eek: feet :eek: ... even in physical formulas?As fas as I know NASA lost one of their Mars surveyors because they did this.... :D

Anyway, I'd love to see the code. I once tried to code a collision detection engine and miserably failed :) /bow Silvercord

It compiled okay (8 macro redefinition warnings) but it says it needs GamesTutorialsBSP.bsp on execution. Wanna attach that so I can check out your engine?

I've deleted all of my posts and started this over with new links (bottom of first post, which is where they were originally). This site should be more reliable than friggin angelfire. So, back to where we started, download, run, tell me what you think. Sorry for the hassle, thanks for sticking in.

email:
[email protected]

AIM sn:

OpenGLProgrammer

Eh, it's been done.
1/10

Thats very nice, I actually tried to pull down the console to type "quit" only to realize this isn't the real quake engine =)

The mouse input was surprisingly smooth (better than what some games use imho) but way to fast on my mouse. But thats of course just a matter of mouse specific settings.

Keyboard input was fine.

Gravity was not realistic :) Maybe my computer can't handle "feet" but unless this map is situated on a neutron star, the gravity was not what I'd expect. I was always instantly on the ground again. [Maybe this is not time- but frame- based?]

I'll try a real quake map now =)

edit: I did. A few other issues:

Movement speed stacks. You are faster when strafing and at the same time moving forward. Maybe it's even intentional. Just mentioning it.

Movement speed is based on current FPS. I had a map where the number of visible polygones changed a lot from vis to vis zone. Sometimes this made me move faster, sometimes *a lot* slower.

Curved surfaces don't display. That's gonna be a major challenge I assume :D

Impressing engine!

- uses time based movement, so no matter how fast the scene is being rendered you will always move SPEED units per second

Movement speed is based on current FPS. I had a map where the number of visible polygones changed a lot from vis to vis zone. Sometimes this made me move faster, sometimes *a lot* slower.

which is it?

You guys are good testers, everything mentioned were problems I have been pondering over. I need to find a realistic conversion from the arbitrary world units to feet or meters, that will fix gravity. The movement isn't contsant because it measures how long it took to render the frame and uses that to determine the fraction of how far you should move (based on your speed per second). What I'll probably do to fix that is only get the time every five seconds.

This is a very limited renderer, I have not implemented curved surfaces or entities or much of anything...in fact your starting position in the world is hard coded into the program because I haven't even written anything to read the INFO_PLAYER_START entity.

Thanks for taking the time to look at this for me :)

I'm more motivated than ever to continue working.

Quote:

---

Originally posted by blackrat364
which is it?

---

ra3map1, the clanarena part of this map (ra3 maps consist of several small arenas with independent spawn points.)

Quote:

---

You guys are good testers, everything mentioned were problems I have been pondering over. I need to find a realistic conversion from the arbitrary world units to feet or meters, that will fix gravity.

---

I may be wrong, but don't you try to convert something that doesn't need to be converted here ? Why don't you simply use the world units for everything, including acceleration and velocity? This should work as long as you can eliminate t.

Quote:

---

The movement isn't contsant because it measures how long it took to render the frame and uses that to determine the fraction of how far you should move (based on your speed per second). What I'll probably do to fix that is only get the time every five seconds.

---

Mhm,... maybe try using a second thread for user input and movement. You could run it at 25 constant "snaps" (you know that quake command?) with constant speed. Thats also the way Diablo II does it, not sure about Quake here.
Don't know how strict windows handles threading. May as well be that gl prevents the scheduler from switching the thread in the right moment. It's been a while since I did something with threads, so I may be wrong again. Just a suggestion.

Quote:

---

This is a very limited renderer, I have not implemented curved surfaces or entities or much of anything...in fact your starting position in the world is hard coded into the program because I haven't even written anything to read the INFO_PLAYER_START entity.

---

Ya, I know. I didn't expect it to render CS anyways. Just wanted to mention it.


edit: Not that I want to spam you with newbie suggestions, but here is another one =) It's in pseudo code. Didn't know how to explain it.

initialize a high precision timer
mainloop {
- perform all user-input related stuff
- multiply "visual" velocity with current timer value (the more time it took to render the frame, the further did the player move between frames (IF there was a movement))
- reset timer to zero
- render scene
}

Quote:

---

I may be wrong, but don't you try to convert something that doesn't need to be converted here ? Why don't you simply use the world units for everything, including acceleration and velocity? This should work as long as you can eliminate t.

---

I am using world units for everything, but realize 32 * timeinair and 9.81 * timeinair are both accurate representations of the instantaneous velocity of gravity. The problem is representing 32 feet or 9.81 meters in order for the equation to work.

Some problems fixed:
I fixed some problems with preserving the movelength and projecting the move onto the xz plane. I also *may* have fixed a problem that occured when looking straight into the ground and trying to move (you could go through walls when this happened, so I made it so you cannot look directly into the ground and it seems to have been fixed).

If you want to, download the new executable named BSP1.zip and run it...when you do try walking up the stairs while looking down at the ground and/or try walking up the side of the archways and doing the same while on the top. If any of you can manage to get through the walls then I still have a bug to fix.

the link is (again)

www.thedevelopersalliance.com/~shadow12345

Well, played it.......sadly I lost :(

On a serious and less pathetic note, I thought it was a good game(much better than the earlier stuff you showed me), and I hope when you sell your game for millions of dolalrs I get a free copy...NO, I demand a free copy of your game!!!:D

Quote:

---

I also *may* have fixed a problem that occured when looking straight into the ground and trying to move (you could go through walls when this happened, so I made it so you cannot look directly into the ground and it seems to have been fixed).

---

Workarounds are bad. Terrible, like goto. Workaround=Doom of the world. Workarounds will kill us all. :D

That reminds me of Dark Age of Camelot. Whenever something is broken there, they just disable the feature. Archers can shoot through dungeon walls ? oops. That must be fixed: Archers can't shoot in dungeons anymore. (Thats not a joke.)

You shouldn't do this. It starts with something simple and in the end you will fix a problem like "the graphics isn't displaying correctly on ... cards" with "graphics has been removed from the game, ... is now a text adventure".

Of course those were extreme examples... :)

naw, not being able to look straight down in a FPS is fairly normal.

Quote:

---

Workarounds are bad. Terrible, like goto. Workaround=Doom of the world. Workarounds will kill us all.

---

No offense but you really don't know what you are talking about. Even if something is mathematically correct there's such a thing as, let's say it together now, floating point inaccuracy. Even in your most beloved and advanced first person shooters they have to develop methods for getting around this. For example when splitting your move into fractions when checking a BSP tree for collisions the idea is to check the fraction of the total move from the starting point to the plane, then from the plane to the endpoint. However, it always actually checks EPSILON units in front of the plane from start to the plane, and then from EPSILON units away from the plane on the other side to the endpoint. Download the quake2 source, open sv_world.c and search for BACKFACE_EPSILON. Also, directly from the quake1 source:

Quote:

---

// 1/32 epsilon to keep floating point happy
#define DIST_EPSILON (0.03125)

---

EPSILON is usually 1/32

The limit in my engine for the camera rotation was PI/2 radians (directly up or directly looking down). That worked except for the fact that you could look straight down and move backwards because the view vector projected onto the XY plane introduced floating point inaccuracy and allowed it to be projected in the opposite direction (and no gimbal lock was never a problem).

No ...real... offense taken, but you may have noticed a few smilies in my post. They were there for a reason =)

There are games like Descent where it is no problem. Is it that much work to rotate the world the last few degrees instead of the camera? Anyway, I don't know what I am talkin about... ;)

graphics programming is officially my thing, so, like, understand I had to correct you and provide evidence

I'm trying so hard to actually become the novice wannabe that grew up to become a good game programmer. i don't like being corrected even if you are right, but imma digest you if you're wrong in any way

Quote:

---

Originally posted by Silvercord
i don't like being corrected even if you are right

---

With that attitude it will be much much harder to learn, that and you seem like a pompous dick. Accept people's input and judge it in an unbiased manner, they aren't attacking you, your mom, your sister, or you dogs honor, they are giving you advice from what their standpoint dictates.

I agree with you on the "its not a workaround" part, but you saying that just kinda irked me.

How long have you been working with OpenGL? I've been working with it for a bit now learning from "OpenGL Game Programming" but I haven't gotten as far as you yet, it looks good. I'm working on a tile based RPG right now heh. I'm gonna move on to FPS some time...

//napKIN

as if you actually took that SERIOUSLY...I've learned a lot so obviously I don't really have that attitude. However I'm not loaning any of my hard earned experience to you for calling me a pompous dick. In fact that is borderline asinine that you insult me and turn around and ask for advice. I've got a real computer game to be working on (I'm sitting in san jose with a group of real developers) so I'm going to be going to do that.

EDIT:


and for a side tidbit your beloved carmack said he had an 'ammoral arrogant attitude about being smarter than other people'. If you don't believe me read masters of doom, or better yet just go googling or something.

I didn't ask for any advice, I said it looks good to balance out me calling you a dick. I don't mind a little pride in one's work, but when you refuse to take other's suggestions and you think you are better than others, that starts grating on my nerves. It's better to be better than you think than thinking you're better than you are.

As for Masters of Doom, is that worth reading? I was going to buy it but instead I got a book on 3D modeling (figured it'd be better to learn programming than read about my "role model").

//napKIN

buy it and find out for yourself

stop reading into things so seriously, I guess I keep forgetting not everyone is like me (i.e nothing is ever serious enough to get negatively worked up over).

I'm posting this against my better judgement:

There does seem to be an air of superiority in most of your posts.

[light hearted comment]
yours and carmack's crap smells just as bad as anyone elses. :)
[/light hearted comment]

When you talk to Silvercord you can't take everytihng seriouslym but it seems everyone does. I seem to be one of the few people who find humor in things he says.

Thank you Sean.

Quote:

---

There does seem to be an air of superiority in most of your posts.

---

Yeah, I'm better at graphics programming than most (if not all) of you guys, but whose fault is that. It's kind of stupid to make stupid suggestions to someone who knows more than you...BIG STUPID FACES!

Basically, deal with it.

everyone sucks.........................

but silvercord

Am I the only one who actually starting laughing at SilverCords last post, his outbursts are funny and well he does seem talented too.

Just need to stick up for the man himself.

"Carmack was cocky, but if someone could teach him, he wasn't going to let his ego get in the way. On the contrary, he was going to listen and stick around."

-Masters of Doom, page 37

Nuff said

//napKIN

Quote:

---

Originally posted by unanimous
Am I the only one who actually starting laughing at SilverCords last post, his outbursts are funny and well he does seem talented too.

---

nope. As Jackson said: You are not alone =)

napkin I don't get in the way of other people that actually have something to teach to me, and I'm not cocky in person...but I've put more work into 3d programming than any of you.

Quote:

---

Originally posted by Silvercord
Yeah, I'm better at graphics programming than most (if not all) of you guys, but whose fault is that. It's kind of stupid to make stupid suggestions to someone who knows more than you...BIG STUPID FACES!

---

how can anyone disagree with that???? Silver is just such a super amazing graphics programmer, i mean look at this screen shot from his latest 3D graphics engine. i think the picture says it all.

i think we should beat him up and make fun of his mother

and i can't tell if you are being serious perspecitve, that link doesn't work...it's probably a picture of super mario brothers to make fun of me or something, which would have been cool about thirteen years ago

my first one looked like this.

did I say looked ? looks =)

Mine looks like this right now, and is being improved as we speak.

Note: That site is not hosted reliably. It's hosted on my computer, and there have been a lot of thunderstorms recently, so I keep shutting down. If it doesn't work, just try it again later.

Quote:

---

Originally posted by Silvercord
i think we should beat him up and make fun of his mother

and i can't tell if you are being serious perspecitve, that link doesn't work...it's probably a picture of super mario brothers to make fun of me or something, which would have been cool about thirteen years ago

---

i was just screwin with ya silver, all in good fun. The link works now (damn web host server was down for a bit)

since everyone is postin links to screen shots.... here
note* sky box images stolen from gametutorials, still workin on makin my own.

While we're at it, here's my current game. Its still in alpha, but I'm pretty pleased with it.

//napKIN

(disclaimer: Carmack is the ruler of all, please don't sue me)

Quote:

---

While we're at it, here's my current game. Its still in alpha, but I'm pretty pleased with it.

---

Looks strangely familiar :D

Anyway, it's a faintly plausable excuse to post pics of my game (resized down from 1024x768) :D

Random Battle
Not for the faint at heart :)
Closeup shot :D
(very basic) menu
Boom!
Sniper in LavaLand

Wow bieh awsome. Are you using directX?

You've come a long way since i when i saw your "space wars" last.

Perhaps the bug of looking down while running into walls does have an easy fix. Are you testing for wall collisions along the camera vector only or are you testing between the character's position and other polies in the game? The only way I could see walking through walls would be if you are testing along the camera vector which would effectively allow you to walk through walls while looking down. Because you are moving perpendicular to the ground and never get closer to it, you will never get a collision with the ground.

If this is true, then theoretically looking straight up would do the same thing, I cannot download the demo b/c I'm at work so this is just a guess as to why this is happening.

Better way to put this is that the view frustrum changes when you look down and up - if you are testing for collisions only inside of the view frustrum, then you will never get one while looking straight up or straight down. Your collision code should have nothing to do with the camera vector and everything to do with the movement vector. If you test along the movement vector, thus having nothing to do with the camera/view vector, you should be able to walk backwards, forwards, sideways into walls all while looking whichever direction you want to.

Quote:

---

Originally posted by Nutshell
Wow bieh awsome. Are you using directX?

You've come a long way since i when i saw your "space wars" last.

---

he's using OpenGL (its in his sig)

looking very good Bieh :)

polygons aren't ever accessed in this collision detection, and if they are ever accessed they will always be the last things tested

Then how are you detecting whether you hit a wall or not??

Quote:

---

Originally posted by Nutshell
Wow bieh awsome. Are you using directX?

You've come a long way since i when i saw your "space wars" last

---

Quote:

---

Originally posted by Perspective
he's using OpenGL (its in his sig)

looking very good Bieh :)

---

Thanks, guys :)

@ Nutshell: Yes, that's OpenGL :)

Look for a release in 2-3 months, at the rate I'm going (/me curses school :()
I'll have a website up soon with any luck, instead of the
placeholder that I've got atm, so check there for updates :)

Quote:

---

Then how are you detecting whether you hit a wall or not??

---

Very, very easily, and at much much faster than per polygon detection

it's done with convex (normals point outwards) sets of planes that represent the geometry, and a simple algorithm that determines
1) whether or not you actually hit the actual geometry that is represented by the plane normals
2) the closest fraction of the intersection

That was the next thing I was going to say. Are you using the normals of the planes?

Hmm. If the normals all point outwards, I'm not sure why the algo is failing when you look down. Quite odd.

So you have surrounded your characters with planes that approximate their shape? Very good idea. In fact, I might steal it.


:D

I guess it would not make sense to try to detect every collision with every poly nor would it be efficient.

I'm really lost as to why the camera or view vector would cause collisions to not register. Are you also rotating the planes that you are using for collision detection? Perhaps you are rotating them too far which would cause the normal test to fail. Give me some more info on exactly how you are testing for hits on the walls - I think I understand but I want to make sure.

well at least part of the problem was the fact that the collisions failed when your move length was less than EPSILON units

So basically you are using the normals as 'feelers'? Then you do a 'point-in-plane' test to see if the normal (extended a bit) hit any walls?

Umm, not exactly. Here's the algorithm. Note this is described in Frank Puig's tutorials in the code dump at gametutorials.com. Frank helped me a lot by uploading me his projects before posting them on GT, and just plain helping me when I was stuck.

The algorithm:
float startfraction = -1.0f;
float endfraction = 1.0f;


-Loop through every single plane of brush.
-For every plane:
-If the startdistance and enddistance are both positive cancel the tests (the move doesn't hit the brush if it's completely in front of any one of the planes)
-If the startdistance and enddistance are both negative skip this plane but continue checking the brush for it may intersect another plane of the brush
Otherwise your move spans one of the brush planes and potentially hits the geometry represented by the planes. To find the exact intersection and to determine if it actually hits the geometry (and doesn't just hit an infinite plane) do the following:
-If the startdistance is on the positive side of the plane calculate the fraction of the intersection against the plane, and if the startfraction is less than the intersect fraction assign fraction to startdistance
-If the startdistance is on the negative side of the plane calculate the fraction of the intersection against the plane, and if the endfraction is greater than the intersect fraction assign the intersect fraction to the endfraction

At the end of checking this brush if startfraction is > -1.0f, and if startfraction is less than endfration then you know you hit the geometry and is a valid intersection. Then you go on to check to see if this fraction is the closest fraction of the entire leaf (each leaf usually has many brushes, so you only want to keep the closest brush intersection for the leaf you are in)

If you've already got at least the BSP file then download this, it's a bunch of balls that bounce around the world