Generally, automatic seed increase doesn’t work. Both ‘manually increment’ and ‘create locally’ do not increment seeds in pflow. Partitioning works when seeds are incremented manually.
When create locally is activated, it does not check whether the files already exist. It does the calculations, but returns an error when trying to write each file.
When creating a loader - if ‘cancel’ is chosen in the open dialog, the loader is still created (empty).
When creating new partitions, the partition names are not reset - so if you had previously created 6 partitions, the automatic suffix stays to 6 of 6.
Some UI problems/proposals:
The big one. Don’t you guys think that file operations should be encapsulated and abstracted to the user? I imagine the user interacting with a tree structure - level 1 for animations, level 2 for frames, level 3 for partitions. So it would be easy to manipulate everything. The way it is now is nice for an in-house tool, but a shelf product should have an extra interface layer.
The partitioning roll-out is closed by default, and the message saying that the save partitions is only active when ‘save particles’ is selected, is hidden. Believe me if you wish, but this took me couple of minutes to figure out
When lighting is disabled, the ‘use render density for lighing pass’ button should be disabled, too.
The whole ‘render’ and ‘lighting’ naming convention is unusual. Maybe it would be better to use ‘diffuse’ and ‘lighting’?
That’s it for now. Thanks, and keep rockin! Krakatoa is great!
Generally, it does work. It looks like when saving a single frame with changed Seed, PFlow somehow feels it has not changed and does not update, so Krakatoa saves the same cached first version again and again. The Seed is obviously changed (if you open the PView, you can SEE it changing), but we will have to force a refresh of PFlow in this case. Will fix ASAP!
When create locally is
activated, it does not check
whether the files already
exist. It does the
calculations, but returns an
error when trying to write
each file.
This might happen if you are already LOADING the particles it is saving to. This is a tricky one but we found it too and will have to figure out how to deal with it. It SHOULD NOT check whether the files exist (as you might want to overwrite existing files), but it should be aware of the fact some files might be trying to save recursively - in other words, a PRT Loader is loading a partition and writing to the same partition at the same time.
This is a known defect, but thanks for reporting it!
When creating a loader - if
‘cancel’ is chosen in the open
dialog, the loader is still
created (empty).
This is “as designed”. When creating a loader from the Create panel, it comes without any files and sits there empty. Then you have to press a button to load files.
When you do it through the Krakatoa GUI, it creates the loader AND pressed the “Load” button after that to save you one click. If you cancel, no files will be loaded, but the cancel is for the open file dialog, not for the creation. It WOULD be possible to change it as you think it should work if you really feel cancelling loading should cancel creation, but I would rather remove the opening of the open file dialog to avoid confusion…
When creating new
partitions, the partition
names are not reset - so if
you had previously created 6
partitions, the automatic
suffix stays to 6 of 6.
It does when using Generate Locally.
There is also a button to reset the name back by removing the suffix if using the Manual Increment option.
Some UI problems/proposals:
The big one. Don’t you guys
think that file operations
should be encapsulated and
abstracted to the user? I
imagine the user interacting
with a tree structure - level
1 for animations, level 2 for
frames, level 3 for
partitions. So it would be
easy to manipulate everything.
The way it is now is nice for
an in-house tool, but a shelf
product should have an extra
interface layer.
I will ask Mark Wiebe to discuss this.
It is the way Digital Fusion deals with files and the way we wish MAX would deal with sequences but it does not. There are significant advantages to how it is now.
I would suggest posting a separate thread about this in the General Discussion forum…
The partitioning roll-out
is closed by default, and the
message saying that the save
partitions is only active when
‘save particles’ is selected,
is hidden. Believe me if you
wish, but this took me couple
of minutes to figure out
I believe you. Right now, it opens automatically if you set to Save Particles. Otherwise, it would be open and completely grayed out, just sitting there. Should we cater to the first time user of the GUI or to the everyday user who has read a (still not existing) documentation of using this new rollout? This is the main question I have constantly to ask myself…
When lighting is disabled,
the ‘use render density for
lighing pass’ button should be
disabled, too.
The whole ‘render’ and
‘lighting’ naming convention
is unusual. Maybe it would be
better to use ‘diffuse’ and
‘lighting’?
Krakatoa performs two internal passes - lighting creates the shadow maps by rendering the particles from the POV of the lights with these separate settings for density, then the scene is rendered once again from the point of view of the Camera. When we separated the density controls for these two passes, we needed some names that describe what the pass is doing. “Diffuse” is not really descriptive of the Rendering pass, but “Shading” might be.
Ok, I just confirmed that it happens with single frames but it works as expected in animations. Now we’ll have to figure out why - I am forcing PFlow to update after each seed change and Krakatoa still saves identical positions for all partitions…
>2. The partitioning roll-out
>is closed by default, and the
>message saying that the save
>partitions is only active when
>'save particles' is selected,
>is hidden. Believe me if you
>wish, but this took me couple
>of minutes to figure out :)
Ok, we can open it by default. It stores its last state, so if you close it, it will stay that way for the current scene.
We used to have this "smart" feature that it would open if you select Save... and close if you select Render... This might be too much, or an "Expert Mode" feature, so I am disabling it for now and will make it a user option in the future, so you can decide whether you want it or not.
This way, everybody will be happy.
I like it as it gives me what I need when I need it, esp. if moving from top to bottom - you set the mode to Save, select a save file name, then move to the Partitioning rollout and don't have to expand it as it is there already... ;)
Cheers,
Borislav "Bobo" Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
Just to confirm that it is indeed a problem with PFlow and automatic seeds update. I think I have seen similar cases where the flow would not update after scripted changes unless saved and reloaded (for example via hold and fetch). Since submitting to deadline involves save and load, it was never an obvious problem.
Now I remember that when I implemented the Local Automatic Partitioning, I was testing it on PCloud as I had just implemented seed support for Legacy Particles. That’s how the PFlow problem slipped undetected.
After an even closer look, it appears that the PRT Loader is now broken and does not load all partitions correctly. If I create multiple loaders and load each partition individually, they appear to contain the different seeds.
Difficult to tell when it got broken, but it appears that it is not the Partition generation that is causing this, but the Partition Loading!
Getting closer...
Borislav "Bobo" Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
When I had this problem, it seemed that partition generating was the problem, because I didn’t wait at all for a PFlow update between saving the separate partitions
