From demo to engine (1)-irenderable

From demo to engine (1) -- irenderable

For personal use only, do not reprint, do not use for any commercial purposes. 

 

From normalDemoToEngine (To facilitate the discussionEngineOnly refersRender engine)The most important part is abstraction and batch processing. This statement may not be easy to understand.Code:

Object1.draw ();
Object2.draw ();
Object3.draw ();

ThisWe writeDemoFromOoThis is a very good design solution. Every object knows how to draw itself, encapsulate all rendering-related data methods in the interior, and in the design mode.Shape, circle, rectangle. But you should have guessed that the reason why I wrote this articleArticleSo surely this method is not good. Let's take a look at the problem with this code.

1. Performance. Write graphicsProgramPerformance is always the first consideration. For Object. Draw To ensure correct object rendering, Draw All statuses must be set internally ( Render state , Vertex Declaration , Stream Source , Etc .. ) , If many objects are rendered in the same state, it is clear that redundant state settings affect performance. Secondly, as we all know, GPU It is better at rendering a large number of triangles at a time rather than rendering a small number of triangles at a time. Therefore, small ry is often packaged into an overall rendering.

2. Maintainability. This code is very difficult to expand. Ojbect , You must write Draw . In addition, more importantly, the underlying functions will spread all over the code. Once the underlying layer changes, almost all the code should be rewritten. For example Object All need to be saved Device And directly call Drawprimitive Drawing when the program starts from DX9 Upgrade Dx10 , Or from DX Migrate Openggl , All Draw The rendering-related code in the function must be rewritten.

If you are aware of these problems, congratulations, you have an initial engine idea. Back to the beginning of the article, the key to solving the above problems is to put allObjectAbstract As a unified object, and thenRendererOrganize and render in batches, such as the following:

 

Renderer. addrenderable (obj1 );
Renderer. addrenderable (obj2 );
Renderer. addrenderable (obj3 );
Renderer. drawscene ();

 

Here, all the rendered objects are abstracted Renderable Object. At first glance, all the rendered objects are unified into a class. / The interface does not seem so simple, but it is not complicated to analyze it carefully. What are the minimum elements necessary for rendering an object? 1. Ry information, including Vertex/index buffer, vertex Declaration ; 2 , Material information, including Shader , Render state , Texture ; 3 , Transform information, usually Matrix . What else? No, it's that simple. You can write it now. Renderable Prototype:

Interface Irenderable
{
Getgeometrypackage ();
Getmaterial ();
Getmatrix ();

}

 

RendererNegativeResponsibility settingsGeometrypackage, material, Matrix,IrenderableIt no longer depends on the underlying layerAPI. Further,GeometrypackageHow should we design it? For convenience of discussion, we assume that only one geometric data is used.Stream, You can write similar code:

Abstract   Class Geometrypackage
{
Packagetype;
Vertexdecl;
}

ClassBufferedpackage: geometrypackage
{
Vertexbuffer;
}

ClassIndexedbufferedpackage: bufferedpackage
{
Indexbuffer;
}

ClassRenderer
{
Switch(Packagetype)
Case: Buffered: drawprimitive;
Case: Indexedbufferd: drawindexprimitive;
}

 

Geometrypackage Is an abstract class. Different subclasses are derived based on different geometric data. You may say that this is not Object3.draw Implement for each class Draw Is it the same? Also, the key here is Geometrypackage There may only be a limited number of sub-classes. Since the hardware does not change for a long time, these limited sub-classes are relatively stable. However Geometrypackage Use the underlying type ( Vertexbuffer ) It may also change. Yes, but more importantly, we have already put all possible Object Vertex data in, centralized Geometrypackage In a few limited sub-classes, even if the underlying function changes, the modification is very fast, and all interfaces can still run. Renderer According Packagetype Judging which function to call, refactoring tells us Switch Yes Bad smell ? As mentioned above Packagetype Basically, stability is limited, so there will not be too many side effects, but the whole program will only Renderer Will appear Drawprimitive And so on. It will be very convenient to maintain later.

AboutGetmatrixThere is not much to say, but the above Code hides a more important part,Matrix [] getmatrix ()It is the complete writing method. In this way, it is applicable to objects with simple or skeleton animations.

AsMaterialIt's complicated. Let's talk about it next time.J

 

========================================================== ========================================================== ==========

I have long wanted to write some articles about the Renderer and material design. Unfortunately, I have never thought about how to write it. Today I am free. I just want to write something about it ..........