PDA

View Full Version : shooting sparks



Jakkar
06-24-2008, 12:25 AM
I have a job that requires sparks shooting our from train wheels as it slams on its brakes. This is not the first time. I was given this grinding wheel photo as reference.
Has anyone been able to duplicate this look?
Try as I might, I can't get particles to take on this appearance. Even with photoreal motion blur, stuff traveling this fast has very angular and faded blur instead of these bright, curving paths. I think it has to be done with a cheat.
Appreciate any help...

voriax
06-24-2008, 02:01 AM
Tough one.. You can get so close using particleFX but you can't do the curving paths with particle blur.
I'm getting (sorta) close by using highly luminous objects linked to a particle emitter, with high PR blur and multiple blur passes. That will allow you to get the curved motion.

Maybe it's just not possible in LW though...

RebelHill
06-25-2008, 06:23 AM
Photoreal MB should deal with things using HDR values... u can either use objects attatched to particles, or the particles themselves I would have thought... and turn their brightness/luminous way WAY up over 100%, and prmb ahould create this streaking for u.

JeffrySG
06-25-2008, 08:01 AM
Just a though:

Would there be a way to use some wind emitters to push different groups of sparks into slight arcs like that?

Ty Catt
06-25-2008, 10:58 AM
I agree with JeffrySG.

I think you can use several different wind emitters with varying degrees of strength.

Also, the Proton Videos have a tutorial with water flowing through pipes using several "guides" to control the water flow.

May be worth checking out to see if would work for you, too.

Good Luck.

Jakkar
06-25-2008, 11:51 AM
Ok, the problem isn't how to vary the paths, that's pretty basic with particles and wind. :rolleyes: Maybe I didn't explain it well. The problem lies in getting the motion blur to render the arcing path properly. Moving an object very quickly and rendering one frame with photoreal motion blur works well. But when you attach geometry to a particle system, the blur does not render curved paths well. Instead, each blur pass creates a hard looking angled blur vector, not a smooth curve as it should. This seems to be a problem with the particle system.
I'll post images of what I'm getting...

Jakkar
06-25-2008, 01:07 PM
Ok, here's an example of what I'm experiencing...
The nice curve on the right is from 1 object traveling a curved path over 3 frames, this is a render from frame 2 with the real lens camera, AA set to 2 with 40 blur passes. Perfect, exactly how you'd expect real motion blur to work.
However, as you can see on the left, I attached a clone of this object to an emitter using fxlinker. The emitter settings approximated the velocity of the single object over 3 frames. Added enough gravity and wind to see the attached ones traveling in an arced path. And if you scrub the timeline with "allow fractional frames" on, you can see the curvature as they travel. However, the motion paths of the particles in the GL view show up as straight line vectors that suddenly pop and change after a point. And this is what renders as well.
Very frustrating. I know from other posts that this also occurs when using hypervoxels and "particle blur" selected in the camera settings. But this doesn't use the particle blur setting as these are actual objects, and still getting this.:confused:
Anyone have success getting curved blur out of particles? Or is this simply impossible with LightWave?

Sarford
06-25-2008, 01:17 PM
Don't know if it is possible in LW, but what if you bake out the motion of the objects, get rid of the particles and then try with motion blur?

vfxwizard
06-25-2008, 02:29 PM
Anyone have success getting curved blur out of particles? Or is this simply impossible with LightWave?

It can be done, but I don't know if it fits your scene (as it requires a separate render pass).

To the best of my knowledge LW's motion blur interpolates deformations linearly so you have to cross the border between frames to get more points and define a curved path.

So set Blur Length to an high value, say 1500%, and a large number of passes. Particles will draw curved trails, very effective for wispy smoke. Hope it can work for sparks as well, but timing will be way off wrt to what you see in Layout.

BTW, Sarford's idea is likely to solve your problem better than this trick.

RebelHill
06-25-2008, 04:31 PM
U can use the editfx tab after calculating ur pfx to bake down the paths the particles take to standard object motion paths, or curves... then it should work as per ur working example once the motion is "free" from the emitter.

Jakkar
06-25-2008, 11:50 PM
U can use the editfx tab after calculating ur pfx to bake down the paths the particles take to standard object motion paths, or curves... then it should work as per ur working example once the motion is "free" from the emitter.

