Is there a good way to evaluate something at a different time for the history dependent Embers?
Like I want to get the velocity of an object, but that’s not calculated for me, so I figured I’d just get the position in the previous frame and compare to the current. Problem is, I don’t know how to reference that. I’ve got workarounds, but I wanted to know if there was a better means of doing this.
Maybe a Delta operator that would compare the current and the previous timestep? Add a time input for PropertyQuery?
Have you tried a inputScript node? You could try the At Time context
ex. (at time (currentTime - 1f) $someObject.pos)
Of course it doesn’t iterate through the particles it would just return that value in a channel for every particle but you could use it to subtract from.
It returns proper values in the PDV but not the new debugger
BTW Chad I did notice you asked “is there any good way” AFAIK this is the only way BUT I suppose you may be able to write out another PRT offset -1 frame, use the inputParticles and run against that, maybe? Would that work? Then again you did say you have workarounds.
Some sort of time offset node would be cool, haven’t we asked about something like this for a long time, is this, can it be, a “Wishable” item?
It can be and I think is. I’ve been hesitant to go after this one though, since I can feel it in my bones that it will open up a whole new world of 3ds Max crashes to desktop and the like. I find those embarrassing.
The Particle Data Viewer always shows the RENDER state of the particles.
The Debugger on the other hand shows the actual viewport state of the particles.
If you disable the PRT Loader’s Viewport display, the Debugger will show no particles (as in the screenshot, note all the N/A for Min/Max/Mean in all columns), while the PDV will show correct data if render time particles are on.
In my tests here, the InputScript node shows the correct value when particles are enabled in the viewport and Debugger is on.
Sorry Chad, I am jacking your thread, last post from me I will start a new one if necessary
“User error” You are probably correct
Hmm I do not understand this is pretty much what I did but it is working, in max2012 KRK 2.1.3.47998
Whilst discovering my user error I noticed something with debugger too. More like A wish I guess, If you have two outputs the debugger always seems to choose the first output. Is it possible to select which data stream we want to debug?
Here is the simplified example of what I tried above (but working), I will try this at home on the same build/version as above, as I am not exactly sure if they are the same (above is max2013 but I don’t know which version of Krakatoa, I am pretty confident it is the latest beta build) max2012_KRK_MgmInputScripts.rar (22.3 KB)
I am not sure I see the problem.
The only thing that is kind of confusing in the new Debugger is that the OUTPUTs themselves are NOT listed in the Debugger.
So in your case, you have two Outputs, one called SomePosition and one called SomeDistance. Neither is listed in the debugger, but you know their values because you see the nodes that are outputting to them - 6:Subtract contains the value going to SomePosition, and 1:InputScript goes out to SomeDistance.
So my wish would be to also include the (redundant) Output values so it is easier to follow what goes out where. But BOTH sub-flows are correctly evaluated and displayed in the current Debugger in 2.1.x, just without the actual Output nodes (they used to be there in the old Debugger back in the day).
LOL “problem” is very relative at the moment. This is the same setup I used as above, it should show values, yet it did not. I wont know until I get home, it is using a different max version.
In my haste this morning, I failed to notice that the debugger was listing all of the nodes, I could have easily counted them I suppose. Would it make sense to have some sort of switchable/all filter? I mean it would make sense to me, my stuff is fairly simple but like Chad or yourself, of whom use more complex mutli-teired flows.
Chad, hmm, yeah so you would select the stream and see the nodes listed in an order of ascension through the flow in teh debugger dialog and not by the nodes objectID number, so instead of selecting a dozen nodes you simply hit the input or the output. It is very functional the way it is, that would just be a faster thing.
the Krakatoa debugger just reads N/A? I would think that it would list the vector that I am grabbing.
