DCC Software and Graphics System

标签：handle   direct   osi   style   gic   exe   more   work   ini   

After working with DCC software for so many years, I saw the realtime solution went forward so much, also more and more low-level. As the game engine, 10 hears ago the game engine was such a challenge that now everything become so cheap, everybody could own it. But to the DCC software, with the birth of CG industry, actually most of them are very old/classical, but if we still don‘t learn anything new from the mistakes, and didn‘t figure out the boundry of the problems we have, that‘s not a bright future LOL.

Here are some popular realtime frameworks used by popular DCC software.

• OpenSceneGraph Popular framework for visualization, used by many projects widely, such as Foundry Katana. It has a complete object model as a 3D rendering system also with a lot of utility libraries such as osgFX. But to the rendering, it just wraps the OpenGL API, the style is almost near to the traditional OpenGL.
• PIXAR Hydra Still a traditional framework. As a critical part of the huge USD, it depends on the other components of USD. Whatever how complicated the architecture it is, it still doesn‘t solve the critical problem.
• Autodesk VP2 (OGS One Graphics System) Used by Autodesk M&E products, the 3dsmax and Maya. The idea is to cover the all main stream API thought single API, now it supports both OpenGL and DX as the two most important backends.

Now let‘s think about the reality. What‘s the bottleneck of the DCC software on viewport ? Usually if we have the numerous different object, the interactive performance will be go down, or use too much memory to consolidate the world which means pack the static geometry data as much as possible to reduce the number of draw calls. Okay, now let‘s back to the reality and the real problem. Today, the latest graphics API become more and more low level, means the application could really find a proper way to maximal the performance.

If I design a rendering system for a DCC software, what will I do ? First of all, an abstract layer for the low level of API, both Vulkan and DX12. Because now, from the practical point of view, no big difference between Vulcan and DX12, but just the vendors considering their monopoly position for target platforms. So in future, there might be a new API or middleware to cover this requirement.

Based on 1), application supplies an asynchronized frameworks, there is an Gather/Reduce mechanism which will have a global statistical info about rendering entities. From the object model side, it sends the request to generate hashed rendering data, and tell the graphics system how many instance, and how many variants it might have. This logic works as the 1st level, then later at the 2nd level, the graphics system will aggressively reduce the draw call by packing the data.

The other features ? In my opinion, even not necessary if still based on realtime solution. Such as hardware shadowing in the viewport. Actually in the DCC software, most of the time, people even don‘t care about shadowing, but the draw performance for the layout. And also, realtime rendering, now is still less flexible than offline rendering, because in a nutshell, "realtime rendering" equivalents to "pre-rendering".

After so many years, people had invented so many useless craps, from the AMD Ashli, tried to translate RenderMan shader into realtime shader directly, or later the Autodesk ShaderFX, another unfinished crap, even the main developer just left. People always search a way to clone the offline rendering features into the viewport.

Actually today, with high performance Path Tracing renderer, if turn off the AA, the software rendering performance is totally acceptable, and much more reliable than the realtime rendering generated image.

Revise the fundamental concept.

• To the realtime rendering, the "renderer" equals to "rendering logic", executor is the GPU.
• But to the offline rendering, the "renderer" equals to "renderer logic" + "external logic", executor usually is the CPU.

So, still, back to the reality, what‘s the best solution for the user ? My answer is, super fast viewport with good extensible feature for the offline renderer. We even don‘t have to spend any time to do realtime shadowing, but focus on the geometry optimisation. We don‘t need realtime displacement, because for the production, the viewport will definitely die. But we need a way to check qualities, such as UV rendering, simple texture rendering, vertex attribute rendering, which is necessary for the DCC software. User could directly preview the real production frame, but don‘t have to care the viewport. To the viewport, it must be able to handle massive different objects, that‘s the most important things in future production.

Unlucky, today we are surrounded by the all advertising bullshit, whatever how good the demo it is, just the demo, if people do believe demo, that means not professional or lying. So easy.

DCC Software and Graphics System

标签：handle   direct   osi   style   gic   exe   more   work   ini   

原文地址：http://www.cnblogs.com/Jedimaster/p/6105477.html