Referencing attributes from a given simulation state - better way to a

[jrockstad]

Hi guys, here's the situation - I'm working on a particle simulation and would like to globally reduce the applied force as the particles age. The general idea is easy enough - multiply force by a ramp driven by normalized age, but the implementation is a bit tricky as I'm obviously not going to be getting the values I need pulling from force in a POP VOP while updating force at the same time. The best solution I've been able to come up with is caching out the sim with a File SOP, bringing that into a POP VOP and pulling the force attribute. This works just fine, with the obvious caveats that I need to hop back into SOP level and re-cache if I make any changes and potentially eating up a lot of time / hard drive space in the process depending on the complexity of the sim. With that in mind, are there any better ways to approach this? 

 

What would be great is having a DOP that would let you mask the effect of another DOP or group of DOPs, store the attributes that would be present in the simulation absent those DOPs but have no effect on the sim otherwise and allow you to reference those values in a POP VOP / Wrangle. I'm sure there are a bunch of great technical reasons why this isn't really feasible, but hey, I can dream. 

 

 

[anim]

maybe you can just use VEXpression on your POP force

force *= 1-@nage;

or if you want to affect all accumulated forces for current substep use  POP Wrangle as the last POP node before POP Solver:

v@force *= 1-@nage;

[Atom]

If you need to reach into another DOP you can fetch their attributes like so.

 

Here is an example of fetching the P osition from an agent.

Place this code in a Pop Wrangle in your current AutoDopNetwork.

string agent_path = "op:/obj/crowd_sim:crowdobject/Geometry";                    // Path to our agent database of attributes.
int agent_count = npoints(agent_path);                                                          // Number of agents in the system.
for (int i = 0; i < agent_count; i++) {                                                                 // Begin looping through all agents. (scatter point count assumed to be equal).
    vector agent_location = point(agent_path,"P",i);                                          // Fetch the point location of the agent.
}

Edited March 27, 2016 by Atom

[jrockstad]

Thank you both - I think I may not have explained myself perfectly. Tomas, that was essentially the logic I was initially using in my POP VOP, multiplying force by my age ramp and feeding it right back out to force. The issue is that I don't want the normal solver behavior of basing those calculations on the value of the previous frame. The whole age thing might actually be complicating things here - the problem could be demonstrated more easily even just using a simple constant as an example. Say I want to cut all my force values in half, using something like force *= 0.5, I get the expected value on the first frame, then half of that in the next, and half of that in the next, and so on. What I'm looking for there is half of whatever the value for that frame was initially. By caching out my sim geometry at the point right before I add that logic, I can read it back in and get the values I need, it's just a bit awkward. 

 

Atom, that's interesting - I think I may have already tried something similar. I discovered that if you set a POP VOP input to use a SOP you can actually drill down into certain DOPs and grab their SOP Solver network to fetch attributes from. However, this only works in a small number of DOPs, POP Object and POP Source for example, neither of which contain the force attribute I need.

[anim]

not sure I understand, if you don't want the changed value to affect your simulation, why would it matter that you change force attribute?

can't you do v@scaledforce = v@force * chramp("ramp", @nage); ?

then access v@scaledforce to use for whatever you need

 

...The issue is that I don't want the normal solver behavior of basing those calculations on the value of the previous frame....

force attribute is 0 at the beginning of each timestep, then all the forces accumulate the value, so there is no interference with values of previous timesteps, so if you change force in half it will be just half of the force for current timestep. But again, I'm confused about whether you want it to influence your sim or not, example of what you consider working would help, as it's not clear what you need that value for and why it would need to be in force in that case

Edited March 27, 2016 by anim

[jrockstad]

force attribute is 0 at the beginning of each timestep, then all the forces accumulate the value, so there is no interference with values of previous timesteps, so if you change force in half it will be just half of the force for current timestep. 

 

Ah, now that's interesting... that deduction of mine was from observing the way velocity generated from a POP Source behaves. Set a (0, 1, 0) velocity, for example, on a POP Source, do something like v@v *= 0.5, you'll have a velocity of (0, 0.5, 0) on the first frame, (0, 0.25, 0) on the second frame, and so forth. I mistakenly assumed that this was just how forces behaved in DOPs, but I see now that if I leave velocity on the POP Source alone, manually add the attribute and then perform the multiplication it works just as I expect - (0, 0.5, 0) velocity on every frame. 

 

I think my confusion on that point is really at the heart of this. So, yes, it seems that force *= whatever_value should be getting me exactly what I want, and in fact it, well... does, basically anyway. The discrepancy in expected values I was seeing was simply the result of a low substep value that became more obvious as the simulation went on. 

 

Wow - that was a lot of words to basically reach the conclusion that my initial setup in fact did exactly what I wanted and that I have absolutely no clue how forces work in DOPs, which I kind of already knew. 

 

In all seriousness, thank you very much for the clarification Tomas. Obviously I've a ways to go in getting my head around all this DOPs madness, but I'm having fun with it, so it's all good. Thanks again!