Connect to valid dynGlobals node

[hansesurfer]

I need to connect my custom node to the dynGlobals node.
Unfortunately, its possible to duplicate that node.
So there might be 2 dynGlobals nodes and only the original one is valid.

How can I find out which dynGlobals node is the valid one?
I don`t want to force the user of my node to select the valid dynGlobals node manually
and then connect the nodes with a script.

Moreover, I cannot connect the nodes via node name, as the name of the dynGlobals
node can be changed.

What I need would be a attribute which says: hey this node here is the original dynGlobals node  ;]
But, of course this attribute does not exist..

I`m open for mel or API solutions..

Any idea?

[joojaa]

There can only be one in charge, true. The first on the list is in charge to my knowlege you can find it:

dynGlobals -q -active

 Anyway this may be bad deasign on autdesks part, since the tricky thing is what happens when user imports a scene with your custom node connecting to something that should not be connected to? Your settings just got lost.

So not only do you need to enforce the rule you also need to do gimicks, chekking imports and referencings to be sure.

PS: editted the stuff a bit as i found teh definitve answer

PPS: why do you design stuff thats against the design of maya? Just gets you agravated

PPPS: you are not connecting out the over samples value to your node now are you?

[hansesurfer]

dynGlobals -q -active
aaah, nice, thanks Joojaa!

PPS: why do you design stuff thats against the design of maya? Just gets you agravated
Uh, why is that against the Maya design?

PPPS: you are not connecting out the over samples value to your node now are you?
Yes, thats what I do ;]

[joojaa]

Uh, why is that against the Maya design?

es, thats what I do ;]

Bingo theres the design mistake. Or to be honest

outputForce = 10 * pow( 25, 2 ) = 6250.

is against the design. You just blasted yourself trough thinking you understood whats going on. Ever wonder how maya does dont need to refeer to the dynGlobals?

outputForce is in NEWTONS*. Your not supposed to calculate the fractional effect yourself. 1 newton over 0.2 seconds is a velocity increase of 0.2 m/s. The output force is not tied to framerate force is not dependent on time . Please note maya MAY not allways take even steps, when it colldies it may actually go back in time to refine the solution. Well factually maya does not, however the implementation IS open for it. So you can not rely on the step size to be constant.

Anyway its the dynamic engines job to actually integrate the factional result. By taking the entire thing into your won hands your now forced to do all of the job associated with the dynamics engine. But you may actually want to convert data to fps reason but you only need to manage input, even with dual steps it doesn't change the solution. Dont mix this tthinking it just means you input unit differs step size does not matter.

Ok so the fractional stepsize may be important to you because you might want to integrate something inside your node. Most nodes dont need this, the field just has a magnitude and thats it, you just give the force in newtons and maya will figure out how much to move. However if your doing some integration you have a input attribute in your node:

static MObject mDeltaTime

that will keep tabs on the size of your time step size.

Now your a unfortunate victim of reading a bad example without thinking deeply.

• its easy to proove, make a gravity field and attach it to something and querry:

getAttr gravityField1.outputForce[0]

and youll notice that irrespectively of my timestep/framerate the value is 0 -9.8 0 and indeed the object moves 9,8/2 units in one second. which is correct. PLEASE NOTE: Im not kidding when i say that the linear unit in maya is plain wrong. The default unit of cm is NOT CORRECT, the dfault unit is meter some idiot just has renamed m to cm for some blooper reason. Theres NO DESIGN WHATSOEVER behind in maya to acctually correlate with the claim in preferences. Thus setting the unit to ANYTHING other than cm is even more wrong.

So if somebody claims something and all evidence points to contrary then the claim is wrong no matter how much yud like to belive it.

PS: I suspect that your trying to actually drive velocity, yiu can do that then you need the step size as velocity is the integral of force.

[hansesurfer]

I see what you mean.
Seconds would be better. I will think about that.
Thing is that I have another timeUnit layer implemented ( like picoseconds per "real" seconds ),
and the basis for all conversions is in frames ( picoseconds/frame ).

I know the mDeltaTime.
Its the child of the mInputData compound.
And when I try to get the value from the connected particle I get the value from the last evaluation cycle. And thats worthless as I need the current deltaTime of course.

So I have to create my own deltaTime.
Unfortunately, when the deltaTime is negative, the particle node does not ask for data and the fieldNode is not computing.
Thats why it has to be done in a timeChanged callback.

