+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: General (https://obi.virtualmethodstudio.com/forum/forum-5.html)
+--- Thread: Feedback Non destructive blueprint regeneration (/thread-4600.html)
Non destructive blueprint regeneration - Qriva0 - 06-03-2026
Hi, this thread mentioned destructive nature of blueprint generation, I noticed too that iteration based on mesh changes is really slow because of this, adding one vertex to softbody or cloth requires regeneration.
My proposition is to add feature to map existing data to newly generated particles.
To be precise, there would be checkbox next to "Generate" button (or button dropdown similar to lightmap bake) and this mode would keep old blueprint data cached, then after generation it mapsnew particles to old one by finding the closest particle. So things like weight, radius, groups would be copied from previous setup. Also groups - it would keep groups, but replace indices with new one that fit previous positions. In this case adding single vertex to mesh would require minimal changes, if any. In case of meshes with similar surface (but different density of particles) the same would apply, because 99% of data would fit previous setup.
This is not critical feature, but I think it would sagnificantly help many users and make iterations way shorter.
RE: Non destructive blueprint regeneration - josemendez - 06-03-2026
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,
RE: Non destructive blueprint regeneration - Qriva0 - 06-03-2026
I agree, multiple iterations result in lose of information, however in many cases, even if that happens it is still faster to get partly correct mapped data, otherwise everthing must be painted from the start anyway. In my case, up until now I had to regenerate and paint groups, radius, weight from the start every time, but it's way faster to fix 1-10 vertices, instead of painting from scratch. Yes, I could try workflow with textures, but as you said, not everything can be done and it requires additional setup and skills.
However, the problem is that current workflow is completely destructive - I understand problems with the case above (where number of triangles is different), but in case where mesh is exactly the same, with exception of positions of vertices it could be done better, because user data does not change overall, I want to keep groups, weights and all the stuff, there is no data lose, I just need to auto update constraints, and that is all. So it would be great if there was non destructive regeneration in any form.
RE: Non destructive blueprint regeneration - josemendez - 06-03-2026
Will experiment with this idea before Obi 8 is released, and consider the possibility to include it in Obi 7 to make lives like yours easier. Will let you know more shortly.
One possible avenue is to make a more general approach to transfer data between blueprints, that allows you to choose between world space or uv space spatial proximity, or particle index-based data transfers without an intermediate texture support. Something like Maya's Transfer Attributes tool: https://download.autodesk.com/global/docs/maya2014/en_us/index.html?url=files/Coloring_polygons_Transfer_color_data_between_meshes.htm,topicNumber=d30e168827
Essentially, you'd select blueprints A and B and have the data from A transferred to B using a variety of methods. This gets rid of data loss entirely (blueprint A would be your "base" blueprint that contains the data you don't want to lose, B the one you're iterating on) and doesn't require non-overlapping UVs. Downside is it doesn't allow you to work on your data outside of Unity.
RE: Non destructive blueprint regeneration - josemendez - 06-03-2026
(Yesterday, 11:45 AM)Qriva0 Wrote: but in case where mesh is exactly the same, with exception of positions of vertices it could be done better, because user data does not change overall, I want to keep groups, weights and all the stuff, there is no data lose, I just need to auto update constraints, and that is all.
Btw this is something that I already implemented in Obi 8: you can choose to only regenerate constraints, keeping all particle data intact instead of regenerating everything from scratch:
![[Image: Iiupn1a.png]](https://i.imgur.com/Iiupn1a.png)
Only useful in cases where vertex count stays exactly the same, but edge connectivity or vertex position changes. There's no need to do any spatial mapping at all in this case, you simply keep the old data as-is. Not sure if you're interested in having this right now, if you are, I can see how difficult it would be to backport this to Obi 7.
RE: Non destructive blueprint regeneration - Qriva0 - 06-03-2026
(Yesterday, 12:06 PM)josemendez Wrote: Btw this is something that I already implemented in Obi 8: you can choose to only regenerate constraints, keeping all particle data intact instead of regenerating everything from scratch:
Only useful in cases where vertex count stays exactly the same, but edge connectivity or vertex position changes. There's no need to do any spatial mapping at all in this case, you simply keep the old data as-is. Not sure if you're interested in having this right now, if you are, I can see how difficult it would be to backport this to Obi 7.
This is exactly what I meant in the second case - very nice to see this implemented!
Currently I am past the stage of intense experiments with meshes, so it is not so important (at least for me), but I am very happy this feature will come soon!
(Also I don't want to contribute to delay for release of obi 8
)