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… 
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.
[/quote]
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. 
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.
On average:
~1600 projectiles in the scene
~200 explosions
edit: added info on other images
~900 projectiles in the scene
~100 explosions
~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.
Right, absolutely. What I was curious about was if you ran a similar stress test and evaluated physics process, and perhaps we could’ve compare notes. If you haven’t, no big deal as I’m done with this part of gameplay and moving onto my next feature.
edit: er, I wouldn’t call it gameplay but implementation, testing and proving that I can have several entities fire projectiles in the game.
I did run stress tests, and my bottleneck was the AI raycasts - line of sight checks, path collision, etc.
I provided segmented raycast implementation to Urho, which in my case doubled the whole game’s FPS.
Sorry, that didn’t come out right when I said you didn’t run a similar stress test which sounds like you ran no stress test because every developer does stress test.
I didn’t know about the segmented raycast, thanks for that.