I can see that the lighting channel is not supported in a direct FumeFX save particles to PRT (I thought I would at least try it anyway 
), it also crashes max with an --unknown system exception and opens the KrakatoaGUI.ms at line - 4408
BTW thanks for the visual indicator around the save/render particles section
A quick test shows that the saving of the Lighting channel is simply broken, even without FumeFX. Thanks for the report, we will look at this on Monday.
Anytime you use the RENDER button in the Krakatoa GUI, the MAXScript command “max quick render” is being executed (equivalent to pressing the Quick Render icon).
Should Krakatoa crash during the rendering, MAXScript will catch it with an Unknown System Exception in that line. If you were to use the real Render icon/button in Max, you would have crashed completely. I feel that the crash in max quick render gives you more chances to save your work before restarting Max, so I recommend using it…
As for the visual indicator, one of the results from that questionnaire we sent out was that a large number of users hit the RENDER button while in SAVE PARTICLES mode.
In fact, we wanted to split the saving as a separate process (both internally and in the UI), but this had too many implications - for example you could not send a render job to the network to simply save particles, it would have required completely new handling of Backburner/Deadline saving. So adding some color sign was the least we could do.
We also got a lot of people mentioning how the Matte Objects rollout was too far away from the Main Controls rollout. Now it is a) closer and b) a right-click away via the >Use Matte Objects button in the bottom of Main Controls, with the ability to jump back to Main from any other rollout with a single click…
Thanks to everybody for the feedback!
The Lighting channel crash was fixed today internally.
While looking at it, we decided to REMOVE the Lighting Channel from the list (it causes Darcy enormous pains to manage).
Instead, we added a switch to the Channels To Save section of the Channels rollout which reads “>Calculate Lighting And Copy Lighting Channel Into Emission Channel When Saving”. When you check this option, the Emission channel will be added to the list of channels to save if it is not there already and the content of the Lighting channel will end up in the Emission of the PRT. This way, all you have to do is load the file in a PRT Loader, hit >Ignore Scene Lights, enable >Use Emission and you should have your scene with pre-lit particles! (In the past you had to use a KCM to copy the Lighting channel into the Emission channel for every PRT or via a Global KCM Override).
Very nice So this should in reality save all the separate per light passes at render time, correct? I imagine it will still need to write a pass per light when saving to PRT?
This was the reason I was trying to use the lighting channel to begin with. Write the lighting once.
When rendering out smoke with the voxel engine, a scene with three lights was rendering a pass per light. I had hoped that this would cure that.
Ummm… But what happens if there is already an Emission value?
And wouldn’t the Absorption negate this? Like the Lighting value was filtered through the Absorption/Scattering, but when you load Lighting as Emission, it will still be passed through the Absorption again? Hmmm…
Please add a Shading channel. It would be so darn useful for stuff like this… Faster rendering, simpler compositing, etc. 
Just the savings in sanity would be enough, no?
In this case the Lighting value is added to the already existing Emission values. I think it makes perfect sense, because it is converting the previously reflecting particles into self-illuminated particles that produce the exact same scene if rendered without the original lights. Absorption doesn’t affect the light scattering on a particle or how it is emitted, only how light is attenuated as it travels through volume-filled space.
What exactly would a “Shading” channel do?
I see what you mean about Absorption. The lighting is attenuated by Absorption on the way “in”, then that’s converted to Emission which is attenuated by the Absorption again on the way “out” later. Totally cool.
The “Shading” channel was just an idea on how to speed up rendering and GREATLY simplify compositing.
See http://support.franticfilms.com/viewtopic.php?f=33&t=1462&p=7911&hilit=shading+channel&sid=b1411f729cd9c2900489de2e5dc54d1e#p7911 and http://support.franticfilms.com/viewtopic.php?f=33&t=2310&p=9399&hilit=shading+channel&sid=b1411f729cd9c2900489de2e5dc54d1e#p9399
Anyway, the idea is you store not the color, nor the lighting received, but the result of the shading. The color that get sent to the filter when rasterizing. Call it Shading so it doesn’t get confused with Color or the now defunct Lighting.
The minimum data needed to render anything would thus be the Position (3x32), Density (1x16), and Shading (3x16) channels. No lights would be needed, and no other per-particle information. This would reduce the memory overhead for the particles, so you could render more at the same time, and it would give you faster renders of non-shaded effects like DOF. Rendering out different resolutions would be trivial, as would “light as particle, rasterize as voxel”. You still have to sort, and composite as you do now, but that’s the same as if you loaded the PRT Color and Density channels and didn’t use lighting.
But who cares about faster rendering with less memory? The REAL reason I want to be able to bake the shading to a channel is for COMPOSITING. I could bake in isotropic shading, then add in specular. I could render some particles with Phong, and others with Schlick. I could cull particles without affecting shading. I could render a subset of the particles without affecting shading (viewport preview!). I could export the shading to ANOTHER renderer, like Fusion or Houdini or Flash. I could sample the shading from the PRT’s from inside of Pflow. It would be a TD’s “get out of jail free card” allowing them to disassociate the shading from the rasterizing. Like texture baking, but for particles.
And I THINK it would be simple. You do the shading as you do now, but you send the RGB result to the PRT saver code, not to the 2D filtering/rasterizing code. Or am I missing something vital?
The new lighting as emission seems to be the ticket. Compositing will now be trivial. Yay!
Oh, and tweaking the DOF is easier too. Nice.
What’s the suggested workflow for rendering unlit voxels?
If I have emission only, as with this new method, I need a light only to define the voxel plane orientation, but should I just make a light with 0 intensity? Or is there a better way?
You don’t need a light for Emission only, it uses Camera aligned planes when doing the Light independent pass.