Help Parenting Emitters Question

[sothorael]

I've had some trouble with other products and parenting emitters to a character (or spawning them on death) to create blood pools. Other products seem to 'refuse' gravity when parented, and the particles fly off into the distance rather than flow downwards. The example videos look awesome and I'm tempted to spend the money, but I'm wondering if the emitters can be easily parented to a ragdoll/rigidbody and moved without losing the ability for gravity to work (think continual leaking if moved). I tried looking through the forum and the videos, but haven't seen anything specific to this that would tell me for sure before spending

[josemendez]

I've had some trouble with other products and parenting emitters to a character (or spawning them on death) to create blood pools. Other products seem to 'refuse' gravity when parented, and the particles fly off into the distance rather than flow downwards.

There's no reason for gravity not to work when parenting an emitter in any engine, unless you're performing simulation in the emitter's local space. Even then, it's trivial to convert a world space gravity vector to the emitter's local space (just use Unity's InverseTransformVector). Tried this will Unity's built-in particle system, works just fine.

The example videos look awesome and I'm tempted to spend the money, but I'm wondering if the emitters can be easily parented to a ragdoll/rigidbody and moved without losing the ability for gravity to work (think continual leaking if moved). I tried looking through the forum and the videos, but haven't seen anything specific to this that would tell me for sure before spending

Obi makes a distinction between the solver (the component that performs the simulation) and the emitter (the component that creates particles). See: http://obi.virtualmethodstudio.com/manua...cture.html

Simulation is always performed in the solver's local space:
http://obi.virtualmethodstudio.com/manua...olver.html

So if you rotate the solver, gravities will rotate with it. You can use two approaches:
- Place the solver outside of the character, in a transform that does not move/rotate with it. Then place the emitter anywhere in the character's hierarchy.
- Place the solver at the character's root, then convert gravity from world to local space.

Either way it's completely doable. Keep in mind that Obi assumes you're comfortable with C# scripting and familiar with basic physics/3D concepts (vector spaces, forces/impulses/accelerations, inertial reference frames, etc). Let me know if you need any help with it.

kind regards,

[sothorael]

Thank you so much! I'll do a bit of research on the code part of doing what you said and working with physics specifically, but it sounds like Obi Fluid will be perfect!

---

I was just thinking of what is probably a newB question - if the solver is separately placed outside the character (say an invisible box in the scene) and the emitter is spawned by script, how would the solver know it? Or would the emitter/s need to exist in the character already at runtime? I have a feeling I'll be prodding you a lot after pay-day

[josemendez]

I was just thinking of what is probably a newB question - if the solver is separately placed outside the character (say an invisible box in the scene) and the emitter is spawned by script, how would the solver know it? Or would the emitter/s need to exist in the character already at runtime?

The solver will update all actors -emitters- that are underneath it in the hierarchy. So as soon as you parent an emitter under a solver (at any hierarchy level, no need for it to be an immediate child) the solver will start updating it. You don't need to explicitly tell the solver which emitters to update.

Internally, the way this works is that the emitter calls GetComponentInParent<ObiSolver>() in OnTransformParentChanged(). This way, every time the emitter is re-parented, it looks for the first solver it can find above it and registers itself on that solver (and unregisters from any previous solver)

No need for the emitter/solver to exist in-editor, they can be both created at runtime.

From the manual:
http://obi.virtualmethodstudio.com/manua...olver.html

Every actor needs to have a solver up its hierarchy in order to get updated and rendered.