fractal sum

[Madfox]

I restarted a subject I did earlier about fractal sum. I made this Thunderbird and wanted it to have a flare of light and smoke. This isn't that bad, make a small transparant disk and position it at the end of the engine. That is.., if  the object is flying one direction all goes well. But the fractalsum asks a lot of calculation, which makes it hard to navigate between the frame position. So after all is planned and I want to change direction at say after 15 sec I have to wait several minutes before my computer has calculated this position. This is a bit weird because after another frame I have to wait again.

So I compromised my choreography by shutting down all fractalsum with as less parms as possible. In this way I can position the Thunderbird, turn it and make changes. Later on recharge the fractal sum and render the choreography. But it isn't that simpel, as turning the thunderbird, won't change the direction of the fractalsum. 

I have tried to approach this "hubble" in different ways. A disk with a fractalsum attached can chage direction with a bone, but it won't change the position of the fractal sum. So every change of the direction of the fractalsum_disk have to be rechanneld in the fractalsum generator at the pointed frame. I've lost a lot of time just waiting before the computer calculation is done, before I could go on to the next keyframe. This made it almost hopeless to end the choreography, due to crashes and all.

Then I thought to collect them in a group, or just start with one leading fractal sum to change later the others. 

At last I came to the idea to le the Thunderbird for what it is, and change the position of the camera and the background. It would give the suggestion of a flying bird, but the static view is a bit slowing.I have to find a work around to work with these fractalsum, because I have the feeling they have a strong expression.

 

 

 

 

[robcat2075]

I'm not sure what you are describing.

When you say, "Fractal sum" you really mean "particles", right?

Fractal sum is a turbulence combiner that gets calculated on each frame but it doesn't depend on previous frames like particles do so it won't be slower if you are scrubbing the timeline backwards.

Particles do need to be recalculated from the beginning of the chor if you scrub the timeline backwards (unless they have been "baked"). If you want ot make the chor easier to navigate while animating

The direction of the object on the screen should not matter either way.

 

[Madfox]

Sorry for my unclear statement. The thing is I use a Streak_emitter to create smoke and fire.  Like New Material > Particle System > Streaks. This is made with the force atribute turned from the horizontal axe , while a simple rocket turns 360 degrees. For some reason I never understood the force atribute, as it is no 360 degrees. So I had to switch x y z from x 100% - 0 -100%  - 0. Then there is the effect of a trail of smoke turning slower than the object. For compensating I came somewher, but it is still a  bit chunky.

Here are the files, maybe that's easier to understand. For I can see is, that the delay of the smoke trail and the object could have a better performance.

 

 

 

 

arrow_amv17.0g.zip

[Madfox]

I made an example for myself to illustrate the difficulty I had by making a streak_emitter turn horizontly around its own axe. When I think some longer about it, it looks exact as a lighthouse beam. Only when I tried to set up the parms for the streak_emitter I got a little confused as they also started turned up and down on unexpected moments. With a little hussling I got it working, but decided to make a little diagram for not loosing it.

Maybe there are more clever ways to do it. I shall take a look at the lighthouse example.

[robcat2075]

I will try to give this a look today. Sorry i didn't get to it earlier!

[robcat2075]

Streaks leave the emitter in the direction of the patch's surface normal, but if the the patch is turning the streaks that have been emitted will always appear to be lagging since they are continuing in the direction that the patch was facing rather than how it is facing on the current frame.

If you need an absolutely rigid "flame" a volumetric light might work well.

If you need a more specific shape you could model a series of nested flame shapes that are nearly transparent. I did this with the duplicator wizard. This is just 8 layers. More layers with higher transparency could be used for a smoother fade.

RocketFlame01.prj

 

If you need the flame to flicker both the volumetric light and the modeled version can have a turbulence moved through them to create a sense of motion. Ask if you have questions about that..

[robcat2075]

Animated turbulence...

[robcat2075]

slight variation...

[Madfox]

Yes, that are some good examples for a fire rocket. 

Thing is when I make a launch effeckt "the change of direction in three axes" was my greatest problem. Indeed the fade effect goes on in the distance it was facing. The hardest part was how to overcome the time it took after some 20 seconds. From then my computer just froze, as the amount was too large. Then I saw Icould turn off the streak emitters, and from then it was much easier.

Still have trouble while making changes in the streak emitter, as sometimes the screen refreshment lacks.

Sofar the results are amazing, but time consuming. 

 

[robcat2075]

Quote

Thing is when I make a launch effeckt "the change of direction in three axes" was my greatest problem.

I'm still not sure what you regard as the problem.

 

When I looked a Emit08.avi, the flame was slightly behind the rotation of the rocket.

Is that what you wanted or didn't want?

Did you want it to lag more or less?

[Madfox]

My biggest problem was to change the direction of the flame, like in emmit08.avi. As the image in the topvieuw shows it takes some parms in the timeline to make the streak_emitter change its direction. Probably the 100% x-y-z axe took me some time to understand, as it are no 360 degrees.

I made this whole launch scene with a ground and background that turn down, while the cheography remains static. I did this because everytime I made a cheo that changed the direction of the airplane the streak emitters didn't change. So it is a bit of a movearound. Now I understand how to channel the emitters over time it goes better.

It would be good if the emitters would act with less lag. 

 

[Madfox]

Maybe this makes it more clear. The first part of the animation goes untill the stars with a static cheography on the thunderbird, and a background/terrain that lowers out of sight. From the moment I try to change the airplane the streak_emitter starts shifting, although the streak emitters are adjusted in the right direction. (ie. from upwards to camera side .)

 

[robcat2075]

In your project 02_emitter.prj you have the fire and smoke emitters as separate models from the rocket and you are keyframing them to follow the motion of the rocket.

That is unnecessarily complicated. It is easier and better to make them part of the rocket model and then they will always follow it exactly.

 

Here is a simple rocket that emits streaks. The streaks always follow the rocket as it turns and always emit straight out the back of it.

Load this PRJ, watch it, and then tell me in what way it is not what you are trying to do.

RocketStreaks01.prj

 

 

 

[robcat2075]

If you need an absolutely rigid trailing flame, then the modeled flame will be easier...

 

RocketStreaks03_modeleldFlame.prj

 

 

[Madfox]

Hey thanks Robocat!

I don't know how I came to the idea to split the streak emitters from the model. Probably I thought I could change the position of the streak emitters. Then I saw that the scale of my model versus particel measure was wrong. After some altered position I managed to get what I wanted. Not expected it was so easy.

The start position of the streak emitter is on the y axe 100%. THis works for the upward position. So all changes in the position of the model will change the streak emitter also. Does this also work when positioning it in horizontal position? Or should the emitter aways be on this start position in materials. 

 

[robcat2075]

Quote

So all changes in the position of the model will change the streak emitter also. Does this also work when positioning it in horizontal position? Or should the emitter aways be on this start position in materials. 

You can either make the emitter part of the model, or if it HAS to be a separate model you can TranslateTo and OrientLike constrain it to your model.

Either way, it doesn't matter how the model turns or is initially positioned, the streaks will be emitted perpendicular to the emitter surface.