node中间层服务端渲染_中间渲染或功能内容

node中间层服务端渲染

We’ve got a feature we want to do — it’s something we call “intermediate mode render calls”. The idea is that some script could say:

我们有一个我们想做的功能-我们称之为“中间模式渲染调用”。 这个想法是一些脚本可以说：

Draw( position, rotation, mesh, material );

Draw( position, rotation, mesh, material );

And that would make the mesh appear with the given material at the given position on the screen, and it would just work with pixel lights, shadows, projectors and whatnot.

这样一来，网格就可以在屏幕上的指定位置以给定的材质显示出来了， 并且只适用于像素光，阴影，投影仪等。

A step aside on why this is needed: in Unity 2.0 the terrain engine does not fully integrate with pixel lights or shadows; and Projectors don’t work with it either. The reason is that terrain is rendered immediately: at some point terrains gets it’s render call, draws the chunks of the terrain, the trees, the detail objects and all of this goes straight to the screen.

除了需要这样做的原因之外，还需要做一些准备：在Unity 2.0中，地形引擎未完全与像素光或阴影集成； 投影仪也不使用它。 原因是立即渲染了地形：在某个时候，地形得到了它的渲染调用，绘制了地形块，树木，细节对象，所有这些都直接进入了屏幕。

For shadows, pixel lights or projectors to work, however, something has to be remembered, so that the most important lights can be calculated for each object, so that shadow casters could be rendered, and so on.

但是，要使阴影，像素光或投影仪正常工作，必须记住一些事情 ，以便可以为每个对象计算最重要的光，从而可以渲染阴影脚轮，依此类推。

With intermediate mode render calls the terrain engine could “submit” this lightweight rendering information: mesh, material, position; and the rendering system would figure out everything else at rendering time.

使用中间模式渲染调用，地形引擎可以“提交”此轻量级渲染信息：网格，材质，位置；等等。 并且渲染系统会在渲染时找出其他所有内容。

Ok, the above sounds like a plan. What goes into developing such feature?

好的，以上听起来像是一个计划。 开发此类功能有什么用？

The basic functionality is obvious. Draw() above would not actually draw anything immediately, just merely record the information somewhere in the scene: “this mesh with this material will have to be drawn here”. At the end of the frame, all this information would be discarded, so Draw() persists for one frame only.

基本功能是显而易见的。 上面的Draw()实际上不会立即绘制任何东西，而只是将信息记录在场景中的某个位置：“必须在此处绘制带有这种材质的网格”。 在帧的末尾，所有这些信息都将被丢弃，因此Draw()仅保留一帧。

Some design issues immediately pop up:

一些设计问题立即弹出：

• Maybe it’s drawn in all cameras if called from inside Update(), and drawn for current camera if called from inside OnPreCull() or OnPreRender()?

  如果从Update()内部调用，是否在所有摄像机中绘制，如果从OnPreCull()或OnPreRender()内部， 则为当前摄像机绘制？

• What to do if Draw() is called from inside of Start(), Awake() and other functions that are not related to “frame” or “camera”?

  如果从Start() ， Awake()和其他与“框架”或“相机”无关的函数中调用Draw()怎么办？

Some of the work required is also obvious: Right now all renderable things in Unity are Renderer components. That means they live in some game object, and so on. For intermediate mode calls, we need to put base rendering functionality somewhere “up” – so that a renderable thing can not necessarily be a Component in a game object.

所需的一些工作也是显而易见的：现在，Unity中所有可渲染的东西都是Renderer组件。 这意味着它们生活在某些游戏对象中，依此类推。 对于中间模式调用，我们需要将基本渲染功能放在“某个位置”上-以便可渲染对象不一定是游戏对象中的组件。

• Make IntermediateRenderer that would be used for intermediate mode. It has transformation matrix, pointers to mesh and material. Make it setup and update all related internal structures that describe Unity scene.

  制作将用于中间模式的IntermediateRenderer。 它具有变换矩阵，指向网格和材质的指针。 进行设置并更新所有描述Unity场景的相关内部结构。

With the above, we can go and write some code to implement the feature. Look ma, no game objects are here, just two lines of code drawing 100 meshes with random rotation in a loop! And it works with shadows!

通过以上内容，我们可以编写一些代码来实现该功能。 看吧，这里没有游戏对象，只有两行代码绘制了100个网格，并在循环中随机旋转！ 它可以处理阴影！

So the proof that the base feature works is there already (we say it’s a killer feature for making demoscene demos). We still have the design issues of the above, and some more that popped up while writing the code:

因此，基本功能有效的证据已经存在(我们说这是制作演示演示的杀手级功能) 。 我们仍然有上面的设计问题， 还有一些在编写代码时弹出的问题：

It’s a long rocky road between thinking up a feature and shipping it. Surprisingly, actual development does not take up much time; the most difficult part is answering all the design questions.

在考虑功能和发布功能之间，这是一条漫长的艰难道路。 令人惊讶的是，实际开发不会占用太多时间。 最困难的部分是回答所有设计问题。

Anyway, after all design issues are solved (or… ignored!), the feature usually is shipped. Yay!

无论如何，在解决了所有设计问题(或忽略了！)之后，通常会交付该功能。 好极了！

翻译自: https://blogs.unity3d.com/2007/12/06/intermediate-rendering-or-what-goes-into-a-feature/

node中间层服务端渲染