sprockets 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 New Radiosity render of 2004 animation with PRJ. Will Sutton's TAR knocks some heads!
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

Layers rendering time


wingalls

Recommended Posts

My apologies if this topic has been covered and answered, but I'm way too lazy to do anything more than a cursory search for past posts.

 

I'm using AM 1.1 (2007 version is being rushed to my door by dedicated men in brown as I speak type, so this may be a problem that has already been solved).

 

This is what I'm doing: It's a very very simple animation (on the level of an animated gif, really) made up of about a dozen jpgs with different timings. I strung them together and made up an avi using another program, but wasn't happy with the results. I wanted to add a smoke effect (mostly to indicate time passing between jpg changes), so I decided to try it as an AM project.

 

I was able to import the jpgs as layers, and switch them on and off at the appropriate times. I also figured out how to make the smoke work (once I discovered that the smoke emitter group needed a surface to make particles).

 

Now the problem annoyance comes when I try to render to file. Naively, I thought that since there was only a few (minor) changes in the jpgs that compiling this puppy would be a breeze. If anything, (I thought), the smoke effect would take most of the computing power.

 

In actuality, though, it is the rendering of the layers that takes the most time. Each frame is taking 20 seconds to render. 95% of that time is rendering the same layer over and over and over.

 

It might sound petty that I'm complaining about 20sec/frame rendering time. I'm sure that the more complicated projects take much more time. But it's heartbreaking to watch AM compute patch visibility; render patches; and antialaise each layer for each frame, even though nothing's changed.

 

I've tried rendering in shade resolution, and the result is a much faster compiling time, but without the quality I want. (Final mode makes those jpgs look really good).

 

My question is this: Is there a way to tell the rendering engine that once a layer is rendered, that it doesn't need to be processed again? (Maybe a hidden switch somewhere that needs to be toggled).

 

If not, is there a way to render a single frame of each layer and then stitch them together again with the smoke over-laid? I saw a reference in one of the posts to seperate rendering, but I wouldn't know where to start. (If this is the only answer, maybe someone could point me to the tutorial "Taking It All Apart, and Putting It Back Together Again").

 

Thanks for your time and any (constructive) suggestions you might have.

 

- Wes

Link to comment
Share on other sites

  • Replies 7
  • Created
  • Last Reply

Top Posters In This Topic

  • Hash Fellow
Each frame is taking 20 seconds to render.
:D

 

well, anyway.... I don't think there's a way for A:M to identify and store non-changing image elements from one frame to the next. I'm not aware of any compositing program that would. I don't think After effects even works that way. After effects will quickly skip thru frames if nothing has changed from one frame to the next, but if anything changes, even in a small corner of the screen, it rerenders the whole frame.

Link to comment
Share on other sites

  • Admin
My question is this: Is there a way to tell the rendering engine that once a layer is rendered, that it doesn't need to be processed again? (Maybe a hidden switch somewhere that needs to be toggled).

 

20 seconds per frame is pretty good!

 

The terms Preproduction, Compositing and Planning immediately spring to mind.

 

In traditional (feature film) and even limited animation (classic TV shows) they have historically approached the problem from the same angle. The emphasis is usually in diffferent places however.

What you are trying to set up (your final results) would dictate what approach you would need to take.

 

The following might provide a starting point:

 

- Isolate* those elements in your shots that don't move at all.

- Isolate* those elements in your shots that move very little.

- Isolate* those elements in your shots that move a lot.

 

*Isolate them on paper first. Write it out... Sketch it out... stick figure it out... Keep it simple.

 

Once you have a workable plan you can investigate techniques that can help you put the plan together in A:M.

 

Because your resolution is fairly low you might be able to get away with some tricks to make your rendering go faster. Some off the wall suggestions follow:

 

Option 1 (you'll need to remove those areas that you don't want in another program)

Place a rotoscope of those areas that will never change on the camera and switch it to 'On Top'.

This will create a mask through which the camera should be able to see through to changes below/behind and therefore not render the elements in front/above.

 

Option 2 (this assumes you are using images made outside of A:M, which you are)

Create 2 or 3 grids

- Create 1 grid you'll apply the image sequence to as a decal. It hold the image that never changes.

- Create 1 grid will hold the image sequence with elements that rarely change via decal.

- Optionally, create 1 grid that will hold those elements that will change a lot.

Remove those grid areas where no change occurs or make them transparent. There are several ways to do this part...

 

Option 3

Something else

 

Again... 20 seconds per frame... pretty good. ;)

I can't help but here Yves Poissant's voice in my head saying, "Just render it and save yourself some time". Unless you are in it for the education just rendering it will probably be easier.

Link to comment
Share on other sites

Lots of good stuff here, Rod (can I call you Rod?).

 

