PDA

View Full Version : Thinking outside the cylinder...


FireSlash
31st Oct 2001, 05:34 PM
is there any way to make UT collide with polys and not the cylinder around the model? i would REALLY hate to chop my structures into cubes to make them collide right.

HOB
31st Oct 2001, 06:03 PM
you could use multiple collision cylinders

FireSlash
31st Oct 2001, 10:24 PM
ugh. more work than i really wanted... :hmm:

usaar33
31st Oct 2001, 10:40 PM
no ;p
it doesn't have to be a cube though!
It is a cylinder! ;p

FireSlash
1st Nov 2001, 03:46 PM
a cube would have been BETTER then a cylinder in my case...:rolleyes:

Eater1
1st Nov 2001, 04:13 PM
A cube would have been better in my case too... Just figure out some way to use multiple cylinders. Why, what do you need to make?

Eater.

TaoPaiPai
1st Nov 2001, 05:15 PM
One idea:
Make a subclass of mover and recode it to make it work the way you want.Now one big problem is that your actors will be map dependant ....unless you find a way to import BSP geometry into a map on the fly .(that might be possible...)

Eater1
2nd Nov 2001, 03:35 PM
No, it's not. Any geometry needs to be rebuilt (trust me, I've tried... ugly errors). No way to insert geometry on the fly.
As for using a mover, the biggest problem with that is that a mover doesn't collide with level geometry.

Eater.

FireSlash
2nd Nov 2001, 04:30 PM
so the cylinder is coded into the engine, or is it just a class?

Eater1
4th Nov 2001, 04:20 PM
Well, it's not a different object, if that's what you mean. If it's coded anywhere, it would be in the Actor class, but I believe it's somewhere in the native code.

Eater.

Papapishu
6th Nov 2001, 07:12 AM
Me to would like to find out where the heck the cylinder is defined, since I've been looking for it for a long time...
Anyone knows?
Eater1, now you have crushed my hopes and dreams... :mad:
I wanted to make a GeoMod-Mutator.
You've seen red fraction, haven't you?
It's based on the "GeoMod" 3D engine, which has the capability for, as the name states, demolish the geometry...
The idea I had was to make weapons that, when doing damage to the level, they should leave a subtraction-brush there in the shape of a more-or-less round shape ((de)intersected ofcourse (whichever's right for sub's))
If the engine had been capaple of that, it would certainly rock your pants...
Imagine that ig you blast the wall with the RL, you carve out a meter-wide hole, spreading the gravel on the floor...
And then Imgaine the redeemer... Whoo!
There's no way you could hide behind a glass-window, or anything incredible like that, when it comes flying... :D

You make me sad:(

Well, let's hope you have that possibility in Unreal 2 :)
Since they have dynamic raytracing, then why not have dynamic rebuilds...? :D

Eater1
7th Nov 2001, 03:33 PM
Heh... Keep hoping, although I very strongly doubt it. And yes, I'm completely, 100% sure that it can't be done... Back in the days of Unreal 1, I spent over a month trying, and all I have to show for it is a gun that generates a very pretty error message when fired.

Eater.

TaoPaiPai
7th Nov 2001, 06:50 PM
Originally posted by Eater1
Heh... Keep hoping, although I very strongly doubt it. And yes, I'm completely, 100% sure that it can't be done... Back in the days of Unreal 1, I spent over a month trying, and all I have to show for it is a gun that generates a very pretty error message when fired.

Eater.
Lol

BTW I'm not sure that it is impossible to import geometry without rebuilding.Think about it.
When a mover moves it can be calculated in a virtually infinite number of position (depending on the framerate of the computer playing UT).So we can say that the number of positions for a mover can be infinite.So the engine Has to do some kind of interpolation sometime (the mover class uses a function called 'interpolateTo' to make the brush move) .You cannot say that all the positions of the mover are computed once and for all.
Moreover a mover can be 'attached' to another mover or another actor (using uscript) making it impossible to assume with anticipation all its possible positions,so the engine has to compute the Geometry 'on the fly' somehow.And what about semisolids huh?

Eater1
8th Nov 2001, 04:09 PM
There is a difference between moving geometry and creating geometry out of thin air. If you have the wall as a mover to begin with, you don't even need to code anything to make it destructable (just make it damage triggered). Even semi-solids needs to be rebuilt.

[EDIT]
Oh, by the way, you are right that movers can have an infinite number of positions, and I have a much better proof for that: I've made a mover that follows several meters behind the player... It's VERY easy to make. A mover is basically a moving brush, so it can move, but that still doesn't mean it can be created or destroyed (well, maybe it can be destroyed... I'm not 100% sure on that one).

Eater.

usaar33
8th Nov 2001, 11:49 PM
as for the BSP:

You can, under no condition, move walls. End of discussion. As a matter of fact, it is impossible to access them.

as for movers:
You cannot create them at all. HOWEVER, it is possible to move or rotate them in any direction. Yet you cannot have them break apart of have anims and stuff. (vertex minipulation is not possible).

thank you.

as for meshes with poly by poly collision, forget about doing it in uscript. With luck, you might be able to pull it off in native code, but even when someone wrote skeletal collision code it was quite difficult.

