Download - Chipped paint Lightwave3D preset

Yes, yes I know it's been a rather long time since my last update. While I have been hard at work revamping a lot of the assets, I have also been kept busy with paid jobs. In fact, this project is the only thing that keeps me from burning out from all those mundane, un-creative jobs that pays for my meals.

Anyway, I am working on a short teaser at the moment. The teaser will not only serve as a demo of the visual style and quality I'm aiming for, but also a means to experiment with my production pipeline. I've made some progress, albeit slowly, but I'm hopeful I'll get it done very soon. Oh, and having one of my workstations die on me the last weekend didn't help.

One of the things that I had started to develop early on was a metallic chipped surface shader that I could reuse (and easily modify as needed), since the story takes place on a space station where there will be many, what else, old, scratched metallic surfaces.

I have completed a version using only the layers system in Lightwave3D with procedural textures and gradients, the result of which you can see below:

A version of the shader was applied to my early prop models, such as the barrel:

You can download the preset here (Newtek Lightwave 3D v9.0 or higher required).

I am currently working on a node-only  version of the shader which will allow me to control the amount of chipped areas via a weight map, such as on the edges of an object.

Using a procedural shader saves me the trouble of painting chipped paint textures for every single object, and I don't have to worry about texture sizes since procedural textures are resolution independent. The downside of this approach is the increased CPU overhead when rendering since the textures have to be generated during rendertime. But considering the alternative of using high resolution image maps, which will incur memory overhead and possibly a larger impact on rendering time, I think it is a fair compromise, if not a solution.

Alright then, back to work!

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.

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.