Krakatoa build 1.1.0.31158
Max 9 x86 SP2
TP 3.0 March 7th build (latest)
please see attached image
it appears Krakatoa is only aware of first-level children groups.
it is VERY common to have children of children (and then some).
groups “All” and “Group1” both appear in Krakatoa UI, but “Group1b” does not (he is a child of Group1)
Thanks, looking into it…
Ok, I fixed the UI to scan recursively for any number of sub-groups. Which leads to the question - should we make the lists wider and placed one below the other to allow for longer lines? I have the line “Thinking01.group01.group02b.Group03c” and there would be no place for more, and no way to scroll to the right.
Obviously, we have to fix the internal code that scans for groups inside of Krakatoa to first not render the specified groups and then to support the nested groups correctly.
What do you think - if you specified both
“Thinking01.Group01” and “Thinking01.Group01.Group02b”, should the particles in Group02b be rendered twice (since they are in the parent group and in the sub-group), or should only the parent render?
How do you use nested groups exactly?
If you pipe particles into a sub-sub-group, these particles are visible in all parents, right? So if all stages, “All”, “All.subgroup” and “All.subgroup.subgroup” are selected for rendering, WHICH particles do you expect to see rendered? If All is set to render, should we skip all its children?
If “All.subgroup” is set for rendering, should “All.subgroup.subgroup” be rendered at all? Any info on how TP handles this when rendering in other renderers than Krakatoa would be useful - what would happen if both the sub-group and its sub-sub-group have a DC “Color”? Which one should be used - the parent’s or the child’s?
Ok, I fixed the UI to scan
recursively for any number of
sub-groups. Which leads to the
question - should we make the
lists wider and placed one
below the other to allow for
longer lines? I have the line
“Thinking01.group01.group02b.G
roup03c” and there would be no
place for more, and no way to
scroll to the right.
I would think omitting all prefixes would be best, e.g. “All”, “group01”, “group02b”, “Group03c”. Maybe it’s easier to code with the whole sub-tree visible, but we’re mostly concerned with the final group name. The more they can look the way they appear in TP the better.
-------------------------------------------
What do you think - if you
specified both
“Thinking01.Group01” and
“Thinking01.Group01.Group02b”,
should the particles in
Group02b be rendered twice
(since they are in the parent
group and in the sub-group),
or should only the parent
render?
This is a great question. First, I would only have them render once. Double-rendering because both groups are listed would probably not be desired (until it’s desired, of course).
I would actually only render the groups that are added to be rendered. So if All is the only group specified then all his children are ignored. If All has no actual particles in that group then nothing would render.
This would give us the ability to exclude certain child groups. I think this would give the best control.
-------------------------------------------
How do you use nested groups
exactly?
For organizing particles into groups so we can apply rules to multiple groups at a time.
Imagine a group called “Gravity-Bound” who contains “Fragments”, “Dust” and “Sparks”. We might apply a gravity force to the “Gravity-Bound” group in order to affect all his children. Then of course if we want to create a rule that affects the “Sparks” then we create a rule specifically for him.
-------------------------------------------
If you pipe particles into a
sub-sub-group, these particles
are visible in all parents,
right?
Yes. Every child is a member of his parent, so every rule applied to the parent is applied to all his children. It’s all about applying rules to hierarchies.
Rendering is totally separate! Hierachies don’t matter when it comes to rendering (see below).
------------------------------------------
So if all stages,
“All”, “All.subgroup” and
“All.subgroup.subgroup” are
selected for rendering, WHICH
particles do you expect to see
rendered?
I would expect all the particles in each of those groups to be rendered (only once, not doubled-up or tripled-up, etc).
-------------------------------------------
If All is set to
render, should we skip all its
children?
Yes. I would require the user to add each subgroup that he wants rendered.
Imagine this group tree:
All
GroupA
childA1
childA2
GroupB
childB1
childB2
If the user only specifies to render “All” and there are no particles specifically assigned to the All group, then nothing would render. Groups can be empty… their child groups might have all the particles. Group trees are really only used for applying rules to hierarchies.
The user should be required to add each group he wants rendered. So if he wants only childA1 and childB2, then he only needs to add those two groups to the render dialogue - no need to bother with their direct parents – just specify the actual groups to be rendered. This would give direct & understandable control.
Just a reminder, for example, if there are ONLY particles in the childA1 group, then the GroupA group itself is empty – it has no particles assigned specifically to the GroupA group. But of course because TP applies rules to hierarchies, any rule applied to GroupA will be applied to childA1.
For Krakatoa in this case, if the user specified GroupA to render but not childA1, then nothing would render because there are no particles assigned ONLY to the GroupA group. As well, the user would only have to add the childA1 group to render if he wanted them to render (and not have to add the GroupA group).
-------------------------------------------
If “All.subgroup” is set for
rendering, should
“All.subgroup.subgroup” be
rendered at all?
ONLY if “All.subgroup.subgroup” is also added to the render dialog. Else ignore those child particles.
I think having Krakatoa only render the groups specified would be best.
-------------------------------------------
Any info on
how TP handles this when
rendering in other renderers
than Krakatoa would be useful
hehe, TP 3 has an option for each particle group to render or not (the “Renderable” switch in the group properties). This switch only affects that specific group – not its hierarchy.
Really, the hierarchies are only used for applying rules - no real effect on group rendering (afaik).
But as a tangent… if a material is applied to GroupA, the both childA1 and childA2 will have that material applied. If the user wants a different material for those two child groups he has to create a rule after the first material rule to do so.
-------------------------------------------
- what would happen if both
the sub-group and its
sub-sub-group have a DC
“Color”? Which one should be
used - the parent’s or the
child’s?
Pardon my layman speak, but the Data Channels in TP are like variable containers, and they work in hierarchical fashion. A color data channel applied to GroupA means both childA1 and childA2 will have that variable container available.
When a rule assigns a value to GroupA’s color data channel, the child inherits that color value, too. The only way to assign a different value is create another rule to assign a different color to the child (or do it dynamically based on size or some other variable or condition).
So to answer the question I’d expect each group to use his own assign color value.
-------------------------------------------
Thanks for getting this stuff working with TP – it’s a huge help and makes Krakatoa MUCH more accessible to us…
I am happy to report that we fixed the reported issues with channels and groups and we hope the new system will work closer to the way TP users think.
First of all, the Krakatoa Thinking Particles rollout has been changed to display the actual Renderable state of each group. This means that the two lists you see there are like an extra scripted GUI to Thinking Particles - moving Groups from right to left will uncheck their Renderable checkbox, moving them from left to right will check the Renderable checkbox.
Krakatoa itself will respect the renderable checkbox of the TP system’s groups, thus any scene loaded to render with Krakatoa should now automatically look like in any 3rd party renderer. No data about renderable state of groups will be stored by Krakatoa itself, only the TP states matter now.
This also fixed the bug with groups not being disabled correctly (found in build 31158).
In addition, the hierarchy is now shown by default in an abbreviated form, for example if you have Thinking01 with the group hierarchy “All>GroupA>GroupB>SomeGroup”, the list will show
Thinking01.All
Thinking01…GroupA
Thinking01…GroupB
Thinking01…SomeGroup
Each dot represents one level of the hierarchy. Assuming you are using meaningful names, it should be obvious which is which without listing all children.
Optionally, a new “>Show Full Hierarchy” option allows you to show the full path like
Thinking01.All
Thinking01.All.GroupA
Thinking01.All.GroupA.GroupB
Thinking01.All.GroupA.GroupB.SomeGroup
Finally, particles are rendered only once - the default SDK method was designed to implement Operators, so it was returning all particles from all hierarchy levels, thus duplicating particles a lot. We had to jump through some hoops, but we managed to figure out which particle corresponds to which group and now the behavior should be as expected.
Regarding Data Channels, creating a Data Channel in a higher level group will enable the channel for all children groups, but you can feed the data into that channel into any of these groups independently. Krakatoa will not allow you to have a duplicated “Color” or “Density” channel name though - if you are going to create colors for only a portion of particles, create the DC once at the level right above the groups you want to assign the colors to, or in each children group separately. There is no valid reason to duplicate channel definitions (it just eats memory) and we are not going to use channel indices because these can change more easily than the name and are frankly an ugly practice. “I am not a number! I am a free man!” ;o)
lol
nice work!
The latest build with the mentioned TP fixes (and some more) was posted to the Builds conference as 1.1.0.31258 RC2.
Please download and test!
If you happen to have Max 8 with TP 2.5, please also test it as we lost the ability to run TP 2.5 since the update to 3.0 (still investigating why) and we could not test it there.
That being said, once again, the moment Cebas releases TP 3 for Max 9/2008/2009, Krakatoa support for Max 8 will be dropped. Just a warning…