guide for using partitions

Krakatoa for 3ds Max
1

Hi all -
Brand new to Kt and very limited knowledge of particles in general, but I’m working with the demo for now and trying to see if I can get it together well enough to do some wispy smoke plates for a job I’m quoting. Basically need a bunch of random smoke wisps, bang on to what is shown in the “fighting the grainy look” page in the KT help docs. The end product is just a still image, no animation needed other than to generate some smoke variations.

I’ve worked out a basic wispy smoke but I cannot really find any good handle on how to start using partitions to create smoother /less grainy versions. There is no real step-by-step so coming in raw I’m at a complete loss. Is there a tutorial somewhere that anyone could point me to? Basically need to figure out how to take a simple Pflow and go from there. I have read the docs as best I can, and have spent about a day messing with it now.

Any tips would be much appreciated.

b

2

Fair enough, the documentation of the partitioning process could use an update.

In the mean time, here are the basics:

*As you probably know, the main idea behind partitioning is that you can use a Particle Flow that contains Operators with a Random Seed (“Uniqueness”) parameter and produce many very similar but slightly different versions where the positioning of particles, application of random speeds etc. are randomized using an incrementing seed value.

So if you have something that looks good with 100K or 1M particles but you want to get the particle count up to 10 or more million, you can save 10 or more versions of the 1M system and combine them together.

To do this, all you need to set up is:
*Switch Krakatoa to “Save Particles To File Sequence” mode.
*Specify a saving path in the Save Particles rollout.
*In the Max Render Setup dialog, set the time range you want to process.
*Open the Partitioning rollout and make sure all the Operators you want to modify per partition are checked (they are by default).
*Enter the total number of partitions you intend to produce. The Max. is 100 and you can always set it as hight, but produce less actual partitions. The default is 10.
*You can specify a range to process at once, for example if the Max. is 10 and you enter 1 to 3, only the first 3 partitions will be processed and later you can continue with 4 to 10 if you like the results so far.
*Press the “Generate Partition Range Locally…” or “Generate All Partitions Locally” to either process the From/To range specified or all 10 partitions. Keep in mind you can cancel at any time so it doesn’t matter much.
*You will see Krakatoa calculating and saving the PFlow to disk, producing multiple versions of the same Particle Flow with incremented random seeds.
*If you have a good multi-core 64 bit machine with plenty of RAM, you could also save the scene, open two or more copies of Max, load the same scene and set the Range to different portions of the total number of partitions, e.g. 1 to 3, 4 to 6, 7 to 9 etc. and launch them all in parallel. This way, you can get the final results many times faster… (that’s what the Range option is there for actually).
*Once you are done calculating, create a PRT Loader at the world origin, pick ANY of the saved sequences and confirm the loading of all partitions.
*If you render the PRT Loader (disable the PFlow!), you should get a denser version of the PFlow combining 10 (or more) variations of the same flow.

Some notes for your particular case - if you intend to use a single frame and you know the exact frame needed, you can specify that as the only frame to save, but you will get a warning that two frames will have to be processed. This is because PFlow is too “smart” and refuses to update its random seeds unless two or more frames are being saved. Also note that while you might be saving frame 100, PFlow still has to preroll the 99 frames if emission started at 0 so you would save disk space, but not necessarily much time. Saving several frames might be a better idea so you can pick the one you like the most.

There are some more advanced features in there, but these are the absolute basics.
Please feel free to ask ANY questions here (even if you think they are “stupid”) so we can base the improvements to our documentation on your feedback!

3

In addition, if you want to learn more about using PFlow for effects creation, take a look at some of the tutorials on Allan McKay’s site:
allanmckay.com/site/index.ph … -tutorials

Specifically the Cigarette Smoke one:
vfxsolution.com/allanmckay2/ … esmoke.avi

and the Particle Dispersion one:
vfxsolution.com/allanmckay2/ … ersion.swf

4

Thank you for the detailed and quick reply - very much appreciated!
I’ll give it a try. Thanks also for the links. I was just digging around his site earlier today :slight_smile:

b

5

That explanation helped a lot - thanks Bobo.

A question about detail/res. I have posted one version of the test flow with 9 million particles and one with 29 million (more particles in the flow, and also a few more partitions). Clearly there is more and finer detail, but the overal grain structure is still quite strong. I’m wondering if that is really avoidable at this sort of res (rendering at 4K for now, but the job would be 6K). The times are going up a lot as well with partioning and rendering. Would I be better off to try and do this with voxel rendering instead?

Thanks in advance,

b

p.s You guys don’t mess around with your watermarking :wink:

6

