Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

ikoon

Pre-solve, post-solve, evaluation order, debugging

This is a newbie DOP question. Please, I have been investigating the functionality of pre-solve and post-solve. I have tried the POP solver. If I connect SOP Solver to presolver and alter the @P, then there is difference between @pprevious and "real" positions. Pprevious gets values, which never "were".

As I understand it, POP solver works like this:

Just born particles:
post-solve
store to spreadsheet (call it "The Previous Frame Value")

All other particles:
pre-solve
store pprevious to spreadsheet (so not "The Previous Frame Value")
post-solve
store to spreadsheet


I am trying to understand it, because I would like to dive into these relationships:
Point Number: dopoption($DOPNET, $OBJID, "CopyInfo", "copynum")
Position: dopoption($DOPNET, $OBJID, "PointPosition", "tx")

 

Now I am not sure, when are the values being written in the spreadsheet: E.g. when referring to "tx", is it always "The Previous Frame Value"? Probably not and probably it works like this? Simplified:

End of 20th frame:
- "tx" was 1.0

Computing 21st frame:
- read "tx" as 1.0 (because "solving" something)
- alter "tx" to 2.1 (because "presolving" something)
- read "tx" as 2.1 (because "postsolving" something else)
- read "tx" as 2.1 (because "presolve"..)
- alter "tx" as 5.0 (because "solve"..)
- read "tx" as 5.0 (because "presolve"...)
- write "tx" as 5.0 into spreadsheet, render it

Is it one single thread like this? So the value goes trough one thread of the code of different solve/post/pre/post/solve/pre/post/... and is being read/altered on the way?

How does the compiler sort the influences? How do you debug these? Can I see the code, or filter $OBJID and "tx" influences?

Probably the "@pprevious" is just a specific exception of "not previous frame value", because it is just a side product of some "in-between" collision solvers? I didn't even find, where is @pprevious initially created. I didn't even find, where is the particle decided to be presolved or not. Is it blackboxed?

Share this post


Link to post
Share on other sites

I have been reading the docs, Sop Solver DOP says:

By using an expression like stamps("../OUT", "DATAPATH", "../.:objname/Geometry") in an Object Merge SOP, the output of the previous timestep can be used as the starting point for the next timestep within the SOP Network.

- shouldnt the doc say "output of the previous timestep, altered by the solvers which have been already evaluated in the current timestep"
- the mentioned path "../OUT" confuses me ... because global parameter DATAPATH is stored on the "sopsolver" itself

When I saw the path "../OUT", I thought that there is really a storage of "the previous frame value", no matter if the current timestep already altered that value. But there isn't such a storage? During the timestep, all the values are "live", am I right?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now