Hover vehicle prototype

Couldn’t decide what kind of game to make but decided it’ll revolve around some type of physics - hover vehicle prototype: no effects, just demonstrating dynamics.

Had trouble figuring out how to lock the roll angle during turning. First tried detecting if it exceeded max roll value and resetting to it but that caused wobbling/jittering effect. What you see in the video uses btGeneric6DofConstraint.


nice demo… no mans sky urho proto… :grinning:

You can try separating physics object and visual model. Make physics one to never roll, and make visual model to roll based on physics object turn speed.

no that’s empire strikes back hoth battle.

Yea looks nice. I would suggest a non-linear relation between the turning speed and banking amount; put a Sqrt or Pow somewhere.

Thx. Still working on hovering aspect as it still kinda oscillates up and down a bit, but it’ll get there.[quote=“Bananaft, post:3, topic:3182”]
You can try separating physics object and visual model. Make physics one to never roll, and make visual model to roll based on physics object turn speed.
That might actually be a lot simpler than using btGeneric6DofConstraint method because it was tricky figuring out how to get around the multiple axis constraint issue.

Something similar to using a quadratic curve? That might work, not sure if it still won’t result in a jitter at desired max roll angles. Will have to test at some point.

Quadratic functions are limited to power-of-two situations by definition, but yea some exponential relation. :slight_smile:

Well, the idea is that the changes in the effect get less and less towards the extremes.

Right, it seems exponential computation might be more common than I expected. I’ll need to test it sometime.

All right, took some time to actually integrate btGeneric6DofConstraint from test code to Urho3D::Constraint class. Currently, its use is similar to using the

    btGeneric6DofConstraint(btRigidBody& rbB, const btTransform& frameInB, bool useLinearReferenceFrameB);

constructor for the caller. But to get around the multiple axis constraint issue when using btGeneric6DofConstraint class, the 2nd btRigidBody is not static but dynamically created (opaque to the caller) because its rotation is manipulated at runtime to overcome the axis constraint issue. And current implementation only deals with angular limit.

Anyway, I can create a repo for the integrated Urho3D::Constraint with this addition. Unfortunately, I cannot post the flyer code since it’s based on Unity - it’s free to use but I believe there’s restriction on posting it as open-source code.
Let me know if anyone is interested in seeing a repo for this.


Any chance to PR it ?

I typically just create my own repo.

Projectile and explosion testing. I’m posting this because when others post their game progress, it inspires me.

From programmers perspective, I thought the cyan plasma and explosion looked good. Maybe I just don’t have an artist’s eye.

Does this look better?

How about cyan bullets with a cyan-to-orange explosion? To suggest ignition of the backstop by the bullet.

So… you don’t like either one?

btw, if you get a chance to implement your exponential forces to lock down rotation, I’d like to see it.

seeing projectiles curving gives a fuzzy feeling imho. Gives the impression shooting is difficult. I’d give them a more straight trajectory, while retaining some curvature for effect…

I like both, but may like 'em mixed up best.

johnnycable, projectiles actually do travel in straight path, they just appear to be curving when the vehicle and camera are moving.

Modanung, ah ok. I have very little confidence in art that I make and thought that perhaps both were bad ha.

Stress test

100 shooter simulation

On average:
~1600 projectiles in the scene
~200 explosions

edit: added info on other images

50 shooter sim

~900 projectiles in the scene
~100 explosions

20 shooter sim

~340 projectiles in the scene
~50 explosions

@Enhex you’re the only other person that I know that’s also doing something with shooting - do these numbers look right to you?

Depends on things like hardware, implementation details, and what your game demands.

I’d say keep it simple when first implementing stuff, and only when you have performance issues measure & optimize.

I don’t know any implementation details so I can’t give you actual tips for optimizing.