Here’s a little FPS blend with a virtual (laser Light) rope. To catch things or swing with it.
Left Mouse button: attach the rope
Right Mouse button: detach the rope
Mousewheel up: make rope shorter
Mousewheel down: make rope longer.
When swinging you can apply some power and direction with the WASD-keys.
The physics code was quite challenging to find out. Especially to get rid of bouncing when “falling into the rope”.
Hint: Objects for connection must have the last collision layer enabled for the mouse to be detected.
(Another approach would be to use compose a rigid-body-chain. Will have to look into it.)
Now we can make a Spiderman game
UPBGE 0.3 FPS_Constraint.blend (1.3 MB)
Above blend now has a solid rope. in rope.py you can set
use_laser_rope=True
if you want the red laser rope.
The rope will now be “shot” at the object instead of being instantly there.
Does anybody know how to create a cool lokking procedural shader node for the rope that doesn’t scale in z.direction when the rope object will be stretched?
—update—
Still only forces without usage of rigid-body constraints.
But better behaviour and you can swing on hanging rigid-bodies too.
Does anybody know how to create a cool looking procedural shader node for the rope that doesn’t scale in z.direction when the rope object will be stretched?
The rope is a short object that is scaled to length of the virtual rope. I tried to make a material that is independent of the object scale. Luck
If I use the Vector-transform node (Object->World) it also is independent of rotation and position. Would like to have only position and rotation of the texture with the object but not the scaling. I wasn’t able to solve this with nodes.
So now the material mapping is scaled by code along with the object in
“rope.py”.
For the rope I used a Wave-Texture node.
Sometimes the rope takes some color of the objects behind with it. Looks a bit strange.
What is this? An Eevee render artefact, my graphics card, or a setting in my rope material?
For the fun of it now you can have 2 Ropes.
The MouseWheel UP still makes the rope shorter, MouseWheel DOWN longer.
Right Mouse Button removes the Rope.
When you have 2 Ropes your Camera Angle matters which Rope will be affected. You see it highlighted. FPS_Constraint2.blend (1.4 MB)
First Test for a segmented Rope:
The first rope has 4 Segments. All Constraints pure python (no rigid body joints). Expandable. (but needs more elegant code structure). FPS_Constraint5.blend (1.4 MB)
Here is a Version with 10 Segments and the code is structured, so you can add as many Rope segments and as you like. You just have to have 1 Rope-object more than “atom”-Objects.
This is just experimenting. For a swinging game I’d prefer Version 2 or 3. FPS_Constraint6.blend (1.4 MB)
Here is the above Version but the Rope_Segments and Atoms are automatically added.
You can set the number of Rope_Segments in the code in this line: num_of_ropes=11 #must be at least 4
Note: The more Rope_Segments you have the more the physics on the player are slowing him down when in a certain distance. Not easy to solve for me at the moment.
Anyway it’s a riddle how to choose workable factors for the rope.
In this version both ropes are the single line as default. But you can easily change Rope 1 or 2 to the multi-segments versions in the logic bricks.
Instead of giving a target object an impulse in these version the target is connected by a rigid-body-Ball-constraint to the ropes which gives less jumping if the target is hanging. (you can still give it a force or impulse instead of position change in the code if you prefer.)
The multi-segment-versions still are really bad for swinging.
(edit: ah, hope for multi-segment-ropes in version 13 after re-introduction of velocities.)
(edit2: Aha, have set the mousemovement sensors to pulse because in UPBGE 0.33 it is required. Surprise, surprise) FPS_Constraint13.blend (1.5 MB)
Step by step the multi-segment ropes are workable for swinging.
By using applyforce instead of adding velocities in the multisegment springs the swinging velocity is preserved better.
Ropes 1 and 2 are set to multisegment in this version. You can change each to the single-segment version in the logic bricks. FPS_Constraint15.blend (1.5 MB)
Now the ropes can have any number of segments, from 1 to x.
This number depends on the property “stick” of the object the rope will be attached to.
The objects that the ropes should be attachable to must be on the last collision layer and have the integer property “stick”.
The integer number of the property “stick” will be the number of rope segments.
So here for example the ropes will have 8-10 segments on all movable objects but only 1 segment when attached to the fixed objects for swinging. FPS_Constraint17.blend (1.8 MB)
Swinging pool
PS: The waterdroplets-glsl-effect in version 17 and 18 are from martinsh’s watershaders. I wish I could make his watertexture work instead of my foolish attempt. FPS_Constraint18.blend (1.9 MB)
If I had known to search for this.
