Krakatoa

#1201

Ah, i see heh :slight_smile: Thanks!

#1202

Sounds like there is some problem reading from this sim.
It would be cool if we could take a look at a some of this data to figure out why the warning appears.

It makes no sense to use a KCM to peek into the data because where the data is missing, there are no particles in the PRT FumeFX. I wanted to see what the channel data looks like in the FumeFX itself.

#1203

Bobo, I’ve just sent you the ffx data and the max file.

#1204

I found another problem too.
Max crashes when i use PRT FumeFX with Post Cache in FFX.

     Steps to reproduce:
    
    [u][b]Common way:[/b][/u]
    
     1- Create a FFX container and a simple source.
     2- Add the Temperature and Velocity channels.
     3- Simulate
     4- In WT tab, change Time Scale factor to 0,1
     5- Change sim mode from Default to Post
     6- Simulate
     
     7-

[ul]
[li]Change FFX Cache from Default to Post.[/li][li]Create a PRT FumeFX and add FumeFX container.[/li][li]Max will crash[/li][/ul]or
[ul]
[li]Create a PRT FumeFX and add the FumeFX container.[/li][li]It will work with the Default Cache[/li][li]Change FFX Cache from Default to Post.[/li][li]Max will crash[/li][/ul]

Faster way:

    1- Create a FFX container and a PRT FumeFX.
    2- Add the FFX container to the PRT FumeFX.
    3- Change Cache to Post.
    4- Max will crash
#1205

Thank you very much!
I have forwarded the info the the senior developer of Krakatoa.
I would also like to mention that this is exactly what bug reports should look like - precise steps, test data, screenshots… I wish everybody would report bugs like you did!

EDIT: Both bugs have been fixed internally along with several other issues.
We will prepare a Service Pack build most probably tomorrow and let you and everybody else try it out to see if you can break it :slight_smile:

#1206

Four weeks after officially releasing v1.6.0, we have now replaced the original download link with a Service Pack 1 build 43376:
http://software.primefocusworld.com/software/products/krakatoa/download/

It contains the following bug fixes and enhancements (some reported on this thread):

Major Bug Fixes
*PRT FumeFX with FumeFX 2.0 was causing a crash when switching to Post Cache mode. This has been fixed.
*PRT FumeFX was showing only a portion of the simulation due to incorrect handling of Adaptive bounds. This has been fixed.
*Thinking Particles was causing particle evaluation to hang at render time if there were two or more TP objects in the scene. This was Cebas’ fault, but we worked around it.
*Deformation Modifiers were inverting the Velocity Channel in PRT Loaders. This has been fixed.
*Fixed the MAXScript call for saving all rollouts to presets.
*Fixed a crash when trying to load a Save Channels Preset.

Minor Bug Fixes
*Turning off the Viewp.Spacing in PRT Volume causes the render-time Spacing value to be used for the viewport, too, but changing the spinner wasn’t updating the viewport cache and required a manual update. This has been fixed.

Feature Improvements
*The TP Partitioning code was tweaked to allow an Integer Helper containing “RandomSeed” in its name to be incremented just like a regular “RandomSeed” property. This can be used to adjust the Random Seed of MatterWaves by connecting an Integer Helper node to the RandomSeed property which is otherwise not exposed to MAXScript.

New UI Features
*PRT Volume, PRT FumeFX and PRT Source now expose an Icon Size spinner to the UI. The MacroScripts now use the XY size to define the icon size of PRT Volume and PRT FumeFX.
*Added support for saving and loading the Channels To Save list.
*Added all rollouts to the right-click menu of the Float/Dock icons with a check mark for visibility. Selecting will toggle visibility, holding SHIFT will navigate to the rollout.
*Added right-click handling to all “Back To Main Controls…” buttons in addition to the left-clicking.

UI tweaks
*Added the keyboard shortcut names to the right-click menu of the Float/Dock icons.
*Changed the navigation buttons throughout the UI to unhide hidden rollouts before navigating to them.
*Reworked all MacroScripts to disable themselves and avoid any crashes if the Krakatoa path is removed from the plugin.ini.
*The Rollout Preset files were not restoring the visibility of the “Shader Parameters” rollout correctly - even if saved as hidden, it would be displayed because the update of “Main Controls” rollout’s Shading Mode list was forcing it to appear. This has been fixed by processing the “Main Controls” before “Shader Parameters”.
*Optimized the “Load From History” dialog to use the History Cache instead of scanning the files from disk. With 8281 History files on disk, the old code was taking 47 seconds to update the first time the dialog was opened, and 10 seconds in consecutive attempts. With the new code, the time to open the dialog went down to 0.078 seconds!

