Problem with motion blur

[CosX]

Hi all,

There is a task to compute the simulation of the tyFlow geometry in Redshift with Motion Blur.
When the Particle Object Interface is turned on, the time of the Transforming Vertex operation becomes almost infinite.
http://forum.tyflow.com/thread-1652-post-5636.html
Following the link above, I found what I thought was an alternative way to compute Motion Blur:
1) In your source tyFlow, use a Custom Properties operator to store your particle velocity to a custom data channel (in continuous mode).
2) Use a Mapping operator in continuous mode to save that channel data to map channel 20.
That’s amazing!
MB is instantly computed without prior long transformation of vertexes. However, there is some confusing dependence on the form of the emitter. I change the area of the emitter (simple plane) using the “Slice” modifier. When the emitter becomes larger, the MB is no longer computed.
Is it a bug?
How to solve the problem by this method so that the MB is computed for any emitter size and number of particles?

[tyFlow]

You don't need that elaborate workaround, but you have to also enable instancing in the Mesh operator for moblur to work when the particle interface is on.

[CosX]

You don't need that elaborate workaround, but you have to also enable instancing in the Mesh operator for moblur to work when the particle interface is on.

Thanks for your answer.
Unfortunately, changing the Mesh operator to render as instances  and turning the Particle Object Interface on changes the frame rendering time from 18 seconds to 132 seconds. And this is just about the test scene, in a working project with a lot of geometry, the rendering time tends to infinity.
We approached Redshift support with this question and here's what they told us:
"Looks like it’s still the issue with changing topology.  That means tyFlow is not giving us appropriate vertex velocities on the specified map channel.  So we default to sampling the mesh at all sub-frames being blurred.  If the number of vertices is changing, we cannot deform the mesh.
When that happens, we output a message that shows in Redshift Feedback Display (if enabled), the Render Messages window, and the Redshift log file:
WARNING: The geometry of ‘tyFlow002’ changes while the shutter is open.  Cannot perform deformation blur on this mesh for this frame.
I’ve looked a little deeper here, and I see that tyFlow is actually populating the vertex velocity channel, but the vertex count on that channel is completely different.  This breaks our code, which requires that the channel contains the same number of vertices.  It looks like a vertex used by multiple faces is being assigned a separate velocity for each face."
Is there anything that can be done by tyFlow to fix the situation? So it would be possible to calculate MB via channel 20 for any topology and any number of geometries?

[tyFlow]

I don't understand the reply from the RS devs, because when rendering as instances the geometry is not being deformed...only transforms are changing. The issue has nothing to do with velocity channels or changing vert counts. Each instance assigned to a particle is a static mesh with no mesh-based velocity information. Note: there are exceptions to this rule that apply to cloth/actor rendering, where instances will have deformation information...but that doesn't apply in this case.

When the particle interface is enabled and all Mesh operators are set to instances, I get a decent render time and the moblur looks fine.

If RS is giving you an error about topology and/or deformations, that means your settings are not correct and you're not rendering as instances. Or you're not rendering with a compatible version of RS.

In any case, the emitter size is irrelevant. Perhaps you're misinterpreting an error about the changing topo of your sliced emitter, as a tyFlow problem.

Attached is what I see when rendering with the latest RS, with the particle interface of both flows enabled and all Mesh operators set to render as instances. As you can see, moblur renders correctly.

[CosX]

Yes, in our case in the test scene, with the particle interface enabled, the render time was also decent (132 sec, as I wrote above). But in the working scene, the rendering of one frame takes more than 33 minutes, which is inappropriate, and without the particle interface enabled, the rendering time is 27 seconds.

The question that we are trying to clarify is the possibility of rendering a frame with MB without the particle interface enabled.  

There is a mode: we write Velocity data in Channel 20 via the Mapping operator, and then in Redshift Object Properties we specify Velocity Channel 20 as well. In this mode, MB is also computed, but not stably, selectively - some of the particles are computed without MB. The question is how to stabilize this process that without the particle interface enabled, MB is computed stable and always, because it is much faster way.

[tyFlow]

Ok so if I understand correctly,

1) if you render using the particle interface/instances, RS will render with moblur but it takes a long time

2) if you render as meshes, RS is much faster but it won't render with moblur

3) if you render as meshes using the map channel 20 workaround, you get a fast render with moblur but it's not consistent across all frames

Issue (1) sounds like a RS issue. Once tyFlow passes data to RS, it is no longer involved in rendering. In other words, once buckets begin, tyFlow is not doing any work any more. I know there was an issue in VRay, where using Embree with millions of tiny particles would take much longer due to the way instance bounding boxes are queried at rendertime. Perhaps RS has a similar issue.

(2) makes sense and is expected behavior.

Why (3) is not working is more curious. If RS is indeed using the mapping data to calculate moblur, then topological changes should no longer matter because it's not sampling points in time to figure out geometry deformations, instead it should just be implicitly moving vertices along the velocity values in the mapping channel. Perhaps, due to the fact that this velocity/mapping workflow is somewhat of a workaround, they have an internal switch that is still activating when topology changes are detected, even though for your use case such a switch could be ignored because topo changes wouldn't matter.

Either way, tyFlow seems to be doing all it can to get vel data to RS. The remaining issues seem to be things that need to be sorted out by RS.

If you really want to dig in, once you assign your mapping values to particles and convert them to a mesh with a Mesh operator, you can use MAXScript to query the mapping values of particular faces and such...just to be sure the geometry is getting the correct velocities values assigned to the map channel of your choice. Also since RS has a spinner which allows you to define which mapping channel will contain the velocity data, you could set that to whatever channel you want - doesn't necessarily have to be 20, that's just what tyFlow uses internally. Make sure the channel matches whatever you set in your Mapping operator as well.

A final note: it's possible the RS devs have assumed that a a velocity-containing map channel will have an equal number of map vertices as vertices in the mesh. Maybe that's what they're using as their criteria to either accept or reject the data in the channel. When doing a regular Mapping override on particles though, the number of mapping verts in that channel is not guaranteed to match the number of verts in the mesh. Only the face counts are guaranteed to match. This is consistent with how all mapping works on meshes...but may not be consistent with the way RS expects the data to be arranged. That would have to be confirmed with the devs.