Particle rotation addition.

[All8Up]

With the other item in review, I decided to add another rendering ability to the particle systems. This one builds off the rotation ability and adds the ability to do velocity based stretching. It's a good way of doing sparks and other streak like items and can be helpful with flames and such also. Anyway, here is a simple example image:



This is not a great usage of the item but since it was a quick 5 minute addition I figured what the heck. The particle in use is "portal1.bmp" 10x10 with a 10 times stretch amount along the velocity. The patch needs to be applied on top of the particle rotation patch and can be found in the tracker at: https://sourceforge.net/tracker/?func=d ... tid=540678

Regards.

[All8Up]

And a better image after fixing view vector alignment attenuation.

[ACE247]

WOW
Allthough, whats the side effects?

[All8Up]

WOW
Allthough, whats the side effects?

If not turned on, just an extra comparison and one float multiplication per particle. When turned on, a bit of extra math (dot product and lerp) and also the rotation code from before.

[Virion]

awesome O_O you're my hero

[CuteAlien]

Could you also add your example somewhere - beside the patch or post it in the forum. Saves me the time to write my own when testing this :-)

[All8Up]

Could you also add your example somewhere - beside the patch or post it in the forum. Saves me the time to write my own when testing this

I didn't want to put it in there as it is just a hacked up version of the per pixel lighting. I suppose if you remember to remove the changes to that it should be fine though. Or I could post it as a separate patch file. Of course I should actually post a completely new patch, found/fixed a couple bugs later in the day and ended up finding/fixing a bunch of other issues when I did a cleanup pass. Just a list of the changes I have locally now (perhaps too much for integrating to trunk at this point, lots of small and large changes here and there):

1. Moved all shared code for the emitters into a new CParticleEmitter.h file. Not sure if you folks will like this as it uses a template injection so all the concrete classes can share the code. I could have done this a couple different ways but the pattern in question is the lowest maintenance variation, there is probably 90% less code in the remaining files now. Most of the emitters are now not much more than a constructor, overridden "where" to emit new particles and serialization of their custom parameters. All the core routines/update etc is moved to the shared code.

2. Fixed a couple bugs in serialization I found when making sure all the emitters shared the common code. Cylinder for instance was writing "Distance" out as the "Center" attribute I think was one of them. I was going to go ahead and add in serialization for mesh and animated mesh emitters but couldn't find a good reference about how to serialize the node pointers in those two items.

3. Reworked the emission direction vector randomization. I noticed in many cases that the randomization only worked in one quadrant around the direction vector which made it nearly useless for my purposes (seemed like a bug at least). At the same time I wanted to add in a MinAngle ability so you can build a point emitter with direction set to yaxis, set min to 85 and max to 95 and it will spit particles out to the sides but none up or down. I did not add this to the constructors though as that would have changed the interfaces too much.

4. Added an option to the gravity affector to use "real" gravity. The version doing interpolation looks too funky for my tastes, it is an option and defaults to using the interpolation method so no changes to anyone expecting the current behavior.

5. Moved the rotation about arbitrary axis code (the big equation in the rotation bit) into the vector class and fixed a goof in it when I translated it from my right handed math library to the left handed Irrlicht version.

I think the only two things I care to do from here on out with the existing code is perhaps adding a noise affector to give particles a random drift and the other thing would be related to the gravity change, basically because true physics are unstable with variable frame rates, I'll add an option to the update loop to do a max step update. I.e. if the delta time is more than 10 ms, run the movement/affectors in multiple steps as an option.

Anyway, that will have to be in a couple hours. Late here and have errands to run in the morning.

[CuteAlien]

Could you also add your example somewhere - beside the patch or post it in the forum. Saves me the time to write my own when testing this :-)

I didn't want to put it in there as it is just a hacked up version of the per pixel lighting. I suppose if you remember to remove the changes to that it should be fine though. Or I could post it as a separate patch file. Of course I should actually post a completely new patch, found/fixed a couple bugs later in the day and ended up finding/fixing a bunch of other issues when I did a cleanup pass. Just a list of the changes I have locally now (perhaps too much for integrating to trunk at this point, lots of small and large changes here and there):