Normally, the callback is called once for every time change.
But when the oversampling is not 1, the callback is called twice before the first substep: once for the whole step and once for the first substep.
And that makes the whole trouble which I am in.
And thats why I need the data from the dynGlobals, which tells me if the oversampling is 1 or not 1.
From that I can adjust the behaviour of the callback.

I thought, a connection to the dynGlobals node would be the solution.
But, hehe, its not.
When going back in time the fieldNode does not evaluate and so I don`t get the updated oversampling value from the dynGlobals node.

I hate that but it seems I am forced to ask for the dynGlobals value via a mel call in the callback....

[joojaa]

I get the value from the last evaluation cycle

huh? Yes true the first evaluation has no timestep! Because first frame begins at its 0. So how do you know the data is old?

when the deltaTime is negative, the particle node does not ask for data and the fieldNode is not computing.

yse thes by design simulation can unfortunately not go backwards, however wouldnt it be easier to make a time input slot in your field, that would cause it to trigger and offcourse delta time is then the time input - last compute.

This way your not dependent on the dynGlobals node, beseides time is one of those infeered connections so if you name it right you dont even need to connect it it implicitly does connect to global time unless overridden.

PS: you trying to implement a particle cache of sorts?

[joojaa]

Just scrub the time slider very fast forward. Then you get different delta times.

Yes you should maya doesnt calculate all the frames in between so this is important if you must integrate something thats kindof the point. Like i said theres no guarantee that maya takes the amount of steps you assume it does.

PS: sorry i pressed teh worng button and your post got lost.

[hansesurfer]

ooops   :]

okay I wrote:
you can see that the particle node gives you the deltaTime from the last and not current evaluation when you scrub the time slider forward very fast. When you then print out the deltaTimes in the fieldNode you see its always the old ones, not the current ones.
And I wrote that I dont know if Im allowed to talk about the project. I will have to ask before.

[hansesurfer]

beseides time is one of those infeered connections so if you name it right you dont even need to connect it it implicitly does connect to global time unless overridden

Hey Joojaa,
that is totally weired!
It works without a connection.
I always wonder how you can know all this things, hehe....(...)...

Very funny. Are there some others attributes which work without a connection?
edit: ahh, of course all those attributes for rendering do not need a connection.
But why then do nodes connect to the time node when they can get the currentTime data without that connection?
( don`t tell me its performance reasons )

However, the problem cannot be solved with that.
Its still the case that when I go backwards in time the node does not evaluate and thus the callback gets no new data of the oversamples value or the currentTime.

The idea is the following:
when there is some bad user guy who goes backwards in time, then changes the oversamples, then continutes to go backwards in time and then goes forward, my node cannot know whether the oversamples changed which will lead to wrong calculation results in the callback.

So, if there is just no other way I will have to use mel in my timeChanged callback to ask for the value, gngngngngn.

[joojaa]

I always wonder how you can know all this things, hehe....(...)...

Well unlike other people I dont use my time for just work I reserve prefeerably half of my day for play (even if its my own time sometimes), so i have a LOT of time to experiment.* Anyway this is documented, ableit very subtly. Having read the manual cover to cover each maya version really pans out. See the number one thing to read is the NODE documentation, yes even if you plan to ditch maya nodes and make all of your own. Wierd huh? So what you do is you mimic how the built in nodes work, theres a few attributes manily shading attributes that maya fills in just as long as you ask for the data. They are implicitly connected things.

look in the node docs.

when there is some bad user guy who goes backwards in time,

hmmm.... you know theats terribly heavy, whet you do is you enable cache and then going back look up in the cache, then whan going again forward detele the future cahce and recompute. You can force maya to recompute atll the missing frames even with just mel, its quite efficent, just as lomg as you turn the viewport off.

*creativity happens when your relaxed, work happens when you need to. So you need to combine the two in right propotion.

[hansesurfer]

Finally, I got it working.

The callback checks whether the compute was called after it was called itself. That way I can adjust the behaviour of the callback. It the compute was not called, it is called twice and thus we have subframes.

Moreover, I found how to adapt the output force to subframes:
you just have to divide by the deltaTimes value. Actually that seems a bit strange to me, but thats the way Maya works.

Imagine the particle node has a force of 100 in it. In case the overSamples is at 2 ( deltaTime value is 0.5 ), we have a effective force of 50 per subframe.
If you want to delete that force you have to add 100*2 = 200.