[Beta 9] No Krakatoa Geovolume modifier for max 2010

Hello,

I am running krakatoa on max 2010 now… Scene I am working on , i am doing thick smoke but I don’t see Krakatoa geo volume modifier in a modifier list neither in rendering options for “render geo volume”…

Is it not working with max 2010? or it’s now implemented another way in beta 9?

Thanks and Regards,
Jignesh Jariwala

Read the Release Notes. :slight_smile:

GeoVolume Modifier was replaced by a PRT Volume Object (found in the Krakatoa category where the PRT Loader lives).
The difference - the object lets you pick a geometry object as the source and creates a visible particle system in the viewport.
*You can add KCMs on top of it to modify its channels interactively.
*It can be bent and deformed as a regular object.
*It acquires channels as needed on the fly and twice as fast as the modifier version.
*It can be transformed independently from its source, so you can move it, rotate, scale it, keyframe it etc. and it will be independent of whatever geometry you selected.

Now you can work with KCMs in the viewports without having to dump the particles to PRT and load them in a PRT Loader first.

In the next beta, we will be adding more UI goodness to it, like separate viewport Voxel Length controls for faster and independent viewport performance and better Voxel Length limits to avoid hanging up Max with impossible counts. It will also respect Standard and Krakatoa Materials correctly and acquire Colors from its Wirecolor, Material or the Color Channel of the source geometry. Also a bug will be fixed which prevented the conversion of Thinking Particles and Legacy Particle Systems to PRT Volumes in Beta 9.

Unfortunately, existing Beta scenes will have to be edited to replace the GeoVolume modifiers with PRT Volume objects. Note that we provide a MacroScript for quickly turning the selected objects into PRT Volumes. Sorry for the inconvenience, but I hope you see why the new approach is a better idea.

thanks … I found it now…

So do I have to create mesher object as well? or can I directly add pflow system to it?

I selected pfsource object in PRT volume, and when I clicked render, it stayed on “Retrieving particles” status…and nothing happening…got freezed i guess. Is it bug?

I believe I have to make mesher for this too.

For PFlow, you need a Mesher. It should not crash though. I tried it yesterday and it simply did nothing.
In Beta 10, all other systems (TP, Legacy etc.) will work directly with the PRT Volume.

Note that there is a crasher bug in saving Attenuation Maps in Max 2010. If you check the Attenuation saving option, it will crash Krakatoa. The same applies to v1.1.3 we posted. This is related to a wrong version of OpenEXR libraries and is being fixed as we speak.

yes for pflow, I wasn’t using mesher and I directly selected pflow source in PRT volume. and It was freezed there.

Also in PRT volume, can I lower the limit of particles with that limit multiplier? Coz in the scene I was working required geosphere with radius of 90 and it took very long for PRT volume to fill those spheres volume with particles.

The Limit is used only to limit the amount of particles drawn in the viewport. It does not affect the Level Set generation process (which is a sort of voxelization of the geometry before we can figure out where to put the particles). So it is meant to reduce the load on the graphics card if millions of particles are requested, but it does not speed up the conversion process. The size of the bounding box of the object vs. the Voxel Length (which will be called “Spacing” in Beta 10) defines how long it takes to convert. For example, if you have a Geosphere with a bounging box of 100x100x100 and a Spacing of 1.0, you are looking at creating up to 1,000,000 voxels, then filling some percentage of them with particles. But if the Spacing is 0.5, you are looking at 200x200x200 or 8 million voxels. Then every particle that falls in an inside voxel has to fill its channels with data which also takes some time (my benchmarks show that it is about twice as fast as it was in GeoVolume days).

So for Beta 10, we will give you a separate Viewport Spacing parameter you can set to some high value like 5 or 10 and get a few thousand voxels while creating millions at render time. Also we made the right-click on the spinner arrows reset the Spacing to 1.0 instead of 0.0001 which would kill Max instantly. There will be some other additions like the ability to disable the Material in the Viewport for KCM work (same with PRT Loader), an update button to force a refresh when needed etc.

Also I wish there is an option to cancel voxel calculation for PRT volume by pressing esc. If I have set lower voxel lenght, it takes time to make volume… By simply pressing esc , we can quit the calculation if possible?

“Simply Pressing Esc” is unfortunately not so simple (at least in Max). It is possible, but might have to wait until the next point update. We have a long list of wishes and ideas that have been pushed to 1.5.1 or whatever it will be called. There are some major things to polish in this release and we have 10 days left, so for now just be careful what values you enter.

I am sorry, I might sound like harsh and a bit disrespectful to your guys effort.

But I wished like we can cancel pflow update and something like that with PRT volume. I guess it was working with Krakatoa geovolume(it was calculating and showing particle counts) before when I tried. But not sure.

Don’t worry, no offense taken. We do what we can with the resources we’ve got.

The GeoVolume was a Scripted Modifier. It was showing counts via a scripted function that was calculating the volume of the bounding box, the volume of the mesh and trying to figure out the ratio to show you some numbers. The GeoVolume did nothing in the viewports, so there was nothing to cancel, and it could not be canceled during rendering.

The PRT Volume is a C++ plugin and designing its UI is a PITA, but it makes it faster and more useful since it generates particles in the viewports and can show colors, can be deformed by modifiers and edited by KCMs and so on.

PFlow cannot be canceled while it is rendering, only (if you are lucky :wink:) in the viewports. We talked to Oleg and he said he could not do it at render time due to Max system limitations.

We will try to make the PRT Volume safer as time passes by. One thing I could do when using the GEO MacroScript we provide is calculate the bounding box of the selected object and set the Viewport and Render settings to reasonable values while making the PRT Volume. Of course, people would have to learn to use the Macros we ship for this to help them, from our questionnaire it looked like most people don’t know how to use Krakatoa to its fullest :frowning: