If you are installing a 1.5 Beta for the first time, please be sure to follow the steps for copying additional DLLs and Plugins described in the Release Notes.
The main new features besides bug fixes are:
*New dedicated Krakatoa Material providing Scatter, Density, Absorption and Emission values and maps for quickly populating the corresponding particle channels without the use of KCMs. (PRT Loaders only, not implemented for GeoVolumes and other sources yet!)
*Support for the Diffuse, Opacity, Self-Illumination and Filter channels and maps in the 3ds Max Standard Material as sources of the Scatter, Density, Emission and Absorption values in addition to the dedicated Krakatoa Material. (PRT Loaders only, not implemented for GeoVolumes and other sources yet!)
*New Noise node in MagmaFlow which can return a float value based on either a Float or a Vector input and two Integer controls (Octaves and Persistency).
*Max 2010 is now correctly supported (no missing rollouts in plugins)
Important changes to existing features:
*Changed the wording and workflow of PRT Loader’s Culling geometry picking. In the past, a single object was picked and added to a dedicated Named Selection Set. This was misleading since most users assumed the OBJECT was selected, not its NSS. The new workflow uses the Multi-Object Select By Name dialog to select any number of objects and create a NSS out of them.
*Assume Densoty of 1.0 and Density->Mapping # options have been removed from the PRT Loader since they can be implemented using KCMs now.
*Krakatoa Skin Wrap WSM had a wrong range limit for the Base Frame value, this has been fixed.
*The viewport performance of the Krakatoa Skin Wrap WSM has been improved.
*The order of some rollouts in the Krakatoa GUI has changed based on users feedback - Matte Objects and APME have been moved up closer to the Main Controls.
*The folder structure used to store Krakatoa presets and MagmaFlow files has been centralized, allowing various 3ds Max versions to reuse them. Local settings and preferences are still handled separately, allowing for unique looks and behaviors in each version of 3ds Max.
gonna give it a go right away. Great stuff. Hooray for the Material support and double hooray for centralised preset locations…and thanx for getting in the autoexpose for loaded flows so quick…as am using a lot of preset flows these days and moving forth and back a lot.
We found some bugs in the scripts, we will post a new version of the file with the fixed ones, but I am also providing them here so you can patch by dropping them into the \Scripts folder of the installation.
Fixes in this Patch:
*AutoUpdate state was written to the wrong INI file, causing new KCMs to have the wrong AutoUpdate value (whatever was the last state before updating to Beta 7). With this fix, it is back to normal - AutoUpdate will have the LAST KNOWN state, so if you turn off a KCM and create a new one, it will also have AutoUpdate turned off etc.
*Fixed a bug in the updating of the enabled state of the Undo buttons in MagmaFlow - the path of the UndoRecords has changed, but the code was still looking into the wrong folder. Krakatoa_v1_4_7_SP1_Scripts.zip (56.4 KB)
This is still Work In Progress and might not be exactly obvious how it is used. We will be refining the workflow in the coming weeks.
*Currently the KrakatoaMaterial only works with PRT Loaders. Applying it to a GeoVolume for example will result in RED particles.
*The Materials (both Krakatoa and Standard) are being applied AFTER the KCMs. This allows you to generate channels like Mapping coordinates for the Krakatoa Material Maps for example, but if you were setting the Color (Scatter), Absorption or Emission channels and the Krakatoa Material had either one of these checked, it would overwrite the result of the KCM. You can uncheck the corresponding color in the KM to leave the KCM channel, for example uncheck “Scattering” to preserve the existing Color channel set by a KCM. In general, the idea of the KM is to do quick “All Particles One Value” assignment without wiring a KCM and populate one or more channels of a PRT Loader at once. (In fact, it runs a MagmaFlow internally to set the values!)
*The Standard Material ALWAYS overwrites the Color, Emission and Absorption values and there is no way to disable any of them to preserve the KCM content. If you need to do so, replace the Standard with a Krakatoa Material and use the checkboxes to disable certain channels. If you want to use Per Particle values from KCMs, remove the Standard Material by assigning None material to the PRT Loader.
*The PRT Loader’s color selection lists don’t work anymore. If a material is assigned, it is used. If no material is assigned, the saved Colors or KCM Colors are used. These controls will soon be removed from the UI. We believe that PRT Loaders should behave like Max objects - you assign a material - they render it.
Here is the target logic we are trying to implement:
**If a PRT Loader does not have a material assigned and has no color channel saved in the PRT, it will render the wireframe color.
**If there is a Color channel, it will be rendered.
**If there is a KCM modifying the Color channel, the resulting Color channel will be rendered.
**If there is a Standard or Krakatoa material modifying the Color (Scattering) channel, it will be used instead.
The viewport particles will reflect these colors too.
I’m concerned about the combination of these two. I don’t want to be evaluating a material for the viewport display continuously. I can set the KCM to render only, but with materials, are we expecting to set up shell materials? I actually like the way the PRT Loader is now, where you can say to the viewport colors “get whatever the render will be” or you can override it to “just show me your wire color”.
We are looking into possible ways to override the viewport independently.
We would like to support the global display settings in the Display tab (Wireframe/Shaded - Object Color/Material Color). Would that be useful?
We might have a checkbox (instead of the current dropdownlist) that overrides the viewport color with the Color channel ignoring the Material (it could read “Ignore Material In Viewport”). If you have a Color channel in the PRT, it would show it. If you have no Color channel, the Wirecolor would appear.
We were looking into adding support for the Object Properties>Display Properties “Vertex Channel Display” option where you could select the Vertex Color to show the Color Channel or Vertex Alpha to show the Density Channel or Vertex Illumination to display the Emission channel etc. without adding a KCM to copy channels to the Color channel which of course would have affected the renderer. This would affect only the viewport display of particles, not the rendering color and could be useful to visualize the content of some channels.
Combining 2 and 3 would be tricky, but we could expose the controls of 3. into the PRT Loader’s UI so you would be setting indirectly the Display Properties of the node.
Does the color channel eat up memory or slow the loading process down? Meaning, if you only load the position channel, and display wire color, would that be faster than loading the position and the color from disk? Or does it not matter?
If you’re going that far, could you just keep the dropdown in the viewport and add in the other channels? So it would either be wire, render, or channel, and for the channel, we just set which data channel we want to use, be it color, density, velocity, joy, etc? It would only be channels stored in the PRT file, of course, and missing data would have to either be black or wire color.
What we are currently trying to do (but have done only the first steps) is reduce the feature overload of the PRT Loader and move more and more of it to the Stack, until all the PRT Loader does is load particles.
Currently you can add a KCM to the stack, set to Off In Renderer and load ANY channel into the Color channel to visualize the content, with the added ability to scale the values, shift them, clamp them or combine with other channels. If you have another KCM dealing with render colors, you can set it to Off In Viewport and you will have two pipelines - one for viewport display, one for render time shading. Granted, using KCMs is a TA/TD domain, but we hope more people with start using simple forms of them to manipulate both rendering and viewport display.
In the future we also want to add Selection/Weight Channel support to KCMs so you could select particles and pass that info to Modifiers (as you know, only Volume Select does this right now).
Then we would like to have a channel for marking particles for Deletion and add Geometry-testing Nodes to KCM so you could do everything Culling does right now and more (cull by Position, Velocity or Cellular Map, anyone?) We might create a dedicated modifier for Culling that could interact with KCMs if desired to have the current simple workflow and the advanced MagmaFlow approach, but we want it moved out of the PRT Loader. This is mainly because the Culling happens on top of the stack in world space right now, but is placed at the bottom of the stack in the base object and is counter-intuitive this way.
So our hope is that by 2.0, the PRT Loader will have only controls for loading particle sequences and all additional handling of channels, colors, culling etc. would be moved to either dedicated modifiers (like possibly “Delete Particles” modifier) or custom KCM modifiers.
We know that this might be too advanced for simple artists, but it looks like our primary customer base is Technical Artists and Directors. Please correct me if I am wrong.
From the user perspective, they will create a PRT Loader, not a PRT Loader with a bunch of KCM’s already on it. It’s the difference between starting PFlow from a PFlow Source or with an Empty Flow.
So for the very beginning, you want them to be able to have something that they can look at, just so that they can verify that the PRT is in fact loading. So you need something in the PRT Loader that can draw something in the viewport. Even if basic. I guess the simplest thing would be a toggle between color channel (the most obvious per-particle channel to use) and wire (the only way you could differentiate 2 different overlapping PRT Loaders who have color channels that are the same). If color channel is missing, draw wire color.
Anything beyond that could be handled by the KCM’s, or other modifiers, sure. I’d be fine with the viewport shape being a modifier as well, so long as you left the default as large dots.
True.
We are getting lots of complaints right now about the removal of the simple Color Override option, despite the fact that adding a Global Override KCM is 2 clicks away and a lot more powerful. I know people will learn how to use it sooner or later (although from the feedback we are getting it looks like even some advanced users inside of Frantic don’t know how to use basic features that have been in for years), and we try to push KCMs as the weapon of choice for anything that has to do with Particle Channels Data, but I know that it can be a pain when moving from a simple but limited feature to a less simple but more powerful alternative.
We don’t want to duplicate features though, so if something can be done with a KCM, we will probably make that the only way to do it. That being said, we intend to ship a lot of preset KCMs (for example, “Position As Color”, “Density As Color”, “Velocity As Color” etc.) in the newly created Local Settings folder for MagmaFlows and probably add some quick buttons for adding such preset KCMs to the stack via MacroScripts or buttons/RCmenus inside the PRT Loader. So the user could create a PRT Loader and then Click-Click-Click create a stack of modifiers that show the desired color in Renderer and/or in the Viewport, Cull particles, jitter the Positions or whatever. There is a lot that can be done at UI level to make life easier again without losing the newly found flexibility and awesome power.
We could also make the PRT MacroScript in the Krakatoa toolbar create a PRT Loader with several pre-added KCMs (like the Standard PFlow you mentioned) that control various aspects of the “default” setup. These could be then disabled, switched to view or render, modifierd or removed at will.
Don’t treat it like duplication of features, treat it like the base object with a modifier stack.
The PRT Loader has display options, and the modifier overrides that. Not confusing at all for 3ds max users.
The confusion over the culling is understood. That should go in the modifiers, not the PRT Loader. But I don’t see a problem with redundant controls for viewport display so long as the modifier stack works the way God and Yost Group intended.
I tried to use Krakatoa material with pflow and it rendered red… But fantastic thing is that with voxels, now I can use standard material and self illumination and filter color property to control emission and absorption value…
Also I noticed tests I was doing, I was able to get RGB lighting pass type of rendering using different color value in diffuse, selfillumination and filter color value. Another thing I noticed, If I had filter color set to Red, I get greenish/bluish absorption in particles ( in shadow area)… ( I was more concerned on this, coz setting Red filter chennel I got nice bluish scattering (well absorption of krakatoa) for water spray particles. but outer particles were rendered a bit reddish. So I had to mixed up with selfillumination value to color outer particles bluish white…
Also to absorption value depended on opacity chennel value. lower opacity more absorptions I got…
Also new voxel rendering with matte object is faster and much better.
As mentioned in this thread, the Krakatoa Material is currently just a C++ plugin UI to a custom MagmaFlow. Internally, it modifies Krakatoa Particle Channels the way a KCM would do, so right now it works with PRT Loaders only (until we get GeoVolumes etc. to participate in KCMs). So it should be used only with PRT Loaders as an alternative to the Standard Material or multiple KCMs - the main benefits of the Krakatoa Material are that it only exposes the controls that can affect Krakatoa and you can disable the effect on Scatter, Emission and Absorption channels separately so you can set only one of them if needed, while Standard Material always sets all of them.
MAXScript Rollout Handler Exception: – Unable to convert: undefined to type: String <<[/code]
I’m only getting back into krakatoa now so a tonne of stuff to catch up on! The direct fume render is very very nice and the geovolume stuff looks very useful too - I take it that the geo volume is a separate system and can’t be used as a smart way to more efficiently replace the position object operator in pflow? If the object is animated or deformed do the particles filling the object stick to it in object space or is it like the geometry acts as a culling object almost like an object sliding through a 3d texture in world space? Also the kcm seems to be a way of manipulating data by layering other maths functions in - adding in extra noise and that sort of thing?
LOL! I arrived in Bulgaria yesterday and discovetred this myself on my laptop running Max 9.
My first thought was - now this is a stupid bug. The second was - why is nobody reporting it?!
It is easy to fix - just add
theSuffix = “”
inside the catch() portion of that code.
Alternatively, move the declaration of theSuffix variable out of the TRY() portion and BEFORE it in the beginning of the function so if is defined throughout its body.
The error happens because the error trap catches some error (in the case of Max 9, the function for getting the local bounding box does not exist unless the Avguard.DLX is installed), but the trap does not define the suffix variable.
Will be fixed in the next Beta.
The GeoVolume tells Krakatoa to get the mesh of the object in its object space and create a level set out of it using some technology borrowed from Flood. This gives us a voxel representation of the volume where the voxel size is the Grid Size value. Now we can create one particle in the center of each voxel as long as the distance to the surface is negative (in other words the particle happens to be inside the volume, behind the surface). WIth the Shell option, the distance to the surface is checked and a particle is added only if it is farther than the given Start value and less than the Start+Thickness.
So if the object is moving via Position/Rotation/Scale, the particles would stick. But if the object is being deformed with a Bend for example, the ones inside the volume will stay there, but some others would be added/removed to define the new volume. So if you want to bend the cloud, you would have to
*Create a single PRT file out of the GeoVolume on the first frame of the animation.
*Create a PRT Loader with that file selected
*Check the Use Range option and hit the Range button to set the start and end to the same frame
*Add a Krakatoa Skin Wrap WSM and pick the deforming mesh, setting the first frame of the animation you saved as PRT as the Base frame.
*This will deform the particles by the deforming mesh while keeping their count and will of course potentially compress/expand the distances between the particles.
We have discussed a potential GeoVolume Position and/or Birth operator for PFlow (which would be rather useful with Box #2 I guess), but so far it has not made it into the v1.5 feature list. Possibly in the update right after it.
The KCMs do not work on the GeoVolume data YET, but we are looking into changing this. If it works well, we will probably leave the Jittering to the KCM and won’t add Jitter code to the GeoVolume itself.
Right now, you have to save to PRT to be able to add KCMs on top.
Perfect that clears all of it up - I’m still on max 9 over here since most of the work I do doesn’t necessitate any of the new features of the newer max’s (aside from the speed ups which would no doubt be nice). Definitely quicker ways to fill volumes than the standard position object operator in pflow are going to come in very handy though.
