In Urho3D is there an easy way to implement an explosion?
For example, I have missiles in my game and I would like to instantiate an explosion for when they collide with something.
Any help would be greatly appreciated, thank you.
In Urho3D is there an easy way to implement an explosion?
For example, I have missiles in my game and I would like to instantiate an explosion for when they collide with something.
Any help would be greatly appreciated, thank you.
You’re probably going to be using a combination of different effects to achieve an explosion: UV animated geometry, particle systems, full-screen whiteflash if the explosion is powerful enough, etc… For a jumpstart on some ideas, you might check out this game art trick regarding mushroom clouds in Fallout. It uses a combination of various systems to simulate the components of a mushroom cloud explosion, and it goes into discussions of a number of different techniques that you can use.
Hi, thanks a lot for the reply, unfortunately I’m currently doing a space game. Mushroom clouds may not make much sense in my game as there wont any solid ground around the player. I’m just looking for a simply explosion like the ones you typically get in a game where a player dies by explosion or a simple grenade type explosion.
Again thanks so much for the reply
Well, most of the same tricks should still apply. The only difference is the columnar shape. You’ll still make use of the same kinds of techniques, that’s why I suggested that article as a jumping off point. It talks about the kinds of billowy textures you’ll want, color grading them, adjusting alpha and falloff to smoke colors, etc…
At its’ simplest you can create a node with a ParticleEmitter
that’s set to auto-remove
at the explosion location.
If you need debris/shrapnel you can use Scene::Instantiate____
functions to insert a prefab and iterate over it’s contents applying physics forces as necessary (ie. radially from center, in a cone around contact normal, etc).
If you need to apply a blast wave of physics forces you can use an expanding sphere query over-time (keyed on whatever physics mask is desired) and apply forces as needed.
If you need a visual shock-wave you can use a model and an AttributeAnimation
on it’s scale along with material-animation for any fade/ramp. Model is a bit more versatile than a BillboardSet here since the shock-wave can then be whatever (a shell, a card, death-star exploding ring mesh, w/e) and oriented however (along normal, looking at view, randomly, etc).
There’s a ton of different ways you can tackle it depending on what you want.
Also, you can use camera shake to make the impact shocking
You could move the camera in update or make camera animation in Blender or something and export the animation and then apply the animation to the camera.
@WangKai Something like this?
Exactly! And pre-made animation can be very high quality but static.
The best way is to someone (probably someone with more spare time than me) expand the current particleEmitter class and implement template based interpolators for various parameters (e.g scale , velocity , gravity , force , etc) very similar like how in SPARK was done.
<interpolator>
<param = Scale|Rotation|Velocity|Force|Color|Texcoord|Texture />
<type = Constant|Graph|Random />
<operation = Add|Subtract|Multiply|Override />
<values = "value , time" />
</interpolator>
Note : There is a Texture param which could be a really useful parameter.Using two different textures (Perhaps diffuse and enviroment) and fade into each other.Just imagine a yellow flame texture fades into a grey smoke texture.
@Dave82
I don’t think there’s that much missing from the built-in particles.
The only changes I’ve had to make:
Quaternion(90, Vector3::RIGHT) * rotation
Path-following GIF: there’s a wagon-wheel illusion with the gif framerate, they actually go up - not down
I could make a PR for those changes.
Only really major thing I feel missing is aggregate effects so multiple emitters with different effects sort together - that’d be full of of hacks though so I haven’t touched it. Means same material, same FaceCameraMode (shader cares), etc. Only the emitter behaviour can really change.
That’s arguably a small price to pay to not have to use 8 different partial ring emitters so ring particles don’t render in-front of a plume.
Edit: cleaning up what I have and porting it back to master (aka: actually testing the daylights out of it). Aggregate effects were actually really trivial once I set down to it (let the children all be but deny them rendering responsibility, master memcpy’s their billboards into itself - done and not insane), though the constraints I mentioned still apply.