Eater1
9th Nov 2001, 03:40 PM
Exactly... Just what I've been saying all this time.
Anyway, as for poly-by-poly collision, correct me if I'm wrong, but aren't They (with a captial T) planning to include it in Unreal 2?

Eater.

Smoke39
9th Nov 2001, 04:26 PM
Couldn't you make stuff out of pieces? For example, a player's torso could be one actor with its own cylinder, its head could be another actor with its own cylinder, etc. and have one part controll all the other parts and would keep track of damage. So when one of the arm actors was hit, it could do however much damage it took to whatever part is keeping track of everything.

Papapishu
9th Nov 2001, 08:10 PM
It could prove difficult to keep it all pieced togehter correctly.
Althoug you could do a "body"-piece which has a mesh and cylinder, and then add on block-actors as arms, heads where the mesh "exits" the cylinder, which would give more accurate hit-detection...
Again the problem is to hold the pieces in the correct place.
Unless there's some very good way of checking how the mesh moves, it's gonna be hard...
Maybe it'll work with seletal chars, if you get the vectors from the skeleton...

usaar33
10th Nov 2001, 01:04 AM
Originally posted by papapishu
It could prove difficult to keep it all pieced togehter correctly.
Althoug you could do a "body"-piece which has a mesh and cylinder, and then add on block-actors as arms, heads where the mesh "exits" the cylinder, which would give more accurate hit-detection...
Again the problem is to hold the pieces in the correct place.
Unless there's some very good way of checking how the mesh moves, it's gonna be hard...
Maybe it'll work with seletal chars, if you get the vectors from the skeleton...

Actually it is surprisingly simple. Just set each pieces "base" to another. You will need to take care to ensure that collision is universal, but oh well :)

Eater1
10th Nov 2001, 12:01 PM
Ah... I think I see what you're getting at usaar... You will need to explain it a little more however.
var const Actor Base; // Moving brush actor we're standing on.
This is the Base variable in the actor class. Now, although it says "moving brush" in the comment, the variable is of the type actor. I assume what you mean is that if the player's torso is the actual player and is set as the base of the arms and the head, the arms and the head would follow it, correct? I've never made use of Base before which is why I'm asking. Would they keep their offset from the player's location as the player moved around and even rotated? I'm too lazy to test this out at the moment...

Eater.

Smoke39
10th Nov 2001, 01:32 PM
Having all the parts not in exactly the same place is what would be complicated.

Eater1
10th Nov 2001, 03:27 PM
Yeah, I thought about that to... That's why I'm asking exactly how the Base thing works. I know that if you use a PHYS_Trailing method they will be in exactly the same place, but I'm not sure about the Base method... If someone who has time could test this out...

[EDIT]
Another thing to keep in mind, in case someone didn't figure it out already, is that if you simply use the SetLocation(...) function every tick to keep the parts in the right place, the collision won't work because the Touch(...) and HitWall(...) functions are only called when the collision cylinder comes in CONTACT with the object, not when it encroaches on it (and almost all of the time, with the SetLocation(...) function, you'll end up encroaching on the wall/actor instead of coming in contact with it).

[EDIT]
Another thing I just thought of... Even if all the parts ARE in the same place, it might still be useful to have several collision cylinders in the same place especially for something like the player. Here is an image to illustrate this.
http://members.home.com/lsergey/multicylinder.jpg
A script could be used to ignore any collision with the head cylinder in the lower half and the leg cylinder in the upper half... Of course, this wouldn't help much if you want to make nice collision for something more complex such as a vehicle.

Eater.

usaar33
10th Nov 2001, 05:51 PM
"base" means that it moves with its base.
If the base moves 3 units right, so will it.
Now I stress you WILL need to write custom code to handle multiple parts collision. or else parts might fall off...

Smoke39
10th Nov 2001, 09:43 PM
Does that mean the limbs and such would rotate with their base, or just move with it?

Eater1
11th Nov 2001, 03:43 PM
Yes... That too... If they can't rotate with it, it's pretty useless.
And we of course realize the part about having to write code that will link all the collision (so if the arm hits a wall, the whole body should stop)

Eater.

Papapishu
12th Nov 2001, 06:57 PM
Yeah, that would be annoying in istagib matches, if your arm got stuck someplace and someone hit it... :D

One problem is that if you want it to move with the body, you gotta find out somehow, how the mesh is standing.
Take running for example
The legs move back and forth, and seeing from the side, you could shoot the player between the legs when they're apart, if the cylinder isn't moving like the legs...
But that might be a bit picky...
But the very best should be if then engine could cope with realtime polygon-hits on the mesh...
Although it might prove to be bad, since many ppl might cheat by using a smaller mesh, like the female...
I thought that's how it worked before I knew the topic "collision cylinder"... :o

EasyRaider
13th Nov 2001, 06:40 PM
I think you could also do a lot with Pawn.AdjustHitLocation(), but that too would be very hard to get right.

Eater1
14th Nov 2001, 04:32 PM
Well yeah, but with that you wouldn't be able to do fancy collision for something like, say, a long car or plane... I still want to know if the Base thing will adjust the rotation as well as the location, because it may be just what I'm looking for.

Eater.

EasyRaider
14th Nov 2001, 04:36 PM
I believe it does change the rotation. Why don't you give it a try?

Eater1
15th Nov 2001, 03:34 PM
Too busy... Must work on Nali Chronicles...

Eater.