Implement a fully custom particle system simulation - PhotonDust

Frooxius commented 1 year ago

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

At the moment, the particle system used in Resonite is a hybrid of Unity's system with some custom code for handling emissions and collisions.

This presents a problem, where we don't have full control over the particle system stack and makes a dependency on Unity's system, which needs to be resolved before we can move to a custom engine.

Describe the solution you'd like

Move all parts of the particle system into a fully custom system - emission, simulation, collision, forcefields, generation of mesh data and so on, into fully custom system.

This will give us full control over the system, making it easier to extend, add new features and evolve it based on our needs, as well as easily move to a custom rendering engine in the future.

One particular feature that I'd like to implement is also asynchronous simulation - the system will not block the whole rendering pipeline when simulating large number of particles - it will simply simulate particles at lower frame rate than the world runs at, which is more desirable, particularly in VR.

It will also allow the particle system to be used and simulated separately for various effects - e.g. baked simulations and so on.

Describe alternatives you've considered

There aren't too many viable alternatives if we want to move away from Unity.

Additional Context

No response

JackTheFoxOtter commented 1 year ago

On that note, an interesting thing to consider might be GPU acceleration for particle systems. That's how Godot implemented their 3D particle systems.

Frooxius commented 2 months ago

I've recently started the design process on this system as the next step for the performance optimizations. The overall plan right now is to introduce this as a new set of particle system component, which means it'll be usable by increments as it's getting implemented in parallel to the existing particle system.

The goal for the system is to be a lot more modular and extensible, with a lot more functionality than the current system has. However first part will try to mainly achieve feature parity with this new system.

Once the feature parity if achieved, the old instances will be auto-converted into the new system and the old system will be fully removed.

I'll share the design notes in #devlog as this goes.

TisFoolish commented 2 weeks ago

Will there be a period of time, even a short one, where people can selectively convert the unity particle system to Dust? EG Grabbing the component and opening your context menu to get an option to convert. (I don't really care how it's done, this is just an example)

It'd make comparisons easy, and thus bug reports could be more detailed and have direct side by side comparisons

Frooxius commented 2 weeks ago

Yes. During testing period, both system will exist alongside each other, with a toggle to trigger the conversion. This will allow to test on the public builds and fixup any issues.

Once we're confident the conversion and new system is working okay, we'll remove the old one and make conversion automatic.

TisFoolish commented 2 weeks ago

Will the testing period be in the prerelease branch or on main? Main would allow for a much larger number of testers, but your speed of updates might be reduced.

Frooxius commented 2 weeks ago

It'll be on the main. It's what I meant by "public builds" in my previous post.

Frooxius commented 4 days ago

I've got good news! PhotonDust should now have a full feature parity with the legacy particle system and the main thing left to write is the conversion from the legacy to new. With this, we'll start testing very soon, possibly this Wednesday (November 27th).

My plan is following:

Phase 1: Publish PhotonDust to prerelease branch first and do initial smoke testing - not focusing on compatibility, but checking if it's easy to blow sessions up with any of its bugs
Phase 2: Once I'm confident enough that the system is stable, we'll move to phase 2 - PhotonDust will be released to public branch alongside the legacy particle system. Conversion will be triggered optionally by a setting. In this phase, we'll focus on making sure everything converts right and that we have good feature parity
Phase 3: Once PhotonDust is able to work with the legacy content well enough and we have sufficient feature parity, the legacy particle system will be removed and conversion will become automatic.

I'll post a testing Discussion once I have things ready, but this is currently the game plan.

Banane9 commented 3 days ago

Correct me if I'm wrong, but in the video it looks like the skinned mesh emitter is based on the vertex density of the mesh, i.e. where there's more vertices, there's more particles. Would it be at all possible to allow this to be surface area or volume based as well? That would greatly improve the effect for many applications, imo. For example in the video, it's kinda distracting from the effect, that the particles are much denser around the head and hands than the body when moving, imo.

TisFoolish commented 3 days ago

Doing it based on surface area or volume would be a significantly more expensive operation. And it's not something you could 'bake' to make it faster either because both of those properties change as the bones move.

badhaloninja commented 3 days ago

Doing it based on surface area or volume would be a significantly more expensive operation. And it's not something you could 'bake' to make it faster either because both of those properties change as the bones move.

I'm pretty sure they are more concerned about the spacing of the particles instead of performance here

On an avatar, usually the face or hands would have more vertices than say the forearm which would cause inconsistent particle densities across the mesh, taking into account surface area would make this more evenly spread out

However the current particle system does let you do this with the EmitFrom field on both the MeshEmitter and the SkinnedMeshEmitter Looking at the component in the skinned mesh emitter video, this field also exists in the new particle system

It does not however support volume based mesh emission currently

Banane9 commented 3 days ago

However the current particle system does let you do this with the EmitFrom field on both the MeshEmitter and the SkinnedMeshEmitter Looking at the component in the skinned mesh emitter video, this field also exists in the new particle system

It supports Vertices, Lines, and Faces as the emission options, but all of them suffer from inconsistent density.

badhaloninja commented 3 days ago

However the current particle system does let you do this with the EmitFrom field on both the MeshEmitter and the SkinnedMeshEmitter Looking at the component in the skinned mesh emitter video, this field also exists in the new particle system

It supports Vertices, Lines, and Faces as the emission options, but all of them suffer from inconsistent density.

Oh, I opened resonite to test it with face emissions before writing that and it seemed pretty even, maybe I just got a lucky initial draw

Banane9 commented 3 days ago

Oh, I opened resonite to test it with face emissions before writing that and it seemed pretty even, maybe I just got a lucky initial draw

Iirc it picks a random face to spawn a particle on, so they also get weighted implicitly towards denser areas.

Frooxius commented 3 days ago

Let's keep this on topic please. This is not really relevant at the moment, since the goal here is feature parity and the testing has not even started yet.

Banane9 commented 3 days ago

Sure, it's just this seems like a prime opportunity to request this, since you're just working on it now. Rather than having to get into it again at some other point. Of course I don't expect it to be part of the initial testing.

Frooxius commented 3 days ago

Any new feature requests should be their own issue - we do ask not to hijack existing issues for those requests.

shiftyscales commented 3 days ago

Sure, it's just this seems like a prime opportunity to request this, since you're just working on it now.

As Frooxius highlights, it is in our reporting requirements (basically guidelines for use of our GitHub) to not hijack existing issues for additional feature requests. Please respect that and keep issues on-topic, @Banane9.

Do not hijack issues for another feature/bug, Make another issue instead.

Issues should never have comments similar to "While you're at it, can you also do this?", it will not be considered and will get lost.

Banane9 commented 3 days ago

As Frooxius highlights, it is in our reporting requirements (basically guidelines for use of our GitHub) to not hijack existing issues for additional feature requests. Please respect that and keep issues on-topic, @Banane9.

Do not hijack issues for another feature/bug, Make another issue instead.

Issues should never have comments similar to "While you're at it, can you also do this?", it will not be considered and will get lost.

I'd appreciate it, if you (general) did not put words into my mouth. I specifically asked if it was something that was possible, to determine if it was even worth making an issue for, without it immediately being closed down as "not possible".

Frooxius commented 3 days ago

Please stop.

You've been given a way to request this - make a separate issue - if you want us to evaluate this do that and we'll look at it when we can.

I'm stressed, overworked and trying to get this thing ready for testing while dealing with a bunch of other things. What you're doing right now is adding to this unnecessarily.

Yellow-Dog-Man / Resonite-Issues