Yeah, pixel lighting origin was visible, but I didn't think of a patch for it, but as it's just a single file you can just add that main.cpp completely in an extra file as example so we can test it without having to write our own first (yeah, I'm lazy).

1. Moved all shared code for the emitters into a new CParticleEmitter.h file. Not sure if you folks will like this as it uses a template injection so all the concrete classes can share the code. I could have done this a couple different ways but the pattern in question is the lowest maintenance variation, there is probably 90% less code in the remaining files now. Most of the emitters are now not much more than a constructor, overridden "where" to emit new particles and serialization of their custom parameters. All the core routines/update etc is moved to the shared code.

Template injection is certainly an idea, the part that makes me worry there a little is that it's very different from the usual Irrlicht style which works throughout with interfaces (except in core-classes, but those are an own topic). Also if it's put in a CParticleEmitter the common part is not useable for users trying to do own emitters and supporting custom emitters from users should be the long-term target (yes template injection could be made visible to users, but that would introduce a complete new style in the API which might be the preferred style when starting a lib from scratch these days, but having it mixed is probably not a good idea). Then again I haven't had a good idea yet how to fix that stuff, it's obvious from the code that one more layer is necessary (a parameter class might be another possibility).

2. Fixed a couple bugs in serialization I found when making sure all the emitters shared the common code. Cylinder for instance was writing "Distance" out as the "Center" attribute I think was one of them. I was going to go ahead and add in serialization for mesh and animated mesh emitters but couldn't find a good reference about how to serialize the node pointers in those two items.

Ok, have to look that up. Preferably keep patches independent, as for example a single-line serialization patch can be added without much review. And yes - you run into the reason why mesh and animated mesh emitters don't have serialization. Our serialization system has no common style so far for creating objects - so it's using workarounds there all over the place and in many places things are not serialized for exactly that reason. Basically we have 2-3 directions to go there... adding more factories - replacing factories by a common factory system for all serializable objects - or maybe even continuing with creating types in the attribute-system itself (the way textures are created). But also an own thread, for emitters it just means that it's currently hard to fix without thinking about reworking serialization first.

3. Reworked the emission direction vector randomization. I noticed in many cases that the randomization only worked in one quadrant around the direction vector which made it nearly useless for my purposes (seemed like a bug at least). At the same time I wanted to add in a MinAngle ability so you can build a point emitter with direction set to yaxis, set min to 85 and max to 95 and it will spit particles out to the sides but none up or down. I did not add this to the constructors though as that would have changed the interfaces too much.

Great, but another candidate for an own patch.

4. Added an option to the gravity affector to use "real" gravity. The version doing interpolation looks too funky for my tastes, it is an option and defaults to using the interpolation method so no changes to anyone expecting the current behavior.

Hm, yeah - someone mentioned that before (http://irrlicht.sourceforge.net/forum/v ... 09#p260109), but didn't make it optional.

5. Moved the rotation about arbitrary axis code (the big equation in the rotation bit) into the vector class and fixed a goof in it when I translated it from my right handed math library to the left handed Irrlicht version.

Again great - but preferably an own patch.

I think the only two things I care to do from here on out with the existing code is perhaps adding a noise affector to give particles a random drift and the other thing would be related to the gravity change, basically because true physics are unstable with variable frame rates, I'll add an option to the update loop to do a max step update. I.e. if the delta time is more than 10 ms, run the movement/affectors in multiple steps as an option.

Anyway, that will have to be in a couple hours. Late here and have errands to run in the morning.

Thanks for all the work.

[All8Up]

So, I posted up a full patch with the new stuff and the example. You can take a look and we can discuss how to proceed. Some of the points though:

Template injection is certainly an idea, the part that makes me worry there a little is that it's very different from the usual Irrlicht style which works throughout with interfaces (except in core-classes, but those are an own topic). Also if it's put in a CParticleEmitter the common part is not useable for users trying to do own emitters and supporting custom emitters from users should be the long-term target (yes template injection could be made visible to users, but that would introduce a complete new style in the API which might be the preferred style when starting a lib from scratch these days, but having it mixed is probably not a good idea). Then again I haven't had a good idea yet how to fix that stuff, it's obvious from the code that one more layer is necessary (a parameter class might be another possibility).

For the users, this changes nothing, they simply don't have access to the shared code but they can still write new emitters the same as always.

Great, but another candidate for an own patch.

Most of this is interrelated due to the dependence on the particle rotation code. I could break it out into 2 or 3 patches but at the end of the day they are all required together at this point. I'll look into how I could present this as a series of smaller patches at worst and how much can be isolated if possible.

I've posted up the full patch which includes the modified example code. Take a look and we can see how to move forward. But, as you should see the upgrades are pretty notable in how upgrading the simple bits can make a big difference.

[All8Up]

Just as a note, I went ahead and fraps'd the simple example to show some of the changes in action.
http://www.youtube.com/watch?v=c_isjelj ... e=youtu.be

Have fun.

[CuteAlien]

For the users, this changes nothing, they simply don't have access to the shared code but they can still write new emitters the same as always.

Yes, I realize that. But the reason I didn't just put it into a common class when I found about the current class layout is that I wanted to find a solution which is also useable by users. But maybe it's better at least having it nicer in the engine than keeping on current style and waiting for a perfect solution. Haven't found time yet to look at the patch now, so I must admit I don't know yet why you need template injection (instead of just a struct with all common parameters for example).

Great, but another candidate for an own patch.

Most of this is interrelated due to the dependence on the particle rotation code. I could break it out into 2 or 3 patches but at the end of the day they are all required together at this point. I'll look into how I could present this as a series of smaller patches at worst and how much can be isolated if possible.

I've posted up the full patch which includes the modified example code. Take a look and we can see how to move forward. But, as you should see the upgrades are pretty notable in how upgrading the simple bits can make a big difference.

Yeah - it's just that applying a the whole patch may take a while (until someone finds time to review it), while it's just easier to add small patches, which can be done in an evening or so.

[All8Up]

For the users, this changes nothing, they simply don't have access to the shared code but they can still write new emitters the same as always.

Yes, I realize that. But the reason I didn't just put it into a common class when I found about the current class layout is that I wanted to find a solution which is also useable by users. But maybe it's better at least having it nicer in the engine than keeping on current style and waiting for a perfect solution. Haven't found time yet to look at the patch now, so I must admit I don't know yet why you need template injection (instead of just a struct with all common parameters for example).

I started with the struct of common functionality actually, the injection just makes things much less error prone. Once everything is looking correct I could go back to that solution at the cost of the easier maintenance. I'm not picky about this, it is still a major step up from the duplicated code of the original. Of course I'm still trying to figure out exactly how this all fits together in the intended installed library format. I.e. is the problem that when installed on a Linux box the C prefixed files are not part of the install? I haven't booted up my Linux box in ages and the OsX build wasn't working (Lion OpenGl header issues) so I haven't really checked it out on other platforms. Worst case it seems that it could be provided like irrArray as a helper header as part of the install.

Great, but another candidate for an own patch.

Most of this is interrelated due to the dependence on the particle rotation code. I could break it out into 2 or 3 patches but at the end of the day they are all required together at this point. I'll look into how I could present this as a series of smaller patches at worst and how much can be isolated if possible.

I've posted up the full patch which includes the modified example code. Take a look and we can see how to move forward. But, as you should see the upgrades are pretty notable in how upgrading the simple bits can make a big difference.

Yeah - it's just that applying a the whole patch may take a while (until someone finds time to review it), while it's just easier to add small patches, which can be done in an evening or so.

Well, I'm in no hurry. I just had a knee operation so I'm kicking back and just putzing around on my laptops.

[All8Up]

Another example video showing the new Direction distribution ability. Basically this is a sphere emitter with the min=85 and max=95 so the particles are mostly shot out randomly around the sides of the animating direction vector.
http://www.youtube.com/watch?v=oflUCuR- ... e=youtu.be

Just a fun variation I used for testing. I won't post any more video's unless I do anything more interesting, just figured seeing it in motion makes any particle system example more useful.