While we haven’t started the actual development of Krakatoa 2.0 features just yet, you can use this forum to post and discuss feature ideas and wishes.
You can also use this thread to answer the following questions:
What are the top 3 feature ideas you would like to see implemented in the future (either your favorite wishes, or other people’s ideas from this forum)
What is the top one annoyance / weakest feature of Krakatoa as of v1.6.0 (for example, prior to v1.6.0 it was probably the Shadow Casting on Geometry workflow).
If you could optimize/improve just one existing workflow in Krakatoa to make you more productive, what would be it? (Examples: Saving Particles, Iterative Rendering, integration with other renderers, integration with compositing applications etc.)
Thank you in advance for your feedback and continued support!
other things that came in my mind that would be cool:
to have several output nodes in the top right corner of one magma flow,excecuted from top to bottom or so. For example sometimes i want to use a similar flow for emission that i also used for color just some additional nodes, when i copy the “color” modifier to base the “emission” flow on it and then want to make changes i have to tweak both
a pflow operator like the shape instance operator where i can pick PRT Loaders as a instance and treat it like a regular particle, that could be quite usefull if you do some kind of multiple explosions to scatter and offset one PRT Loader
probably a lot too computing intensive but something like multiple scattering where the particles are illuminated based on the emission of other particles would be cool
a second option for retiming based on the ids considering the position and velocity of the next and previous frame, the current method is awesome to speed up animations and also to slow them down slightly but if you want to go really slow it does not work / this is my nr2 feature idea
just some of my thoughts dont know if they all make sence
Wow 2.0, gees its tough to think of anything at the moment, it is such a robust package as it is.
Wish #2 - Of course PRT Mesher never have enough good meshing options.
Wish #1 and Current Annoyance - Ability to use any PRT object within PRT Birth/Update Plfow operators, for instance PRT Volume is an awesome birth option, PRT Fume well speaks for itself you can virtually bypass the existing fume ops or use them in conjuction.
Wish #4 - I like the multiple outputs idea too, for sure, I have often had a duplicate mFlow for color/emission
Wish #3 and Current Annoyance - 3. From a non-studio users point of view, better project management, I love the current PRT save versioning options. Adding a simple Project Folders structure would be cool, so you have the option to have every saveable object in krakatoa default to this location and its subfolders, it would be icing on the cake. I have saved a bunch of blops, mod stacks, ect. hell if I know where they went. I have lost almost all of them, I stumble upon one every now and again, after I could have used it ie some/most of the folders in the Local Settings could be more effectively used in a project tree structure instead of the local settings. Samples/Blops/ModStacks to name a few, some could easily live in both places.
General Request from current community observations - Currently no real need for it myself, I could see it happening though, seems like a good idea, I have seen a few requests for it, a bundle of package export plugins (which I suppose is what PRT Source is for) So virtually any major package could write PRT’s and easily be brought into MaxAtoa.
We’re allowed to edit our responses, OK? Otherwise I’d be too afraid to say anything…
a) PRT referencing per particle. The idea that you could supply something akin to the box#3 shape operator, but it would reference pointsets, either from disk or (even better) from other PRT objects in the scene. The points would contain an index to the object to reference, as well as a transform and maybe variables (in case you want to tweak each one in their KCM’s, ala box#3). I’ll include the link to the prior discussion in an edit.
b) Variable splatting geometry. The easiest sounding one is to use the DOF disk method to splat circles comprised of many points into the lighting and rendering buffers. So you’d have a radius channel for each point. Other ideas would include tetrahedra that gets filled. You would need to, per point, have channels to define the other 3 points of the tetrahedron, probably just IDs. Maybe allow some sort of duplication inside a KCM? I’ll include the link to the prior discussion in an edit.
c) More sampling options in KCMs. Offset sampling of textures? Input the UVW coordinate instead of inferring from the particle. I’ve implemented central differences bumpmapping in KCM’s, but it was NOT pretty. Kernel operations are similarly hard to set up. ID based particle sampling (assuming spatial sampling is too crazy)? This would be extra sweet if you could sample other PRT objects by ID. So we could “merge” particle channels together. EDIT: For an example of merging, consider if you baked out your lighting to emission but later found that you needed to add another light. Easiest thing would be to bake out the new light to it’s own PRT and then merge the original PRT with the new one, comparing ID’s to match up the emission channels and add them together. Temporal sampling? Input a time or time offset for getting a parameter.
I have sweet memories of Krakatoa, so I might be more optimistic about the meager weaknesses. It’s 5000% better than earlier versions, so I feel bad complaining. One thing I would like to see is pathmapping and local caching, so we can store PRT’s on local SSD’s or RAM drives and still have files that are happy on the render farm. How lame is that for a request? I might change this later. EDIT: OK, I was training some people yesterday, and the whole process of making proxies for viewports is way to complicated for beginners, and they’re the people most likely to need proxies.
For me, it would be integration with compositing applications. I’d like to see easier setup of Fusion comps. Another possible thing would splitting/merging of PRT’s, related to making proxies or generating PRT (as opposed to rasterization) passes. But that’s related to 2) and 1c) above.
It’s a lousy list, half of it is redundant with matthiasm’s… I guess I’m just pretty happy with the product.
The PRT spec is well documented. We have a plugin that can write them out from Fusion. It shouldn’t be hard for anyone to make PRT writing/reading tools. (CSV is an option too, and you can convert CSV to PRT easily inside Krakatoa).
ye thats true i am also quite happy about the package as it is already
another idea that came in my mind since i could need it right now for a snowy voxel pass, a “voxel size channel”, so i could have different voxel sizes and make it look more random for example
Wow, guys, thank you very much for the awesome feedback!
I started collecting these wishes in a spreadsheet and compared them to our internal discussion list, and you have matched 8 out of 12 points so far - not saying which exactly as we haven’t decided on the final list, but we surely are on the same page when it comes to potential features!
Please, keep them coming.
And yes, feel free to edit as much as you want.
Since having reused operations won’t speed up KCM’s (unless there’s caching, which I doubt?), maybe an alternative would be instancing of operators between KCMs? So you select some tools, and copy/paste instance to the other KCM? Maybe have some sort of underlay that duplicates everything that happens on the underlay between KCMs?
This wish is more about workflow / usability than performance. We have considered it before and if we weren’t about to ship 1.6.0 end of August, it probably would have made it into a build already. It has more technical implications at the UI side of things (my domain) than the actual low-level implementation since right now the MagmaFlow editor is built around the assumption the flow is a tree with a single root node (the Output). But secondary Output operators that could be added and removed without affecting things like Reordering might be quite doable. We will investigate.
Currently, if I have a flow that generates a Color and I want the same or slightly different value in the Emission, I usually drop a second KCM on top, read the Color and pipe the result into the Emission, plus any modifications in between. So often there is no reason to redo the whole flow if both exist on the same stack and the bottom one produces a result that can be reused without doing all the math again.
Yeah, that’s what we do now, either directly, as you describe, or indirectly, like we do a matrix transformation on a vector and store the result in an unused mapping channel. I was thinking more about instancing a lookup or object selection or map selection. So you could change that once for all the KCMs that use it. Of course it might not be difficult to do that from track view either.
I’m pretty sure I wouldn’t use multiple outputs since it isn’t faster, and makes it harder to manage a modifier stack. Would get really hard to read, as well as turn KCMs on and off. Maybe if ALL the KCMs were on one flow, but that would be rare since we’re almost always interleaving other modifiers.
Hmmm… what do I like or not like about how box#3 does this…?
It would be nice to have some particle to particle data, specifically the distance to nearest particle and number of particles within a specific distance from each particle (number of neighbors).
The ability to get the speed data off an animated (deforming or not) mesh in the Surface Data.
A min/all particles - max/ all particles function…or perhaps a function that automatically puts a specific channel in a normalized state where the smallest amount of the channel becomes 0 and the largest becomes 1
The ability to control Additive as an amount per particle as to render some particles with and others without and some in between.
Matte particles
And it would be useful at times if you could create new particles via KCM (not really a Krakatoa Channel I suppose, but…) This would be useful for filling gaps in PRT’s (used in conjunction with my first request)
And a few things not specific to the KCM…
I would love to see matte objects that support gray scale values rather than a clamped black or white.
Another vote for larger particle render sizes
Another vote for prt mesher
more standard view options for the PRT Volume (specifically color controls as well as toggling particle count and bounding box like the PRT loader)
-A density of 1 particle per screen output resolution pixel option in a PRT Volume (perhaps spread only on the surface normals facing the camera?)…this may be possible now with a fancy KCM…but it could negate the need for matte objects supporting gray scale values…
A speed up of the volumetric rendering
I had a couple more, but I can’t remember them right now
Some awesome ideas, thank you.
Not sure about the above though - you can already control the amount of additive vs. volumetric shading by tweaking the combination of (Scatter) Color, Absorption and Emission. As explained in the docs, Additive rendering is purely emissive with no Scatter and no Absorption. Thus setting the Color and Absorption to Black and the Emission to the color value you want gives you Additive rendering and no alpha. As you start adding Color and Absorption, you start blending into Volumetric rendering.
what would you benefit from having direct phoenix integration with? Although i’ve never used fume integration with krakatoa, so maybe that might explain
my question. You looking for the ability to read the information stored in the voxels? temp, fuel, etc ? I’m really at a loss what to suggest for the future of
krakatoa, i feel like this whole discussion is already above my knowledge of the plugin, its already very deep and versatile. I think adding in its own
meshing ability would be pretty great, rather than trying to depend on the slow and clunky blobmesh, but it does seem like that is an extension of the
plugin rather than a direct practical use of the software.
Well there’s different advantages coming with a direct integration (which also holds true for the fume integration of course)
For one you can directly render a Sim without pushing it through the slow PFlow first. And you gain all the flexibility of MagmaFlow etc.
In addition it is a nice way to create particles from the Sim without PFlow at all simply writing it to a PRT cache. There’s a lot more
but this is showing where i am aiming at.
We believe that the Culling option shouldn’t be even in the PRT Loader and should be moved to a dedicated InVolume operator or something similar inside of MagmaFlow. For example, if the SignedDistance value returned by the NearestPoint > SurfData operators were actually signed (right now it is not), it would be enough to check the sign and select all particles with a negative value and delete them.
In fact, you can get very similar results using a MagmaFlow and the Surface operators - just take the Position of the particle, convert to world space, pass to a NearestPoint operator with a Geometry input listing all volumes you want, get the Normal and the Position of the nearest point, build a vector from the Particle Position to the Nearest Point and Normalize it, calculate the Dot Product of this vector and the FaceNormal at the nearest point and use Greater than 0 converted to Float to output to Selection channel. Drop a Krakatoa Delete modifier and the particles in the volume will be deleted.
Alternatively, if the volume is a box, cylinder or sphere, you can use a VolumeSelect modifier. It just fails in Mesh mode, so don’t use that (we tried to make it work, but it broke other things and in general it is a piece of crap code-wise).
Well, you asked about workflow, and your suggestion is taking the workflow where I have to check a box and make a selection set to a paragraph long description of a magmaflow setup. You mentioned having an inVolume operator in MagmaFlow which would be fine.
However, I would rather see something like a Krakatoa inVolume modifier, which would basically be the Culling rollout in a modifier form. It could also just be a preset Krakatoa Channels modifier with the correct inputs exposed to the UI layout.
Which brings me to another suggestion - ship with some preset magma flow files. A good start would be any flows you used in tutorials. Sometimes people don’t have time or patience to walk through a tutorial, but can dissect a magmaflow just by looking at it. Something like the inVolume preset would be very useful, but even setups that might not be useful but can illuminate users to the power that is in the KCM would be exciting, and give a great starting point to start to rewire some different inputs and see some new results.
The paragraph was for those who want culling in PRT Volume NOW. The alternative would be to save to PRT and cull in the PRT Loader, so I’d rather wire some KCMs than do that
We know the current culling in the PRT Loader is optimal for users from the ease of use point of view, but it is full of problems related to the fact the culling has to be performed in world space after the modifier stack. So from a developer’s POV, we hate the existing Culling option and would love to get rid of it. Having a dedicated modifier might be a possible approach, but having a preset flow as you mentioned would be much more flexible. In fact, we could ship a MacroScript that would add a KCM and set up the culling with a single click, while still using KCMs and Krakatoa Delete modifiers.
A version 2.0 would be a good time to break compatibility and remove the features we don’t feel good about…
We are collecting flows and BlackOps (I just saved the InVolume BlackOp here for eventual future inclusion) but somehow we don’t ship enough of them.
never have enough good meshing options.
)