06-03-2026, 10:48 AM
(This post was last modified: 06-03-2026, 11:08 AM by josemendez.)
Hi!
Thanks for the suggestion! what you described is something we have explored in the past with very poor results, unfortunately.
The problem of using the value of the closest "old" particle is that it causes data to slowly degenerate if mesh topology changes a few times (since there's no baseline data it always reapplies the previous data in a lossy fashion, losing integrity each time you regenerate the blueprint with a modified mesh), and is completely useless if mesh shape changes significantly, with vertices no longer spatially close to themselves in previous incarnations of the mesh.
To keep per-particle data consistently across blueprint re-generations, the current intended approach is to export data as textures using the Texture tab in the blueprint editor - or author data in external software to begin with, which is usually much better from an UX perspective since the blueprint editor is no substitute for Maya or Blender - then reimport the data after regenerating the blueprint. Compared to world-space distance based mapping, working in UV space is a much better option as it ensures particles always get consistent values even if topology or shape significantly change between iterations. It's also easy to scale or remap values at import time.
The downsides of the current texture-based approach is that it only works if the meshes are UV-unwrapped and contain no overlaps (exact same requirements as lightmapping), and that it must be manually done for each particle property every time you regenerate the blueprint. A vast improvement would be to do this process fully automatic: references to the textures containing data would be persistent, and the blueprint would import their data automatically every time it is regenerated.
Particle groups currently cannot be imported/exported from/to textures. It would be easy to apply the same technique to them allowing us to store up to 4 particle groups per texture, one per channel. (technically we could possibly use bit masks to store up to 256 groups per texture, but would make it a lot harder to author these in external software).
Will consider including these improvements to the Texture tab (automatic data import, particle groups import/export) in the first few versions in the 8.X cycle. I'd also like to document this workflow deeper, since many users are unaware of it.
kind regards,
Thanks for the suggestion! what you described is something we have explored in the past with very poor results, unfortunately.
The problem of using the value of the closest "old" particle is that it causes data to slowly degenerate if mesh topology changes a few times (since there's no baseline data it always reapplies the previous data in a lossy fashion, losing integrity each time you regenerate the blueprint with a modified mesh), and is completely useless if mesh shape changes significantly, with vertices no longer spatially close to themselves in previous incarnations of the mesh.
To keep per-particle data consistently across blueprint re-generations, the current intended approach is to export data as textures using the Texture tab in the blueprint editor - or author data in external software to begin with, which is usually much better from an UX perspective since the blueprint editor is no substitute for Maya or Blender - then reimport the data after regenerating the blueprint. Compared to world-space distance based mapping, working in UV space is a much better option as it ensures particles always get consistent values even if topology or shape significantly change between iterations. It's also easy to scale or remap values at import time.
The downsides of the current texture-based approach is that it only works if the meshes are UV-unwrapped and contain no overlaps (exact same requirements as lightmapping), and that it must be manually done for each particle property every time you regenerate the blueprint. A vast improvement would be to do this process fully automatic: references to the textures containing data would be persistent, and the blueprint would import their data automatically every time it is regenerated.
Particle groups currently cannot be imported/exported from/to textures. It would be easy to apply the same technique to them allowing us to store up to 4 particle groups per texture, one per channel. (technically we could possibly use bit masks to store up to 256 groups per texture, but would make it a lot harder to author these in external software).
Will consider including these improvements to the Texture tab (automatic data import, particle groups import/export) in the first few versions in the 8.X cycle. I'd also like to document this workflow deeper, since many users are unaware of it.
kind regards,