Thought of that, but this has to be a huge shower of intermittent sparks with the flexibility to modify the intensity, speed, size of the bursts etc... Saving out hundreds of motion paths is not practical in that case.
Lightwave needs a serious overhaul of its particle system. It has remained unchanged for too long and is definitely behind max and maya in this regard.

LightFreeze
06-26-2008, 12:44 AM
could you increase your frame rate when you calculate the particles then play them back slower when you go back to your original frame rate or put a step value in when rendering to get back your fps

jameswillmott
06-26-2008, 01:01 AM
I have a job that requires sparks shooting our from train wheels as it slams on its brakes. This is not the first time. I was given this grinding wheel photo as reference.
Has anyone been able to duplicate this look?
Try as I might, I can't get particles to take on this appearance. Even with photoreal motion blur, stuff traveling this fast has very angular and faded blur instead of these bright, curving paths. I think it has to be done with a cheat.
Appreciate any help...

Can you film the real thing ( use a grinder, not a train :P ) and fake it all using a textured polygon?

Jakkar
06-26-2008, 02:04 AM
Can you film the real thing ( use a grinder, not a train :P ) and fake it all using a textured polygon?

That's why we're trying it in 3D now. Originally (as would be the simplest solution) was to use grinding wheel stock footage (see my original post with reference from this) and track it in behind the wheels in a compositing package like Flame. Problem is, the director wants it to be more intermittent, bursty-er, which you can't really do to the footage. Sure you can scale it down and dim it out, but it looks scaled and dimmed. What you need is a birthrate, particle speed ramps, gotta go 3D particle system.
Trying a cheat now...more soon.

gerardstrada
06-26-2008, 02:28 AM
You might want to try by calculating pfx as always until you get the sparks motion you are looking for (render with 50-100% mblur). Later in post, you can exaggerate the mblur effect.

A test with 100% LW mblur (particle mblur) and Eco filter from AE:

http://imagic.ddgenvivo.tv/forums/SPARKS.png

Eco filter can slow down sensation of speed:

http://imagic.ddgenvivo.tv/forums/eco_blur.gif

so you may want to stretch the duration of the final comp for this particlefx pass, I guess.



Gerardo

Jakkar
06-26-2008, 02:55 AM
You might want to try by calculating pfx as always until you get the sparks motion you are looking for (render with 50-100% mblur). Later in post, you can exaggerate the mblur effect.

Gerardo

Interesting...but wait, those curved blurs, they're done in AE not LW?
What does the straight LW render look like before the AE blur?

gerardstrada
06-26-2008, 03:31 AM
In this way:

http://imagic.ddgenvivo.tv/forums/spark.gif
(Better optical effects results by working with a LCS workflow)



Gerardo

vfxwizard
06-26-2008, 04:04 AM
You might want to try by calculating pfx as always until you get the sparks motion you are looking for (render with 50-100% mblur). Later in post, you can exaggerate the mblur effect.

A test with 100% LW mblur (particle mblur) and Eco filter from AE:


Very cool! I think this is the way to go.

As a reference, here is a quick test done entirely inside LW with the "longer blur" method in my previous post.

It's going to be slower due to the many passes, but allows to preview and tweak the result in layout.

http://www.vfx-wizard.com/external/sparkslayout.jpg

gerardstrada
06-26-2008, 04:33 AM
Nice! :thumbsup:



Gerardo

Otterman
06-26-2008, 05:44 AM
Wow...that looks cool! Any chance of posting a scene so we can have a play?

vfxwizard
06-26-2008, 08:21 AM
Meanwhile, here's mine, hope it's useful. (Turn on "DOF/MBlur Preview" to see the streaks in preview).

karlieman
06-26-2008, 09:00 AM
Thanks for posting the scene, i looked at the settings and i can finally do it on my own.


Thanks again.:thumbsup:

Otterman
06-26-2008, 09:05 AM
Yeah i second that-it works great.....i off to blow up the houses of parliament now!!!

Joke!!! Im only a lightwave terrorist at heart! 8/

Ta vfxwizard :lightwave

CMT
06-26-2008, 11:54 AM
This would make good fireworks :)

karlieman
06-26-2008, 02:51 PM
i think it looks better when u add particle age to the hv size, it looks more like the real thing.

