Chaotic Dreams

would it be possible to mod it so light things can be picked up and swung around?

1) What is poly hit detection?

Per-polygon hit detection. That means that you can tell when an object "touchs" another object by looking at each of the ploygons that is making up those models. Current UT2k4 supports this but it will turn your UT2004 into a power point presentation So this would be the most acurate form of hit detection. Our current melee uses bones in the weapons and taces them to see if its a hit. How much better would to look at the model of the weapon and the model of the player and if the two are touching (meaning looking at the polygons of each model, so any of them touch), then its a hit.

2) Soda can collision? What do you mean objects don't turn or rotate because of soda can collision?

Most objects in unreal will use the standard form of collision wich is a cylinder shape (ie coke can, or beer can, mt dew can, ect). This collision is used to detect hits in UT2k4 and all other physics that the player pawn has on it while its alive. Its the same for pickups, ect. All Unreal engines have a limiation where you can not rotate this collision cylinder at all. So no matter of the model, flips,spins twrils the collision stays the same For some objects like a projectile its not a big issue. However for other objects it is. Consider a staff weapon. The pick up model will have a cylinder collision. Now we can only change the hieght or radius of that clynder. But how do we cover a staff when the staff is laying down on the ground?

This were a PPU could come into play. The reason for these current limitations is mainly that all these phyics take lots of calcuations and math to figure out from each frame. So much that it will have a negivtive impact on your game. So for now they use a cylinder which is much quicker to check and save your CPU from doing all that math. But a PPU would take all of that work from the CPU and....tada

jb wrote:Our current melee uses bones in the weapons and taces them to see if its a hit. How much better would to look at the model of the weapon and the model of the player and if the two are touching (meaning looking at the polygons of each model, so any of them touch), then its a hit.

Hmmm...

So you're saying that if a bone passes through an object but doesn't hit another bone, no hit will be detected?

jb wrote:Most objects in unreal will use the standard form of collision wich is a cylinder shape (ie coke can, or beer can, mt dew can, ect).

Sorry, didn't really understand...

what is soda can collision exactly?

So you're saying that if a bone passes through an object but doesn't hit another bone, no hit will be detected?

Not really. Right now the code traces between the different bones in the weapons. In order for an object to "be hit" in the trace that objects collison must be in the way of the trace. We also have tried to place the bones at/near the weapon edges so we try to get the best possible hit detection that we can. As you can see while our system works and is pretty good, its by no means ideal. Per Poly hit detection would remove the need to have bones, would remove the trace calls and allow for almost a perfect hit dection system.

Sorry, didn't really understand...

Naw, its my fault. Here let me use a picture. I will borrow malcom. This first picture show Melcom in the 4 view of UE:

http://www.chaoticdreams.org/ce/jb/collision1.jpg

You can see the cylinder aound him in each of the 4 views. Thats the collision box that ALL ut2k4 players use. This is what detects if you touching something. And the collision cylinder looked like a soda can


Now watch what happens if I rotate Malcom:
http://www.chaoticdreams.org/ce/jb/collision2.jpg

See how the collision never changes? We can twist, flip and spin him all which way but the collision is the same as if he was standing upright. If we used collision of the melee weapons for hits it would never work out. We could get the collion to aline nicely to a sword, when the sword was standing upright on its hilt. But as you then attach that sword and swing, its collision would always remain upright, even though the sword was moving at different angles which would result in very bad hit detection...

Make sense now?

so basically, you can hit, even if u miss awefully with this "coke can" method

Bit if u used the poly hit thing, it would work alot better

but would hit ure cpu alot degrading game performance and play

Well nowadays pc's are more powerful, so they could stand this alot better

Then again my pc dies alot when you have a 32 player bot match and a flamethrower going

Like i get about 40-50fps before play

it drops to like 30-40 during play, depending

With 12 odd bots it can go to 20

And with 32 it sits at about 10

with a flamethrower and 32 bots it hits 5, and 2 flamethrowers hits 2-3 fps

Damn that flamethrower hits my cpu :p

Its a 2.8 althon xp and a fx5900 256mb gfx card, and 1gb ram

depends how much of a performance hit this poly detection takes

jb wrote:Not really. Right now the code traces between the different bones in the weapons. In order for an object to "be hit" in the trace that objects collison must be in the way of the trace. We also have tried to place the bones at/near the weapon edges so we try to get the best possible hit detection that we can. As you can see while our system works and is pretty good, its by no means ideal. Per Poly hit detection would remove the need to have bones, would remove the trace calls and allow for almost a perfect hit dection system.

Sounds Logical. So basically, Bones suck skin rulz...

jb wrote:See how the collision never changes? We can twist, flip and spin him all which way but the collision is the same as if he was standing upright. If we used collision of the melee weapons for hits it would never work out. We could get the collion to aline nicely to a sword, when the sword was standing upright on its hilt. But as you then attach that sword and swing, its collision would always remain upright, even though the sword was moving at different angles which would result in very bad hit detection...

Make sense now?

I see... (Though it isn't Malcolm you're using it's Othello )

Neways, so you're saying that there are three hit systems:
1) Collision
2) Poly hit
3) Bones

