While Paint Blob Collisions are a powerful tool and open up rich gameplay possibilities, there are limitations you should be aware of:

—

From Physx’s point of view, paint blob collisions do not exist

Unreal Engine uses Physx for handling all of its low-level collision (not just physical simulations, but also basic collision detection for any mesh). Physx is not aware of any of your painted pixel collisions.

This doesn’t matter much if you’re doing things like Lava Traps, Behavior cues for A.I, etc, but if you’re doing portals, pits or holes, i.e. subtracting geometry, it becomes a very real issue.

For example, you can create holes in walls (via paint) and send projectiles through those holes (using the plugin’s smart projectile component), but because Physx doesn’t see these holes, basic Physx operations like LineTrace/Sweep will not pass through our newly created holes. They will simply hit the wall and report that they found a hit.

There are plans to mitigate this by providing a suite of Physx equivalent functions (Eg: LineTrace_PaintBlob, Sweep_PaintBlob, etc) that can harmonize Physx’s viewpoint with the paint blobs, but currently these haven’t been implemented yet. You can always manually call QueryPaintCollision upon Hit to check for portals and let your trace pass through though; that kind of trickery is demonstrated across several examples in the sample project.

—

Paint Blobs are an API rather than a ready-to-use gameplay toolkit

While the plugin does provide some ready-to-use components like the smart projectile component (which can be instantly used), anything to do with characters (such as portal travel, falling through pits, etc) requires carefully planning and orchestration in your blueprints/code. Remember that you are always fighting against Physx view of collision so to create a believable effect you’ll need to perform custom work using the API provided by the plugin. The sample project does have several examples of how to achieve this.

—

Portal Travel for Characters is tricky to get right

If you’re purchasing this plugin with the sole purpose of implementing portal travel for characters, be aware that there will be a significant number of challenges to be overcome with custom logic in your character’s blueprint/code. Portal travel involves a brief period of teleportation (necessary, because Physx will otherwise block you from entering) and during this period you’ll need to ensure the character cannot turn around, cut corners or do anything else that might get them stuck in wall, bypass sections they’re not supposed to (especially relevant for a maze), etc.

The sample project’s portal character uses a slew of measures to combat this, but once again, these are not provided by the plugin. They custom code that end-users will need to write for their characters using the basic building blocks of paint blob collision.

Another issue can be preventing your character from passing through portals that are not fully flush with the floor; unless you’re able to animate the character stepping/climbing onto the hole and across, its just not going to look believable because your character’s legs with intersect with a portion of the wall which is still visible. 

Generally speaking, portal travel across floors (falling through a pit) is far easier to implement than travel across walls.