Hi,
I've got a vellum sim where I would like to extract some of the attributes, say velocity for example, off of the simmed geo. I found that I can do this via the extract centroid node, so now I can get some attributes from a geo onto a point per piece. Fine. However, the attributes change their values from frame to frame too fast. So, I would like to further this by averaging out the information over three or five frames (1-2 frame before the current and one after), and then transfer or copy this back onto the simmed geometry for further use. But how? I cannot seem to find a good way to do this. What is the best approach?
The case is further complicated by the fact that the vellum geo starts out as copies to points over a certain range, so that I have an unequal number of points/pieces per frame for the first part of the frame range (until all pieces are in the scene).
Does anyone know a good answer to this?
Thanks,
Dag
How to best average out attributes over time?
1480 13 3- Dougie0047
- Member
- 82 posts
- Joined:
- Offline
- CYTE
- Member
- 708 posts
- Joined: Feb. 2017
- Offline
- Dougie0047
- Member
- 82 posts
- Joined:
- Offline
- tamte
- Member
- 8785 posts
- Joined: July 2007
- Offline
For CHOPs you still need to have stable unique id attrib to be able to track your changing topology which may be unnecessary complication
It may be easier to keep adding your attribute to an array per point and keep N last values in there
Then post-sim each point at each frame will have its last N values in there so you can do whatever you want with those
It may be easier to keep adding your attribute to an array per point and keep N last values in there
Then post-sim each point at each frame will have its last N values in there so you can do whatever you want with those
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- Dougie0047
- Member
- 82 posts
- Joined:
- Offline
@tamte Thank you for your reply.
I'm not quite sure what you mean though. How would I do this and what do you mean with N last value? The steps before the sim are that I first scatter some few points in a volume with a seed set to $F. So, that gives me 2-3 new points per frame. How can I keep adding an attribute to an array on this? Via a sop solver and then somehow transfer information to the points? I suppose what confuses me is how I can make the attribute stick when I'm constantly generating new points? And, when you say n last value, do you mean that I have to somehow throw out the other values in the array?
Thanks again
I'm not quite sure what you mean though. How would I do this and what do you mean with N last value? The steps before the sim are that I first scatter some few points in a volume with a seed set to $F. So, that gives me 2-3 new points per frame. How can I keep adding an attribute to an array on this? Via a sop solver and then somehow transfer information to the points? I suppose what confuses me is how I can make the attribute stick when I'm constantly generating new points? And, when you say n last value, do you mean that I have to somehow throw out the other values in the array?
Thanks again
- tamte
- Member
- 8785 posts
- Joined: July 2007
- Offline
here is an example, only look at green nodes inside and outside of Vellum Solver
essentially inside of the solver you create array of your attribute, being it v or Cd or whatever attribute you want to accumulate and limit to N values in this case 5, but feel free to promote it to slider
this will simply accumulate the value per point so it doesn't care whether you emit more pieces
then after solver you can process the array however you want, for example average it like this
essentially inside of the solver you create array of your attribute, being it v or Cd or whatever attribute you want to accumulate and limit to N values in this case 5, but feel free to promote it to slider
int max_values = 5; insert( v[]@v_array, 0, v@v ); if ( len( v[]@v_array ) > max_values ) { resize( v[]@v_array, max_values ); }
then after solver you can process the array however you want, for example average it like this
v@v = avg( v[]@v_array );
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- Dougie0047
- Member
- 82 posts
- Joined:
- Offline
- Dougie0047
- Member
- 82 posts
- Joined:
- Offline
- tamte
- Member
- 8785 posts
- Joined: July 2007
- Offline
It's just because you said you have 2-3 new points per frame
While I just used 1, having id increment by 5 per frame, gives you space to have 0-5 new points per frame, obviously if you need more you do more
Or you may not need id at all, I just used it in example to generate random Cd attrib which is more visible for illustration than just doing it to v
While I just used 1, having id increment by 5 per frame, gives you space to have 0-5 new points per frame, obviously if you need more you do more
Or you may not need id at all, I just used it in example to generate random Cd attrib which is more visible for illustration than just doing it to v
Edited by tamte - Oct. 18, 2024 19:59:22
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- HristoVelev
- Member
- 82 posts
- Joined: Nov. 2017
- Offline
Maybe you could also do a running weighted average? Each timestep you take the previous, average it with the current value weighted by the duration of the sim. More here:
https://en.wikipedia.org/wiki/Moving_average [en.wikipedia.org]
This would have a smaller memory footprint than collecting all the values per frame and per point, that sounds dangerous
https://en.wikipedia.org/wiki/Moving_average [en.wikipedia.org]
This would have a smaller memory footprint than collecting all the values per frame and per point, that sounds dangerous
Edited by HristoVelev - Oct. 20, 2024 05:33:58
- Dougie0047
- Member
- 82 posts
- Joined:
- Offline
@tamte - ah, ok, see what you mean. Thanks!
@HristoVelev: This is interesting. I'll have a closer look at this later. On first glance I see that the article is quite math heavy. Do you also know of a more "pleb-friendly" reference? If not I'll work through it in my own time. From your short description above it seems to me that the practical solution would be to use the sop solver for this. Would that be a fair intuition?
Thanks again!
@HristoVelev: This is interesting. I'll have a closer look at this later. On first glance I see that the article is quite math heavy. Do you also know of a more "pleb-friendly" reference? If not I'll work through it in my own time. From your short description above it seems to me that the practical solution would be to use the sop solver for this. Would that be a fair intuition?
Thanks again!
- HristoVelev
- Member
- 82 posts
- Joined: Nov. 2017
- Offline
Yes a sop solver or operation inside a dop, if that's where your geometry comes from. It's basically just average of the last few time samples. It does have the problem of only seeing inside the sampled range though. And it would be memory inefficient to save all the samples. Maybe you could save min and max only, and average these - would this be good enough?
- tamte
- Member
- 8785 posts
- Joined: July 2007
- Offline
HristoVelevThat's why you should keep only last N samples, like last 5-10 per point
This would have a smaller memory footprint than collecting all the values per frame and per point, that sounds dangerous
The advantage is that you can quickly tweak the average after the sim, for example to do lower or 0 weights for further frames, or use other type of filter
It should not be a problem for typical Vellum sims
But for memory heavy sims like very large grain sims or FLIP you may want to be more cautious and do all the math during the sim, but in most cases resimming just to tweak the values is not worth the saved footprint
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- HristoVelev
- Member
- 82 posts
- Joined: Nov. 2017
- Offline
-
- Quick Links