particle flow synchronize layer not working

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 08 August 2012   #1
particle flow synchronize layer not working

Hi guys, i am trying to organise each of my particle flow system into different layers. However using the synchronize layer doesn't seems to help. The hidden "helpers" still remains in the default layer instead of moving to the layer where i put the PF source.

I am using 3ds max design 2011 btw.

For testing, I tried creating a standard particle flow system in default layer, shifted the pf source to a new layer then used synchronze layer. Only the "event" was moved to that new layer. The rest of those hidden helpers still remain in default layer thou.

I got a scene where i got several particle flow systems which i want to organize into each individual layer. Any ideas? thanks
 
Old 08 August 2012   #2
Hmm, not sure there is an "easy" 1/2 click way to go about it.

Selecting everything and moving it to a single layer is a snap but by individual flow could prove a bit difficult. Gees I seem to remember a while back that Outliner used to list everything, it no longer does, I ask if it could be added as a settable option.

You might try:
  1. Saving out each flow to an individual file via the particle view->Selection Menu->Save Selected (obviously select the source and its children in the particle view first)
  2. Then open each saved out flow in a new instance of max
  3. Organize to layer either by hand or via script
  4. Save and re-import to parent scene
You do it all via script. I think it would/could get tricky of course by how organized your systems are.
__________________
poof ~>Vimeo<~
 
Old 08 August 2012   #3
Thanks. It works. Thou troublesome, but helps. Thanks
 
Old 08 August 2012   #4
I wish there where a better way, my typical course, Pflow is always on the default layer just because of this, it is pretty messy when you get into some complex systems.

I tried writing up a quick script to do the job but quickly noticed there is no hierarchy in the pflow system. Meaning I was hoping I would be able to see the children of a PF Source. That is not the case, the only parent/child relationship lie between PF Engine and PF source and unfortunately that is where it ends

Since naming conventions vary from person to person, I can't think of a way to make this work via strings unless the naming convention of the child events/operators/ect. where to correspond with the parent Source object. That in itself, to rename the systems/events/ops, could easily take as long as the export/tweak/import method I mentioned earlier.

I will let it brew see if anything else comes to mind, it is a good idea for a utility.
__________________
poof ~>Vimeo<~
 
Old 08 August 2012   #5
It wouldn't be overly hard to script, because all operators are linked to one of two objects (Particle Flow Source or Particle Flow Event). From within either of those you can use the ActionList interface to get access to any sub-Operators/Tests/etc. So using a simple loop of all objects testing for Event or PF_Source will get you all containers where Operators can live. Basically this code should sync all operators to the layer of the event or pf source they are attached to:
-- Get all Operator Containers PF Source or Event
pf_containers = for o in objects where (classof o == Event) OR (classof o == PF_source) collect o
-- Loop through the Containers
for obj in pf_containers do (
	-- Get the layer of the Container
	pfLayer = layermanager.getlayerfromname obj.layer.name
	-- Loop through the actions assigned to the container
	for val in 1 to obj.numActions() do (
		-- Get the Operator
		pfOp = obj.getAction val
		-- Assign Operator to the same Layer as the Event or PF_Source it is attached to
		pfLayer.addnode pfOp
	)
)

-Eric
__________________
"The Evil Monkey hiding in your closet."
 
Old 08 August 2012   #6
Ah I had this nice long descriptive post and my system just crashed anyway...

Eric that was close but it doesn't seem to work fully if I print out the returns it looks like it should work. It move the ParticleGroup to match the source but oddly it won't move the ops.

So you made me feel bad for not even trying, so I put this together. It is similar to yours except I am grabbing the ParticleGroup as a roadmap for the events. So now it checks the source and events against the particleGroup so it knows which source each event and ops go to.

This only works when the Source is on the layer, if it has been synced this will move the particleGroup to the same layer as the source and may not work. Simply move the Source to its own new layer and it will work properly. I added feedback to the listener so you can see how it mapped.

NOTE: it won't move dependencies like position object reference geo, or others similar external ref objects.

EDIT: Attached Script Below
__________________
poof ~>Vimeo<~

Last edited by JohnnyRandom : 08 August 2012 at 04:53 PM. Reason: minor script fix
 
Old 08 August 2012   #7
Your code is erroring here in the src loop.

-- Unknown property: "name" in undefined

-Eric
__________________
"The Evil Monkey hiding in your closet."
 
Old 08 August 2012   #8
Hmm, maybe a bad copy/paste? It seems to be working here, on a different machine than I wrote it on and thankfully works in max2009. I only tested in 2013 last night.

Here is an .ms of it.

I managed to figure a way to get the pf arrows to move to the correct layer too. The only thing I think it may need is an option to move all external dependencies. Particle View remains on the default layer but this is rebuilt by default when there isn't one in the scene.

BTW thanks for the iterator idea, for some reason it never occurred to me to use a more descriptive for-loop iterator, makes it super easy to trace nested loop iterations.
Attached Files
File Type: zip PF_Moverator_v100.zip (1.1 KB, 25 views)
__________________
poof ~>Vimeo<~

Last edited by JohnnyRandom : 08 August 2012 at 05:09 PM.
 
Old 08 August 2012   #9
Thread automatically closed

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.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 05:42 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.