Jump to content


Photo

Quick Defocus For Particles

Macros Particles Gringo

  • Please log in to reply
20 replies to this topic

Poll: Quick Defocus For Particles (27 member(s) have cast votes)

Would you like to have such a macro for defocusing?

  1. Yes (25 votes [92.59%] - View)

    Percentage of vote: 92.59%

  2. No, I prefer post-defocusing with all its edge artifacts and transparency troubles (1 votes [3.70%] - View)

    Percentage of vote: 3.70%

  3. No, I prefer slow true 3D defocusing (1 votes [3.70%] - View)

    Percentage of vote: 3.70%

  4. No, I prefer native 2D particles soft DOF (0 votes [0.00%])

    Percentage of vote: 0.00%

Vote Guests cannot vote

#1 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 04 May 2010 - 03:45 PM

Hi!

I was recently working with sparkles and came up with a solution which lets you make DOF effect on such kind of particles very quickly.
Ultimately, to mimic the DOF effect on sparkles, you only need to alter their size and transparency according to the distance to the camera. Performing this operation with a pCustom doesn't take any considerable time and defocused sparkles are being rendered as quickly as basic ones.

The only difficulty I experienced was I had to redefine all the size and color variation parameters in this very pCustom.
When you use size, r, g, b, a and other particle properties, you actually refer to these modified by the pCustom in the previous frame, which is sometimes just what you need, but in this case isn't desirable.
So, I was unable to just modify these properties because of the modifications accumulated from frame to frame.
It would be great if pCustom could refer to the original properties.

http://www.compositi...klesDefocus.mov

Attached Files



#2 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 04 May 2010 - 04:05 PM

The only way you could refer to those properties is to embed them into a new data channel that doesn't change. You can't make new particle channels in Fusion, nor can a particle system sample data from another particle system by ID (pCustom can only refer to 2 images, not another particle system). Either or both of those options would be desirable outside your use case.

- Chad

#3 rubberduck

rubberduck

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 157 posts

Posted 13 May 2010 - 03:52 AM

Hi Gringo,

Any change I could take a look at how you did that in the pcustom tool? Would be helpfull here!

cheers,

#4 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 13 May 2010 - 06:00 AM

Hi!

No problem. I'm going to need more of this effect soon myself, so, I'll share a macro.

#5 rubberduck

rubberduck

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 157 posts

Posted 13 May 2010 - 06:46 AM

Can't wait to see it!

#6 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 13 May 2010 - 07:34 AM

I'm curious too. I wonder how quickly the float32 values break down and accumulate too much inaccuracy to be useful. It's not something we usually worry about.

#7 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 13 May 2010 - 09:01 AM

Here is the macro and an example composition:

Attached Files



#8 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 13 May 2010 - 12:51 PM

Here is the macro and an example composition:


Says particle tools cannot be branched... weird.

#9 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 13 May 2010 - 02:01 PM

It happens all the time when particle tools are enclosed to groups or macros. Annoying.
Can Eyeon resolve that?

Actually, the best solution would be to allow branching for particle tools.

#10 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 13 May 2010 - 02:27 PM

Actually, the best solution would be to allow branching for particle tools.


But how would you iterate? By sets?

- Chad

#11 rubberduck

rubberduck

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 157 posts

Posted 13 May 2010 - 02:56 PM

Thanks!
Looks promising

#12 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 13 May 2010 - 04:21 PM


Actually, the best solution would be to allow branching for particle tools.


But how would you iterate? By sets?

- Chad

I'm not sure I see a problem. Branched particle tools would behave just like their instances.

#13 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 13 May 2010 - 05:33 PM



Actually, the best solution would be to allow branching for particle tools.


But how would you iterate? By sets?

- Chad

I'm not sure I see a problem. Branched particle tools would behave just like their instances.


But as your issue illustrates, the particle data isn't passed once, it iterates for every timestep. If it branched, the particles from both ends would have to repeat through. You'd need some way of keeping them "separate" even though they were the "same" particles.

- Chad

#14 rubberduck

rubberduck

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 157 posts

Posted 19 May 2010 - 03:42 AM

Hi guys,

Just to check. As mentioned, when I use this pcustom-fast defocus macro, I get and error "particles cannot be branched". When I render this comps with the Fusion render manager, I get this messages as well. But Fusion keeps on rendering the comps (I just need to click the error messages away in the morning.
But when I render this comps using the generation farm manager (which uses the console-render), the renderclient keeps on crashing. This is kind of shitty, because using the generation manager would be very nice (it keeps the organisation of the project a lot easier, then manually submitting the comps, one by one, to the Fusion manager).
Anybody any idea what can be the solution here? Some generation guru maybe has an idea?


cheers

#15 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 25 November 2010 - 06:29 AM

I believe, this happens because in any macro output of the last tool has to be instanced to be exposed outside the macro.
Would be nice if Eyeon made an exception for particle macros. "Particle tools cannot be branched, but virtual branching of the output is OK".

Otherwise, I can suggest unwrapping the macro and using the tools from it as a setting.





Also tagged with one or more of these keywords: Macros, Particles, Gringo

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users