How do I start the debugger from a .p file?

I'm using the node now to trigger a motion curve in the nodal motion editor.
This different behavior in node editor type is a good lead to indicate where the problem lies I think. In the displacement editor it does work but in the nodal motion it doesn't. Does this mean I can assign values to instance data in the nodal displacement editor but not in the nodal motion editor? Because I think I am actually changing instanced data in evaluate. So you are saying things like this inst->v_frameOffset = timeinfo->frame; are not possible or am I misunderstanding what you mean?
 

Sensei

TrueArt Support
In Evaluate() you have input parameter LWInstance instdata or so,
you don't modify it....
I can't think of situation when you need to modify LWInstance from Evaluate()..

Evaluate() can be called by Surface Editor previewing routine, by VPR routine, by regular renderer routine, by LWSN..
Some of them from multiple threads,
some of them mixed each other..
You can get Evaluate() from preview, from VPR, and F9, nearly parallel..
 
Isn't one situation when you would want to modify instdata one where you would store an input value or when you want to cache something?

So this snippet down here is a bad idea or not possible you are saying?

XCALL_(static void)
Evaluate(void *data, LWNodalAccess *na, NodeOutputID out, NodeValue Value)
{
Trigger_p inst = (Trigger_p)data;

inst->v_frameOffset = 0;
 

Sensei

TrueArt Support
Isn't one situation when you would want to modify instdata one where you would store an input value or when you want to cache something?

Ah, right. Cache (per-pixel, per-3d vertex), is example when you want to modify instance data.
But you can forget about using it in LWSN, random frame F10, render queue, etc.
without making baking functionality (store cache in external file, which LWSN (inside of Evaluate()) will just read (so again Evaluate() won't be storing anything)).

So this snippet down here is a bad idea or not possible you are saying?

Yes, because it does not bother about different rendering states (preview/VPR/full render), and does not bother about multi-tasking...

Node learns which mode it's in, inside of Init( int mode )
LWINIT_PREVIEW,
LWINIT_RENDER

Imagine:
1st render node in LWSN mode is rendering frame 1, NewFrame() receives LWFrame/LWTime for 1st frame,
2nd node in LWSN mode is rendering frame 2, NewFrame() receives LWFrame/LWTime for 2nd frame,
3rd node in LWSN mode is rendering frame 3, NewFrame() receives LWFrame/LWTime for 3rd frame,
(....)
n-th node in LWSN mode is rendering frame n, NewFrame() receives LWFrame/LWTime for n-th frame,
This will happen simultaneously (or close to it)...
Render nodes don't communicate to each other machine..

What does this line anyway?
v_frameOffset = 0;
Where is used v_frameOffset later.. ?


Evaluate() can be called from multiple threads at the same time,
thread 1st is calling it, there is context-switch,
or 2nd core is calling Evaluate(),
and thread 2nd is calling it...
How can they both set v_frameOffset to 0?
If 1st set it, then f.e. incremented,
and 2nd thread will set it again to 0..
It'll be complete mess.
 
Last edited:
Ah, right. Cache (per-pixel, per-3d vertex), is example when you want to modify instance data.
But you can forget about using it in LWSN, random frame F10, render queue, etc.
without making baking functionality (store cache in external file, which LWSN (inside of Evaluate()) will just read (so again Evaluate() won't be storing anything)).

That's why I was storing a bool to check if this node was triggered so I could skip the part of code that resets all the stored values. Because it only resets on frames where it wasn't triggered it actually worked.


Yes, because it does not bother about different rendering states (preview/VPR/full render), and does not bother about multi-tasking...

Ah crap.

Node learns which mode it's in, inside of Init( int mode )
LWINIT_PREVIEW,
LWINIT_RENDER


Imagine:
1st render node in LWSN mode is rendering frame 1, NewFrame() receives LWFrame/LWTime for 1st frame,
2nd node in LWSN mode is rendering frame 2, NewFrame() receives LWFrame/LWTime for 2nd frame,
3rd node in LWSN mode is rendering frame 3, NewFrame() receives LWFrame/LWTime for 3rd frame,
(....)
n-th node in LWSN mode is rendering frame n, NewFrame() receives LWFrame/LWTime for n-th frame,
This will happen simultaneously (or close to it)...
Render nodes don't communicate to each other machine..

I know that's why I'm storing the point in time the trigger happend. I can use that value later to load back in to the node while it renders on LWSN.

What does this line anyway?
v_frameOffset = 0;
Where is used v_frameOffset later.. ?

I'm using that to zero out the reset point in time. For example when you change the animation and the nodes trigger condition is no longer true is resets.

Evaluate() can be called from multiple threads at the same time,
thread 1st is calling it, there is context-switch,
or 2nd core is calling Evaluate(),
and thread 2nd is calling it...
How can they both set v_frameOffset to 0?
If 1st set it, then f.e. incremented,
and 2nd thread will set it again to 0..
It'll be complete mess.
Ah yes that a big problem.

Could this be a solution? I could create a function that scans all trigger nodes in the scene (or just one.) This function could be called by pressing a button in the node itself or outside of it.
Just like dynamics and particles have their calculate button?
 
Top Bottom