In this video, Autodesk 3D application specialist Michael Langmayer gives a demonstration of 3DS Max and how it takes advantage of multi-core computing. 3ds Max integrates the Mental Ray rendering engine and uses distributed processing, including over a network.

"Metal Ray allows you to take advantage of multiple processors -- not only processors in this machine, but processors in the network," he says. "We have something called distributed bucket rendering. If I switch this one on, and the network here is connected to other machines, I could basically connect to four other machines having dual-core processors intalled, and I could then render with the power of four machines."

He then demonstrates the rendering process: "At the bottom you can see we're getting all those different buckets. Each bucket is actually representing one core of this machine I'm running here. It's helping the artists or the creator of any office or design-related building to render a lot quicker. ...We can utilize this in the games market for texture baking, for example. ...We're really harnessing the power of those multi-threaded machines."

Langmayer also demonstrates the 3D sculpting tool Mudbox.

Posted by Chris Remo at 11:07 AM | Permalink | Comments (0)

Kyle Hayward, a Purdue University senior studying graphics research who we've featured before, posted a useful primer to dual-paraboloid reflections, which he describes as a "view-independent method of rendering reflections just like cubemaps."

Unlike cubemaps, which can require updating up to six textures when rendering dynamic scenes, dual-paraboloid reflections only require updating two textures.

Hawyard comments: "They won't give you the quality of cubemaps, but they are faster to update and require less memory. And in the console world, requiring less is almost reason enough to pick this method over cubemaps."

He goes on to share several reference articles and a math overview before providing code for developers to experiment with generating their own reflections with paraboloid maps.

Hayward notes that there are a couple faults to watch out for in addition to reduced quality: "One drawback of paraboloid maps is that the environment geometry has to be sufficiently tessellated or we will have noticeable artifacts on our reflector. Another drawback is that on spherical objects, we will see seems. However, with objects that have convex and concave polygons, the seem won't be as noticeable."

Posted by Eric Caoili at 11:50 AM | Permalink | Comments (0)

In the latest Intel-sponsored feature, Goo! developer Tommy Refenes of PillowFort matches wits with multi-threading in four gripping acts -- and emerges victorious.

Refenes begins by describing his initial attitude to threading, one which proved a poor choice: he dedicated a thread to the specific tasks of collision, only calling that thread's functions when needed and keeping it in a nonfunctioning loop otherwise. Here, he explains his mistake:

"The model of having two threads sleeping and waiting for work (at least in the way in which they were waiting) was horrible. The threads waited in an infinite loop for work, and if they didn't find any, they performed a Sleep(0) and then continued waiting for work. At the time, I thought the Sleep(0) would free the processor enough so that other threads running elsewhere on the OS would be scheduled efficiently. Boy, was I wrong. The work check loop had the two processors constantly running at 90 percent to 100 percent capacity- an absolute waste of time. To understand why, picture this scenario.

"Let's say you are in charge of five construction workers tasked with paving a road. You know that you will need at least two of them to lay blacktop and at least the remaining three to grade the road, dig the ditches, and so on. Being the efficient supervisor that you are, you wouldn't think of allowing the two workers that need to lay the blacktop to sleep in the middle of the road until the blacktop is ready to be laid. No, to work as efficiently as possible, you would put all five of them to work grading and then all five paving. "

Refenes goes on to describe how he then created a new custom multi-threaded collision engine -- which he once again threw away and rewrote since that version of the game would not run on single-core machines. By the end of Act 4, he has programming another engine, one which dynamically scales based on the number of cores available.

You can now read the full feature, which includes specific technical details and visual aids.

Posted by Chris Remo at 01:01 AM | Permalink | Comments (0)