MagmaFlow tweaks
*Undo/Redo wasn’t restoring the Input Nodes’ value correctly. This has been fixed. Please note that if the track is keyframed, performing Undo/Redo can affect the complete curve as the animation state at the time of Undo creation is not stored and there is no way to store/restore the complete controller. This fix also improves the Macro Recorder playback.
*The “>Interactive Mode (SLOW!)” option in the Krakatoa Channels Modifier wasn’t handling Geometry objects used in Surface Operators. This has been fixed.
*Added conversion buttons to the SurfDataValue Operator to quickly turn the output value from Integer to Float, from Float to Vector, extract X,Y and Z components of Vector or transform Vector From World to Object space or into View Space.
*Added an explicit INSERT/BRANCH mode displayed in the title bar of the MagmaFlow Editor and controlled by the Insert key in the Numeric Keypad. When set to Branch and a single node is selected that has an output socket connection, creating a new operator will not insert into the existing connection but branch into a new output connection. Once the node is branched, the mode will revert to INSERT automatically, since it makes more sense most of the time. In previous versions, this was done with the SHIFT key, but it could collide with some keyboard shortcuts that use the SHIFT key as a modifier key.
*Fixed the mouse hit testing when the MagmaFlow Editor is docked as Extended Viewport.
*Added support for Schematic Flow as Extended Viewport, including correct right-click handling.

#1207

Hi Bobo I’ve been working through an old tut (below) on using Krakatoa to disintigrate the mini (yes you must be sick of that thing by now ;0) & I’ve run into a few probs.
http://www.studiodaily.com/main/training/Disintegrate-Geometry-Objects-using-Frantic-Films-Krakatoa-and-Autodesk-3ds-Max_10691.html

  1. Do you need to light the end PRT system to render it? When I do render with no light I get nothing in the render other than the Alpha. I thought the colour channel would take the material 100% Self Illumination & not need a light for the final render?

  2. As the PRT plays in the viewport the particles disapear as the deflector hits them but they don’t rise as they do in the PFlow but it renders fine though, whats going on there?

  3. At frame 69 I get a mass of particles appear up to the left of the PRT loader this doesn’t happen in the PFlow it’s set up the same as the tut so did I go wrong somewhere?

This is all on a flat plane using one image no fancy materials or rendering. Max 2011 x64 Krakatoa 1.5.1
Thanks peeps sorry for the newb questions.

Steve

#1208

No, you just have to enable >Use Emission and create a Global Channels Override to copy the Color Channel into the Emission Channel. This is because in 1.5.0 and higher, if you have no lights, no automatic self-illumination will take place.
http://software.primefocusworld.com/software/support/krakatoa/important_workflow_changes_in_krakatoa_v1.5.0.php#Default_Illumination

The alternative is to assign a Standard Material to the PFlow via a Material Static operator and put a Vertex Color Map into the Emission channel, then enable >Use Emission in the Main Controls. This will be a lot slower though.

  1. As the PRT plays in the viewport the particles disapear as the deflector hits them but they don’t rise as they do in the PFlow but it renders fine though, whats going on there?

The PRT Loader defaults to loading 1% from the BEGINNING of the PRT file in the viewports. Since the content of the PRT files is generally a good representation of the concatenated containers of all PFlow events, you usually get a small portion of the one side of the cloud and the moment the Deflector touches the particles, the order of particles changes. There are two solutions and both are slow - the one is to enable 100% in the viewport, the other is to switch to “Load Every Nth Particle” mode. Why these are slow is explained in the FAQ:
http://software.primefocusworld.com/software/support/krakatoa/frequently_asked_questions.php#Every_Nth_Particle_Is_Much_Slower_Than_First_N_Partices

This might be related to what you are getting in 3., but I cannot tell without knowing all settings. Does it RENDER right? If it does, then the viewport settings are probably what is causing strangeness.

#1209

Thanks Bobo I got the emission working now. If I save the emission channel then load the PRT file will Krakatoa read the emission channel with the Overide Emission checkbox or do I still need to apply a map in the Global override channel? Since the Emmision Channel will just add to the PRT file size.

As for the random particle mass appearing I’ll just cull them off if they get in the way. As long as it’s rendering ok it’s fine I guess.

What I’m planning on doing is emitting particles from a Spray Can, these then blow around to then form a final image.
Could you/anyone give me a few ideas on doing this?
Originally I was thinking of emitting the particles on a flat plane (as I have been) then using a find target to get them back into the Spray Can then load the PRT file & play it in reverse but I’m now thinking this isn’t a good idea.
So what would be the best way to emit particles using the Colour information from the final image & use the Position infomation from the final resting position so the particles find their original resting place to form the final image? I’ve done this with Max script but that was building a brickwall but it was very long winded & time consumeing (I’m not a great scripter) so I was hoping Magma Flow would be able to help in someway?

Thanks for the help as always!

#1210

If you have the emission channel already saved in the PRT, you can just turn on >Use Emission and disable the Override and it will work. The file will be the same size, simply the content of the Color channel will be saved in the Emission channel instead.