20 seconds per frame is pretty good!
I agree! It's just the fact that over 90% of it is redundant.

 

Option 1 (you'll need to remove those areas that you don't want in another program)

Place a rotoscope of those areas that will never change on the camera and switch it to 'On Top'.

This will create a mask through which the camera should be able to see through to changes below/behind and therefore not render the elements in front/above.

I haven't tried rotoscope, but it sounds like an interesting option. Obviously, the program will only render the rotoscope once ... right?

 

 

Option 2 (this assumes you are using images made outside of A:M, which you are)

Create 2 or 3 grids

- Create 1 grid you'll apply the image sequence to as a decal. It hold the image that never changes.

- Create 1 grid will hold the image sequence with elements that rarely change via decal.

- Optionally, create 1 grid that will hold those elements that will change a lot.

Remove those grid areas where no change occurs or make them transparent. There are several ways to do this part...

Decaled grids. Ok. Probably will get rendered with every frame also (like the layers), but, hey you never know until you try!

 

Option 3

Something else

I'll probably save this one 'til last.

 

 

I can't help but here Yves Poissant's voice in my head saying, "Just render it and save yourself some time". Unless you are in it for the education ...

Education, first, last and always!

Link to comment
Share on other sites

  • Admin
Lots of good stuff here, Rod (can I call you Rod?).

 

Sure. You can even call me 'Fred' if that's what you want. ;)

 

I agree! It's just the fact that over 90% of it is redundant.

 

I think the only way you won't get that redundancy is with 'real time' applications.

WebHAMR is about as close as you'll get there with A:M but that won't help you much now.

 

Decaled grids. Ok. Probably will get rendered with every frame also (like the layers), but, hey you never know until you try!

 

Yes, cheats like grids, rotoscopes and such will still rerender images but with less redundancy.

 

Education, first, last and always!

 

Excellent. :)

Link to comment
Share on other sites

Option 1 (you'll need to remove those areas that you don't want in another program)

Place a rotoscope of those areas that will never change on the camera and switch it to 'On Top'.

This will create a mask through which the camera should be able to see through to changes below/behind and therefore not render the elements in front/above.

Ok, I gave rotoscopes a shot and came up with these results:

 

(BTW, my project entails placing effects (smoke, blood, etc) over static images, so "On Top" wasn't an option).

 

I liked rotoscopes because I didn't have to scale and place the images in the scene, as I did with layers. Also, the render time for the image (computing and rendering patches) went way down.

 

Buuuuuuut ...

 

Render Time:

 

The render time for Rendering Particles/Fur went through the roof! Over several tests, I found that the render time (particles/fur) increased with the number of rotoscopes in the camera. Even though the transparency of all but one of the rotoscopes was set at 100%, they still effected the render time. Here is a table of the times:

Rotoscopes	Rendering Particles/Fur
	   (Frame 1)  (Frame 2)

0			   1 sec	  0 sec
1			   6 sec	  2 sec
2			  23 sec	  6 sec
  10			  36 sec	 34 sec

4*		   21 sec	 14 sec


* rotoscopes that are transparent in "smoke" area

 

The last test was using four rotoscopes whose transparent section (alpha channel) covered the area where the particles (smoke) was being generated. Apparently, just being present is enough to effect the render time.

 

Other Considerations:

 

Besides render time issues, using rotoscopes lead to other problems. Whenever I finished rendering (usually to file) and was switching back to Chor view, there was a long period where AM had to regenerate each rotoscope. The info bar said "Generating Real Time Texture". This was not render time (which can happen while I sleep), but me time (while I'm sitting on my bu chair).

 

Even if I was happy living with that, there were exceptions thrown while generating these textures. Sometimes, the exceptions resulted in AM crashing.

 

Conclusions:

 

Rotoscopes are not going to be the solution for my case. On the upside, though, I think I will try layers again using the TGA (alpha channel) images that I created for the rototests. Instead of each layer containing a complete picture of the frame, only the changed elements are visible (as was recommended by Rodney). This reduces the number of layers (since I can use them in combination). If this new approach to layers bears no fruit, then it will be on to Rodney's second suggestion ... grids!

 

Wish me luck.

 

-Wes

 

P.S. Quick update -- I just tried a combo of one rotoscope (for my main image) and layers (for changing areas) with outstanding results. Render time went from 15 secs/frame (which was the time with ver 14 using all layers) to 5 secs/frame! Huzzah!

Link to comment
Share on other sites

  • Admin
P.S. Quick update -- I just tried a combo of one rotoscope (for my main image) and layers (for changing areas) with outstanding results. Render time went from 15 secs/frame (which was the time with ver 14 using all layers) to 5 secs/frame! Huzzah!

 

A considerable savings in time (relatively).

Looks like you are on your way. :)

Link to comment
Share on other sites

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