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.

Here’s a quick list of the plugin’s current mesh-painting limitations that prospective buyers should be aware of:

—

Seamless Painting Features:

Seamless painting in the mesh-space (3D painting) workflow is only supported for procedural brushes (i.e. circular strokes/etc), it is not supported not for Decals or Text.

Consider using World-space / local-space workflows where possible as they have full for seamless painting, even for Decal / Text projection.

—

Brush Size Accuracy:

While the plugin measures brush size in world-space units, accurate brush size for 3D painting is also only supported via procedural brushes, not for decals or text. For decals/text projection the size of your UV islands will influence the effective size. If some UV islands are disproportionately large (compared to their actual 3D faces), then the brush size will also scale accordingly.

World-space/local-space painting support fully accurate brush size though.

—