Death Eaters Smoke trail

#21

Without what tutorials exactly? There ARE tutorials about changing color or density over age.
I would love to see a list of things you feel are difficult and require more tutorials, or existing tutorials that are hard to follow.

In pretty much every post you say “it is not easy”. I beg to differ, but what IS easy in 3D? :wink:
Have you ever used a node-based editor (say, Eyeon Fusion, PFlow Tools Box #3, Thinking Particles, or Softimage ICE)? Were these easier to use and how exactly? What would you like to see changed in MagmaFlow to make it easier for you (besides better documentation which I admit could use an update?)

Thanks in advance.

#22

I really love node based.
I used to work with Fusion, now with Nuke.
The thing about Magma are the concepts, what exact parameter does and what connections are best. The tutorials from the website are really good but lack a bit the explanation on what parameter can do, perhaps I didn’t reach that part of the tutorial.
At the moment I can tell what you could improve just need a little more practice to get used to the system. The lack of tutorials like the ones from Allan Mckay for example, there aren’t tutorials like these don’t know why. CGAcaddemy have some very good tutorials on PFlow.
The tutorial I was talking was that example from the GIJoe production. I’m in that one at the moment. I say mostly it’s not easy because I’m a maya user for seveal years and a lot of the process are different.
I start with Max about 2 months ago.
I’ll keep you posted about my doubts.
Really appreciate all your help.

#23

Fair enough, and quite helpful feedback, thank you!
We are in the process of rewriting portions of the documentation for the upcoming 1.6.0 release (you might notice pages changing daily) and I will try to provide some more in-depth explanations.

That G.I.Joe “tutorial” was just a draft for my presentation at the Autodesk booth last Siggraph so I had to keep it short - I could go into more detail why certain things are done for sure.

Unfortunately, I cannot develop a MagmaFlow DVD for CGAcademy because of conflict of interests. As co-developer of Krakatoa, I am being paid by Prime Focus to provide documentation to all our current and prospective customers. Developing such content for a 3rd party publisher and caching in on my internal knowledge would be amoral.
So I will have to find time to do some recordings and publish them for free sooner or later.

Once again, thanks for the feedback and keep it coming.

#24

So I will have to find time to do some recordings and publish them for free sooner or later.

That would be awesome.
I’ll keep you posted of my progress.
Cheers

#25

I’ve started for some time with the Krakatoa tests.
But there’s one thing I’m not understanding.
The movement of the particles is defined by particle flow right.
I’ve made an smoke animation in Fume and after that I activated particleFlow (fumeFx follow and birth) an then Krakatoa. Well when I made the partitioning in Krakatoa the simulation was completely ruined.
I’ve noticed now that the velocity channel wasn’t activated on FumeFx, is this an important subject?
Thanks
Cheers

#26

The velocity channel is required for the particles to actually follow the simulation… sooo yeah it’s important. :thumbsup:

#27

One thing I’ve noticed that sometimes they blow out the FumeFx simulation.
Why does this happens?
Should I increase the number of particles?

#28

They’ll blow out because the influence is probably a little too high, and/or because your sim just gets close to the edge of the grid, if a particle gets a velocity from the grid that’s high enough, it’ll escape the grid… the simplest solution is to turn down the influences, or just turn on the option that kills the particles when they exit the grid. You could also do some fun stuff with scripting (or box3 preferrably) to tell the particles to head back into the grid if they are getting too close to the boundry.

#29

Scripting at the moment it’s not my field.
But I tend to activate that option that says to kill the particles that go outside the container.
I’ll check that influence parameter.
thanks

#30

I’ve created smoke in FumeFx.
I really liked the look but I wanted to see how it behaved in krakatoa.
This isn’t the first time an animation I make looks very bad when I try to render it with Krakatoa. The rate in ParticleFlow is 200000. I think this is high enough to get detail.
In the part of the channels in Particle Flow I only have the smoke activated and the max value is 40 and the min is 1.
I have a spotlight in the scene but it doesn’t seems to have any affect on the particles.

#31

You need a lot more particles in your krakatoa render, try starting out with 2 million and work up from there. The idea is to achieve a really dense cloud that is more representative of smoke, rather than dust.

Give this a read: :slight_smile:
http://lotsofparticles.blogspot.com/2009_11_01_archive.html

#32

I’ve been reading this post from Bobo:
Back To Basics - Krakatoa Best prectices for fast iterations

My question maybe a little stupid but just wanted to make sure.

For example, if you have 4 cores, you can open 4 copies of 3ds Max and let the first one partition from 1 to 3, the next one from 4 to 6, the third one from 7 to 9 and the last one from 10 to 12. After about the same time it would take a single copy of Max to create 3 partitions you will have 12 and all cores will be used.

To do this I have to define for example that the Partition Count will be 10 and after that the Partition range is defined right? But in all the different copy’s of Max the value of 10 has to be there. I’ve made this.
To test it I put in the Particle Count: 6
Partition Range from: 3 To: 4.
But When I click Generate All Partitions Locally they all start with 1.
How can I do what Bobo is talking about?

Sorrrrrrrryy my problem.
I’ve just noticed that I have to click on Generate Partition Range Locally.
Sorry

You need a lot more particles in your krakatoa render, try starting out with 2 million and work up from there. The idea is to achieve a really dense cloud that is more representative of smoke, rather than dust.

I’ve increased a lot the number of particles and when I start to render, after 10 minutes krakatoa gives me an error message saying “Bad allocation”
Why is that?
Cheers

#33

Are you using a 32 bit version of Windows and/or Max? If that’s the case, then no wonder.
Even though you can allocate up to 2GB of RAM in Windows 32 bit, 3GB with the switch or 4GB when running 32 bit Max on 64 bit Windows, there is an additional limitation to memory usage in 32 bit - when Krakatoa, Max or any other program requests a chunk of memory, it has to be contiguous. When the memory allocation requests come in small chunks, Windows can fit them between existing ones even if memory is severely fragmented. But if the requested chunk cannot fit anywhere, you get an error.

In contrast, on 64 bit Windows with 64 bit 3ds Max, even if you have only 4GB of physical memory, the maximum addressable memory space is so huge that the memory manager can pretend the memory were contiguous even if when it isn’t and with a little paging (which makes things very slow) ensure you get your memory. Thus the only crashes you could get with Krakatoa 64 bit are related to actual bugs in the software (there are not too many of those) and never due to memory allocation issues.

During the last couple of years, the idea to discontinue Krakatoa for 32 bit Max has popped up often, but so far we provide it just in case. But we DO NOT RECOMMEND using it for anything.

If you were using 64 bit Max and you still got an error, please report it as a bug.

As for the partitioning, the Count value defines the total number of partitions that will be created. If you hit the “…ALL…” button, all partitions will be saved in a row. But if you would open several copies of Max on the same machine or multiple machines and want to save 1 and 2 out of 10 on one, 3 and 4 on another etc., then you can set the Range to a sub-set of the total count and press the “…RANGE…” button.

#34

Thank you Bobo.
I’m in Windows 7 64 with Max 2010 x64.
I’ll try to explain what I did.
I’ve increased the particle rate up to it’s very limit - 9999999999999999;
I’ve noticed that particle flow started not to update it’s particles, even when I had only had 1% of the viewport active in the quantity multiplier. If I scroll the timeline the particles would stay only in a certain point. Maybe the problem is related with ParticleFlow.
So initiate Max again and started rendering with Krakatoa.
This happened when I did this.
I decided to save the particles to Disk and then after some time this happened again.
The version of Krakatoa is the 1.5.1.

One thing that I noticed is that I tried to render only the FumeFx, without the particle flow, I activated the FumeFx option and them when I press render it appears Krakatoa Error.
–Argument count error: GetPath wanted 1, got 0

Whys is this?
Thanks

#35

First of all, if you are rendering directly from PFlow, Krakatoa and PFlow have to share available memory. I am quite sure Krakatoa cannot run out of memory on 64 bit machines (I have pushed it well beyond my available RAM and while it slows down to a crawl, it does not crash). So I am not sure what is going on there, but keep in mind PFlow has certain technical limits (Oleg knows the details better, but I think it breaks around 100 million particles).

You should ALWAYS save to PRT files (saving uses no memory on Krakatoa’s side, only PFlow will use memory). After creating as many partitions as you need to get the density you need, load with a PRT Loader and check the memory requirements in the Channels rollout (there is a calculator there to show you how much memory you will need). I have 12 GB here at home and can fit nearly 500 million particles at default settings (600+ MP in the office with 16 GB RAM). How many did you make?

As for FumeFX, I thought it was obvious that Krakatoa was compiled against a specific FumeFX version (1.2) and cannot work with any other version until we buy the FumeFX 2.0 SDK and recompile Krakatoa to support it. This is because Krakatoa actually calls functions inside FumeFX and there is no general version-independent way to get that data. But judging by the number of people asking about this, it looks like it was not obvious after all… :slight_smile:

#36

You’re trying to birth a 9 quadrillion particles per second? (literally, that’s called quadrillion!)

#37

Probably the problem is in the PFlow side.
I can’t even save the .PRT files Bobo because it gives me that error.
Perhaps I’m using too much particles and I don’t need too many because I can crank them up with Krakatoa with the partitions.
For example at the moment I’m using 200000000 in the rate and I’m not getting any problem.
Maybe this is too much or a good starting point.
Cheers

You’re trying to birth a 9 quadrillion particles per second? (literally, that’s called quadrillion!)

Loool
I’ve seen in a tutorial if you place a number like that, ParticleFlow would replace it with the max number of possible particles.

#38

That number looks a lot like our national deficit :smiley: or oil company profits!

Baby steps young Jedi :wink: that is quite a huge jump from 200 thousand, although I think it should get you the density that you need :smiley:

Also take a look at Bobo’s High Frequency noise for PRT tutorial, you can somewhat cheat your Pflow particle counts, using less pflow particles and more partitions.

Also note you can have a viewport visibility rate of 0.001, which I in my humble opinion should go as low as 0.00001 or less considering some of the outrages particle counts you can use.

#39

Great lol
You are completely right.
At the moment for the death eaters smoke trail I’m trying to create something similar to that ink effect that Bobo showed me in a previous post.
I’ve started to create some tests.
I’ll post them as soon as I can.
If someone can give an hint that would be great.
Cheers

#40

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.