Making a CG movie with a game engine?

I'm not sure where to put this so I stuck it here. Mods can put it wherever they see this as being suited for the best audience.

I've been looking to see how close a game engine can render (non-realtime) CG-like quality to make a movie. My goal is to make sense of the realtime, VR, gaming space to see how viable it is for CG movie-making. How limited is the hardware? How limited is the software used today with some of the most advanced graphics engines on the market today? My goals here are twofold: (1) possibly create CG movies using a gaming engine and (2) be able to use the same assets, light rigs, animation rigs, etc.. with scaled down features for the VR sector. Looking at the latest Pixar realtime lighting tool was an inspiration.

Having about 2 weeks to play with a published graphics engine, some impressions have been mixed. Here is a list of things that are immediately concerning:

1) Memory. There just isn't enough of it right now. I'm not concerned with tricking the hardware to extract out FPS. I'm more interested in moving assets from the CG space to gaming space. 12/16G of VRAM just isn't going to cut it (more details below).

2) Physically Based Lighting/Shading. Right now most gaming engines tout that feature, but there really isn't any consistency here. PBS in the film world means you can move the same shader to various lighting conditions and it will hold up (i.e. using all the basics of energy-conservation, etc..). I was amazed to see how great 1 character looked under a set of lights for a particular scene, but when importing another character with the same shader and different parameter values, the character shading broke under the same lighting. This forced me to think how I could get consistency without adding a big burden on the lighters to hand tweak every single shot.

3) Fur. It's just not there. A bit disappointed to find out that some of the more popular gaming engines just don't have any implementation for rendering out actual curves to represent hair rendering. Why should they though? They are living in a land where FPS vs. Quality is a continuous balancing act. But I can't really use transparency cards to represent hair and it not be prone to breaks in the look at certain angles. Even with fur strips in offline rendering, we see some of these artifacts and can just add more to fill up the gaps. Rigging of curve primitives is also a big need. I'm not looking for simulations more than being able to hand-tweak curves to control "how" the curves move. From a director's point of view - they basically want control over everything.

Things that are good:

1) Excellent use of editing tools that can quickly be made to give rapid iterations of shots by moving various cameras and takes in realtime.

2) Incredibly robust screen space features which will pretty much remove the need for doing comp work in Nuke.

3) Unmatched speed at rendering (even though I hate the slow compile times for shaders). I'm still waiting to see how much I can throw at the hardware to where the render times equal CPU offline rendering. I have a long way to go for that, so there is room for pushing more to the hardware.

Another pet-project of mine was to research using the full programmable pixel/vertex pipeline with the latest OpenGL version to see about realtime texturing/lighting in the Maya's viewport for displaying texture/lit assets based on the Alembic cache. I was excited about this prospect and immediately went to work making a small "proof-of-concept" realtime renderer that could give me a small picture of how much can the hardware handle given a certain current texture workflow.

I first needed to make a gpu memory manager class (not yet finished) that could query the hardware and give me all the pertinent information.

This is on my newly built-machine with the following specs:

i7-6800k
64G DDR4 RAM
Titan X @ 12G DDR5 VRAM
EVO 840 1T SSD
OpenGL driver: 4.5

hardware_specs.png


What concerns me about this is the maximum number of texture units bindable for any given mesh. I also saw significant latency when all the texture contexts were initialized and uploaded to the GPU.

Using multithreading to load 75 unique textures (single threading was a non-starter) where most were 4k and some were 8x8 textures (this is a behavior of Mari to fill in rows of udim spaces), I was a bit surprised at the memory usage:

test_2-e1468776395403.png


I'm wondering how to control the mip-mapping levels in OpenGL as some of these textures have very high frequency and seems like the renderer can't help but introduce undersampling as seen here:


I went for the gusto and tried to load in 200 unique textures (these were diffuse only) and got this:

enterprise_test-e1468776833158.png


Basically consumed all of the Titan X's memory. LOL!

Lots to learn but enjoying the exploration and discovery.. more to come!
 
Last edited:
You should probably get a Quadro board for that job. The M6000 model comes with 24GB of on-board memory -- it is essentially Titan X with double the memory size.
 
You should probably get a Quadro board for that job. The M6000 model comes with 24GB of on-board memory -- it is essentially Titan X with double the memory size.

24G probably won't be enough either. :( How do the 6000s compare to the speed of shader execution compared to the Titan?
 
Is offline rendering using CPU based clusters because of speed or of the available memory?

Yes, we have Xeons (they are freaking fast) with 48G of RAM.

A lot of offline renders use tiling to control memory by sending threads to render a tile (usually 32x32), then throwing away chunks of memory it won't need. I might investigate this for OpenGL at some point. It might be a great solution. Right now, if I can barely get 1 asset in memory, I can't imagine an entire set.
 
Well, AMD offers 32GB on their high-end FirePro board (S9170), but the OpenGL support from them may not be on par to Nvidia's for professional applications.
Otherwise it's a desirable choice for those who use off-line OpenCL accelerated renderers -- lot's of memory for the assets and best in class OCL driver support.
 
Should probably go for virtual texturing, you shouldn't run out of memory regardless of the detail level of textures, at least provided mipmaps are correct etc... :)

And fur, you crazy? Lol. If we just get decently realistic-looking human hair sometime in the next decade we can probably count ourselves so lucky. Fully furred creatures would require simply boatloads of computational power above what we have available today.
 
Well, AMD offers 32GB on their high-end FirePro board (S9170), but the OpenGL support from them may not be on par to Nvidia's for professional applications.
Otherwise it's a desirable choice for those who use off-line OpenCL accelerated renderers -- lot's of memory for the assets and best in class OCL driver support.

I'll have to look into that. Never actually played with OpenCL.
 
Should probably go for virtual texturing, you shouldn't run out of memory regardless of the detail level of textures, at least provided mipmaps are correct etc... :)

Yea, I was thinking about virtual texturing too. Not sure how complex that would be writing in this simple engine though. Also, opens up a potential can of worms for problems when I eventually port this to Maya. I would prefer to brute force it. :p

And fur, you crazy? Lol. If we just get decently realistic-looking human hair sometime in the next decade we can probably count ourselves so lucky. Fully furred creatures would require simply boatloads of computational power above what we have available today.

Well, when I meant "fur", I meant anything that renders a flat curved ribbon (like most conventional offline renderer). Just not sprite cards. Speaking of curves, I wonder exactly what would be the computational cost with rendering several million flat-shaded segmented curves. I'll have to put that on the list.
 
Texture compression is my friend.. :)

So with regards to that 200 UDIM test, I was able to bring the memory footprint down to 3G from 12G using the DXT1 function in OpenGL. I'll have to add a compression tool to our pipe so that I'm loading pre-compressed textures so I can send them straight to the GPU instead of compressing on-the-fly.

There is still some latency when memory is moving around. I'm not sure if it's coming from the shader compile or the single threaded binding of texture objects in CPU to GPU. I'll multi-thread that at some point and see if I can record if it makes it better.
 
Back
Top