Jump to content

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

Recommended Posts

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:
store to spreadsheet (call it "The Previous Frame Value")

All other particles:
store pprevious to spreadsheet (so not "The Previous Frame Value")
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