and currently you're using bones cause:
(1) Cannot be rotated, etc
(2) cannot be computed by the computer without slowing it down like hell

so basically, you can hit, even if u miss awefully with this "coke can" method

That or consider this. You hold the sword upright. The collision matches. You then trust your sword into an enemys chest, not all the way say 70 of your sword. Since the collision would only be cylinder shape it would be perpendicular to the players collision but would not touch it, it would not follow the blade of the weapon and it would not detect the hit

Bit if u used the poly hit thing, it would work alot better

but would hit ure cpu alot degrading game performance and play

Yes the poly should be almost perfect hit detection. With the only drawback of it being heavy on the performance. But with a dedicated PPU.....And if we can always look at ways to optimize it so to save as much cpu/ppu/gpu power as we can

Neways, so you're saying that there are three hit systems:
1) Collision
2) Poly hit
3) Bones

and currently you're using bones cause:
(1) Cannot be rotated, etc
(2) cannot be computed by the computer without slowing it down like hell

Sorry to casuse confusion. The bones have nothing really to do with collision. They were created as a work around as we could not relay on just using collision allone to detect hits. And we could not use per poly. So we use the bones in the weapons to help us detect when that weapon hits a players (or walls) collision.

The bones are nice because it allows us to get a decent system with out causing the performace issues that a per ploy or other system would cause. The bones can be rotated or move, its the collision that the players use that can not. Does that help now??

lord_kungai wrote:and currently you're using bones cause:
(1) Cannot be rotated, etc
(2) cannot be computed by the computer without slowing it down like hell

I think these are both the other way round

They can be rotated, and the they can be computed by the computer without slowing it down alot

I may be wrong here though ...

And what is a PPU
i know what a cpu and gpu is, but ppu :s

Yahooadam wrote:i know what a cpu and gpu is, but ppu :s

Physic Processor Unit

jb wrote:

Yahooadam wrote:i know what a cpu and gpu is, but ppu :s

Physic Processor Unit

and where is that in my computer

dont remember installing one of those ....

You dont have them yet as they are just abuot to hit the market place. Rumors have that UT2k7 will support them....

Yahooadam wrote:

lord_kungai wrote:and currently you're using bones cause:
(1) Cannot be rotated, etc
(2) cannot be computed by the computer without slowing it down like hell

I think these are both the other way round

They can be rotated, and the they can be computed by the computer without slowing it down alot

*sigh*

What I was saying was:

lord_kungai wrote:and currently you're using bones cause:
Item number one on previous list [represented by (1)] cannot be rotated
Item number two on previous list [represented by (2)] cannot be computed by the computer without slowing it down like hell

Also, changing a previous question:

lord_kungai wrote:Neways, so you're saying that there are three hit systems:
1) Soda Can Collision
2) Poly hit
3) Bones

Where item number one from the above list refers to the cylinder thing jb showed us, item number two on the above list refers to the new and improved software that will hit the market with a loud "THWAP!" soon and item number three does not refer to the stuff that goes crack when you are being run over by a tank, but is the stuff that is used to construct dynamic objects (such as bibeds and melee weps) and help detect collisions.

Is that correct?

and item number three does not refer to the stuff that goes crack when you are being run over by a tank, but is the stuff that is used to construct dynamic objects (such as bibeds and melee weps) and help detect collisions.

A bone is used in animating. A modeler maps the verts (corner points of a poly) of a mesh (model) to them so when they are moved the mesh will deform (appear to move) They are not normaly used for anything other then creating animations. IE: every model that is animated has bones. Static Meshes do not have bones. They do not move. Epics Vehicles use attachment points as bones, but dont use actual bones.


FYI: I really enjoy boning a model

LoQtUS wrote:A bone is used in animating. A modeler maps the verts (corner points of a poly) of a mesh (model) to them so when they are moved the mesh will deform (appear to move) They are not normaly used for anything other then creating animations. IE: every model that is animated has bones. Static Meshes do not have bones. They do not move. Epics Vehicles use attachment points as bones, but dont use actual bones.

I understand... they are the base structure of the model that is to be animated... literally the 'skeleton'. This sounds like 3Ds max...

LoQtUS wrote:FYI: I really enjoy boning a model

*Cringe!*

Remind me never to play against CUT bots again...

PPU's would also take away alot of the processor demand on things like flamethrower effects. So, if all this PPU stuff is established and in use by the time UT2k7 comes out, we may be able to give the Chaos flamethrower another crack, by using physics instead of relying on a particle-nightmare.

What I am thinking is this: Instead of spawning bunches of particles to give the flame the visual effect, we just create physics flames (remember the explosion in a wind tunnel example I gave earlier) and blow them in a direction. So, instead of having a projectile with a visual effect attached, we create actual flames and physically blow them out the gun. The PPU ends up processing the whole thing, taking all the load off the processor, and vastly speeding up the entire process. We could have a much more realistic flamethrower (and one that would interact with water and other objects realistically, as dictated by the PPU itself), without lowering framerate.

So you can see why I'm looking forward to this. I can't wait to start playing around with a PPU-powered physics engine. :drool: