Conversion should be handled outside Krakatoa. And 3ds max. And your local machine.
Let the conversions happen via commandline using Deadline on the farm, and just use the resulting PRT files in Krakatoa.
Seems like the most straightforward thing.
Though industrious people COULD utilize the PRT Source and implement their own particle format reader in 3ds max.
Agreed! PRT should be the one that they all should choose to use (as mentioned it is open already), it is production proven, been in use for years now, and yes it is somewhat awesome!
hi i am not completly sure if its a suggestion for 2.0 or i just dont know how to do it, my goal is to have a background image rendered behind the particles like putting an image in the background slot when doing a scanline render, this would be really usefull because if you want to use a background for the particles in post which is not just 1 plain color this happens:
you get this color fringing if your background has different shadings, would be really great to have an option right beside the override background color feature in krakatoa to also chose a image or image sequence as background, if it would just use the regular environment slot you would loose the option to have env. reflections at the same time.
Render on black and composite additively. Or render on black, divide by alpha, color correct, and composite subtractively. It is possible to render on a color and remove it, too, but it doesn’t get you anything in Krakatoa.
hmm in compositing you can get close to how it would look with the actual picture rendered behind the particles but it will never be the very same, as soon as you modifiy the alpha you loose data, and these subtle differences really do make an impact on the viewer
Then you’re doing it wrong. 
There’s nothing that Krakatoa CURRENTLY can do that would not be EXACTLY duplicated by the composite.
EDIT: In fact, we’ve tested this before, after our wishlist item of “baking out the shading” was implemented. You can render the full Z scale in one go in Krakatoa then render every Nth Z slice. In the composite, you can over the N slices in order and get an image that is EXACTLY the same as the full Krakatoa render within just a very small precision error (less than .0001%, less than can be seen by the human eye or displayed with any common technique).
Matthias are you talking about lightwrap on particles from background?
Which isn’t to say that a 2.0 version of the PRT format might not be needed. I was thinking yesterday that I would really like it if there was a means to store arbitrary metadata in a PRT. The PRT Loader would allow us to read in the metadata via maxscript and we could do whatever we wanted with it. We could store anything, like the source of the PRT, the owner, the version, the deadline job/task that made it, etc…
What other changes to the PRT format would be desirable?
Metadata is indeed the major feature that was missing from PRT 1.0. Pretty much everything could be stored that way, including the things I mentioned like coord.system type, units/scale factors etc.
Considering the size of PRT’s, you could probably store the entire max file that made the PRT in the PRT without noticing.
Whoops. I missed where you already had mentioned that. Sorry for restating it.
@ jhjariwala: ye i think lightwrap or i say color fringing, the effect that occurs for example when i want to comp a gradient behind the alpha croped raw rendering rendered on a solid color, but since Chad explained there is a way to achieve that using the render elements i will have a look at that, maybe there is a page in the documentary explaining that ?
anyway i think the option to load a image sequence to render upon as background would just has advantages, since you directly see the result when doing a test render + it would be very easy and intuitive to use, 2 qualitys that make me love krakatoa so much 
Some info sure would be nice but to store it in every frame? seems a bit redundant, of course a boat load of metadata would only consume a couple k if that, compressed bytes. Something like a base .xml file in the sequence folder, you wouldn’t need anything but notepad to at least read it then, or also edit it . I guess storing something in just the first frame, I would probably be less likely to loose it then. 
doesn’t of course have to be .xml, just for example sake, could be a .txt or a .F for that matter 
Either way it is a good idea:)
Well, just like the metadata in an EXR or RPF, you have no assurance that A) the metadata exists anywhere else and B) that it isn’t changing per frame. And reading the data isn’t hard, anything that could read PRT’s would probably add functionality to read out the metadata too.
Lightwrap is the effect of FILTERING colors from the edges of a matte, FRINGING is unfiltered mis-compositing. They’re different effects/artifacts.
The problem with including the background for me is mostly about exposure. How do you expose and color correct the Krakatoa render with the background in there? You can’t unless you remove the background, which is extra steps compared to just rendering on black in the first place. And it’s harder to light and expose the scene correctly just in 3ds max. The standard max VFB is smothered in suck, it’s way too hard to get an appreciation of the full float color data in there.
Removing the colored background isn’t hard, you just invert the alpha, multiply by the cleanplate/background, and subtract the result from the original precomped image. As long as you do it at high precision, you won’t get any artifacts at all. And when you over composite it back on the cleanplate, it will look exactly like what you would get if you rendered over the background in Krakatoa.
Something that would be nice in 2.0 is any improvement in disk I/O, notably read speed.
We just benchmarked loading a small (1.5GB) PRT off of the gigabit network and off a local Fusion-io Duo (RAID-0). The difference was ~10% on the “Retrieving Particles” portion of the render.
I know that some of that is decompressing the PRT’s, but I can’t tell how much. Does seem that it isn’t multithreaded. If I’m loading part_N_of_12, you’d think I would be able to keep 12 threads busy, right?
Mr. Bond was talking about such improvements in the interview he did with FXGuide, if you did or didn’t catch that, specifically about fusion IO based stuff. Sounded interesting. I really like the IO read/write numbers I have seen from their devices, It is just the price tag that is the killer for me anyway.
BTW Sorry to go OT but how does that fusion card fair with other IO ops? Box#3 disk cache, FumeFX, if you have tested that (doesn’t seem you guys would use that much if at all) Realflow, or compositing packages
Just had a thought about PRT volume, so this thing is built upon a voxel grid right? So if one was to have say an adjustable bounding box so you could scale larger than the pick object (if it happen to be animated) you would be able to write IDs for every particle, couldn’t you? basically id for every particle in the sequence of the grids fill order. No one says a live particle has to start with an ID of 1:D Is this at all possible?
As a selectable option of course…
We tried it with Fusion. That was pretty sweet. Didn’t try it with anything else with 3ds max, as Krakatoa is the only I/O bounded tool we use with max. It’s faster than the OCZ IBIS, but the speed difference may not justify the cost.
The option of not culling to a levelset threshold, but doing so afterward in a KCM is on the wishlist. There have been at least 2 threads on the subject around here.
So are we sure that Krakatoa is I/O bound if a FusionIO is providing only 10% speedup vs. network? It sounds like it is CPU bound due to the unzipping of data… Or did I misunderstand your previous post?
Yes, in theory we could use the address of the voxel (and the number of subdivisions / particles per voxel) to generate an ID that remains the same for the same location in space.
The other thing you really need is the ability to remove the ID from the list of already born particles once the particle is deleted. So if a particle is gone and its ID comes up again in the next file, it should be possible to optionally create it again. This way, you could delete those particles that are not in the file anymore and then create them again when they return. As I mentioned on CGTalk, I wrote a prototype TP loader and added that feature with great success. Just need to get Darcy to modify the PFlow operators…
The third thing would be to allow the PRT Volume to be picked as PFlow Birth/Update source directly without saving to disk.
There might be also a completely different approach you will learn about soon enough 