This is coming along quite nicely… keep in mind, the emitter is only running 3 influencers:
Gravity
Color
Size
So, the overall look is pretty uniform. However… Mesh-based particle emitter shapes are FREAKING AWESOME!
11 Likes
Also wanted to mention…
With this emitter, you will be able to generate all particles with no life cycle… soooo… this means:
You can use it to generate:
Grass
Leaves
Fur
Etc, etc, etc…
Yeah… I’m excited =)
3 Likes
Nicely done! =)
1 Like
I need some assistance… but before the questions,
I added a rotation influencer and allowed for min/max initial force range…
[video]http://youtu.be/qL5BK34koKs[/video]
Now… @smartpeople like @pspeed @nehon @normen
I don’t think my idea for setting per particle data is such a good one, as setting/getting per update loop can get expensive (considering the emitter in the vid has 18000 particles). Can any of you think of a potential way of allowing for per particle data that may be faster than a hashmap? I wish I were teh smarter at teh Java… but… well… you already know =)
2 Likes
What would be cool is rotational influencers that spun the position rotationally, so you could do whirlwind/firestorm/etc type effects.
1 Like
@zarch said: What would be cool is rotational influencers that spun the position rotationally, so you could do whirlwind/firestorm/etc type effects.
This will be part of the billboard influencer.
1 Like
Ugh… another question:
This is a method of the ParticleMesh class… and aside from some very minor tweaks, this shouldn’t change at all (when I say tweaks… I mean having the mesh update it’s own bounds instead of the emitter trying to calculate them for no reason).
I am having trouble trying to figure out what this method is doing:
[java]
public void setImagesXY(int imagesX, int imagesY) {
this.imagesX = imagesX;
this.imagesY = imagesY;
if (imagesX != 1 || imagesY != 1){
uniqueTexCoords = true;
getBuffer(VertexBuffer.Type.TexCoord).setUsage(Usage.Stream);
}
}
[/java]
Why 1??!
Are the frame indexes 0 based or 1 based?
And does anyone have a clue what direction this is currently reading frames from/to? Is it bottom right to top left? or bottom left to top right? or?
And what happens when you cycle through images and hit 1 again, does the Usage need to be changed to something else?
Ah hell… is the Usage call even necessary??
Thanks in advance!
1 Like
@t0neg0d said: Ugh... another question:This is a method of the ParticleMesh class… and aside from some very minor tweaks, this shouldn’t change at all (when I say tweaks… I mean having the mesh update it’s own bounds instead of the emitter trying to calculate them for no reason).
I am having trouble trying to figure out what this method is doing:
[java]
public void setImagesXY(int imagesX, int imagesY) {
this.imagesX = imagesX;
this.imagesY = imagesY;
if (imagesX != 1 || imagesY != 1){
uniqueTexCoords = true;
getBuffer(VertexBuffer.Type.TexCoord).setUsage(Usage.Stream);
}
}
[/java]Why 1??!
Are the frame indexes 0 based or 1 based?
And does anyone have a clue what direction this is currently reading frames from/to? Is it bottom right to top left? or bottom left to top right? or?
And what happens when you cycle through images and hit 1 again, does the Usage need to be changed to something else?
Ah hell… is the Usage call even necessary??Thanks in advance!
A guess:
Since the sprite assigned to particles can be part of an atlas then this is saying how high or wide the atlas is so that the images can be randomly assigned. So if imagesX is 1 then there is only a single column of images. If imagesY is 1 then there is a single row. If both are 1 then there is only 1 image.
…thus the uniqueTexCoords flag denoting that when either is not 1 then there is more than one image.
1 Like
@pspeed said: A guess: Since the sprite assigned to particles can be part of an atlas then this is saying how high or wide the atlas is so that the images can be randomly assigned. So if imagesX is 1 then there is only a single column of images. If imagesY is 1 then there is a single row. If both are 1 then there is only 1 image.…thus the uniqueTexCoords flag denoting that when either is not 1 then there is more than one image.
Thanks! You dead on accurate. For some reason I was confusing this with the current index… think I need a break =)
1 Like
Here is my initial take at the impulse influencer.
It has three setting: Strength, Magnitude and Chance. It attempts to effect the velocity throughout the life cycle of the particle.
2 Likes
Hi…
I just became AWESOME!!! And my husband saw it happen!
Not only can you set the emitter shape to a 3D mesh… it now sync’s up with the animation
Here is shit… Here is you checking shit out O.o
3 Likes
Some random unfiltered thoughts
- Some of the massive particle systems in commercial high end engines uses shaders and compute shaders to generate the particles on the GPU. Maybe there are somethings we can offload to the GPU?
- One cool feature, which is probably better of as a plugin/addon once the emitter is production ready, is to “bake” the particle system into a sprite sheet.
- Custom paritcle meshes, if I want my emitter to emit small elephant meshes I want be able to to that.
- It would be even cooler if one could emit emitters (think fireworks).
3 Likes
Some basics can be moved to GPU (billboarding to screen etc, which comes for free with point particles for example) - but if you move all other computations, it won’t be easy to produce pluggable influencers. I think that CPU based particles are good enough for general usage (and a lot easier to extend). If somebody creates particle-bound game, he will probably need very tailored shader anyway.
I think that next big step for particle system is physics, rather than moving to GPU. Bouncing off collision meshes, rolling around the ground and possibly more complicated scenarios which are solved in physics systems themselves (does bullet has anything like http://physxinfo.com/wiki/APEX_Particles ?).
1 Like
One more quick vid before I’m bed bound.
PreferredDirection + Gravity + Impulse makes for a pretty nice looking fountain effect.
2 Likes
Tomorrow I plan to get the preferred destination influencer done first. This should work nice for fires, jet engine effects… anything that tappers, etc.
1 Like
@t0neg0d said: I don't think my idea for setting per particle data is such a good one, as setting/getting per update loop can get expensive (considering the emitter in the vid has 18000 particles). Can any of you think of a potential way of allowing for per particle data that may be faster than a hashmap? I wish I were teh smarter at teh Java... but... well... you already know =)What do you mean by particle data? usually you use the vertex buffer of the mesh, what data do you want to store?
1 Like
@nehon said: What do you mean by particle data? usually you use the vertex buffer of the mesh, what data do you want to store?
Apparently I had some test code that was making things a little funky. The data is basically a mechanism for custom influencers to store data that is specific to them, per particle, since the influencer is passed the particle, it has to store/retrieve data with the particle itself. Most influencers won’t need to do this, but… here is the idea:
the update loop is called on an influencer and passed a particle,
The influencer calls particle.getData(“someKey”); to retrieve the previous passes data.
It updates the data and then stores the it back in the particle using particle.setData("someKey, someObjct);
Originally I thought this was causing a major performance hit. As it turns out, it was something completely unrelated that I had been messing around without prior to getting called away for a bit… and… I forgot about it (embarrassing).
1 Like
You mean you use the userData?
Your particles are geometries?
1 Like
@nehon said: You mean you use the userData? Your particles are geometries?
No, no… I slightly modified the Particle class is all.
ParticleMesh and Particle are still almost identical to the original classes. I have a couple additions to Particle (like the data hasmap and I modified The Tri and Point Mesh classes to call updateBound(). After each update loop updateModelBounds is called on the single geometry. These changes were to get rid of all the TempVar usage for calculating the model bounds which wasn’t necessary anymore.
I’m assuming that the ParticleMesh classes were written prior to the bounds updating for Mesh/Geometry.
EDIT: These updates replaced about 80 lines of code with 2.
1 Like
@t0neg0d said: These changes were to get rid of all the TempVar usage for calculating the model bounds which wasn't necessary anymore.Ok but make sure you don't allocate new vars on each frame. Also try to not use attribute temp vars as much as possible.
1 Like