Beta 1 of Krakatoa 1.5 has been posted:
I forget, what’s the rule regarding this beta and discussing/using outside this area?
Can we post renders on other websites, discuss with co-workers, use in productions, etc?
- Chad
I don’t see a problem discussing with coworkers or using it in production if you are so bold (we are actually using it a bit in production ourselves).
We showed some of the very early (a week old) voxel research at Siggraph, so that’s not necessarily a secret.
As long as you put a note it was rendered with a BETA version of Krakatoa, feel free to post renders, too!
Please don’t post rendering times yet because we still have a long way to go and hope to speed it up in future builds.
Please be sure to post links here so we too can enjoy the beautiful images! 
http://www.anatomicaltravel.com/research/wp-content/uploads/squishyvoxelbrain2-.mp4
Early voxel test, and the first KSW WSM test
I am not able to download it - I get a 80.7KB file which does not seem to play anywhere.
Yeah, the size is correct. It’s an h.246 compressed mpeg-4 file, didn’t want to waste bandwidth. Should play in MPC, VLC, or Quicktime. Interestingly, the voxel renders compress better than point renders because of they lack the high frequency noise. Oh, and it’s a really simple animation. I’ll pop it into a flash container if all else fails.
- Chad
edit: Try http://www.anatomicaltravel.com/research/2008/12/fun-with-voxels-squishy-brain/
Duuude, this is cool!
Can you provide some more info about the data, the workflow and in general what you did to get it working?
Also, any obstacles/problems/limitations you might have encountered that could be addressed…
It comes from standard pre-surgical CT. Our COO, actually. The CT data was segmented in Fusion, and I calculated normals from that segmentation. A PRT was then exported with density and normals, but it was pretty small, around 700 kilopoints. Good for a preliminary test. I also exported the density as a voxel array / 3D map.
Both of those were brought into 3ds max, one in the PRT Loader, the other as a map. In the PRT Loader, I remapped the density to map channel 1, assigned a material, and applied a gradient to the color and one for the opacity, both mapped to channel 1. I could actually get some decent feedback on the color LUT by clipping to a thin box in the sagittal plane. It doesn’t light, or show transparency, but you can see the color at least. I set up a single spot light and rendered points until the levels and shadows and speculars looked right, then switched to voxels.
I took the map of the CT data and extracted an isosurface from it, optimized it, then made a reactor softbody out of it. Dropped it to the floor. The spinal cord looked silly, so I vertex welded it off of the isosurface, then clipped the PRT Loader to that mesh. Export single PRT, import back again to a new PRT Loader. Put the KSW WSM on the new PRT Loader, set to rigid bind to 1 closest face. Exported PRT sequence, loaded that back in again, and did the final voxel render. Saved out exr, and did the float exposure, color correction, post-processing, etc. in Fusion.
Total work involved for me was about 3 hours. Render time, between the voxels and the WSM took a lot longer, but that’s understandable, and even if nothing gets multithreaded, it’s still something that could be done on the farm with Deadline. Memory consumption was less than 600MB, and probably 200+ of that is just 3ds max.
Problems? Observations? Hmmm…
- The KSW needs to default to Tesselation = 0, Count = 1. It gave me quite a scare when I first applied it because it seemed to be frozen.
- The presets… They need a preset! I wanted to save out the shading settings only, but to do that, I had to uncheck everything else, each time I wanted to save a preset. I might try RPManager later. There are too many commonly used shading options now, and I was constantly switching back and forth. Wasn’t an issue in 1.2.
- The multithreaded color/density assignment for the points is great. So fast now.
- The secondary floater is great too. Saved a lot of scrolling.
Thanks for the detailed report, very interesting!
Regarding your notes:
1: I am pretty sure Tessellation = 1 means no tessellation at all, but I could be wrong. If it does tessellate, that would be a bug. As for the Count, I would propose separate viewport and render settings, with the option to use the Viewport settings in the Renderer. We generally use 1.5 Radius in our work (because rigid deformations did not cut it for what we were using it – movie is due out in 3 months if you are curious to see), but viewport performance should be faster from the start. So we could default to Count 1 for Viewport and Radius of 1.5 for Renderer. We were also discussing the addition of “Deform: Always, Render Time and Never” radio buttons like in most Max systems that are slow, so you could turn off deformations in the viewports completely and still render ok. And then there is the huge slowdown mentioned in the notes when deforming PRT Loaders - with geometry deforming geometry, it is relatively snappy, but with Scripted Plugins it is slow. I have prototyped a GUI which turns the current Particle Sequence Manager into a full-blown floating PRT Loader UI, allowing us to remove any Scripted GUI from the PRT Loader itself. So you would have a “Dedicated Command Panel” controlling any PRT Loaders you would care to select, while speeding up KSW deformations. I am not convinced this will make it into 1.5 though.
2: Brilliant idea, will add selection presets to the Save Preset dialog so you don’t have to uncheck constantly. Another thing we could do would be another option to the Right Click menu of most controls that already support Factory/User defaults (almost all of them) - you could initialize an empty named preset and then add to it by right-clicking any controls in the Main Controls area and selecting “Collect to ‘MyNewPreset’”. So you would be able to quickly build a simple preset without leaving the Main Controls rollout. (An option to remove from MyNewPreset would be there, too).
3: and 4: Glad to hear they meet your expectations!
Btw, feel free to reveal what you used in your blog - there is already a question about it there! 
Isn’t “Deform: Always, Render Time and Never” the same as the enabled/enabledInViews/enebledInRenders lightbulb next to the modifier? That’s what I use to turn things on and off like that. Since there’s no visual feedback for the KSW weighting or other features that you might want to process without deforming, I don’t see the point in leaving the modifier on, but turning off the deformation.
For the scripted UI, are you saying the PRT Loader would just have an enormous “Edit” button that would launch a floating window with the scripted controls? If so, that’s fine by me. A bit weird, but would be solve the problem with a minimal amount of fuss.
The idea about the factory/user settings linking to the presets sounds most excellent, however, I think it should work on the groups (and maybe rollouts, though I’m not sure exactly on that). So you could set an entire group out to a named preset, or get a group from a named preset.
- Chad
Yes, but it is much harder to reach than a radio button in the GUI itself.
Sort of. It would be more along the lines of a PF_Source which has a button opening the global Particle View. Once the PRT Editor is open, it will let you edit any PRT Loader in the scene, not just the one that opened it. Of course, an icon on the toolbars or a shortcut could be used to launch the editor and edit PRTs without ever having to use the large EDIT button in their UIs. The PRT Editor draft already supports multi-column Command Panel style rollouts, actually even better than the Command Panel does. 
I don’t know if it is obvious, but unchecking the checkbox in front of a rollout is supposed to disable the saving/loading of the whole rollout anyway. So saving just Main Controls would require uncheking the main checkboxes of just a few rollouts. Or if you saved them all and want to load just the Main Controls, you could just uncheck all rollouts’ checkboxes you don’t want to load. Some buttons or RCMenus to do ALL/INVERT at Top Level (rollouts only) and per-rollout would be useful, too.
Not obvious to me, no. I assumed that checking or unchecking the parent would apply that state to the children. Oh well.
- Chad