There was some discussion about this and it birthed the implementation of the debugger in the Channel editor.
I am curious, is it possible to have a separate utility akin to the PRT loader File Sequence manager that would in essence populate a spread sheet with the chosen particle data cahnnel for say Nth particle(s) at a selected frame, or a single particle for an animation range? Or even more simply choose the first particle born, or Nth particle, understanding that you have literally up to billions of particles it would be outrageous to consider listing data for all of them.
With something like this, it seems for me anyway, that it is easier to manipulate the data once you can see what the data actually is. Positions, speed, color, ect. are one thing and can be read easily through box#3 if the system is born with Pflow, some others though it is anyone’s guess, unless you are really familiar with the originating system. It gets a little frustrating guessing what is in the channel, I understand all of the values, but it is left to my imagination to some extent as to what the originating data actually is.
Thoughts? Would this be difficult? Pipe dream? or…Just plain silly forget about
It is possible and I have suggested it a couple of times, but:
*You can dump every Nth particle to a CSV file and read it or write a simple script to load that into a ListView control.
*To implement it correctly in MAXScript including showing PRT and BIN data, I would need an interface to read PRT streams directly which has been on the ToDo list for a looong time but has been pushed back several times already.
*The KCM should allow better debugging in the future where instead of sending user-defined values through the flow you could specify which particle(s) to send and could get a spreadsheet of all values it passes through (this is also on the Wishlist already as “better debugging in MagmaFlow”)
*We have an in-house anything-viewer (image sequences, geometry caches, level sets, particle files etc.) where you can see your particle cloud in 3D and click a particle to display all its channels and data, so we never felt the pressure to implement something for the public version of Krakatoa.
If we find the time to implement a MAXScript interface for reading PRT streams, I will surely write an editor the same day.
I’ll look into the CSV script approach for sure, that should be interesting haven’t scripted in a little while.
These will be welcome additions for sure, I certainly see the better debugger as a foundation piece for sure, as I had stated, you can derive some values with it easily and others…well I guess that is why you lucky ones have a “in-house anything-viewer”
Thanks for the info, Bobo.
Surely going to take me quite a bit longer than that
Are we just talking inspecting the PRT files themselves, or the PRT Loaders? Or the Nth particle seen by Krakatoa (of all the particle sources in a scene?)
If it’s just the PRT files themselves, I’d be fine with just a commandline PRT processing tool. Wouldn’t need 3dsmax at all, just some commandline app that can read out stuff like that.
And of course once that’s in place, we can wish for more switches, like ones that can concatenate PRT’s or split them, or remove a channel, or randomize the order of particles, or reorder based on a channel, or convert from PRT to CSV and back, etc.
Would probably make non-3dsmax-users happy too, you could have your 3D app spit out some CSV’s, then have a Deadline job that runs the commandline tool to convert them to PRT’s with proxies.
First, we will provide an Interface to read from a PRT file (the counterpart to the one for writing we already have). This should be trivial.
Then, we want to provide an Interface to read a Particle Stream the way Krakatoa sees particles inside of Max. This would allow you to “see” particle data from PRT Loaders, PRT Volumes etc., possibly from the PCache after you render a frame and so on. This is harder to implement, so we wanted to start with the easier one.
Using the read and write interfaces, you could theoretically read particles from a PRT file and write to another, but that would be painfully slow since MAXScript is not very fast at looping.
So a function (or better a library of functions) where you can pass arguments like input file(s), output file, every Nth, Sort, Concatenate, output channel list etc. would be a separate implementation. We could use it to expose tools for proxy creation, but you would be free to implement your own based on that.
We could expose that as a command line utility too, but I really want to have everything MXS-accessible for obvious reasons.
BTW In my excitement, i failed to ask “tasty lunch”, where or better put what? since I there is only the slimmest of chances that I may get to try it I am still trying to find a note worthy lunch spot here at home, tougher than it seems for sure
I am still trying to find a note worthy lunch spot here at home, tougher than it seems for sure