Hi,
I’m new to Krakatoa forum and had the chance to test the tool in the last days.
So, my first impressions:
1.) Why is the GUI no in the Max render dialog like with other render engines?
2.) The UI is mostly logical except the render button. It took my a while to understand the concept of rendering particles and images. Maybe to buttons instead of one would be better?
3.) PRT Loaders. This should show every Nth particle instead of showing just the last particles per default.
Overall I had no crash or serious bug… I still try to find some…
Hi,
I’m new to Krakatoa forum and
had the chance to test the
tool in the last days.
So, my first impressions:
1.) Why is the GUI no in the
Max render dialog like with
other render engines?
There is a page dedicated to this in the manual, but here is the idea:
Krakatoa and Amaretto share the same design - we went with a plugin renderer which does all the underlying operations as a real plugin written in the SDK, but has NO user interface whatsoever. (Except for the one button that opens the GUI). The reason is that the Max SDK sucks big time and creating user interfaces FAST for any plugin is a pain and can take a long time to implement and also long time for even smaller changes.
The Krakatoa GUI is completely implemented in MAXScript which allows us to make drastic changes, fixes or even replace it completely with something else in a manner of minutes. (Plus it allows ME to write the GUI while our programmers can concentrate on the serious work ;o). So it has its advantages - people who have been around the last 6+ months would tell you that often a fix or new UI feature is possible by just a patch to the KrakatoaGUI.ms file which I can provide the same day a request is made - with a real plugin GUI, it would take days.
Unfortuantely, one cannot put a scripted rollout in the Render Scene Dialog, so we had to use an external floater.
The added bonus is that the source code of the Krakatoa GUI is provided for free browsing and potentially editing, so other VFX studios can tweak it if they want to, or see how it connects and integrates with the actual renderer.
If you would install the Krakatoa MacroScripts on a toolbar, you would practically never need to open the Render Dialog except for adjusting your render start and end times (you can switch the time type via the right-click menu on the RENDER button in Krakatoa, as well as set the render output path).
2.) The UI is mostly logical
except the render button. It
took my a while to understand
the concept of rendering
particles and images. Maybe to
buttons instead of one would
be better?
That is tricky. That button just DUPLICATES the feature of the Render icon on the Max toolbar or the Render button in the bottom right corner of the Render Scene Dialog. All it does is calling ‘max quick render’ in MAXScript, thus pressing the Render icon in the main toolbar! If you prefer, you can keep on pressing the Render icon (the teapot :o) on the toolbar, but we felt it is easier to have a button that is closer to the rest of the settings, so if you are tweaking motion blues or densities, you wouldn’t have to go too far.
Saving particles is a “special rendering mode” in Krakatoa - instead of rendering an image, Krakatoa processes the particles and dumps the result to disk, that’s why we have a drop-down list with various modes and a single button which morphs from RENDER into SAVE. Being written in MAXScript, I could change it to two buttons in a matter of minutes, but it wouldn’t help much, because the workflow for rendering and saving requires you to take different steps - in the case of Saving, you have to specify a different output path…
3.) PRT Loaders. This should
show every Nth particle
instead of showing just the
last particles per default.
Unfortunately, Every Nth particle mode is MUCH SLOWER than First N particles because it has to read the whole file (and with 20 million particles that can take seconds per frame). That being said, YOU can set that mode as the default by using the User Presets in the PRT Loader. You simply change the mode to Every Nth, then save a preset with a name like “My Defaults” by pressing Save… button in the “Presets” rollout, then select “My Defaults” from the list and hit “Make Default” button in the same rollout. From now on, every new PRT Loader you create will use the saved settings as template and will show every Nth.
We decided that we cannot please everyone with our defaults and we’d better give you all a way to do what you want with them ;o)
Overall I had no crash or
serious bug… I still try to
find some…
Oh, don’t worry, there ARE bugs in Beta 18, we just fixed a couple yesterday :o)
Beta 19 should be out soon…
Cheers,
Borislav “Bobo” Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
Well the UI is mostly ok. It’s just a first impression, after a while you know where things are… Maybe that can inspire you for the manual, which is pretty ok right now.
Also on my first impression I found that there are so many buttons and just a few that I need for a quick start that I was thinking about suggesting a more streamlined UI, maybe with icons 
But, it’s really not important at the moment.
The render button is something else. I still think it’s worth having more separation between render a picture and cache particles to disk.
Rendering particles is something that really takes a lot disk space. Is there any plan on having some kind of pre calculation to get a warning ect.?
Everything else feels good at the moment… well, except that I need a faster system…
…and one more note:
Installing the scripts of krakatoa and deadline I have one wish. Could you simple add all scripts to category ‘frantic’ ?
I used to collect every plugin by company and this really helps finding the scripts…
…and one more note:
Installing the scripts of
krakatoa and deadline I have
one wish. Could you simple add
all scripts to category
‘frantic’ ?
I used to collect every plugin
by company and this really
helps finding the scripts…
Ouch. It is a bit too late for that.
Frantic Films has an internal category called “Frantic” which is full with inhouse scripts. It was created long before there were any Frantic Software products…
So we put the Deadline stuff under Deadline and Krakatoa stuff under Krakatoa. You could change the scripts to appear under Frantic, but you would have to update them each time you download a new version. We could not do that anymore because people are already used to finding Deadline Submitter under Deadline, and having the Krakatoa stuff under “Frantic” would severely affect Frantic VFX’ workflow ;o)
Well the UI is mostly ok. It’s
just a first impression, after
a while you know where things
are… Maybe that can inspire
you for the manual, which is
pretty ok right now.
Also on my first impression I
found that there are so many
buttons and just a few that I
need for a quick start that I
was thinking about suggesting
a more streamlined UI, maybe
with iconsBut, it’s really
not important at the moment.
Being a script, we could actually provide an alternative GUI for starters that has only the basic functionality and none of the advanced features :o)
We just believe that (like with most plugins in Max and Max itself) you should be given all controls to tweak anything that is tweakable at any time. After a week, you will feel “at home” in the advanced GUI and will not want to go back to a “kindergarten” version of the UI ;o)
Notice that we have the “Advanced View” option in the Save Particles area for a similar reason - the advanced controls are for advanced users, we don’t want to overwhelm you with 6 output fields from day 1. But almost every control in the Main Controls rollout is useful even for beginners, and the rest are rolled up anyway ;o)
The render button is something
else. I still think it’s worth
having more separation between
render a picture and cache
particles to disk.
In order to save particles, Krakatoa has to be switched to a Saving mode. Thus, having a second button saying “SAVE PARTICLES” (for example by splitting the “QUICK RENDER” button into two like the cache buttons are) would not be helpful, because pressing that button would have to switch Krakatoa to Save Particles mode (currently done via the dropdown list), then ensure all the output paths etc. are entered correctly (currently they are enabled only when the save mode is on) and then perform the saving. I feel the current workflow is safer because you have to explicitly select “Save Particles” from the Particle Render Mode list, which automatically invites you to enter the output data (and in certain configurations, actually expands the Partitioning rollout, too).
We can keep on discussing it, but the UI is more or less frozen for 1.0 :o)
Rendering particles is
something that really takes a
lot disk space. Is there any
plan on having some kind of
pre calculation to get a
warning ect.?
Good idea. Unfortunately, we cannot estimate the real disk requirements because the PRTs are zipped, so their size varies depending on how well the ZIP algorithm compresses different types of data. (For example colors are generally compressed better than positions, but we still cannot tell how big a file will be, even if we knew all counts and channels). But it is worth trying…
Everything else feels good at
the moment… well, except
that I need a faster system…
Who doesn’t ;o)
We have plans to further speed up certain portions of Krakatoa in the future, but for now a single fast CPU is better than a multi-core machine.
64 bit helps a lot, too.
>>Rendering particles is
>>something that really takes a
>>lot disk space. Is there any
>>plan on having some kind of
>>pre calculation to get a
>>warning ect.?
>
When you select channels, you can see how many bytes per particle will be taken up. That's pretty much the worst case scenario, the zlib will reduce that amount.
- Chad
Zip?
Still have 40mb per/frame with 2 million particles… well, just thought about zipping them… hehe
Won’t help. The files are already compressed with zlib.
If it helps you feel better, many of our scenes are running in the hundreds of gigabytes. There’s just no getting around the storage needs of completely explicit datasets.
With much power comes much responsibility. Or something like that.
- Chad
I noticed that Krakatoa saves a lot during rendering… Thats a lot traffic running over the network. Rendering locally is much faster!
Yeah, there’s options for both. Remember that locally saved PRT’s have to be moved to the network if you want to rasterize them on other machines.
- Chad
Yeah, there’s options for
both. Remember that locally
saved PRT’s have to be moved
to the network if you want to
rasterize them on other
machines.
To add to this, the Editor dialog of the PRT Loader has a feature that lets you repath all sequences to a new location, so if you copy your PRTs to the network, changing the paths of the partitions to look at the right place is relatively easy.
Wishlist: Support relative paths or path mapping, so we can map “\PRTMadness” to “\server\share\PRT” on some machines, and to “\otherserver\share\PRT” on other machines. Max 9 has added some relative path options, but the way Fusion does it is pretty sweet too.
- Chad
Wishlist: Support relative
paths or path mapping, so we
can map “\PRTMadness” to
"\server\share\PRT" on some
machines, and to
"\otherserver\share\PRT" on
other machines. Max 9 has
added some relative path
options, but the way Fusion
does it is pretty sweet too.
Thanks, logged as 4349.