sprockets Learn to keyframe animate chains of bones. Gerald's 2024 Advent Calendar! The Snowman is coming! Realistic head model by Dan Skelton Vintage character and mo-cap animation by Joe Williamsen Character animation exercise by Steve Shelton an Animated Puppet Parody by Mark R. Largent Sprite Explosion Effect with PRJ included from johnL3D
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

Recommended Posts

Posted

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. 

 

result1h30.jpg

  • Hash Fellow
Posted

Yup, more particles will take more time.

First, Windows will rarely rev the CPU to top speed when A:M is rendering since A:M uses only one core.

So maybe you're not getting full speed. If you run your task manager you can see if it is running at top Ghz. If it isn't you can make a Windows Power Plan to force it.

 

Second... How about Netrender? What CPU do you have? How many cores? How much RAM?

Posted

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. 

taakbeheer.jpg

specky.jpg

  • Hash Fellow
Posted

Only two cores will be tight for NetRender but it would be better than one.

If you are planning to render a particle animation and do it in small sections you will want to "bake" the particles before you render. If you are not sure about that ask.

Have you considered a new PC? Even inexpensive ones will be faster and have more cores.

Posted

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.

  • Hash Fellow
Posted

Do the particles look good enough in real time shaded view for the scene?

We could composite are realtime render of the particles with a final render of everything else.

 

  • 2 weeks later...
Posted

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! :D Reminded me of my idle attempts.

 

 

 

Posted

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.

Posted

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. 

  • Hash Fellow
Posted
On 11/23/2020 at 8:34 AM, robcat2075 said:

Do the particles look good enough in real time shaded view for the scene?

We could composite are realtime render of the particles with a final render of everything else.

 

 

Posted

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.

  • Hash Fellow
Posted

This is a yes or no question...

On 11/23/2020 at 8:34 AM, robcat2075 said:

Do the particles look good enough in real time shaded view for the scene?

 

 

Posted

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. 

 

 

 

frame5ealtime.jpg

frame5srender150.jpg

frame5s_avi.jpg

  • Hash Fellow
Posted

OK, If the real-time render doesn't look good enough, we don't need to pursue that possibility further.

How long is the life of the sprites?

Posted

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

  • Hash Fellow
Posted

I haven't been able to get it to load. I get a freeze after the skylift8.avi file is found. That doesn't mean the AVI file is the problem, it could be whatever is called after that.

Try this... Project>Consolidate>Project as zipped project... and send me the zip

 

I will note that if you need to incorporate a video into an animation it is always more reliable to use a numbered image sequence instead of a compressed video file.

Posted

I can load it, but there are a couple of things missing. (sometimes you can not see anything and it looks like it froze, but press "Alt" or "Alt + Tab" to switch between programs and go back to A:M. Then you will see a popup. "Null pointer" or something like that.

But it works after that. I am currently rendering the scene out.

But currently it just takes around 9 seconds with particles on too... there have to be some things missing.

Best regards
*Fuchur*

Posted

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.

 

tb3start.zip

  • Hash Fellow
Posted
1 hour ago, Fuchur said:

Then you will see a popup. "Null pointer" or something like that.

 

I got two "Null Pointer" messages but it was frozen after that.

Posted

We are very likely using different settings when rendering ;).
I am rendering at 9 passes at 800 x 600.

Best regards
*Fuchur*

Posted

Ah ;), the last tb3start.zip should have the right info. Now I have the better attitude for the smoke sprites, I guess the case of long rendering is solved.

After taking care for the right parms for the smoke_emitters most frames render within a minute, and that is well for a VGA format. Only thing I can't explain is why the front emitters of the rocket have that strange transparancy, while in the model editor it are three constant beams. 

Before I can explain the wrong file format I've come to another breakpoint. I'm working from an update of AMv16.0b to AMv17.0g . I use both versions , but now version16 won't render sprites anymore.  So it might possible the versions give a wrong outcome in case of projectfiles. Version 17.0g renders the sprites well, but also has a tention of crashing more often. I'm working on an old computer, that could also be the case. 

^_^

fab00.jpg

fab01.jpg

  • 3 weeks later...
  • 1 year later...
Posted

NetRendering is a great solution to overcome this problem. The rendertime with four nodes straightens out for a quart of the time.

Now I made this 32sec render in 2h30 on 1480x1233. In 2002 on a Pentium100 on AMv.11 it took 48houres on 640x480. 

 

  • Like 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...