PopcornFX v2.11

Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
  1. Home
  2. Docs
  3. PopcornFX v2.11
  4. Concepts
  5. Transforms
  6. Pitfalls

Pitfalls

There are a couple of common transforms-related pitfalls you can encounter:

1- Only transforming positions

Not transforming other 3d coordinates used for the simulation to worldspace often leads to undesired behaviors if part of the simulation already runs in worldspace.

Transforming only position and changing the effect instance orientation ignores the effect orientation entirely. In the example below, the physics node will see the {1, 2, 0} vector as an absolute, worldspace velocity:

transform nodes: position onlytransform nodes: position only

Using the “local direction to world” to transform the initial velocity before wiring it into the physics node solves the problem:

transform nodes: position and velocitytransform nodes: position and velocity

 

2- Converting to worldspace twice

Doing a local->world conversion at spawn, running the simulation at evolve, and inserting a local to world conversion before rendering in hopes of making the particles follow the effect, will lead to totally incorrect behavior.

Transform nodes: converting to worldspace twiceTransform nodes: converting to worldspace twice

This can also happen with trails and child particles, when you want localspace trails. Here you want the spawn xform node to spawn at the parent particle position, but also want the child particles to follow the effect instance. The solution here is to use a localspace node.

 

3- Localspace scene collisions

Using the “local position to world” node before rendering to transform the effect to worldspace will not work properly when using a collision node. This is because the collision node expects worldspace coordinates.

The effect will always collide as if it was located at the world origin:

Scene collisions: local to world at evolve (incorrect)Scene collisions: local to world at evolve (incorrect)

Having the entire simulation run in worldspace produces correct collisions:

Scene collisions: local to world at spawn (correct)Scene collisions: local to world at spawn (correct)

 

4- Incorrect positioning of local to world evolve conversion

Trying to solve #3 by converting from local to world at evolve before the physics node will not work, and produce incorrect results.

Trying to solve #3 by converting from local to world between the physics and collision nodes will not work either.

 

The physics and collision nodes re-use the simulation’s previous frame results to compute the new particle state.

This is done through a load/store path (also called discretization path). For position, the load happens along the position wire at the first spawn->evolve transition, and the last store performed is at the end of the collision node.

Load/store paths are displayed in yellow in the “Exec rate” view mode of the nodegraph.
Any operation touching that yellow region is on the load-store path and will affect the results of the next frame.

 

Inserting an evolve “local position to world” node before the physics or between the physics and collision will cause it to transform the previous frame position at the start of every new frame. This is equivalent to adding the emitter position to the previous position, every frame.

Transform nodes: Incorrect xform location

Transform nodes: Incorrect xform location

 

It is effectively re-transforming from local to world a coordinate which was already in worldspace. This is like pitfall #2, except it does it every frame and accumulates the results.

This obviously causes totally wrong results whenever the effect is not at the origin, causing the entire simulation to “expode”.

Transform nodes: Incorrect xform location

There are various ways to solve this. The easiest one by far which does not need to worry about or even understand load/store paths is to use a localspace node.

 

 

Was this article helpful to you? Yes No

How can we help?