I’m setting up a particle simulation that’s been created in Bifrost 3.1.0.8-2026 and Maya 2027.
I’ve got the sim pretty much how I’d like it, now I’m testing rendering with it. I’ve been following the examples here to the letter, but I’m still not getting any motion blur.
I’ve selected ‘Write Color Sets’ when create an Alembic Cache as per the instructions, then imported the Alembic Cache and entered ‘bifrost_velocity’ on the Motion Vector Color Set
The geometry renders, but with absolutely no motion blur at all. Physical camera settings are below. The Shutter Speed is generally what I use to match 25fps footage.
I’ve also tried the method below, but I have no idea where that Bifrost Meshing tab is, or the Channel Transfer - it doesn’t seem to appear on ‘bifrostGraphShape1’ nor any other objects in Maya.
From what I tested (I’m no Bifrost expert), the problem seems to be the bake_instanced_geometry Bifrost node, which creates one big deforming object rather than points with changing transforms (on which objects are instanced).
I tried your method and got the typical moblur error with deforming objects:
// Warning: V-Ray : Mesh “bifrost:polySurfaceShape1” has changing number of vertices (114600 expected, 305600 actual).
Maybe it’s a better idea to export the points only and later instance geo onto them. Or set the graph to go through USD - from what I understand, that’s the current best solution.
The Bifrost docs indeed seem unupdated, but this will change when we add native support for Bifrost graphs.
OK , so there is two different things here. You are looking at the documentation for the old bifrost liquid stuff. So forget about what that part of the doc.
If you are using Vray 7.4 you do not need to baked the instances to render stuff in the graph, however if you need MB at the moment isn’t working since they still need support for user data, I ran into myself and I already reported. So you will want bake and transfer the attributes that you want.
Here is an example graph working with motion blur enable and as you can see the proxy read the point_velocity + point_color - I left some notes in the graph, so hopefully make sense.
Still some things to figure out on it… For some reason the Alemic cache is missing the first few frames of the sim, and I need to figure out how to get my particles to keep their orientation when they collide. But, this is brilliant now motion blur is working.
Thank you very much again! I’ll send through the file to the above link , just in case @hermit.crab would still like me to send it.
Thank you very much @hsz for the workaround you provided! Baking to an alembic should work indeed.
I am currently working on user attribute support and particle motion blur, so hopefully we will be able to render these directly. Feel free to message me if you have any other workflow suggestions for Bifrost.
Hi, @sebbiej, I am happy that the workaround @hsz suggested works for you. Yes, you can send the scene and I will try to look at the problem you’re having.
Hi @sebbiej, I looked at your scene and I think I have some fixes for your problems.
Regarding the missing frames of the animation:
The problem happens because the exported animation range (in write_Alembic) is from 0 to 188 but particles start appearing only at frame 20 (as set in source_particles). Note that the Alembic library expects valid mesh input (with existing vertex and face arrays) for the first exported frame. However, in this case, the Alembic writer receives no mesh for the start of the animation which causes the bug. It somehow manages to recover after frame 26 once particles emission stops but this is pretty much by chance.
A simple fix is to export only the animation range for which particles exist, i.e. 20-188. Here is exactly what I did step-by-step:
Move to frame 0 on the Maya timeline and ensure that the timeline playback is set to “Play once” instead of “Continuous loop”. That way, there is no danger that the exported Alembic might get overwritten if a new animation loop begins.
Set Start Frame on the write_Alembic node to 20. Keep End Frame to 188.
Connect the out_meshes output on the write_Alembic node to the graph output.
Run the animation, then disconnect out_meshes.
Import the generated Alembic file as a V-Ray proxy.
(Important!) To keep the proxy animation aligned with the Bifrost graph (i.e. particles appearing on frame 20, not on frame 0), check the Animation parameters->Use alembic animation offset checkbox in the proxy attributes. You can also set Playback type = Once.
Hide the proxy for frame 0-19 because otherwise some part of the animation (depending on Playback type) will continue to be visible for these frames as well.
If you don’t like this approach, an alternative would be to use merge_geometry in the Bifrost graph to add some off-frustum particle to the point list. The particle will not be visible but will trick the alembic writer that a valid non-empty mesh is being exported for all frames.
Regarding the particle orientation
I think the rapid change in orientation on collision with the floor is expected because orientation is driven by point_velocity. Velocity flips on collision and then rapidly goes to 0 which affects the orientation calculation causing the rapid change.
I can suggest changing the orientation math a little bit. Instead of point_velocity, you should use some other value to drive orientation which should a) grow continuously throughout the life of the particle and b) stop changing once the particle collides. One idea is to use the distance to the radial influence centre (0,8,0) but maybe something else might work as well.
