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?

Link to comment
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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...