Irrlicht Engine

in the words of nathan barley... thats "awesome f*cking wells!"

I'm working on enhancements to the particel system now. I'm posting some shots and explanations here, cause it's not ready to be released, but here's a sneak preview.

First of all, I've added the following functions to access emitter data after creating :

• set/get Direction
• set/get MinParticlesPerSecond
• set/get MaxParticlesPerSecond
• set/get MinStartColor
• set/get MaxStartColor

I've also added a sphere emitter and ring emitter, in addition to the point and box emitters.

Here's a basic screenshot of the new sphere emitter :



Here's a screenshot getting a little fancy, using sphere emitters and FollowSplineAnimators



And finally, here's a screenshot using the sphere emitter, and the ring emitter is used around the sphere



Anyone have any ideas on any other additions for the particle system, please let me know!

Spintz, you are the best!
"Irrlicht" written with particles it's discovery! Would like to see demo!

And, thanks to Bitplane for the idea, a MeshEmitter for particle system.

Still needs work, to support multiple meshBuffers and animatedMeshes, but, the basic work is done :

Hi Spinz, about set and get methods:
I wonder why these stuffs are still not implemented in official Irrlicht. Whith every new version I must to adds it for myself /litle bore /

Also by me animators are not developed enough:
- at first they needs extendet interface. Interface like this exist only for collision responce animator. For example if in Irrlicht exists interfaces like
- ISceneNodeAnimatorRotation
- ISceneNodeAnimatorFlyCircle
- ISceneNodeAnimatorFlyStraight
- ISceneNodeAnimatorTexture
- ISceneNodeAnimatorFollowSpline
with combination of set and get methods user will be able to change its propertyes easy at runtime.

Also one function like will be useful.

I add these stuffs for me but thinks that it's must be added to official Irrlicht.

One idea is also to each animator can be added any namel and id, that is useful if node has several animators by one type.
Also maybe is not superfluous any event system for animators, that sort of that one animator will be able to change properties of other an runtime.

Thanks for your efforts for extending of particle emiiters .

Yeah, that's kind of a pain, because there is nothing common between the different animators. The only thing, they use time for something, but for all different times.

It would be nice to modify animators at real time, instead of dropping them and creating new ones.

There's really no need for the Interface classes for each though, I think it's easier just to move the .h files to include, add them to irrlicht.h, and then add all the get and set methods directly to the classes. No need for 7 new files just to have interfaces for each. I'll keep the ISceneNodeAnimator class for now, and the smgr->create functions for animators will still return the basic ISceneNodeAnimator*. You can cast that return value to whichever specific animator you want and then call the set/get methods. That way, if you don't want to call set/get methods, your code won't have to change at all

All that I have left to do in Irrlicht-Spintz for this is finished adding all the get/set methods for the different animators. This will be in the next version I put out.

brilliant!
no more positioning ship boosters one by one, and arrrgh, my arm is on fire!
thanks sprintz

Nice,very nice.
Well I come from 4-5 months of learning OGRE, wich impresed me with it's power, it's effect and flexibility.
But now I want to make a game and I would like to use OGRE, ODE and OpenAL and create a game engine so I can work much easier.But there is the point were I got a problem because I wanted to extend OGRE with a SoundManager and a PhysicsManager and found out that OGRE is made too complicated and too much made to be only a rendering engine.
So a return to my first idea: to extend Irrlicht , but I don't like the leack of fexibility.What I would mostely like would not be OGRE but an Irrlicht with the features OGRE has, because Irrlicht has a simple and clear API.
Now I know some features from OGRE can be made a lot simpler and faster.
Irrlicht is younger and can benefit from OGRE's experience and reinvent theyr methods.I would like some help and you seem to like to improve Irrlicht.
I have got some good ideas for Irrlicht but most of them might scare the newbies of Irrlicht(these are mostely advanced features I want to add to Irrlicht).
What do you say?.

Just bring them up. I never know what I'm gonna work on next, so any ideas are appreciated.

could you have a particle system for rain and snow?

I supposed that you have been moved to Ogree. Welcome back. I guess who will extend Irrlicht water scene node also with some kind of environment mapping I never used Ogree, but have been seen that its water node has more advanced features.
Also, Irrlicht development is fast, because Niko works in game creation business. He ever surprise us with many nice additions in each new version.
OpenAL is easy to implement in Irrlicht. I was started implement OpenAl scene node, but it's not finished, because migrate to development of other stuffs. Here is some examples for ODE using, but you know about this. I'm still not choice what Physics engine to choose, but maybe Niko will include his internal physics engine like addition to graphics engine

@guest-
rain/snow are already possible with the usual particle system. use the particle editor to get the desired effect, then attach the system to the camera and a stick a box emitter just above it. ezpz

How about a Second Order Particle System.
http://www.tml.hut.fi/~tilmonen/vee/dow ... scg-03.pdf
I have read about it on OGRE forum.
@etcaptor:I did the water from OGRE for Irrlicht and with a lot easier code.

I've added the ability for the Mesh Emitter to emit based on the vertex normals for direction, or override direction. I've also added the ability to emit between min/max particles per second from random vertices in the entire mesh, or in a single mesh buffer. I've also added the ability to emit between min/max particles per second from all vertices in a mesh, or all vertices in a specific meshbuffer.

I've also added what I call an attracttion affector, which attracts all particles to a specficied point, at a specified speed, and you can affect any or all of the X, Y and Z positions separately or together for the attraction affector.

I've added interface classes to all SceneNodeAnimators, Affectors and Emitters to be able to modify parameters of the Animators, Affectors and Emitters after they've been created.

I'm still going to add a cylinder emitter and a spiral emitter.

I'll look at the second order particle thing, never heard of it.

Oh, here's screenshots of Mesh Emitter, emitting for all vertices, and all mesh buffers, with a fadeout affect, gravity affect and attraction affector -

Quick glimpse at the second order particle system and it just looks like a fancy affector. I'm more interested in getting volumetric textures and volume rendering implmented for the most realistic effects for fire, smoke, etc

Have some basic math work in, for volume textures and rendering, but need to implement a way to load volume textures from data, or create them dynamically procedurally.