You can read quite often “An asset of type xy may only have xxx polygons”. This represents, what I call a polyphobia.
The number of polygons does not say directly something about its influence to the performance. Yes, it is correct, that most of the polygons has to be drawn and naturally have an influence.
But e.g NVIDIA states, that their GeForce GTX580 can handle two billion polygons per second. Actual other model have a comparable power. So we do not have to worry about the number of polygons that much as we had to do in times of TRS2004 and the GPU at that time.
I will not say not to worry at all, but there is no need to panic if it will be some thousand more.
Much more important is, how the cc (I use this an an abbreviation for content creator) handles the polygons!
First of all polygons which are not visible at all, shall be an absolute no go.
Secondly you have the possibility to gain an excellent optical impression with e.g. pipes, railings and similar objects by using less sides and add an appropriate smoothing (see picture 02). Generally you can use the formula 360 devided by the number of sides plus one as a threshold value to get a very good result.
And thirdly there is one element which is very often completely neglected by many cc, the vertices! These are the points of which a polygon is defined. And here it starts to get interesting. How does a gpu draws a polygon?
Here a simplified explanation.
An application passes an array of vertex coordinates to a so called vertex shader, which decides how they are later on displayed and calculates their screen coordinates. The gpu now groups three vertices, which have been processed by the vertex shader to a polygon and decides with quite complex calculations if the polygon is visible or not. If not it is discarded.
Is it visible, every polygon goes through a kind of setup which creates a definition of it. It is also calculated how this polygon interacts with other polygons, if there is an overlapping etc. and it will be generated a so called fragment.
With the fragment shader the properties like color, grade of reflection and much more will be defined. The gpu now combines the fragment color with the corresponding screen pixel color and the polygon will be displayed.
As you can see, vertices have a decisive part, because at run time the gpu calculates from a 3d model the polygons defined by the vertices. The major properties of the polygons are stored together with the vertices, by which they are defined.
That is why the topmost principle of a cc for his models should be, to connect at any possible places all objects via attach and even more important to weld all vertices. This reduces the number of vertices drastically and therefore the amount of calculation operations performed by the gpu.
Another advantage of welding vertices is the capability of gpu to perform a so called indexed drawing.
Normally each vertex have to pass the vertex shader, but not always. Do adjacent polygons share vertices and those are welded in the 3d application, the gpu can do this indexed drawing and does not have to call the vertex shader for each vertex. This saves a lot of calculation time.
In summary it is not the frequently quoted number of polygons which is important but the number of vertices of a model!
As a small example, look at picture 01. You can see a square where one part is bended about forty five degree around the axis at 3/6 and 2/4. This square consists of two planes (A and B) which are defined by the vertices 1, 2 and 3 for A and 4, 5 and 6 for B. The mesh consists of two objects (A and B) with six vertices and two polygons.
If we export it now to an im file, it has 492 bytes.
Now we attach the planes A and B via the attach function to one object. As a result we still have six vertices and two polygons and the exported im file has still 492 bytes.
Now comes the important step. In vertex mode all vertices which shares the exact same position are welded. The result is still two polygons, but only four vertices and the exported file has now only 428 bytes.
The planes are now defined by the vertices 1, 2, 4 and 2, 3, 4 and the gpu can use its indexed drawing and has left only four instead of six vertices to be calculated by the vertex shader.
It should be quite understandable how to model an asset to gain more performance, even with more polygons.
======================================================
So, if we get used to the thought, that we do not have to worry too much about the absolute number of polygons, as long as we remember what is said above, we can come to a much more important subject about performance.
The materials! About this subject most cc seems to be quite confused.
In the most simple case, a material consists of an indexed monochrome color value. To use a texture for this purpose is again an absolute no go! You should always use a notex material. For havens sake does the Content Manager marks monochrome textures above 32 by 32 pixels as a mistake. A good step in the right direction by Auran/N3V!
If an asset uses more monochrome colors than one, it might be better to use a texture which contains these colors like a checker board, not bigger than 8 by 8 pixel per color. These colors are easy to place somewhere inside another texture which is mostly used (photo realistic parts etc.).
A material can consist of one or more texture files. In the simplest case it is a diffuse map. But there can be more, e.g. opacity map, reflection map, normal map etc.
So, the number of texture files do not necessarily defines the number of materials which are used by an asset. And it is the number of materials which influence the performance most, in general the less materials the better the performance.
You should pay special attention to those bump or normal maps. They allow to reduce the number of vertices in a dramatic way without giving up details! E.g. rivets on a steam boiler, screws, bolts and so on.
Unfortunately, for this you need a 3d software which is capable of render to texture or also called texture baking, like Blender or 3dsMax. With Tools like the NVIDIA Normal Map filter or ShaderMap you can gain quite respectable results, but not as good as rendered textures with the before mentioned programs.
Some words about texture or bitmap files.
It is always better to use less texture files, in the most ideal case only one bigger file, instead of many small ones!
TS2012 can work with texture files up to 2048 by 2048. You can also use 4096 by 4096, but it makes no sense. Why is that?
I believe since TS2012 Trainz uses a so called texture lod. Means textures are displayed reduced and only if you come closer to an object the full map size is used. Unfortunately textures of 4096 by 4096 are generally reduced to 2048 by 2048 and it seems that the
algorithm used for this reduction is actually not state of art. So it might be a good idea to render in a higher resolution and reduce the size with a good graphic software like Gimp or Photoshop.
And if it is necessary, then use two textures of 2048 by 2048 because we do not want performance at any price but also assets with high quality.
It can not be only about reducing at any cost, but to avoid mistakes and unnecessary things which cost performance!
Mick!
The number of polygons does not say directly something about its influence to the performance. Yes, it is correct, that most of the polygons has to be drawn and naturally have an influence.
But e.g NVIDIA states, that their GeForce GTX580 can handle two billion polygons per second. Actual other model have a comparable power. So we do not have to worry about the number of polygons that much as we had to do in times of TRS2004 and the GPU at that time.
I will not say not to worry at all, but there is no need to panic if it will be some thousand more.
Much more important is, how the cc (I use this an an abbreviation for content creator) handles the polygons!
First of all polygons which are not visible at all, shall be an absolute no go.
Secondly you have the possibility to gain an excellent optical impression with e.g. pipes, railings and similar objects by using less sides and add an appropriate smoothing (see picture 02). Generally you can use the formula 360 devided by the number of sides plus one as a threshold value to get a very good result.
And thirdly there is one element which is very often completely neglected by many cc, the vertices! These are the points of which a polygon is defined. And here it starts to get interesting. How does a gpu draws a polygon?
Here a simplified explanation.
An application passes an array of vertex coordinates to a so called vertex shader, which decides how they are later on displayed and calculates their screen coordinates. The gpu now groups three vertices, which have been processed by the vertex shader to a polygon and decides with quite complex calculations if the polygon is visible or not. If not it is discarded.
Is it visible, every polygon goes through a kind of setup which creates a definition of it. It is also calculated how this polygon interacts with other polygons, if there is an overlapping etc. and it will be generated a so called fragment.
With the fragment shader the properties like color, grade of reflection and much more will be defined. The gpu now combines the fragment color with the corresponding screen pixel color and the polygon will be displayed.
As you can see, vertices have a decisive part, because at run time the gpu calculates from a 3d model the polygons defined by the vertices. The major properties of the polygons are stored together with the vertices, by which they are defined.
That is why the topmost principle of a cc for his models should be, to connect at any possible places all objects via attach and even more important to weld all vertices. This reduces the number of vertices drastically and therefore the amount of calculation operations performed by the gpu.
Another advantage of welding vertices is the capability of gpu to perform a so called indexed drawing.
Normally each vertex have to pass the vertex shader, but not always. Do adjacent polygons share vertices and those are welded in the 3d application, the gpu can do this indexed drawing and does not have to call the vertex shader for each vertex. This saves a lot of calculation time.
In summary it is not the frequently quoted number of polygons which is important but the number of vertices of a model!
As a small example, look at picture 01. You can see a square where one part is bended about forty five degree around the axis at 3/6 and 2/4. This square consists of two planes (A and B) which are defined by the vertices 1, 2 and 3 for A and 4, 5 and 6 for B. The mesh consists of two objects (A and B) with six vertices and two polygons.
If we export it now to an im file, it has 492 bytes.
Now we attach the planes A and B via the attach function to one object. As a result we still have six vertices and two polygons and the exported im file has still 492 bytes.
Now comes the important step. In vertex mode all vertices which shares the exact same position are welded. The result is still two polygons, but only four vertices and the exported file has now only 428 bytes.
The planes are now defined by the vertices 1, 2, 4 and 2, 3, 4 and the gpu can use its indexed drawing and has left only four instead of six vertices to be calculated by the vertex shader.
It should be quite understandable how to model an asset to gain more performance, even with more polygons.
======================================================
So, if we get used to the thought, that we do not have to worry too much about the absolute number of polygons, as long as we remember what is said above, we can come to a much more important subject about performance.
The materials! About this subject most cc seems to be quite confused.
In the most simple case, a material consists of an indexed monochrome color value. To use a texture for this purpose is again an absolute no go! You should always use a notex material. For havens sake does the Content Manager marks monochrome textures above 32 by 32 pixels as a mistake. A good step in the right direction by Auran/N3V!
If an asset uses more monochrome colors than one, it might be better to use a texture which contains these colors like a checker board, not bigger than 8 by 8 pixel per color. These colors are easy to place somewhere inside another texture which is mostly used (photo realistic parts etc.).
A material can consist of one or more texture files. In the simplest case it is a diffuse map. But there can be more, e.g. opacity map, reflection map, normal map etc.
So, the number of texture files do not necessarily defines the number of materials which are used by an asset. And it is the number of materials which influence the performance most, in general the less materials the better the performance.
You should pay special attention to those bump or normal maps. They allow to reduce the number of vertices in a dramatic way without giving up details! E.g. rivets on a steam boiler, screws, bolts and so on.
Unfortunately, for this you need a 3d software which is capable of render to texture or also called texture baking, like Blender or 3dsMax. With Tools like the NVIDIA Normal Map filter or ShaderMap you can gain quite respectable results, but not as good as rendered textures with the before mentioned programs.
Some words about texture or bitmap files.
It is always better to use less texture files, in the most ideal case only one bigger file, instead of many small ones!
TS2012 can work with texture files up to 2048 by 2048. You can also use 4096 by 4096, but it makes no sense. Why is that?
I believe since TS2012 Trainz uses a so called texture lod. Means textures are displayed reduced and only if you come closer to an object the full map size is used. Unfortunately textures of 4096 by 4096 are generally reduced to 2048 by 2048 and it seems that the
algorithm used for this reduction is actually not state of art. So it might be a good idea to render in a higher resolution and reduce the size with a good graphic software like Gimp or Photoshop.
And if it is necessary, then use two textures of 2048 by 2048 because we do not want performance at any price but also assets with high quality.
It can not be only about reducing at any cost, but to avoid mistakes and unnecessary things which cost performance!
Mick!