Weapons sticking through walls?

#1 Yeah, the weapon in 1st person is an image.. and is not the same weapon really, that is shown in 3rd person.
On the other hand, that shouldn't really happen if you have set up the bounds correctly, AFAIK the weapon will bounce back rather than go trough the wall.

When I had an incorrect bounds box, what you described would happen and the weapon could be visible trough walls, doors.. and other thin objects - which kind of killed the stealth approach a bit.

#2

Quote:
the weapon in 1st person is an image.. and is not the same weapon really, that is shown in 3rd person

Is this correct?

I recently added collision detection for mounted images which works fine in 1st and 3rd person view.
I never noticed, that there is a different image or model for these two modes.

Regarding the wall issue:
Weapons can have a retract node called: "retractionPoint".
The engine exectues a raycast between the mount node of your weapon and the retraction point, to see if there are intersections. If there are, the weapon is pushed back, by some amount.
(However, in 3rd person, you can see the weapon pushed back inside the player)

So if you position the retractionPoint at the very far end of your weapon (maybe even a bit more) you should not get wall intersections. At least not, if you directly hit the wall.

-- Markus

#3

Quote:
Is this correct?

I recently added collision detection for mounted images which works fine in 1st and 3rd person view.
I never noticed, that there is a different image or model for these two modes.

What I meant to say was that the weapon you see in 1st person is not the one that you see in the hands of the player in 3rd person. Or well, the one you see in 1st person is modified from the other, and is placed in another method to face the eye, AFAIK.

Anyone feel free to correct me on this though.

#4 Sorry Stefan.
I am not a native speaker, so I may mix up things ;)


What you said about 1st and 3rd person view, is this refering to the an already mounted image?
Or are you talking about the 3rd person view, that you get when the weapon is placed inside the level and the player is approaching it. And are you talking about the 1st person view, you get when the weapon is picked up and mounted?

AFAIK: Different models are only used between the unmounted weapon. (This is simply the model, that the item uses) and the model, that is used by the ShapeBaseImage, after the weapon is mounted.
A mounted weapon is rendered as the ShapeBaseImage, regardless of the player being in 1st or 3rd person view. This means, the model is the same for both modes?

I have checked the player.cc file and weapons are rendered during:

void renderMountedImage(SceneState* state, ShapeImageRenderImage* image);

Within this function I haven't found any special or different handling for the 1st or 3rd person view.

Have I misunderstood something?

-- Markus

#5 Ugh! The weapon is an image?

1. Does the engine render those or are they drawn by hand?
2. It is possible to get the model rendered as a shape in 3rd POV?
3. I am using the orc, is this problem due to the nodes? i.e. does he do this on everyones levels?

#6 The term "image" is misleading in this case. ShapeBaseImage's are just special-case dts's for mounting onto the player that also has a state machine for transitioning between animations. They also don't collide against the player (which is what happens when you mount a StaticShape to the player). The 1st and 3rd person weapon is exactly the same mesh.

#7 Yes, Image does not mean: picture here.

Check out the crossbow script code. It defines an object of type: ShapeBaseImage, which has a .dts shape associated with it.

This .dts shape is rendered when the weapon is mounted and this is what you see.
I think simply adding a collision mesh to the weapon is not sufficient, since these ShapeBaseImages are not taken into account by the engine during collision detection.

The only thing that matters here is the retract node.
Checkout:

void Player::renderMountedImage(SceneState* state, ShapeImageRenderImage* rimage)

and look for the comment
See if we are pushed into a wall....

That's where the weapon is pushed back, if it interferes with surrounding objects.
The amount of this "pushing back" is determined by mWeaponBackFraction
which is calcualted in

void Player::calcClassRenderData()

based on a raycast against all objects except for objects of type: water and default.

The raycast is executed for the two nodes i mentioned in the above post.

The orc has nothing to do with this stuff. This is simply a topic for the weapon or better the model, that is used in the weapons model. This works with the crossbow from the demo, so you might want to check out it's node layout in Torque Show Tool Pro.

-- Markus



Here the

#8 @Fruit
Are you using the crossbow in the SDK ?
If you do then it will not work at all .
All backfractions on weapons work in both views , if you have a working collision on the weapon.
And the crossbow in the SDK does NOT have a working collision !

#9 @billy

Yes I am using the crossbow. I'm actually still in the starter.fps working on scripts and models.

Quote:And the crossbow in the SDK does NOT have a working collision!

Thats cool then, still at the early stages and looking for probs before we dive into the serious stuff.

does anyone have an idiots guide to all the export process for models, I know we have the node lists etc but is there a tutorial lying about?

#10 I can send you the crossbow with working collision if you want .

#11 That would be great billy :) don;t suppose you have it in .ms3d or .obj format too ;oD

#12 Thanks Billy :)

#13 Billy, could you send me that crossbow with collision? (just the DTS thanks). My email address is robharwood@runbox.com

#14 Submit it to GG why dont they use it if its better ??? lol

#15 Oh my god !
I only exported the crossbow temporary with collision.
Dont have it anymore , FruitBat got a copy i mailed to him , hope he read this.
I only changed it because they were talking about that the backfraction was not working.

#16 Here is the file you sent me Billy :) Crossbow.zip

#17 Thanx! One fix to get it to work. I had to change the engine to do a castray() from the player_eye to the muzzlepoint to determine if there was an object in between. I did this in 1.5.

void Player::calcClassRenderData()

Parent::getRenderMuzzleTransform(0,&nmat); // Parent::getRetractionTransform(0,&nmat); //RANDY: Get muzzlePoint transform