Originally I was thinking of emitting the particles on a flat plane (as I have been) then using a find target to get them back into the Spray Can then load the PRT file & play it in reverse but I’m now thinking this isn’t a good idea.

Interestingly enough, that’s what I would have suggested. I have done something like that before and it worked great. I even mentioned it in my blog in the beginning of the year…

#1211

Hey Bobo,

I a new user of Krakatoa, first of all congrats for the nice work !
I got a (stupid) question, I’m trying to render some particles from RealFlow and I was wondering if partitionning them makes any sense. I mean (and if I understood the tutorials correctly) since there is no seed attribute in the RF streams there’s no point in partitionning them right ?

Thanks for your reply :slight_smile:

#1212

Interestingly enough, that’s what I would have suggested. I have done something like that before and it worked great. I even mentioned it in my blog in the beginning of the year…

Great! Well at least I’m heading in the right direction s thats good to know thanks! =0)

Can you give me a link for where that is on your blog as I can’t seem to find it sorry Bobo.

Thanks

#1213

http://lotsofparticles.blogspot.com/2010_01_01_archive.html
Second paragraph.

#1214

Hi!

The question is not stupid at all. It is great you are asking it, because there are too many people out there posting RF+Krakatoa videos claiming they “partitioned” the particles, but in fact they got the same particles overlapping multiple times.

Your basic understanding is right, you cannot DIRECTLY partition RF streams.
But you can somewhat fake it using the High-Frequency Noise Modifier approach outlined here:
http://software.primefocusworld.com/software/support/krakatoa/partitioning_existing_file_sequences_and_vertices.php

The results will be similar to the illustrations shown in this OBSOLETE tutorial:
http://software.primefocusworld.com/software/support/krakatoa/partitioning_existing_file_sequences.php
The workflow should be taken from the first link, but the results will look like the ones shown in the second. Note that the produced partitions will have a fuzzy look, but if you are doing foam, it might work well…

BEFORE:

AFTER:

#1215

Hey,

Thanks for the quick reply Bobo. Nice trick indeed, the only issue is that I lose my vorticity channel in the operation :sad:

On another note, I’m trying to achieve sort of a translucent look (I’m rendering a river) should I do this directly from the material editor with basic shader tweaking or do you think it’s better via KCM ? (that’s a pretty open question :o)

#1216

You should not lose it if you have added it to the channels to save list.
Since Vorticity is not a default channel name, you can create a custom “Vorticity” channel of the same type as the one found in the BIN file and when you partition your PRT Loader+Noise Modifier to a new sequence of PRT files, the original value should be preserved.

To create the correct channel type, use the [>>] menu in the PRT Loader to open the File Sequence Manager and look at the exact name and type of the Vorticity channel loaded from BINs. Then create exactly the same channel in the Save Particles rollout and add it to the right-side list so it can get saved.

Does not matter - the Standard Material can affect the Color, Emission, Absorption and Density channels via its Diffuse, Self-Illumination, Filter and Opacity values, while the KCM can affect ANY channel. KCMs are generally faster and more powerful, while materials are more familiar. So it is a matter of taste if you are affecting the above 4 channels. If you have to affect any other channels, KCMs are obviously the way to go.
Note that the special Krakatoa Material is in fact a UI to a custom MagmaFlow that is as fast as KCM but appears in the Material Editor. The drawback is that it cannot be rendered by Scanline so no preview spheres…

#1217

Quick question. Very Noobish. Last night was the first night that I have sat down and played with krakatoa. For the life of me I could not get the max Gbuffer glow to work on particles in the render. are Gbuffer effects not supported in Krakatoa? Mainly I was trying to use lens effect glow.

#1218

Correct, GBuffer effects are currently not supported. What GBuffer channels were you interested in?

Keep in mind that even with the Render Effects supported in v1.6.0, the output does not represent the data fully since we are dealing with volumes and not surfaces. Thus, a pixel could contain data about 1000 particles behind it, but we can output data only about the closest one. So for example the Z-buffer is just an approximation of a surface rendering result, a Normal channel shows you the normal of the top-most particle but not the average of all normals of all particles that might be right behind it etc. (Talking about Particle rendering here, when using the Voxel rendering mode, the data of all particles inside a voxel is combined, so a pixel drawn by a voxel can represent more than one particle, but not data from voxels behind it).

#1219

I was trying to use the old school glow with out doing it in the comp. I’ve been stuck in gameland for 5 years and I was trying to replicate some magic style effects. I was trying to use glow to cause bloom or over exposure I guess I would say.

#1220

In the land of Nuke and Fusion, the built-in effects of Max are “a bit” limiting.
Krakatoa produces 32 bit RGBA and that is not compatible with the Lens Effects Render Effect.
Krakatoa doesn’t even work with Video Post as far as I can tell.
I don’t feel this will ever change since Video Post is on its way out now that Toxik is shipping as Autodesk Composite, and the Render Effects were DOA anyway even back in Max 3.0.

Sorry for the bad news…