AWS Thinkbox Discussion Forums

thinking particles and subframe particle position stretching

Max 2014 16.1.178.0
Thinking particles 5.3.0.0
Frost 1.3.6.51279
Vray 2.40.04

I’ve had this problem for awhile and have narrowed down a bit but would love some help. It seems to be a velocity issue as this particles are being stopped with a velocity node set to replace with 0 (or even a rapid velocity reduction). Looking at these particles in the particle data viewer velocity is (0,0,0) and the speed through tp_PDV float is 0.0. This also occurs when the particles are moving to another group.

Edit : This ONLY seems to happen when moving particles between groups.

Anyone else run into this issue?

The reason I’m not using frame velocity offset it my mesh Geo has subframe animations (wings flapping).

I assume the problem is that you need motion blur on the flapping wings, but there is no such motion blur with frame velocity offset?

Is multi-pass motion blur an option for you?

Would it be possible for you to please send us a scene file that reproduces this problem? You can send us files by using our ticket system. You may need to ZIP your file to get it through to us.

Unfortunately there is no way to send it to you (studio lock down). I’ll try to explain the process if I can.

I was able to do a work around though. And no frame velocity offset did not get the proper MB (might be because TP was assigning a GeomTime).

An example of how my TP system was working relied on different states (walking, taking off, flying, landing) as groups. When a particle would move from one group to the other this problem would happen. Most times the changing of a group would be accompanied with a velocity stop, but even a slow stop this would happen.

I was able to get ride of the issues by keeping the particles in one group and controlling the states another way (memory integer flag). Unfortunately this does cause a bit of head ache as groups are a major to workflow tool in TP.

Ok. I was able to create a sample file which easily reproduce the issue.
FrostMBIssue.zip (589 KB)

Great, thank you! I have reproduced the problem.

I’m glad to hear that you found a workaround. I assume this problem is no longer urgent for you?

I imagine what’s happening here is, when the particles move between events, we change the order of their faces and vertices in the mesh. This produces motion blur between two completely different particles. I think this is pretty easy for us to fix, but the solution is fragile. It might work in your case, but it won’t work if particles are born or die, or if the mesh geometry has changing topology.

A better fix would be for us to handle animated mesh geometry properly, so you can use Frame Velocity Offset, but that is more difficult for us to fix. I will add that to our wish list for future development. Please let me know if you need it fixed sooner.

I’ve sent a few renders off with the work around and looks correct. Thanks for taking the time to look into it.

For other who may have this issue here is the work around I used.

Instead of using groups i.e. walking, sitting, walking use a memory node with a integer called something like state or animation. Walking would be state 1 and sitting would be state 2. Then just run a check : character > memory (state) > is this state 1 > do something.

This way the particle isn’t changing as its still the same particle ID. Its a bit of a pain but will work.

Also a memory node works a lot better than a data channel in TP. Data channels are left in for frost sorta reasons (GeomTime, ShapeIndex ). I have a export dynamicset at the end of my tp that copies all my needed info from the memory channels to a data channel.

UPDATE : If you cache your tp patricles. Then have a dynamic set (with cache applied) called, for your example “frost export”, then take your groups and move them to a master group this will fix the error.

Then from frost only load that new master group from thinking particle.

Thank you for posting your workaround!

Privacy | Site terms | Cookie preferences