As explained in the topic about fighting the grainy look, you have to reduce the global Density multiplier value in the Main Controls rollout / Final Pass area to make each particle less dense as you add more particles. This will give you less pronounced grain but in general a darker image. But the output is floating point (assuming you are saving to OpenEXR as you should) so you can tweak the final brightness, contrast, gain and gamma settings in post to get the result you want after the fact.

Also, you might want to try rendering at 3K and resizing up to 6K to see if the quality would hold up.
Higher resolutions always require more particles, and more particles need more time as you noticed.

Voxel rendering is generally a lot slower, but it does not leave gaps between the particles so it tends to be smoother as long as neighboring voxels are not empty. The result you would get from resizing a lower res. Point Rendering image to 6K might actually look sharper than voxel rendering, but you can try both…

Normally, we don’t render higher than 2K (or 4K for some IMAX projects), so I don’t have much experience with 6K stills :wink:

We stole the idea from Gelato. Given that you can do pretty much anything with the Eval. version, we had to do something about protecting the output.

You can request a 15 days trial license to get rid of the watermark if it turns out you have to render a final.
Btw, right now we are working on a movie with about 250 million particles per frame, at only 2K. The Red Sun explosion in Superman Returns had about 700 million per frame.
So you are just beginning to push the counts…

7

Thanks again for the quick reply.

I did try lowering the density but seemed to be hitting a point of diminishing returns. I thought it might shave a few hours of wasted time if it turned out that I was pretty much at the limit for smooth renders at this resolution :slight_smile:

I will push it along some more and see how it goes. I do not think upsizing from 3K to 6 will be a good way - from my experience with stills and grain it just gets lumpy, but not smooth. It would almost be better to go the other way, but the times would be pretty nasty.

I was really just joking about the watermark - I understand its necessity. I appreciate the offer of the evaluation license, but I can live with the marks for now. if I end up rendering a final for a job I would want to purchase anyway. That’s more fair from my POV :slight_smile:

Thanks /b

8

That’s not exactly what I meant.

Here is the deal: When you render at a lower resolution of 3K, and you have 30 Million particles, the coverage of the pixels is much higher - statistically speaking, each pixel is more likely to be covered by a lot of particles. Each particle is drawn into 4 neighbouring pixels (unless when using Nearest filtering), so the average result in the majority of the pixels will be much closer. When you increase the resolution to 6K, each pixel becomes equivalent to 4 pixels from the previous test. Thus the same particles have much lower chance to accumulate equally and you need at least 4 times more particles (120 Million!) to achieve a similar pixel coverage.

So it is quite possible that 3K or even 2K rendered with all particles you have at a very low density will look a lot smoother than 6K, thus resizing a smoother image would also produce a less lumpy image than you might think.

This is, of course, the theory. You can try rendering all particles that you have at 1K res. and see if you can get them as smooth as you want by gently adjusting the density. Then let the machine produce partitions overnight for 36 times the particle count and chances are the 6K image will look similar… I hope you have enough disk space :slight_smile:

Btw, your digital work looks amazing (went to check out your website, great stuff!). Did you by any chance work on that splash shot of the Advil liquid gels commercial?

9

Oh btw, the Fighting The Grainy Look example uses 100 million particles and the largest image shown is 800x1200 pixels!
It is fairly smooth, but it also means that rendering at 6K would probably require impossible 3.6 billion particles :wink:
So rendering 900 million at 3K, upsizing and probably running some post filters might be necessary in that case…

10

Image processing post-render is definitely the way to go here. A simple rank filter could be sufficient.

It’s worth noting that the randomization using Pflow noise seeds is just that, random. It’s not necessarily ideal distribution at any density, ala blue noise.

  • Chad
11

Thanks for the taking the time to look at the site, and for the kind words. Of course, I am familiar with who you are in the industry, and consider that very high praise indeed. I did not work on that Advil ad - I’m assuming it’s a tv spot? We only do print work here, but in any case, it’s not mine :slight_smile:

Regarding the sizing: I understand better what you mean - I was assuming there would still be some residual grain that would be enlarged, but if the base image is smooth enough then upsizing would be a solution. Particularly given the point about how many particles we would be talking about for 6K :open_mouth:

However, I followed your advice (and your tutorial more closely this time) and adjusted the density down and then opened the shot up in post. This is quite workable IMO. See attached - it’s a piece of a 4K render with the same 29m particles, but lower density by a factor of 10. I also gave it a slight surface blur in Photoshop. I think this could work just fine! I could easily add more partitions as well and still be within a reasonable range.

I need to do some more testing to get a better sense of the parameters, but I’m very confident that the job is doable with KT, even with my very limited skills here. I’m starting to think I might take you up on the evaluation licence though - I am getting burn-in of your logo in my retinas :wink:

Thanks very much again for the help, and thanks Chad for your reply as well.
b

12

Cool, looking much better!

Just submit a request using the form on the right side of the download page:
software.primefocusworld.com/sof … /download/

13

Well, after throwing about 60 or 70 hours into KT testing over the last few days it turns out the job was awareded to some guys in Milan. Drag. Anyway, I’m really loving what KT can do and think I’ll try and finish the image off to help with the learning process.

I’ve got a much better handle on the resolution issues now, but had another question about the KT collision operator. See the linked image for reference, but the concept is a shape (skull) forming out of smoke. I worked out a good way of getting most of what I need using a geometry and KT collision operator. What I can’t figure out is how I can use the KT operator in order to have particles “stick” to the geometry and continuing flowing along the geometry. If you look at the reference you’ll see it’s working okay, but the smoke is fanning off the surface more than I would like. Elasticity gives me more or less deflection off, but is there a way to have the particles hit an object and sort of roll along the surface to some degree?

I’m only just getting a sense of what KT is capable of and it’s clearly amazing, but also pretty dense for a particle newb like me to crack into. That leads me to two more questions if I may:

  1. If I were to buy it are there any Prime Focus people/experts here in Toronto that I could contact about a crash course in KT (paid, obviously)?

  2. Realistically speaking, without scripting am I going to be too limited in terms of what I can really create? I have no maxscript background and probably can’t devote the time to acquiring the knowledge (just too much already on the plate, and really not sure I am smart enough anwyay :wink:). Given the cost of KT and the complexity of the field, maybe I’m better off to outsource this kind of work? Just looking for some advice there really, but obviously it affects my buying decision too :slight_smile:

Thanks!
b

14

The Krakatoa Collision operator was meant as a replacement of the Particle Flow Collision operator which is very very slow, and neither does sticky particles. The main idea is that a particle hits a surface and the velocity changes according to the laws of reflection. If the outgoing speed is along the surface (as we have an option to manipulate that), you can kind of get close, but it is not the right operator to do it.
Max 2010 and 2011 ship with the Orbaz Particle Flow Tools Box #1 built in and it contains a Lock/Bond operator that is supposed to be used in such cases. Alternatively, the same company makes Box #3 which gives you a visual programming language for dealing with particle channel data in Particle Flow (but it costs as much as Krakatoa). We used Box #3 to do the particle behavior in G.I.Joe which called for crawling along a surface.
Look for examples of Lock/Bond on Allan McKay’s page, I am pretty sure he had a dripping system made with it that was quite impressive.

In general your particular problem is more of a Particle Flow nature and much less a Krakatoa-related one. The Krakatoa PFlow Operators are sort of bonus tools to expand PFlow to do the things we need in production, but not a full solution of all problems - Orbaz is the place to go if you need PFlow extensions.

Unfortunately, our offices are in Winnipeg and Vancouver, we don’t have any presence in Toronto, so there is no simple solution to this. Whether we can send anyone is something I cannot answer at this point.
My offer for remote assistance via Skype remains though :slight_smile:

While Krakatoa is half-script-half-plugin, it doesn’t require ANY MAXScript knowledge to operate. MAXScript knowledge is a good thing to have in general when using 3ds Max, but not something you really need. MAXScript in Particle Flow CAN be used but is very slow compared to the alternatives (incl. Box #3 I mentioned before) especially when dealing with millions of particles. I have two DVDs about scripting Particle Flow (https://www.cg-academy.net/es_catalog/product_info.php?products_id=74&osCsid=kgq1htts83pir1dujpkujht08bl0m8b5)and they are about going beyond what you normally do with PFlow. So I wouldn’t say it is a prerequisite, but it doesn’t hurt either.

Hope this helps.

15

Thanks - that makes sense. I had a look at Allan’s site but did not see that tutorial there. I will check again.

Much appreciated - and I may yet hit you up, but I was thinking of a fairly intensive overview which I think would strain even your generosity :wink:. I’m actually in Vancouver semi-regularly so that could work though, so maybe I can look into that option.

Helps a lot. I guess my question was poorly framed in that KT is not so much script-dependent, but particle work in general certainly appears to be. Everyone I see doing cool stuff with it appears to be using scripting heavily and I’m just not fully clear on what I will be able to accomplish with KT if I should buy it and learn it better, without having the capacity to script particle systems. The issue is that it would be such a small part of what I do overall that it’s hard to justify the time it would take to learn. Being in stills is quite a different beast, especially working in the Canadian market :slight_smile:

Thanks again for your time and assistance.
b