Madfox

I tried to consolidate the file, but the program fails in a loop to endless archiving. It is a bit large to splt up all avi files into jpg as it is more than 840Mb. I tried to compromise this with a codec to 80 Mb. So I deleted the background to archive it again, but I think I found a better way to compose the scene. The sprite emitters are too large to serve the given purpose. A smoke sprite covers a explo sprite, so it is useless to use them both. It only makes the render process more timeconsuming. I took the sprite emitter from the first thunderbird, and this one goes much faster as the one I was tying. Maybe the smoke might roll more to the side, but I see no way to make the sprite emitter bounce on the ground plane. Thanks for trying out the file Fuchur. On my computer the still files take 7 sec and the sprite ones 2m30. Only the sharp line between the groundplane and the sprite emitter makes the scene look bad. tail.avi tb3start.zip

Thanks for your attention! The sprites have a lifetime of 9 seconds, but they differ on the track of the timeline. So to give you a right answer it would take a long time to answer. I packed the file so you can take a look at it. I hope all elements are included.☺️ thunderbird3.zip

Not sure if I understand the question, Robcat. I made a render of the smoke and explo sprites alone on solid black. Attempting to change this in an alpha channel so the scene will render some faster and the sharp line in the smoke/explo versus ground would be avoided. Not sure how to add the alpha channel of 16sec smoke background can be acomplished. By real shaded view I end up like start07.avi or asomething like this, what looks a bit poor for a rocket explosion, but I think I can live with that. Here is a real time render vieuw of the scene, the actual rendered file and the moment in the avi file. so my idea is that the real time render isn't good in with the particles. The avi looks better.

I rendered the scene in five houres. I'm a bit concerned about the straight line under the particle surface. Maybe better to lift the camera a bit. This scene has nine sprite emitters, six underneath the launchers for smoke and fire and four in front of them with a turbo smoke and explode. It looks as if the smoke overbrights the explo emitter. The first frames without sprite activity render fast, ie 4 seconds, the others go about 2m30. Yet it isn't still what I was looking, maybe the explo.mat is a bit too dim. 07start.avi

It's not trouble. It's more trying to comprehend how it works by keeping it a challenge. The error that apeared had to do with trying to change the existent choreography. I tried to exchange the rocket with another one . Then my idea was to make a new choreography and that worked better. I'm on 20 minutes rendering for 16 sec on mini format. It becomes 4 hours for low. Mostly things only get worse when trying to improve an exciting scene.

Hey Furchur.., kind of you to offer me the possibillity for rendering. I just looked at the file, but I have some trouble with working on version 16 - 17a. For some reason the sprite emitters won't work since I updated to version 17a. That is .., in version v16 they don't work anymore. A bit frustrating, as it is the more reliable one I have. I won't say 17a is not good, but it crashes more often than the original v16. So now I want to save a v16 project after some changes, but it falls away. Also the background has a 850Mb avi file, which isn't that easy to transfer. I zipped the whole pack to 50Mb, but before sending I saw something was wrong with the set up. Now I am wrenching to get the orifinal file back again in a working set up. It looks as every attempt end upon a closure of the program.

The cloud particles take too long to render. If I count 1h30 for a frame and 30 frames a second it is a long way to 16 seconds. Using only the explode sprite seems less time consuming. I tried another one of Scotty in its turning cabin. Had a long laugh after seeing the pilot of the SpaceX craft! Reminded me of my idle attempts. 04start.avi cabin08.avi

Glad you found your models. I don't have acces to a 3d printer, so the question was just informal. I saw it as a challenge. Got my own Rocky now.

What are the common specks for objects to reach the range for 3d printing? I just made some a arangments for the head to fit on Rocky's purpose. No idea how to obtain the fitting of the spline closure. I could change pink panther in something like Buckwinkel. Just wondered how close these models have to be to give a reliable stl format.

Shot in the dark after some houres of puzling. No idea what I am doing, as I am more famliar with Fred Flintstone. The model should be more rounder, I shaped its head as far I could and put it up to Thom. No intention for what ever, just the atraction.., like Pink Panther.

I have baked the particles before I started rendering. I never tried netrendering. I deleted half of the sprite emitters and made it a target sequence. So I can start and stop rendering whenever I want. It doesn't seem to change much as the render time quickly grows. A new computer? Sure , would like that! Only my fiances are not that broadly.

Thanks for your answer. It was more my surprise, as earlier avi's took only a smaller amount of time. If It takes this size I might better make smaller parts of it. Two days rendering is a bit long. Here are my specks, I've got 3Gig memory.

I remember doing the AM render benchmark test, and I came upon 5 minutes to do the VGA example. I was thinking of it now I have a short animation with rather a lot of particles. When I first did the render, a rising thinderbird into the sky, my minimum render time for a frame on VGA became at highest 3 minutes. So for a 8 second animation I could get away with 6 houres rendering. After some sessions I decided to give it some more sprite emitters for smoke and explosion. Then I realized this quotum would be rather high: three flame throwers - three smoke paths - three explosion sprites and three smoke bursters. It look well, I had all moments set to give the sprite emitters the right amount. When I started rendering my first frames went well. Now I am on 27th frame and it takes 1h30m for rendering. That's rather long for 8 seconds animation. The renderings are fine, that's not the problem. But it would be better to render them to tga's so I can render them partly. Or find a way to get through that wall of rendering time by order up the sprite emitters.

👌

Thanks for your reactions! Fun work to do, but very time consuming. It took two evenings to gather the pix. Good to have a one frame button. Only the registering is rather kinky to keep the object in center when moving. Here is an earlier state.😉

I recently started a small project with a puppit I made of some garden strings and velvet. They were a bit moveable, but I had no idea to set it up with the right stability to make a movie of it. Then I reminded the one_frame_button of my Cad camera. So I made some surounding and tried some pictures. My first attempts were a bit fraggy, as I had no idea to make the puppit straight for a longer period. Then I found some small magnets, and used coins to move the feet as parts for the walk trace. It all looks a bit chunky, as I had hardly an idea how much frames needed a walk pose, or a still. This was made with a range of 600 frames. 😏 pino.avi

Yes sure Robcat! That will make things much clear for me. I admire your knowhow.

I was trying to do the same thing in the fractal sum question with a thunderbird launch. (lunch08.avi). I tried to copy the effect, but I have no SmokeBallF.

A year later and I'm looking for the same kind of effect. The Rocketplume has a smaller size than the later example. Could it be possible to share the parms?

I had also this problem with foot targets after adding a model to skeleton2001. Robotcat explained that it is easy to rebound them again. It needs to uncover the hidden hinge bone of one of the legs. Then it needs some addictions. First use the calf bone as a IK-handler to the foot target. Then use the footbone orient like the foot target. Finally you need to use the hinge bone as a point to foot target. If all went well the foot target responds to the whole leg.

thun1013.avi 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.

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 lunch08.avi .)

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.

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.

After tracing out the forearm error skeleton2001 is good enough for me on 32bit. TM2 is always welcome to explore other ways to do it even in amv16. Great it is a free plug-in now.