New environment, a large, empty storage area. Nothing terribly interesting.
Tuesday, 17 May 2011
Wednesday, 11 May 2011
I blame the sweltering heat
My part of the world is undergoing some sort of freak weather phenomenon. Two weeks ago not a day would go by without an obligatory heavy downpour. Then since a week ago there was not a drop of rain to be seen, the clouds have all but disappeared, giving the scorching sun an un-occluded access to the tarmac, which duly reflected the heat. This wouldn't be so bad if my car's air conditioning didn't pick that time to break down.
But anyway, I have been working hard on creating assets for the project, one of them being the main protagonist. I am taking it very slowly, redoing major parts of the character even, because I don't want to rush it just for the sake of getting it done quickly. This is why I haven't had anything interesting to post for the past week.
I have made some headway in finalizing the script for the first episode, and am contemplating a possible teaser trailer. I'll be sure to post any interesting updates.
Wednesday, 4 May 2011
FX test - Muzzle flash
You know what they say about variety being the spice of life, so I've decided to take a break from modeling today to do some effects R&D.
If you've already seen the first test animation I posted, you'll notice that I have already implemented some form of muzzle flash on the blaster. What I wanted to achieve was a gaseous look, where the dense, superheated gas ejected from the muzzle (the flash) would expand and evaporate immediately. Lacking a easy fluid solution since Lightwave3D doesn't have one ( yet! ), I used a 3D muzzle flash mesh and Hypervoxels.
You can see the development of the effect in the video below.
Warning! Sound effects have been added near the end of the video.
There are still room from improvements such as fixing the geometric spiky look of the flash object, and improve the blending between the flash and the particles.The sound effects also sound kinda cheesy so I'm not sure at the moment.
Other than that, for a few hours of work, I'm pretty happy with it.
Sunday, 1 May 2011
Lightwave 3D - How motion blur killed the render time
Like many other Lightwave 3D users, one of the things I love most about the software is the relative simplicity of it's rendering engine. This is a great advantage for an independent 3D generalist like me - the ability to churn out frames with minimum tinkering is invaluable and an immense time saver. Nevertheless, being simple doesn't save one from aggravating hair-tearing moments, such as the one I experienced when rendering the test animation in the previous post.
The camera and rendering settings are similiar to what I typically use:
The test renders were also normal, clocking at about 6 minutes per frame on my old Core2Duo machine. If you are familiar with LW, you'll see that these are hardly the best settings if you're looking for a high quality output, but for a test animation I decided it'll do.
Satisfied that everything is in order, I sent the job to my i5 quadcore machine for final rendering and moved on to other tasks.
3 hours later I came back to check on the progress. To my utter dismay, it was still working on the third frame, with the second frame taking over 2 hours to render. Needless to say, it was a pretty huge jump from 6 minutes a frame on a lesser computer. Suspecting a freak memory leak at first, I restarted the rendering from the last frame to let it work backwards to the first frame. The first few frames took about 7-8 minutes per frame, which was still considerably slower considering 2 more cores were working on it, but I was too tired to troubleshoot, so I let it be and went to sleep.
In the morning, I checked again and found that the render was stuck at the 37th frame, with the previous frame taking 1.5 hours. By then it was already 10 hours into the render. For a simple 4 second animation, it was getting ridiculous.
By studying the render progress, I quickly realize that the render slowed to a crawl when ever it reach the portions with heavy motion blur. Lowering the blur amount and passes helped very little, and I was not about to reduce the AA and adaptive sampling settings, because it was bordering on being unacceptably grainy.
Initial forum searches yielded no results, until I found a thread on, where else, the Newtek forums. In a nutshell, the problem lied in the fact that I was using Photoreal motion blur and a deforming object, which did not play well with each other.
Faced with the grim prospect of spending a week rendering a test animation, I bit the bullet and switched to dithered motion blur and viola, the render time dropped to 6 minutes a frame, which remained more or less consistent throughout the 130 frames.
The result of using dithered MB, in my opinion, was not all that inferior to photoreal. The MB amount was low enough that the checkered dither pattern was not all that noticable. I suppose that given enough passes, it would look just as good as photoreal MB (photoreal uses stochastic dithering), though I'm not sure the resulting increase in rendering time would be worth it.
In any case, I guess I'll have to start looking into implementing MB in post.
Happy Labour day and first video of the blog
Please forgive the wonky animation, didn't wanna spend too much time animating at this early stage of production.
One of the animations I made to put the rig through it's paces. I've spent the past week de-bugging the rig and getting the damn thing to render. I ran into some rendering problems that caused some hair-pulling, head-banging and face-palm moments. That alone caused some re-renders and wasted a few days of rendering. I'll elaborate in the next post.
Nonetheless, in hindsight it is a good thing that I thoroughly tested these two things before going full swing into animation, otherwise this could cause some serious damage on my sanity.
Subscribe to:
Posts (Atom)