evolross
07-24-2009, 06:51 PM
Does the Eco After Effects filter ship standard with AE CS3? I can't find it.

gerardstrada
07-24-2009, 08:30 PM
Yep. Effect=>Time=>Eco



Gerardo

probiner
07-24-2009, 08:52 PM
Great inputs here. Thanks all

evolross
07-31-2009, 10:41 AM
Yep. Effect=>Time=>Eco
It's "Echo". That's why I couldn't find it. Although I should have been able to put that together that "eco" meant "echo". I was trying to search for "eco" in AE!

That's a really cool effect. I was able to do some cool stuff just using AE's Particle World and Echo.

gerardstrada
07-31-2009, 09:38 PM
Just to clarify, I made that sample in the spanish version of AE, there it's indeed "Eco". Sorry for any misunderstanding :)



Gerardo

evolross
08-01-2009, 04:08 PM
Ah, good to know! Sorry about the assumption!

That was very American of me! (We think the entire world is just like us, all speaking English, driving pickup trucks, and eating McDonald's!)

:beerchug:

Mr Rid
08-01-2009, 06:39 PM
...
To the best of my knowledge LW's motion blur interpolates deformations linearly...

Normally you have subframes to fill in the curve of moblur with most deformations/transforms (unless using vector blur). The problem is that particle dynamics lack subframe calculation in LW. So velocity appears as a straight line from frame to frame. If you scrub with fractional frames enabled, you will see the particles snap to a new direction on each frame, unlike keyframed items.

Lightfreeze had the right idea.


could you increase your frame rate when you calculate the particles then play them back slower when you go back to your original frame rate

Calculate PFX at say 120 fps, bake motion, switch back normal frame rate. This effectively gives you subframes that allow for curved moblur with PFX.

gerardstrada
08-01-2009, 08:32 PM
Ah, good to know! Sorry about the assumption!

That was very American of me! (We think the entire world is just like us, all speaking English, driving pickup trucks, and eating McDonald's!)

:beerchug:

Don't worry, man. My mistake. I should have written it in English, since that's the language of this forum.

:beerchug:



Gerardo

erikals
09-21-2010, 06:03 PM
Meanwhile, here's mine, hope it's useful. (Turn on "DOF/MBlur Preview" to see the streaks in preview).

super! thank you for the file! :]

Getting Board
03-11-2011, 10:49 PM
I've played around with the particle system for a little while but have never seen the orange dashed lines "blob" thingies before. What is that and what makes them appear... and in that shape?

evolross
03-12-2011, 03:16 AM
It's just particles, with little spherical hypervoxels set, with a lot of photoreal motion blur. That makes the "dot" particles appear to "stretch out" into lines. The "Echo" plugin in AfterEffects can also help with this.

In the Hypervoxel panel you can tweak their color, size, etc. In the Image Filters you can add glow. Or use a "Partigon Emitter" to actually surface the particles in the F5 surface editor and add traditional surface glow. This seems to be the only real reason to use a partigon emitters I've found.

prometheus
03-12-2011, 11:30 AM
It's just particles, with little spherical hypervoxels set, with a lot of photoreal motion blur. That makes the "dot" particles appear to "stretch out" into lines. The "Echo" plugin in AfterEffects can also help with this.

In the Hypervoxel panel you can tweak their color, size, etc. In the Image Filters you can add glow. Or use a "Partigon Emitter" to actually surface the particles in the F5 surface editor and add traditional surface glow. This seems to be the only real reason to use a partigon emitters I've found.

Thereīs a reason more to use partigons, if you create a turbulence motion within the particles and at a given time in the simulation, You can freeze the particles by saving them as transformed object, you can do several simulations with small changes and save out many transformed particles.
Later on you can reload as object and use as cloud clusters or nebulaes.

You canīt save out hv emitters like that, unless using a convert to partigon tool that is.

Michael

evolross
03-12-2011, 11:43 AM
Nice. I didn't know that. Thanks for the tip. :)

Getting Board
03-18-2011, 01:25 PM
I need to blur only the particles in a scene.
Is that possible?

I have particle blur turned on and even with "Motion Blur" set to "none" the option to select "particle blur" is not grayed out. Which leads me to believe that this can be done, but the renders seem to have proven otherwise so far.

Mr Rid
03-18-2011, 05:02 PM
I have never found a use for rendering partigons. There is much less control over the look than using HVs. For instance you can not vary the size and they remain the same size at any distance from camera.

Enabling particle blur and setting motion blur to 'off' will allow only single point polys and partigons to blur.

Photoreal blur will not work with HVs.

Classic camera renders HVs much faster than the perspective camera.

To blur only HVs you would have to save the render out as a separate pass with an alpha channel, then comp them with the other non-blurred elements in a compositing app.

4dartist
06-29-2011, 03:23 PM
Don't know if it is possible in LW, but what if you bake out the motion of the objects, get rid of the particles and then try with motion blur?


How would you bake out the motion of 100+ tiny objects? Wouldn't you have to use FX linker and end up with tons of objects having to bake each?

Just wondering.

erikals
06-29-2011, 03:33 PM
ignore, mis-read the question... sory..

4dartist
06-29-2011, 07:47 PM
I seriously wish particles were calculated better.. I can't tell you how many times the stair step effect that comes with particles has stopped me in my tracks and made me work around it. Seriously, hundreds of times...

You name it.. particle age is integer so any gradient linked to it is stepped per frame. Change the direction of particles super fast, well it steps. Always bugged me so much.

I hope the big push in dynamics means an improvement to general particle operations.

erikals
07-31-2011, 12:18 PM
Classic camera renders HVs much faster than the perspective camera.

hm, no, doesn't look like it, using LW9.6

perspective camera 2m 4s
classic camera 2m 44s

http://www.newtek.com/forums/showthread.php?t=105742

Mr Rid
07-31-2011, 07:49 PM
Would like to see the scene.

Here's a couple examples with both cameras to compare (LW96)- 97045 Volume particularly takes much longer with the perspective camera.

I've had this 'Classic vs Perspective camera render time' discussion too many times. Whenever someone claims the P-cam renders faster, it turns out they are not using equal AA and/or moblur settings. So far, the only time I've found the P-cam to be faster is with reflection blur. Classic tends to handle most GI and area light noise better for some reason.

Cageman
08-01-2011, 01:15 AM
Classic vs Perspective camera is also dependent on content. We tend to have between 6 and 12 million polygons for our environments, and none of the tests I've done with classic camera comes close to perspective camera in terms of AA quality vs speed. Smaller scenes related to vfx work where you also render with motionblur, classic might be faster, but again, there are formulas to be used to dial in a combination of AA and AS to get faster renders but with good AA quality.

erikals
08-01-2011, 01:34 AM
@ work atm, so canīt test now, but here is the scene,
http://www.newtek.com/forums/attachment.php?attachmentid=81407&d=1264423714

i seem to recall the quality was basically the same... (perspective / classic)

Cageman
08-01-2011, 02:03 AM
@ work atm, so canīt test now, but here is the scene,
http://www.newtek.com/forums/attachment.php?attachmentid=81407&d=1264423714

i seem to recall the quality was basically the same... (perspective / classic)

For me..

Persp cam: 21.5s
Classic cam: 52.4s

No changes made to the scene or the camera. Classic camera also produced shadow/smoothing errors where Perspective did not.

Pic1 = Persp cam
Pic2 = Classic cam

EDIT: LW10.1 x64

Mr Rid
08-01-2011, 08:51 PM
Classic vs Perspective camera is also dependent on content. We tend to have between 6 and 12 million polygons for our environments, and none of the tests I've done with classic camera comes close to perspective camera in terms of AA quality vs speed. Smaller scenes related to vfx work where you also render with motionblur, classic might be faster, but again, there are formulas to be used to dial in a combination of AA and AS to get faster renders but with good AA quality.

In case anyone missed this thread about alotta Classic vs Perspective testing- http://www.newtek.com/forums/showthread.php?t=112208&page=3&highlight=Enhanced The only significant render speed increase with the P-cam was found in reflection blur. The most common claim is that the P-cam renders heavy ray tracing faster but I have not found an example yet. I dont know if buzillions of polys make a difference. I've already wasted too much time discussing this to keep testing, but Toby is all into it.

Also, I noticed lately that I get away with less recursions with C-cam before multiple transparent surface artifacts disappear.


For me..

Persp cam: 21.5s
Classic cam: 52.4s

No changes made to the scene or the camera. Classic camera also produced shadow/smoothing errors where Perspective did not.

Pic1 = Persp cam
Pic2 = Classic cam

EDIT: LW10.1 x64

Now try to get equal AA quality with the two different cameras. Even without moblur, the C-cam will render in the same or faster time with equal or better AA than the P-cam. Unless you're rendering for previz (in which case you would not need dense voxels as this) most practical HV scenes need AA and/or moblur. You may crank up HV render Q, but if you have to render with AA or moblur for cam moves or whatever else may be in the scene (usually I render HVs in a separate pass, but there are often holdout mattes), then it is more efficient to leave the render Q low and let AA smooth HV noise. Then add five moblur passes and the C-cam is waaay faster (26 secs vs 4mins!).

The shadow errors you mentioned are due to severe non-planars in the geometry.

If anyone is concerned about saving render time, dont assume the Perspective camera is faster as most do. Learn how AA and AS work, and compare carefully. I have one HV explosion scene where the P and C cams rendered about the same speed, up until a point where a single point light comes on and the P-cam suddenly took several times longer to render. I never did try to isolate why it was so taxed by an extra light.

Cageman
08-01-2011, 09:04 PM
Now try to get equal AA quality with the two different cameras.

To me, those two pictures that I posted looks identical regarding HVs and AA.

Mr Rid
08-01-2011, 09:12 PM
To me, those two pictures that I posted looks identical regarding HVs and AA.

Post your comparison scene. You said you didnt alter the scene, so there isnt any real AA, as it appears in your renders.

Cageman
08-01-2011, 09:14 PM
Uh... it is the one Erikals posted... I just opened it and rendererd with Persp. Cam first, then Classic Cam. No changes nowhere.

Mr Rid
08-01-2011, 09:15 PM
My above posted scene result on an i7, with about equal AA-

Classic-
97069

Persp-
97070

Mr Rid
08-01-2011, 09:21 PM
Uh... it is the one Erikals posted... I just opened it and rendererd with Persp. Cam first, then Classic Cam. No changes nowhere.

Right, there is no AA in your renders. Why would anyone render that?

Cageman
08-01-2011, 09:29 PM
Hmm..

Without changing any settings, the only things I changed was the resolution (the multiplier set to 100%).

Classic Cam: 2m 21s
Persp Cam: 2m 03s

EDIT: Tested with the content you provided

Cageman
08-01-2011, 09:40 PM
What I do not understand is how you get Classic Camera, Enhanced Low with AS at 0.1 translated into Persp Cam, AA1, AS 0.02 (!) and oversample 0.5.

Have you tried other mehtods with Persp cam, such as higher AA and less AS?

erikals
08-02-2011, 10:47 AM
Right, there is no AA in your renders. Why would anyone render that?

i do HV animation cleanup in post, that's why ;]
 

Mr Rid
08-02-2011, 08:20 PM
i do HV animation cleanup in post, that's why ;]
 

If you can practically render with no AA or moblur then yes the P-cam is faster. Have found that reflection blur is faster with the P-cam, and also rendering vertically limited regions.


What I do not understand is how you get Classic Camera, Enhanced Low with AS at 0.1 translated into Persp Cam, AA1, AS 0.02 (!) and oversample 0.5.

AA doesnt apply the same in each cam since there are different settings. 'Enhanced' is about equal to oversampling of .5 or .6, but that is not a render hit. Use any P-cam AA settings you want to match quality vs time- crank up P-cam AA, or lower the AS to match the edge and noise quality of C-cam AA. Dont confuse AA with the way some of the filters 'blur.' But so far, I have not seen anyone wind up getting something for nothing. With HV moblur, the C-cam is the clear winner. Without moblur, edges may AA at about equal quality and time, but the C-cam tends to deal with noise better in most examples.


Have you tried other mehtods with Persp cam, such as higher AA and less AS?

Yes, I've wasted way too much time at this. It seems the mistake in comparison that some people make is by merely changing camera type and pressing F9, or they dont understand the difference in the two cams' AA. At first glance, the P-cam may render faster and the renders may appear about the same, so they believe the P-cam is faster. But whenever I closely compare aliasing artifacts, they are really just using lower quality AA with the P-cam. In which case you can match with lower AA quality in the C-cam and get a render that is back at about the same time and quality, so there is no advantage.