@abies
Talk to me about particle stretch along velocity! How does this work in general? How does this work with different billboarding options?
1 Like
Regarding particle stretch - I’m just talking about NWN implementation, as this is what I’m emulating. They call it ‘motion blur’ and it is instead of normal billboard/align mode. In reality, it is just aligned to velocity with extra difference of making y size dependent on speed. One thing which I had to add is to limit the size by particle life - in other case, fast particles were starting too long already. I have arbitrarly decided to have it at half second - below that, I scale y-size resulting from speed proportionally.
What is not nice in this implementation is that particle grows in both directions equally. In ideal case, forward point should move with proper speed and end of particle should trail accordingly.
I think that in your case, it should be simple trick of getting it aligned to velocity and modifying y-size depending on some function of speed - should be trivial with influencers.
2 Likes
Working on a Particle Mesh type that takes a template mesh (loaded asset) and uses it as the template for the particle. I didn’t realize when I started that you would be able to animate the particles. Here is a quick test (still needs a bit of work, but wanted to share the results). This basically automates the process of creating new ParticleDataMesh types.
1 Like
Oddly enough, you can use the output mesh of one emitter as the emitter shape of another emitter, so you can emit particles from particles.
2 Likes
@t0neg0d said: Oddly enough, you can use the output mesh of one emitter as the emitter shape of another emitter, so you can emit particles from particles.
1 Like
Just wanna say, keep up your awesome work!
1 Like
@pspeed: I don’t see an image but I know whats supposed to be there 
@t0neg0d: This really looks nice, for this stuff your ‘direct’ API approach really fits well, the next level below that is manipulating the meshes and material yourself anyway. So yeah, keep it up, we need better particles 
2 Likes
Sorry for the posts on this, however… I want to share progress as it goes in case it sparks someone imagination.
This is 1 hemisphere shaped emitter, kicking out hemisphere shaped particles.
The output mesh of this emitter is being used as a second emitter’s shape.
The second emitter is emitting quad shaped particles from these.
The blue wireframes are test meshes for tracking particles or emitter shapes
The final output into your scene could consist of either 2 meshes (one for each emitter output) or just the final emitter particle mesh, as the particles do not need to reside in your scene to work as a shape for the second (third, fourth, etc) emitter.
3 Likes
@normen said: @pspeed: I don't see an image but I know whats supposed to be there ;) @t0neg0d: This really looks nice, for this stuff your 'direct' API approach really fits well, the next level below that is manipulating the meshes and material yourself anyway. So yeah, keep it up, we need better particles :)
Aww… it was there before. 
I should have known better and imgur’ed it.
1 Like
@pspeed
Basic java generics related question.
I’m removing the ParticleType enum and setting up a method to initialize the particle mesh by passing in the class. Here are the types available:
Point,
Quad,
Impostor
Template
The template requires a mesh (loaded asset) that it can extract the buffers from to define what a particle is. All of them require knowing the maximum particle capacity for the emitter.
My question is this… If I set up a method using T extends ParticleDataMesh, how can I call the constructor for the class being passed in without having to use some type of if statement?
If worst comes to worse, I guess this is ok… as the template mesh is a catch all… but, I’d still like to see how this is done properly.
1 Like
@t0neg0d said: @pspeed Basic java generics related question.I’m removing the ParticleType enum and setting up a method to initialize the particle mesh by passing in the class. Here are the types available:
Point,
Quad,
Impostor
TemplateThe template requires a mesh (loaded asset) that it can extract the buffers from to define what a particle is. All of them require knowing the maximum particle capacity for the emitter.
My question is this… If I set up a method using T extends ParticleDataMesh, how can I call the constructor for the class being passed in without having to use some type of if statement?
If worst comes to worse, I guess this is ok… as the template mesh is a catch all… but, I’d still like to see how this is done properly.
I’m especially dense today… can you post some pseudo code of what you mean?
1 Like
Using generics you cannot pass in a Type T and have the method do a new T() - you just can’t do it. I’ve never actually needed to though.
What are you trying to achieve?
1 Like
@zarch said: Using generics you cannot pass in a Type T and have the method do a new T() - you just can't do it. I've never actually needed to though.What are you trying to achieve?
It sounded like she was going to be passing Class in. That’s why I asked for pseudo code.
1 Like
Sorry for the delay… and thanks for looking at this.
Pseudo code… hmmm… something like:
[java]
public <T extends ParticleDataMesh> void initParticles(Class<T> t, Mesh template) {
this.mesh = new t();
if (template != null) {
this.mesh.extractBuffers(template);
}
}
[/java]
1 Like
Heh… I think my pseudo code was my answer 
1 Like
@t0neg0d said: Sorry for the delay... and thanks for looking at this.Pseudo code… hmmm… something like:
[java]
public <T extends ParticleDataMesh> void initParticles(Class<T> t, Mesh template) {
this.mesh = new t();
if (template != null) {
this.mesh.extractBuffers(template);
}
}
[/java]
this.mesh = t.newInstance();
…with appropriate exception handling.
2 Likes
This was very helpful. I was able to get rid of both the emitter shape and particle type enums, which were carry-over from the original emitter. This allows people to create new Particle mesh classes… oh… and actually use them
1 Like
@pspeed
So sorry to both, but I would like to take this same approach with the emitter shapes as well. As it stands right now, I’ve only created the single triangle emitter shape, but plan on putting together the IsoSphere/IsoHemispere shapes as well. Is there any downside to having these types of methods? I don’t want the emitter to limited by what it is now… and I don’t know of another way of allowing for this sort of thing.
1 Like
@t0neg0d said: @pspeed So sorry to both, but I would like to take this same approach with the emitter shapes as well. As it stands right now, I've only created the single triangle emitter shape, but plan on putting together the IsoSphere/IsoHemispere shapes as well. Is there any downside to having these types of methods? I don't want the emitter to limited by what it is now... and I don't know of another way of allowing for this sort of thing.
Well, many cases where one takes a Class argument and calls newInstance() might be better served by a factory interface.
1 Like