Seperating Cache and Render

Krakatoa for 3ds Max
1

hi, will it be possible in future versions to seperate these two “modes”

often i switch to krakatoa only to cache particles, but not to render it, wouldnt the GUI load faster if i could just load the save particle option, and when i really want to render with krakatoa, use that to render, wouuld be nice if the caching particles would work on the fly

2

This has been on the ToDo list for a while, but it is a bit complicated.

  1. When the renderer was stand-alone in the very beginning, the “render” process involved saving all particles to PRT plus an XML file to describe the scene and call that external renderer. So the saving out of Max is the older method and has remained there since the very beginning.
  2. Saving particles on Deadline or even Backburner requires simply switching Krakatoa to save mode and sending a job. It would “render” to PRT. When we split the Saving and Rendering, we will have to jump through some hoops to get MAXScript jobs that save particles on the network because calling the renderer wouldn’t save.
  3. Some saving modes like the baking of Lighting into the Emission channel are technically a form of rendering where the final output just happens to be PRT and not EXR. The border between rendering and saving is even more blurred there.

That being said, we will start with providing a simplified “Save Particles Wizard” where you select a bunch of scene objects, click a button, pick a path, confirm (or change) the channels to be saved and off it goes without calling the renderer. So you could be in VRay and still save particles with a few clicks without switching to Krakatoa. Same for partitioning. We also want to be able to take a PRT Loader and dump to disk a Proxy version of its stream without having to “render” the scene which involves hiding all other objects, disabling Transforms to avoid double transformations etc. Once we have that, we will see how much we have to expand the UI of this new utility to give you full control over everything the current UI allows you to do, and we will be able to get some feedback from the users how to do it best.

3

Even in the context of running Krakatoa as is, a wizard that handles TM and channel modifications would be useful.

I don’t care about running Krakatoa as a renderer, the time waster/mistake opportunity comes when I’m setting PRT Loaders to the origin and turning off KCM’s. And then putting those all back as they were.

What’s the advantage of not rendering? Or being able to keep VRay running? I don’t catch the value there.

  • Chad
4

If you are running 1.5.1 which takes 5 or 6 seconds just to open the UI, and you are in VRay but want to save some PRTs, the process of switching to Krakatoa, setting it up to save and switching back to VRay can eat a minute and thus waste precious time.

I have most of the prototype code done now (except for one crash in Autodesk code I am trying to figure out right now), and it will be very easy to use in 80% of the cases. Just select some objects, call a macroscript, pick a save path and provide some more feedback about channels etc. It even asks you if you want to hide the selected objects and make a PRT Loader for you to replace them with the cached version…

5

Right, I know how it can save time, I’m just saying, how often are you messing around with PRT Loaders, feel the urge to cache, but are not running Krakatoa? I’ve never been raytracing some teapots and said “oh hey, I probably could do with a pre-lit PRT Loader right about now”. Not saying it can’t happen, I just don’t see where that comes up a lot.

  • Chad
6

I assume it comes up when people don’t RENDER in Krakatoa at all but just cache particles for other reasons, for example to load into PFlow and render as geometry there. At least in the case of phizikl who is dealing with particles coming from a 3rd party application, I can imagine the rendering part of Krakatoa doesn’t play much of a role… Just guessing.

7

Oh, yeah, I can see that.

  • Chad