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的更多相关文章

  1. 《Small Memory Software:Patterns For System With Limited Memory》读书笔记

    原文地址:http://blog.csdn.net/jinzhuojun/article/details/13297447 虽然摩尔定律让我们的计算机硬件得以以指数速度升级,但反摩尔定律又不断消减这些 ...

  2. PatentTips - Sprite Graphics Rendering System

    BACKGROUND This disclosure relates generally to the field of computer graphics. More particularly, b ...

  3. Method, apparatus, and system for speculative abort control mechanisms

    An apparatus and method is described herein for providing robust speculative code section abort cont ...

  4. Intel graphics processing units

    http://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units Comparison of Intel graph ...

  5. Chromium Graphics : GPU Accelerated Compositing in Chrome

    GPU Accelerated Compositing in Chrome Tom Wiltzius, Vangelis Kokkevis & the Chrome Graphics team ...

  6. PatentTips - System and method to deprivilege components of a virtual machine monitor

    BACKGROUND INFORMATION An embodiment of the present invention relates generally to virtualization pl ...

  7. Role-based access control modeling and auditing system

    A role-based access control (RBAC) modeling and auditing system is described that enables a user to  ...

  8. System and method for dynamically adjusting to CPU performance changes

    FIELD OF THE INVENTION The present invention is related to computing systems, and more particularly ...

  9. [wikipedia] List of free and open-source software packages

    List of free and open-source software packages From Wikipedia, the free encyclopedia     This articl ...

随机推荐

  1. NuSOAP与PHPRPC比较(转)

    因为看到有人问 Nusoap 和 PHPRPC 的比较,为了让大家能够更清楚地了解 Nusoap 和 PHPRPC 的关系,所以在这里做一个简要的说明性介绍,所写的内容也不是面面俱到的,只写了一些主要 ...

  2. Oracle数据库高效sql语句的整理

    业务需求说明:由于之前公司后台APP端有一个document表,该表中包含了所有的信息,新的需求就是通过该表创建出一个新的用户表(usertable)和一个档案表(document,该表只保留原doc ...

  3. day11 堡垒机

    项目实战:运维堡垒机开发 前景介绍 到目前为止,很多公司对堡垒机依然不太感冒,其实是没有充分认识到堡垒机在IT管理中的重要作用的,很多人觉得,堡垒机就是跳板机,其实这个认识是不全面的,跳板功能只是堡垒 ...

  4. Python学习路程day9

    本节内容 Gevent协程 Select\Poll\Epoll异步IO与事件驱动 Python连接Mysql数据库操作 RabbitMQ队列 Redis\Memcached缓存 Paramiko SS ...

  5. C语言处理xml文件的库

    读取和设置xml配置文件是最常用的操作,试用了几个C++的XML解析器,个人感觉TinyXML是使用起来最舒服的,因为它的API接口和Java的十分类似,面向对象性很好. TinyXML是一个开源的解 ...

  6. sqlite入门

    SQLite官网: https://www.sqlite.org/index.html 1. 下载请到https://www.sqlite.org/download.html下载相应平台的sqlite ...

  7. [读书笔记] java类初始化

    以下内容来自周志明的<深入理解java虚拟机>: 类初始化阶段是类加载过程的最后一步,前面的类加载过程中,除了在加载阶段用户应用程序可以通过自定义类加载器参与之外,其余动作完全由虚拟机主导 ...

  8. 关于Task类

    private static void tt2() { Task task = null; ; i < ; i++) { task = Task.Factory.StartNew(callbac ...

  9. document.write 方法

    如果在文档加载结束后再调用document.write(),那么输出的内容将会 重写 整个页面. 某次被问及此问题,志之!

  10. 集群中配置多台计算机之间ssh无密码登录的一种简便方法

    当我们在配置多台计算,使之可以相互使用无密码登录-ssh,之前都是一台一台的配置,现在一台A上添加B,然后在另一台B上再次添加A,这样使得 authorized_keys中的内容相同,但时并不是完全相 ...