Thanks for the tip! Where do I find the new version?
1 Like
Hey guys, did anyone get this script working with baked UV’s from emmiter? And if so, which version of blender and of the script did you use? I tried downloading various corresponding versions of this script and blender (that were supposed to work together) but i always got stuck right before baking process on python errors.
Thanks in advance to anyone who is willing to help me.
PS: This script is amazing
Yeah, baked UV’s seems to cause the bake to end in error.
i get the same error as you when i select “Set global UV” and then check “bake UV at ending”
and when i try to select "set active UV(current “UVMap”) i get this error
here is my .blend file if anyone wants to check it, maybe it does work for others and we are doing something else wrong
help is much appreciated
Are force fields not working wit4h 1.08?
I am getting an error "ImportError: cannot import name ‘core_37_64’ from ‘molecular’ " when I try to activate the addon.
Hello,
I made a few fixes for the python errors mentioned here and also packaged a new release zip (1.0.9) per OS.
Didnt recompile the binary since there are only python changes now. So if the binary reports still 1.0.8 as version, this is fine… (didnt bump its internal version), but the addon should be 1.0.9 now
Regarding the force fields, they should work, just tested here with force, wind and vortex and molecular. The simulation did definetely respond to the force fields.
Regarding the binary not being found, make sure to install the proper release zip for your OS. It should contain the binary (which is not inside the github source repo, but its sources are there under “source”)
Edit: I also have 64 bits versions only (precompiled)
Edit 2: seems to work 
Remarks:
- only in cycles
- only in rendered viewport and render
- need to re-bake the sim for UVs after loading (not persistent, it seems)
test_UV_molecular.blend (835.1 KB)
Edit 3: same blend, but with 30x30x30 particle grid:
6 Likes
Thaaank youu! Scorpion81, are you and Pyroevil the same person?
I’ve had financial interest in getting this to work, so will donate once possible.
no, i am not Pyroevil 
He is the original author of molecular, my humble activities were just to fix it for 2.80, based on another fix by PavelBlend.
1 Like
Okay! Thank you so much
Unfortunately, I completely fail to understand how the UV’s are baked.
I check Bake UV at ending, use the Particle Info node setup as shown.
Do the particles and the emitter have the exact same material at the end?
The dupli object, as in the sphere in this example, has a material including the particle info node. On the cube, there is another, similar material, without the particle info node. But this cube material is just for visual reference, its not necessary to bake the UV. (The UV map itself is important, though).
Basically, it is checked which particle is closest to the geometry of the cube in this case and the color from the according UV coordinate in the texture is taken as texture or color (not exactly sure).
Then that color is being mapped onto the dupli objects. That algorithm is a bit complex and its not written by me, so i might have misunderstood a few things. So take this info with a grain of salt.
Thanks for the explanation. Strangely, after doing exactly the same, my particles just come out single-colored like this:
Hmm, you need to be in rendered viewport mode and it works only in cycles.
Otherwise the “texture” on the cube spheres isnt visible.
I also found out if you have baked the sim and checked Bake UV beforehand, you can restore the UV after loading if you are on the sim start frame and press “Set Active UV” in Molecular. No need to rebake.
Thank you! Works perfectly 
Didn’t realize it’s tied to Cycles
Hmmm… Weirdly, UV baking works perfectly in the viewport, but when actually rendering, it goes back to no UV with single color.
hrm, i guess its some internal depsgraph crap going wrong when starting to render. Some unnecessary refresh calls or so which clear the baked UV for some reason.
Tried to hook up a render_pre and render_init bpy.app.handler which was supposed to restore the UV before rendering, but first it wouldnt let me apply the triangle modifier in that state and it crashed blender.
Tried to workaround with bmesh, converting the temporary evaluated mesh datablock via bmesh to a permanent mesh datablock… no complaint, but still a crash. (with render_init).
With render_pre, it wont let me modify the temporary object being created as in setting an object matrix to it. Gah. If you ask me … thats all kinda badly designed. Starting a render seems to clear “too much” internally…
And you cannot just “capture” the viewport render, thats a bummer too (screencasting has been removed, thanks a lot for that… grrr)
So i guess its beyond the python side to be able to fix that properly… 
Don’t know much about Python, but I understand this is something that cannot be fixed?
But Molecular could render with baked UVs in the past, as there are plenty of animations on YouTube.
Is this a Blender 2.8 issue?
i think it is some blender 2.8 specific issue, yes. My guess is that the particle data is cleared for some reason if a copy on write operation is done, and it is being overwritten from the pointcache . Molecular did manipulate the particles from “outside” by directly writing the UV into the angular_velocity property. Angular velocity is also a pointcache attribute, respectively stored there, too. I assume the use case of molecular somehow fell through the cracks when the C / Depsgraph side was changed. I am further trying to find a workaround…