Most of the updates revolve around point emitter and limiting the direction of the emissions. Like… random tangent, random normal aligned, random normal negate, etc. for creating shapes from a single point. Anyways, as you can see, you can produce some pretty cool stuff without much effort.
O.O…wouaw…amazing !!!
I really like the first and the fourth made me curious (i love it too). How many emitters did you used? What is the setup? They seem really pro.
Lightnings in fourth one are really nice. I suppose these are non-moving particles with animation going through texture frames of lightning?
Edit: http://xkcd.org/1313/
You may already have heard about regex golf. Maybe we could play particle golf? Somebody would publish the assets (textures and possible models) he used to create the particle effect and game would be to play with parameters/emitters/influencers to generate same effect. And we could do a repository of cool effects as well (but like shadertoy).
Of course, this would require Tonygod to release her particle code, which is entire reason why I came up with this idea
@haze said:
O.O...wouaw...amazing !!!
I really like the first and the fourth made me curious (i love it too). How many emitters did you used? What is the setup? They seem really pro.
The first is 4
– One for the spiral flames at the bottom
– One for the spirals upward
– One for the blue sparkles
– One for the random hot coals
The fourth is 4
– One for the flames that stretch outward
– One for the spiral glow
– One for the pulsing light in the background
– One for the lightning
Likely, I’ll use these as “How to’s” when I finally get this thing packaged up and released.
@abies said:
Lightnings in fourth one are really nice. I suppose these are non-moving particles with animation going through texture frames of lightning?
Edit: http://xkcd.org/1313/
You may already have heard about regex golf. Maybe we could play particle golf? Somebody would publish the assets (textures and possible models) he used to create the particle effect and game would be to play with parameters/emitters/influencers to generate same effect. And we could do a repository of cool effects as well (but like shadertoy).
Of course, this would require Tonygod to release her particle code, which is entire reason why I came up with this idea
I’ll release it soon(ish). It needs to be refactored and commented. I need to rewrite the clone methods, as much has changed. I also have an issue with the read/write methods, as I’m not sure how you read/write a SafeArrayList. Maybe @pspeed can answer this?
The first is 4
– One for the spiral flames at the bottom
– One for the spirals upward
– One for the blue sparkles
– One for the random hot coals
The fourth is 4
– One for the flames that stretch outward
– One for the spiral glow
– One for the pulsing light in the background
– One for the lightning
Likely, I’ll use these as “How to’s” when I finally get this thing packaged up and released.
I’ll release it soon(ish). It needs to be refactored and commented. I need to rewrite the clone methods, as much has changed. I also have an issue with the read/write methods, as I’m not sure how you read/write a SafeArrayList. Maybe @pspeed can answer this?
@t0neg0d said:
I thought I tried this and got an error. I'll give it another go, as I was sure that would do it.
I had some troubles by the past too with my own emitters…i’ve choose to use a map cause influencers are unique for an emitter so a Map<String, Influencer> (with classname influencer for the string key) is savable without any error (for now) with something like this :
[java]@Override
public void write(JmeExporter ex) throws IOException {
super.write(ex);
OutputCapsule oc = ex.getCapsule(this);
oc.writeStringSavableMap(influencers, “influencers”, new HashMap<String, Influencer>(0));
}
@Override
public void read(JmeImporter im) throws IOException {
super.read(im);
InputCapsule ic = im.getCapsule(this);
influencers = new ConcurrentHashMap<>((Map<String, Influencer>) ic.readStringSavableMap(“influencers”, new HashMap<String, Influencer>(0)));
}[/java]
@haze said:
I had some troubles by the past too with my own emitters...i've choose to use a map cause influencers are unique for an emitter so a Map<String, Influencer> (with classname influencer for the string key) is savable without any error (for now) with something like this :
[java]@Override
public void write(JmeExporter ex) throws IOException {
super.write(ex);
OutputCapsule oc = ex.getCapsule(this);
oc.writeStringSavableMap(influencers, “influencers”, new HashMap<String, Influencer>(0));
}
@Override
public void read(JmeImporter im) throws IOException {
super.read(im);
InputCapsule ic = im.getCapsule(this);
influencers = new ConcurrentHashMap<>((Map<String, Influencer>) ic.readStringSavableMap(“influencers”, new HashMap<String, Influencer>(0)));
}[/java]
I went this route as well, but I think the benefits of direct access to the semi-static backing array is worth the effort of getting this right. Haven’t had a chance to do anything today, but will soon and this is the first thing I’m going to work on.
Speaking of things that have changed, here is a quick sample of some of what the radial velocity influencer is capable of:
