View Full Version : SetParticleMapping and Cache/Krakatoa

08 August 2010, 06:09 PM
Hey folks,

Running into an interesting problem. Using 3dsMax 2010 x64 SP1, and I have a fairly simple script op that sets the particle mapping u and v based on the particle ID. The script works fine but when i go to cache it and reopen the file, the cache says it has information in it but the viewport does not display the particles!

I have narrowed this down to whether or not the script is using the particleMapping property or not. I've tried storing the mapping coordinate in the vector channel, this caches just fine but when I put a script op on top of the cache to grab the vector, no go. In fact, putting a script operator in the global event seems to do absolutely nothing when local events have caches feeding it.

Here is the script that is giving me problems:

on ChannelsUsed pCont do ( )
on Init pCont do ( )
on Proceed pCont do
count = pCont.NumParticles()
pCont.useMapping = true
loopu = 50000
loopv = 1000
for i in 1 to count do
pCont.particleIndex = i
fr = pCont.particleID + 6000
remu = mod fr loopu
remv = mod fr loopv
u = remu / loopu
v = remv / loopv
pCont.setParticleMapping i 1 [u,v,0]
on Release pCont do ( )

Any ideas?

Also, using Krakatoa to cache yields some strange results with this setup. I have a scene where I'm using just a bunch of forces, and that caches out and load just fine (with Krakatoa), with PFlow correctly placing a particle at each visible particle loaded. But when using a Speed By Icon and this script (I haven't fully narrowed down what the culprits are, just noticing that Speed By Icon causes problems when this is done), I cache out load the particles in via PRT loader, all seemingly coming in just fine, and PFlow places particles correctly at each loaded particle on the first frame, but as I scrub it starts omitting particles!

I'm pulling my hair out on this one, any help is much appreciated!

08 August 2010, 06:47 PM
First thing that looks wrong is that the mapping channel is not enabled in the right handler:

on ChannelsUsed pCont do
pCont.useMapping = true

As for the Krakatoa problem, I would like to ask you to describe it again, but this time with short sentences, explaining every step. I could not understand a thing from the current explanation.

Something like:
*I set the Channels To Save in Krakatoa to Position, Velocity, ID, TextureCoord
*I save the PFlow to PRT file sequence.
*I load the PRT file sequence in a new PRT Loader
*I set the PRT Loader's Viewport % to 100.0
*I drag the time slider and ...

In case you are loading the PRTs back into PFlow and the problem arises there, please mention that...


08 August 2010, 08:20 PM
Hey Bobo,

I tried putting the useMapping where I thought it should go, ultimately using what was written in Oleg's example script op instead of the documentation.

-- // to use in Proceed method
-- .useMtlIndex: bool: Read|Write
-- .useMapping: bool: Read|Write

Same result, the cached file opens and if it was cached with that script op on, nothing shows even though the cache says it has information in it.

As for the Krakatoa problem, apologies for the run on sentences. In writing up this explanation I have found where the problem creeps in. I have successfully loaded in 2 of the 3 flows. The 3rd flow is the only one that doesn't start with particles at the first frame. Apart from that I can't find any difference that might be causing this issue.

Global note: All PF Source objects are set to display 100% in viewport and render and have the same integration step of 1 frame.

1) I have a 3-4 event based PFlow chain, it has that very script op in the birth event.
2) I save particles to disk using Krakatoa, including the following channels: Position, Velocity, Color, Scale, ID, TextCoords, Orientation, Scale, Age, Lifespan (went overboard here just to made sure I had all relevant data, I really only need the Position, Scale, Orientation, ID, and Color)
3) I create a PRT Loader, load up my particle cache, set viewport display to 100
4) All the particles appear correctly - an interesting note:
- The particle color corresponds with the assigned texture coordinate and diffuse color from the script op when the particles were cached
5) I create an empty flow with a Krak PRT Birth and Krak PRT Update
6) I select my PRT Loader in both ops, but the only channel that shows up in the Krak PRT Update is Color.

I have re-saved this flow dozens of times, making sure that all the channels I want are correctly added when caching, and still only the Color is showing up. The other two flows work perfectly (thank GOD for Krakatoa!).

Again any help on either matter is greatly appreciated!

08 August 2010, 08:58 PM
I think there was a bug logged against problems when the first frame contains no particles, I think the PRT Loader wasn't loading the channel definitions correctly in that case. I am quite sure it was fixed for v1.6.0, but I have to check.

What build of Krakatoa are you using?

The Krakatoa PRT Update operator will only show channels that it knows how to load back into PFlow. Thus Age, LifeSpan etc. don't show up since they are controlled internally by PFlow.
I am not sure why the TextureCoord channel is not being loaded back (I discovered it myself two days ago and have to check with the developers).

Also, if your particles die during the animation, don't forget to use a Krakatoa ID Test to send them out to a Delete event when reloading...

I have mentioned this a couple of times elsewhere - saving PRTs is NOT equal to caching the particles. The fact that you can reload the particles back into PFlow doesn't mean it is always a Good Idea. It makes sense mainly when you want to apply deformations or other similar modifications to the particles or render pre-saved particles as shapes, or apply new forces that were not known when the PRTs were saved. I wouldn't recommend the Krakatoa PRT Birth/Update as a general caching mechanism since it has limitations, drawbacks and some issues.

08 August 2010, 09:03 PM
Thanks for the fast reply Bobo. I set the PRT loader to load in just a single frame and sure enough the channels came in correctly. I am using build, which appears to be the most current available from the Prime Focus site. Is 1.6 located somewhere special?

edit: I would absolutely be using the out of the box Cache op if it worked with that script that I posted, but I have no clue why that isn't happening.

08 August 2010, 09:08 PM
Thanks for the fast reply Bobo. I set the PRT loader to load in just a single frame and sure enough the channels came in correctly. I am using build, which appears to be the most current available from the Prime Focus site. Is 1.6 located somewhere special?

Yes, we published a public invite to Beta test 1.6.0 a month ago via most 3D sites.
If you have a login for our support forum, PM me with your user name and I will add you to the Beta list so you can pull the latest Beta build (we will be posting a new one in a day or two that adds FumeFX 2 support and some more stuff).

CGTalk Moderation
08 August 2010, 09:08 PM
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.