Happy to report that my assumptions (yeah, they were assumptions) about the emitter working in the GUI node were correct! It looks really good. Tthe emitter is a hemisphere, y-axis as up, flattened by the gui viewport perspective obviously. There are three things that need to be adjusted to make it work:
You want to swap out the queue bucket of the emitter node to Gui
Scale is obviously by pixel… soooo adjust it up, up, up
You may have to adjust the billboard mode, depending on what you are looking for as a final effect.
@t0neg0d said:
I just need to document and I can do this.
I need to know a few things:
Do you want the influencers pre-loaded?
Do you want them all enabled by default? Or just gravity, color, size and rotation?
The entire emitter and related classes are complete rewrites. How should I prepare the source for you?
pre-loaded?
just the ones that makes your emitter behave mostly like the one in core
just name them differently as the ones in core…and maybe create a repo somewhere or just make a zip file of the sources.
I think we’ll have both systems for a time in core, just the time to evaluate, and to make sure it embeds correctly in the other systems. then we’ll deprecate the old system.
@t0neg0d said:
Same thing can be done for rotation and scale.
The problem with the second statement is… that would only work if the particles were individual meshes. No matter where you attach it, the particles are still going to move as a group unless you account for it via code. They are one mesh. Also, the source emitter shape only has to reside in the scene graph if it is animated, otherwise it is just handled as data.
The individual particles will still work the same though.
90% of use cases are going to be to have the particles moving in world space but spawning from wherever the source is. That’s fine, just attach the particle mesh to any stationary node and have the emit/influence etc from the source mapped to the meshes position.
There are other cases though, for example a torch burning inside a sealed moving vehicle would burn upwards. In that case you would attach the emitter mesh to the moving vehicle, and everything else still works as normal but the flame moves with the vehicle.
@t0neg0d said:
I just need to document and I can do this.
I need to know a few things:
Do you want the influencers pre-loaded?
Do you want them all enabled by default? Or just gravity, color, size and rotation?
The entire emitter and related classes are complete rewrites. How should I prepare the source for you?
My recommendation is still to not have any influencers preloaded. Put constructors for the influencers with their most common params and then a constructor for the particle emitter that takes a varargs number of influencers.
That gives full flexibility and full control while also being easy to use.
After all you don’t want a colour influencer running unless you actually are influencing colour.
@nehon said:
1. pre-loaded?
2. just the ones that makes your emitter behave mostly like the one in core
3. just name them differently as the ones in core...and maybe create a repo somewhere or just make a zip file of the sources.
I think we’ll have both systems for a time in core, just the time to evaluate, and to make sure it embeds correctly in the other systems. then we’ll deprecate the old system.
Added to the chain when a new emitter is created. Like @zarch said, it may be best to only preload the influencers that are critical and allow the others to be added manually (or preload none, seeing as static particles that follow an animated mesh, might use no influencers). Though, I think the list would have to include: Gravity, Color, Size, Rotation and Impulse to work as the current does.
The options are:
a) Preload nothing and provide a ParticleInfluencer… param in the constructor as well as add/remove methods
b) Preload some and set them to active as default
c) Preload all with some enabled, some disabled
d) Preload all with all active
And now for the list of things that will need to be updated:
Predefined emitter meshes are a must, otherwise the user is responsible for providing a mesh shape always. I think the choices should be:
a. Single triangle, normal unit y
b. A quad-grid of specified col/row count, normal unit y
c. A cube
d. An IsoSphere
e. An IsoHemisphere
I have not made these custom meshes yet, so… something to keep in mind (The user should be a able to specify one of these as the emitter shape to use in place of providing a mesh)
I haven’t had a chance to update how the ParticleMesh is updating the buffers. This will need to change as @nehon specified so it runs better on android. This should be an easy update.
Some other minor things that escape me atm. None of which will effect how the emitter is used.
Almost done with the docs… now I need to rename things to something unique… Hmmm. Suggestions? Hard to think of something as meaningful as ParticleMesh.
@t0neg0d said:
1. Added to the chain when a new emitter is created. Like @zarch said, it may be best to only preload the influencers that are critical and allow the others to be added manually (or preload none, seeing as static particles that follow an animated mesh, might use no influencers). Though, I think the list would have to include: Gravity, Color, Size, Rotation and Impulse to work as the current does.
The options are:
a) Preload nothing and provide a ParticleInfluencer… param in the constructor as well as add/remove methods
b) Preload some and set them to active as default
c) Preload all with some enabled, some disabled
d) Preload all with all active
Aside from choice d, all have there merits.
I’d go for a and b
One constructor with the ParticleInfluencer… param and one with no args that loads and activate the influencers that gives the Emitter the same behavior as the current ParticleEmitter
@nehon
One final concern and I’m gtg with getting this ready.
I have clone, read and write set up for all influenceers.
I have cloneForSpatial setup for the emitter itself.
I have NO CLUE what needs to be stored via read/write on the emitter itself. Since the emitter shape is a mesh and some sub components are cloned calling clone() on the instance of the sub-component, I just don’t know enough about the Input/OutputCapsule usage to write this properly.
yes actually you just have to write the arrayList where you store them.
there is an outputCapsule.writeSavableArrayList(list, “listName”, defaultValue);
@nehon said:
I'd go for a and b
One constructor with the ParticleInfluencer... param and one with no args that loads and activate the influencers that gives the Emitter the same behavior as the current ParticleEmitter
I agree, and I nearly suggested that…
However there is no way to determine the difference between
[java]
public void foo(int i, int j)
[/java]
and
[java]
public void foo(int i, int j, String… k)
[/java]
If you dont put in any varargs then it can’t tell the difference between the two. You can’t even just do one method and have it detect for the params being empty since you may want to have no influencers.
Given people will need to configure the influencers anyway i really don’t see the value in having “default” ones - since you will need to fetch the default one and modify the config then you might as well just specify it in the first place. There is no saving here.
What would be useful is to add some intelligence to the SDK so it knew about influencers - and when you constructed a new particle emitter you could ctrl space and fill in default influencers.
@zarch said:
What would be useful is to add some intelligence to the SDK so it knew about influencers - and when you constructed a new particle emitter you could ctrl space and fill in default influencers.
Or just have a static factory method on the class that would create a particle emitter with defaults.
Really, do not underestimate the utility of using factory methods instead of constructors where constructors would be ambiguous.
@zarch yes you’re right the constructor is ambiguous.
I just want to offer a no brainer replacement to the current system, for the ones that will be willing to migrate without too much trouble.
I’m really struggling with picking alternate names.
I could drop the word particle on many of the classes, so:
ParticleEmitter would become Emitter, etc, etc.
However, I’m not sure what to do with classes that are named for what they are (such as EmitterShape, ParticleMesh, ParticleTriMesh, ParticlePointMesh and Particle)
EmitterShape could become EmitterMesh as it is no longer a 2D shape
ParticleMesh ?? (this will encompasses the classes that implement the interface)
Particle ??
Particle was the one I was really struggling with… and after thinking about it, the Particle classes is not the visual particle, it’s the data that represents the Particle…
So:
Particle became ParticleData
ParticleMesh became PArticleDataMesh
etc, etc, etc
