Wrong Position in Box 3

[dewey1916]

Hey guys,
at the moment I try to create an spawn by travel operator in Box 3 to get extra channels like “Parent ID”… I noticed, that the “Show Data” in Box 3 does contain “wrong” values. I have a really simple flow to test this:

Just one particle born at [12,0,0] (Position Icon) with a speed of 50 in Z-Direction.
To check the position and speed values I also added a DataOp (Input Standart [Position] -> Ouput Standart [Position] - I did the same with the particle speed).

Here is a quick screenshot: http://puu.sh/dFqSP/0144c5fd9e.png

Now the confusing part begins:
I expect this to happen:

• [Frame 0] The particle is spawned at [12,0,0] and it gets the speed of 50 (1.66 units per frame).
• [Frame 1] The particle speed of frame 0 is added to the position of frame 0 - thus: Position [12,0,1.66]. The speed doesn’t change…
• [Frame n] The partice is at the position [12,0,1.66n] (Example: Frame 6: Position [12,0,10 ~ (1.666)]

What actually happens (in the DataOp “ShowData”):

• [Frame 0] See my expectation (The particle is at [12,0,0] and already has a speed vector.
• [Frame 1] The particle is still at [12,0,0] and also keeps the same speed.
• [Frame 2] The particle moved (finally)! It moved to [12,0,1.66] - it did what I thought it would do one frame before…
• [Frame n] From now on the particle behaves as expected, but one frame behind my expecations. The particle is at the position [12,0,1.66*(n-1)].

What the viewport shows me:

• My expectation (displayed as lines)! At frame 0 line from Z= 0 to Z=1.66 (Pos at Frame 0 to Pos at Frame 1). At Frame n line from [12,0,1.66n] to [12,0,1.66(n+1)].

I don’t understand what’s happening here… This is getting more confusing with more confusing with more integrations steps… BUT I tested one more thing: I saved the particle as .prt and reopened in a PRT-Loader. Then inspected the data via a Magma Modifier and the Krakatoa Debug Mode. This confirmed my expectation! The particle is at the expected position, but why does Box 3 work with different values???

Screenshot: http://puu.sh/dFsrD/f6250c9468.png

I really hope for your help! How is speed and position calculated?
Matthias

[JohnnyRandom]

If you are looking at that type of control you need to mind your Priority and Execution Orders. If I switched off History Dependent (this isn’t necessary since you do not need, in that example, an order of execution, writes, and reads for other channels/functions) and switch to Post it works as expected. Meaning you want the data sample to be read and displayed at the very end of the integration step not at the beginning or middle.

[Nickolay411]

yes you need to mind those execution orders!

Normal order will usually mean it will read in between integration steps and give you the exact number at the exact moment the data is calculated. I don’t know how else to describe it haha. But it’s precise and correct at that given time.

Which is why some people get confused and think box 3 is spitting out wrong values…or it’s some kind of bug. Not the case.

The image i had sent you over at the orbaz forum you’ll see that i was very careful about each sub output and its execution order.

[dewey1916]

If you are looking at that type of control you need to mind your Priority and Execution Orders. If I switched off History Dependent (this isn’t necessary since you do not need, in that example, an order of execution, writes, and reads for other channels/functions) and switch to Post it works as expected. Meaning you want the data sample to be read and displayed at the very end of the integration step not at the beginning or middle.

Oh, thanks!
That’s logical! But I don’t understand a few things with the Priority and Execution Orders (Yes, I already read that part of the Box 3 Documentation):

1. What is the Priority Order for? I mean: All outputs with the same Execution Order get the same data from the SubOp’s above them -> When one Output with Execution Order 1 (and Priority 1) edits the position and a new Ouput edits the speed based on the particle position but has the same Execution Order 1 (so he should deal with the Position the particle had before it was edited by the first output subop), what is the Priority for? They both deal with the same Data - so why does they both have a priority?

2. What happends, when PRE/NORMAL/POST are in a conflict with each other? Example: One SubOp is on PRE with the Execution Order 3 and a new one is on POST with Execution Order 1. When I trust the execution Order the 2nd SubOp is done before the first SubOp. But the first is on PRE, so it should be calculated before the other one?

These are the two things I don’t understand. I hope you can explain this a little bit better to me
Matthias

[dewey1916]

yes you need to mind those execution orders!

Normal order will usually mean it will read in between integration steps and give you the exact number at the exact moment the data is calculated. I don’t know how else to describe it haha. But it’s precise and correct at that given time.

Which is why some people get confused and think box 3 is spitting out wrong values…or it’s some kind of bug. Not the case.

The image i had sent you over at the orbaz forum you’ll see that i was very careful about each sub output and its execution order.

Thank you too !
I also postet my new question about the Execution Order and Priority above!

Matthias

[JohnnyRandom]

This is a pretty grey area, I am only writing it as I understand it from my experience. If it is incorrect hopefully someone will jump in.

Oh, thanks!
That’s logical! But I don’t understand a few things with the Priority and Execution Orders (Yes, I already read that part of the Box 3 Documentation):

1. What is the Priority Order for? I mean: All outputs with the same Execution Order get the same data from the SubOp’s above them -> When one Output with Execution Order 1 (and Priority 1) edits the position and a new Ouput edits the speed based on the particle position but has the same Execution Order 1 (so he should deal with the Position the particle had before it was edited by the first output subop), what is the Priority for? They both deal with the same Data - so why does they both have a priority?

It should deal with data according to the order. I honestly do not have a case scenario for this that would visually explain it. Frankly speaking I just put them in a logical order, one that I think makes sense. I know that really doesn’t explain it. I just don’t know what else to say. It should be the evaluation order of each branch (Input to Output) during each phase (Pre/Normal/Post) of the integration step.

2. What happends, when PRE/NORMAL/POST are in a conflict with each other? Example: One SubOp is on PRE with the Execution Order 3 and a new one is on POST with Execution Order 1. When I trust the execution Order the 2nd SubOp is done before the first SubOp. But the first is on PRE, so it should be calculated before the other one?

Simply put what channels you are trying to manipulate may not work. There is no way to really debug your channel priorities, apart from the Output Order display and in you head.

So image this, you want to store the particles current position when it enters an event, then manipulate that position. You would do something like:
Normal: (Writes Data after it has been acquired during the Integration Step)
Group1 – Std Input(New In Event)->Std Input(Position)->Output New(InitialPos)

Post:(Reads Data at the end of the Integration Step)
Group 2 – Input Custom(InitialPos)->Function((V1-InitialPos)SomeFunction(V2-SomeVector))->Output Std(Position)

In that example you would not be able to properly execute Group 2 before Group 1. Group 1 needs to write channel data before Group 2 because Group 1 contains prerequisite data for Group 2.

[dewey1916]

This is a pretty grey area, I am only writing it as I understand it from my experience. If it is incorrect hopefully someone will jump in.

It should deal with data according to the order. I honestly do not have a case scenario for this that would visually explain it. Frankly speaking I just put them in a logical order, one that I think makes sense. I know that really doesn’t explain it. I just don’t know what else to say. It should be the evaluation order of each branch (Input to Output) during each phase (Pre/Normal/Post) of the integration step.

Simply put what channels you are trying to manipulate may not work. There is no way to really debug your channel priorities, apart from the Output Order display and in you head.

So image this, you want to store the particles current position when it enters an event, then manipulate that position. You would do something like:
Normal: (Writes Data after it has been acquired during the Integration Step)
Group1 – Std Input(New In Event)->Std Input(Position)->Output New(InitialPos)

Post:(Reads Data at the end of the Integration Step)
Group 2 – Input Custom(InitialPos)->Function((V1-InitialPos)SomeFunction(V2-SomeVector))->Output Std(Position)

In that example you would not be able to properly execute Group 2 before Group 1. Group 1 needs to write channel data before Group 2 because Group 1 contains prerequisite data for Group 2.

Thank you really much, Johnny!
I will play with this for a few days and come back to you

Merry Christmas to all of you (In Germany it’s already 2am).
Matthias (:

[Nickolay411]

This is straight out of the help file:

Also, the Execution And Priority Order group also has Pre/Normal/Post radio buttons. This option defines the processing order on a higher level. If it set to Pre then this output is done before any operators in the current event are executed. If it is set to Normal, then the output suboperator is executed in the regular order, in-between the other operators in the same event. If it is set to Post then the output is processed after all operators and all tests in this particle system have finished their jobs for this integration step.

There are also some interesting things you can do with the normal and post steps.

Let’s say you output a speed of [0,0,0] on a normal step.

Then you output a speed of [0,0,1] on a post step.

The particles will get the velocity of [0,0,1] but since it is post step and you’ve got an output speed in the normal step, the normal step will actually rewrite over the post in the next integration step.

What does that mean? Well the particles will inherit a velocity going upwards but they won’t be given a chance move.
This is great if you DON"T want to change the speed of your particles but to elongate motion blur by the ‘velocity’ sorta like how we inject velocity using magma flow

[dewey1916]

This is straight out of the help file:

There are also some interesting things you can do with the normal and post steps.

Let’s say you output a speed of [0,0,0] on a normal step.

Then you output a speed of [0,0,1] on a post step.

The particles will get the velocity of [0,0,1] but since it is post step and you’ve got an output speed in the normal step, the normal step will actually rewrite over the post in the next integration step.

What does that mean? Well the particles will inherit a velocity going upwards but they won’t be given a chance move.
This is great if you DON"T want to change the speed of your particles but to elongate motion blur by the ‘velocity’ sorta like how we inject velocity using magma flow

Thank you for all these tipps!
My current flow for the ‘SpawnByTravel’ looks like this:
http://puu.sh/dJmV1/c6f4e803f8.png

And the DataOp loops like this:
http://puu.sh/dJnmv/d6d394673a.png

As you can see, I have calculated the SpeedVector in ‘Post’ to get the ‘real’ speed in the end of a frame (and I can place the DataOp everywhere in the flow - before or after the speed op), but had to use "Normal’ for the calculation of the Integration-Step length, because it returns 0 if it’s calculated in ‘Post’.

Im pretty happy with the result of the operator!
The only strange thing, is the fact, that the ‘Condition’-subop, which triggers the Spawn, somtimes has strange values (When the integration step is not a full frame). I made it ‘Not’ smaller than the specified value, since the particle has to spawn a new particle if the Travel-Distance is greater OR EQUAL than the specified value…

Than it looks like this:
http://puu.sh/dJo2L/f04267ef2d.png

Value one: 10, value 2: 10. Condition is: Is value 1 smaller than then value 2? TRUE???

That’s why the particles have a little offset…
I don’t know why this happens (maybe something with the pre/normal/post again?). Maybe someone of you guys can help

Have some nice Christmas-Days!
Matthias

[dewey1916]

This is a pretty grey area, I am only writing it as I understand it from my experience. If it is incorrect hopefully someone will jump in.

It should deal with data according to the order. I honestly do not have a case scenario for this that would visually explain it. Frankly speaking I just put them in a logical order, one that I think makes sense. I know that really doesn’t explain it. I just don’t know what else to say. It should be the evaluation order of each branch (Input to Output) during each phase (Pre/Normal/Post) of the integration step.

Simply put what channels you are trying to manipulate may not work. There is no way to really debug your channel priorities, apart from the Output Order display and in you head.

So image this, you want to store the particles current position when it enters an event, then manipulate that position. You would do something like:
Normal: (Writes Data after it has been acquired during the Integration Step)
Group1 – Std Input(New In Event)->Std Input(Position)->Output New(InitialPos)

Post:(Reads Data at the end of the Integration Step)
Group 2 – Input Custom(InitialPos)->Function((V1-InitialPos)SomeFunction(V2-SomeVector))->Output Std(Position)

In that example you would not be able to properly execute Group 2 before Group 1. Group 1 needs to write channel data before Group 2 because Group 1 contains prerequisite data for Group 2.

If you want you can take a look at my current flow
I posted it above!

Matthias

[JohnnyRandom]

np, glad to help

Cool thanks for posting it, will check it out tomorrow!