Yellow-Dog-Man / Resonite-Issues

Issue repository for Resonite.
https://resonite.com
135 stars 2 forks source link

Add a burst at point particle emitter. #2940

Open BaxterOttoman opened 3 weeks ago

BaxterOttoman commented 3 weeks ago

Is your feature request related to a problem? Please describe.

Resonite has an event system that a handful of components I can think of off hand use. For instance, the random event generator and the random sound player. With the new footstep events, it feels like this list is expanding and I'd like to suggest that we'd benefit from a system that creates particle bursts when an event is called at the point specified. Like the audio clip player, but for particles.

Describe the solution you'd like

The component would go on a slot and be given a particle system as the usual particle emitters would be, but you would only have options for bursts. it would have some kind of emit at point method exposed for passing a float3 to, like the random audio clip player, that could be dropped into a random event genterator, character locomotion events, or the footstep system, or called directly with the method proxy Protoflux node. I figure it would make the most sense to have the float3 input handled the same as the audio clip player version.

Describe alternatives you've considered

I've done this in the past by duplicating an inactive slot with a particle emitter, setting it's transform, then setting it to delete itself, but this causes a lot of objects to be created and disposed of that don't need to be.

Additional Context

No response

Requesters

Baxter

Frooxius commented 3 weeks ago

I don't understand why do we need a separate emitter for this? You can already use PointEmitter for what you describe, which supports burst on activation. If you don't want the constant emission from it, just set it to 0 - I don't see a reason to have a version that doesn't have the rate emission at all - you can simply just not use that function.

Is there something I'm missing here?

BaxterOttoman commented 3 weeks ago

image The difference would be down to there being a method exposed on the component. RandomAudioClipPlayer Has it's PlayAtPoint(float3 method that can be put into event generators to trigger a clip playing at that point when the method is called. This would be analogous to that, but for particles. The specific difference is how it integrates into the whole events system.

That said, it doesn't specifically need to be a new emitter. It might be better as some added functionality to the point emitter that already exists, and I'd be plenty happy if it was done that way.

Frooxius commented 3 weeks ago

I see. What you're asking for sounds like this issue: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2710

BaxterOttoman commented 3 weeks ago

That is a similar issue. Would it be more in line with the design philosophy of Resonite to ask for something like the RandomAudioClipPlayer that creates one shot bursts that are point emitters like how that component creates one shot audio slots that handle playing the audio and deleting themselves?

shiftyscales commented 3 weeks ago

Wouldn't that effectively just be #2710 in component form, @BaxterOttoman? Based on the description of the linked issue, using that you could do whatever you wanted with them. E.g. place them, move them, delete them, etc.

BaxterOttoman commented 3 weeks ago

Sort of, but from the last update in there from Froox, he said it was something he wouldn't add, so I'm trying to figure out a form this could take that would work with the design philosophy of Resonite.

Frooxius commented 3 weeks ago

I'd strongly suggest instead focusing on what your use-case for this is.

Figuring out ways to do things within design philosophy of Resonite is what our job is - and when people try to do it for us, it makes things more difficult on both ends.

What helps the most is formulating the use case and the end goal of what you're trying to do.

5H4D0W-X commented 3 weeks ago

From what Baxter mentioned in the original post and what I can think of, example use cases could include footstep particles (for water splashes, dust or static foot print visuals), impact particles for weapons, and other things where particles are seemingly generated by another world item and not the item that the emitter sits on

BaxterOttoman commented 2 weeks ago

Yeah, like what Shadow said, something that takes a float3 and creates a particle burst at a point. I suggested it as an emitter component, because those already take an existing particle system and use them, but if it was something else, that'd be fine too. I just think if it had an exposed method on the component that takes a float3, like the RandomAudioClipPlayer has, and does a burst of particles at the same point the other component would play a sound from, that'd be handy because it would make it so you can use them both in the same ways.

BlueCyro commented 2 weeks ago

The biggest advantage of having a delegate is precise control over when the particle is emitted and from where (potentially with a few settings like the positional/angular velocity, size and lifetime as inputs)

Right now if you want to emit a particle from somewhere reliably, you have to set up a point emitter on a slot, duplicate that slot, set it to a position you want, then enable the particle emitter and delete the slot after a few frames so that the particle has a chance to emit.

With a way to trigger emissions programmatically, we can avoid unnecessary slot creations and reduce the complexity and overhead of more complicated particle emissions patterns. This would also give us the ability to emit multiple particles from N number of unique inputs simultaneously within a single update at exactly the positions desired by the user - something that is currently impossible right now without a lot of slot management and no control over other settings like the size, lifetime, and positional/angular velocity of each emitted particle.

This would make it easier to create detailed emissions patterns such as being able to emit an entire, user-defined emission pattern at once without needing to have slot creations out the wazoo.

This is distinctly different from my other issue cited in this thread, because in my other issue I was essentially asking for parametric particle systems, which is not what's being asked for here. I think the request being discussed here would be very useful still, as it's often something I wish I could do without needing to make a whole setup with slot management to accomplish.

TL;DR: Our particle system emitters right now are great for continuous emissions, but are annoying to use for more programmatic ones.

shiftyscales commented 2 weeks ago

A fair amount of conversation and discussion has been had since the "needs more information" label was applied. Seeking input / re-evaluation from @Frooxius on what should be done with this issue since additional context has been provided.

Frooxius commented 2 weeks ago

I think this issue is very similar to https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2710 and a lot of the points raised here are ones that I already discussed in the other one, so I don't want to have same conversation in two different issues.

There are mechanisms that are planned to be added to the particle system that would cover the use-case of needing to have programmatic control over bursts. The simplest way to achieve that right now is make a emitter template that bursts on activation and spawn that.