Krakatoa

#1621

Now that’s something that would give me a fine jolt starting up :slight_smile:

#1622

Awesome… Is there a “Frost” one? :smiley:

#1623

This is strange, because I have heard of people having this issue (and it shows in Hristo’s Naiad demo videos), but it works perfectly fine on my system.

So I assume there is something related to 3ds Max viewport settings or something else that affects this.

Can you provide your specs?
Are you running Direct3D or Nitrous? What version of Max? And so on.

#1624

I was about to edit my previous post just before I see yours to inform that it seems that the problem disappeared so I don’t make people loose their time searching or trying to help for nothing. The problem went away by itself without understanding what happened. Anyway, it works fine now, we’ll see if it comes back in the future.
Thank you for your support.

#1625

Hi. Have a problem)

I can’t get ID channel from bin or prt from RealFlow. Particle Viewer shows it right but magmaflow says it’s not available or just 0. Maybe it’s because of int64 in RF and max int32 in krakatoa?

#1626

Hi!

We have posted a new release candidate build (2.0.2.46508) which was compiled against the latest Autodesk Max Hair SDK and should fix the 16+ cores crash in Hair.
Please test it with your machine and let us know if it solves the problem (we tested on a 40 core + HT machine and it worked for us).

http://www.thinkboxsoftware.com/krakatoa-downloads/builds-beta

The full Change Log is available here:
http://www.thinkboxsoftware.com/krakatoa-mx-202-change-log/

#1627

Krakatoa supports int64 (although it defaults to int32 when outputting).
How are you using the ID in the MagmaFlow?
If you are using Magma 2, what does the Magma Debugger say?

EDIT: I just loaded a simple RealFlow BIN sequence I had, added a Magma to the stack and set the flow to InputChannel:ID–>Greater (5000) -->ToFloat --> OUT:Selection and put a Krakatoa Delete to the stack. The particles with ID > 5000 got deleted.

#1628

We have posted a new release candidate build (2.0.2.46508) which was compiled against the latest Autodesk Max Hair SDK and should fix the 16+ cores crash in Hair.
Please test it with your machine and let us know if it solves the problem (we tested on a 40 core + HT machine and it worked for us).

I do thank you for this.
Being really busy, I’m not around krakatoa at all for my current projects, but I hope I’ll be able to help you in the future bobo.

#1629
  1. thanks for fast reply.
    i resimed test sequence and now particle viewer shows ID channel as int32 and it works well in magmaFlow mod. I don’t know why it changed from int64. But when it was, debug showed 0 or magmaFlow threw an error - “Channel isn’t available” even with simplest setup: InputChannel (ID) - > output (ID).

And i had to load sequence in pflow and saved as prt (it converted int64 to int32 automatically).

i will try to get the same error and will send you the file.

  1. is it possible to force InVolume to track mesh transform/change? I can think only about creating and deleting InVolume every frame via script handler. But it’s a bit silly)
#1630

This was a bug. We fixed it and the fixed build is available from
http://www.thinkboxsoftware.com/krakatoa-downloads/builds-beta
for testing. Please give it a go and let me know if it works now.

The full list of changes is here (as posted already):
http://www.thinkboxsoftware.com/krakatoa-mx-202-change-log

The major new additions besides the bug fixes are:
*Particle Data Viewer can now show either World Space or Object Space data from PRT objects
*Magma Debugger now shows Object Space data (as it should), used to show World space before
*Magma Debugger can now show every Nth particle and has an Update button.
*Shift+Ctrl+L can bring inputs to the left side of the Magma Editor. See View menu for options which inputs are affected, as well as sticky preferences.
*Several new (experimental) auto-reorder modes were added to the Magma Editor.

#1631

here is th file (prt, max, jpg-screenshot):
http://dl.dropbox.com/u/46208032/krakatoa_problem.zip

seems rf has id channel while krakatoa creates ID channel. “Match…” buttont doesn’t help.
i changed output to 64, changed input as custom channel “id”… it just creates second channel with 0 in it.

UPDATE: it seems i managed it=)
created input (custom channel “id”) - output to custom “id” - no double channels, no zeros. nice)

#1632

Installed latest build (beta) and “Add new custom channel” button in Save Particles rollout isn’t working. Just nothing happens (as in last final build). bug?

UPDATE:
Found in Krakatoa_GUI.ms that channel name must be > 3 characters. But magmaFlow mod doesn’t have such restriction.
Solved)

#1633

I am not quite sure why I limited it to >3. I will look and fix it for future builds.

You can add channels manually by editing the file “Krakatoa_CustomChannelsToSave.ini” found in the folder that opens when you click “Explore Folder…” in the “Presets and History” rollout of the GUI.

#1634

yes, look through 770kb .ms gives me a lot of knowlege))

thanks for fast response!

#1635

I’m stuck(

I have a sequence of prt/bin files from realflow and i want to assign the same color to particle with same ID through all sequence in Magma mod. Problem is that all queries work with index input which differs from file to file for the same particle.

What is Index? Just order in which particles are saved in prt file? And why PDW shows it as 1-based but all queries (particleQuery node for example) - as 0-based input?

Is there way to make Index = ID? (i’ve found that loading bin to pflow makes ID = index but i loose all my channels don’t know why)

Thanks in advance

#1636

Ok, let’ see.

The Index channel available as an Input in the Magma modifier is the internal loop counter. The Magma goes over all particles in order, and the Index just gives you a way to know the Nth particle you are working on. This is NOT used for operator inputs usually. We just felt it would be useful to have in some cases.

The Particle Data Viewer has a column called Index which has NOTHING to do with the Magma or channels. I should have called it Number or # or something to avoid confusion. Once again, it is the internal counter, so it reflects the First and Nth spinners. This is really just for reference to know which particle from the stream you are looking at.

Then there is the ParticleIndex output / input in the Object operators in Magma 2. The NearestParticle op for example outputs a ParticleIndex which tells an operator like ParticleQuery which particle to look at. Since ParticleQuery DOES NOT WORK on the current particle stream (the one the modifier works on), but only on EXTERNAL particle clouds (defined by the Particles input), the Index input of ParticleQuery is kind of internal and should be wired to the ParticleIndex output of the NearestParticle. You don’t touch that, and you don’t care whether it is 0-based or not.

There is currently no way to access OTHER particle than the one the current modifier is operating on. So a Magma modifier loops through all particles in the stream, and all channel inputs will read the data of the CURRENT particle. If there is an ID channel in the input stream, you will know what ID you are working on, and you could assign a color based on it. If there is no native ID channel coming up, the Index won’t help since it does not represent particle order between files, just the current iteration on the current frame.

If you can explain in a short list of steps or a pseudo-flow what you want to do exactly and if you can describe what channels really exist at the bottom of the stack, we might find a solution to your problem…

#1637

Thanks.
here is very rough preview of what i want:
http://dl.dropbox.com/u/46208032/3ak_texMelt.rar

I got only once though)
I think i can bake texCoords in RF with little python but want to try krakatoa for that.
Let’s say i have sequence of bin files (two emitters if it matters) from RF full of channels. Then load this two sequences in PRT Loader, create simple geometry that corresponds to shape of all particles in first frame (sphere in my case), generate mapCoords. Add Magma mod to PRT Loader, and rewrite texCoords channel with very simple setup:

Alternatively i use NeighbourCount channel.
This way i project UVW from sphere to outer particles. THen i just save prt file, load my sequences in first PRTLoader, saved prt with texCoords channel in second PRT Loader and want to find for every particle in sequences correponding (by ID) particle in prt with texCoords:

For particle in 1st PRTLoader get TexCoords from particle in 2nd PRTLoader where ID1 = ID2

But i can access particles only through Index input (in particleQuery op) and order in which particles load is different in every bin/prt in sequence.
So i need a way to get info from first frame prt (with texCoords applied) by ID

I managed this by loading first frame in pflow and saving prt, then added texCoords.
I don’t know why but pflow automatically rearange file the way it loads depending on ID (Index = ID). So this worked:

But it happens only once i and forgot the settings)
Anyway i don’t have access to realflow everytime i want so i need another method)

Thanks in advance.

#1638

You cannot do that currently using Magma. It was designed to be completely history-independent, and right now you cannot do things on a frame that depend on stuff that happened on previous frames. We had to assume that the particles would be completely changing from frame to frame, and there is no way to match IDs from one frame to another since chances are there will be a lot of particles without a matching partner.

In your case, you want to steal the UVs at Age 0 and then keep them around throughout the animation. I think this could be done using PRT Loader + PFlow. Both the Mapping Object operator and the Krakatoa Geometry Lookup operator (in KMX 2) have the option to acquire data only once when a particle enters the event. So you can set up a PRT Loader and a Krakatoa PRT Birth/Update/ID Test and whenever a new particle is born, it will enter the event, get its mapping once and then keep that value throughout the animation. The Krakatoa Geometry Lookup is available only in the commercial version of Krakatoa, but is much faster than the Mapping Object operator which ships with Max.

To do this in Magma, you would need a way to query info by ID (which you cannot right now), or have a Reference Position channel that contains the particle’s position on the reference frame on later frames (PRT Hair does this). I will ask the lead developer whether it would be possible to have a ParticleQuery by ID instead of by Index. It would be quite useful in some cases. But if new particles are born or die in the sim, there could be IDs that don’t have a corresponding reference particle in the other loader. So the PFlow approach described above would still be the better one.

Note that PFlow does NOT order the Index to match ID. When a particle is born, it gets the next highest ID. So if you create 1000 particles, you will have Index and ID aligned. But if you send particles out to other events, the PFlow system will concatenate the particle containers of all connected events, and the ID order could be different. If you delete particles, the Indexing allows no gaps, so again they won’t be symmetrical anymore. Only in a simplest One-Event PFlow you might get Index and ID matching.

Hope this helps.

#1639

Thanks again!

I will ask the lead developer whether it would be possible to have a ParticleQuery by ID instead of by Index.

This would definitly help.
Other things i dream about are inputs in Script node and ability to loop (for example to search through particles with given value in given channel))

#1640

You can search already. Get the input channel, make a compound condition with ‘more’, ‘less’ and ‘and’, so at the output you have 1 when the value is within an interval, and write that into the selection channel - then you can use that channel to do specific things with these particles.