FAQ

Part of the object is not visible. What is the problem?

MascotCapsule : V3, V4(V3 compatible), V4
Platform : ALL

If the settings for the clipping planes are not correct, models will be clipped in some cases, and not be rendered as expected.
When the models are located closer to the viewpoint than the near clipping plane, they will be clipped and not rendered. Also, when the models are located farther away from the far clipping plane, they will not be rendered, either. In other words, models should be located between the near clipping plane and the far clipping plane in order to be rendered.

[ Example of invisible part because of the near clipping plane ]


In the example above, a single object has completely disappeared. However, a part of the object might be rendered depending on the positional relationship between the near clipping plane and object. In that case, a lot of the part that are supposed to be visible may be clipped, making a very unexpected rendering result.

[ Part of the object was clipped ]


In this case, you can avoid the clipping by making the near clipping plane closer to the viewpoint.

[ Examples of invisible part because of the far clipping plane ]


If you have set the near clipping plane very close to the viewpoint, and the far clipping plane very far from the viewpoint in order to address this issue, it might create a new problem. The precision will decrease along the depth direction between the two clipping planes.

The specified light is not applied in the result.

MascotCapsule : V3, V4(V3 compatible), V4
Platform : ALL

If the settings for the light are not correct, models will not be rendered as expected in some cases.
Intensity of the omnidirectional light and spot light varies depending on the distance from the light source. Therefore, a model will look darker when it is far from the light source. When the light source is located behind the object, only the dark side of the object will be visible from the viewpoint.

[ Examples of dark object because of the light source position ]


In the examples above, the light source is located behind the object, or located far away from the object and only the weak light reaches the object. These examples have white background and the problem is easily noticeable. However, when the background is darker, it might be difficult to tell whether the objects are displayed or not.

In the case of spot light, you need to be careful about the influence of not only the distance of the light source, but the direction and the beam angle.
No matter how close the object, it will look darker if the light does not face the direction of the object, or if the beam angle is too narrow and the object is located outside the lit area.

[ Examples of dark object because of the spot light direction or beam angle ]


In addition to this, ambient light settings will also influence the object. For example, if the ambient light is too strong, the three-dimensional effect of shading will be lost.

[ Examples of lost shading effect because of ambient light settings ]

Results in the handset emulator and actual handset look different.

MascotCapsule : V4
Platform : ALL

Most of handset emulators use a software renderer of MascotCapsule engine in order to execute rendering. On the other hand, if the actual handset is capable of using hardware accelerator for 3D rendering, it calls the dedicated OpenGL ES driver to execute rendering (handsets without hardware accelerator capability use a software renderer in the same way as handset emulators).

Rendering process by a software renderer is considerably slower than the hardware; therefore, the software renderer uses algorithm to speed-up the process at the cost of some accuracy. That's why the displayed results on the handset emulator sometimes differ from the actual handset.

Texture mapping results look different depending on emulators or handsets.

MascotCapsule : V4
Platform : ALL

Difference of software renderer's speed-up algorithm is clearly visible when rendering the polygons that are mapped with textures. Accuracy of texture coordinate interpolation, and perspective corrections has a lot of influences on the quality of result.

[ Example of texture rendering results using different renderer ]

Texture colors look different depending on emulators or handsets.

MascotCapsule : ALL
Platform : ALL

Depending on environment, pixel depth or lighting calculation varies.
In an extreme example when the depth of each RGB is only 1 bit, just like in the old personal computers, only 8 colors (including black and white) can be displayed. It would look very different from the handsets capable of displaying multiple color tones. Also, even with the same pixel depth, colors might look different to some degree when the results vary because of differences in lighting calculation algorithms, or calculation accuracy.

Display positions or anteroposterior relationships of objects are different depending on emulators or handsets.

MascotCapsule : V4
Platform : ALL

When multiple objects are located in very close proximity, or when vertex positions of multiple polygons are very close to each other in a single object, the coordinate value in the depth direction (z-value) may become the same because of the error margin. In such cases, anteroposterior relationships of objects will not be rendered correctly.
For example, z-depth might be different between handset emulators and actual handsets. In such cases, results may not look exactly the same; one or the other would display a different anteroposterior relationship.

In some cases, different 3D renderers are used in the emulator and actual handset, or in a certain type of actual handsets. The software renderer in the emulator and OpenGL ES renderer in the actual handset have the same basic workflow for computing and rendering 3D. However, details of algorithm or orders of computing are different. In such cases, computational accuracy varies (likewise, if implementations are different, results may vary between OpenGL ES renderer and OpenGL ES renderer).

Therefore, even when the same objects were rendered at same positions in the emulator and actual handset, actual display positions might be different. In a lot of cases, the size of differences is less than one pixel, and objects' positions are the same. However, in some cases, the actual display positions may very slightly vary because of round-off or round-down.
All told, it is difficult to determine the display positions of 3D rendering without depending on specific handsets, in a single-pixel scale. It would be safe to assume a one-pixel margin for object positions when creating applications.
Conversely, if there are differences of more than several pixels in display positions, it means that there is a possibility of miscalculations in 3D processes (including hardware or drivers).

Some polygons are running off the object's edge.

MascotCapsule : V4
Platform : ALL

Sometimes polygons look like running off the object's edge, because of accuracy issues in the execution environment.
This phenomenon does not always occur throughout the entire object, and sometimes occurs only to the portion of object. Or rather, it would be more correct to say that occurrence depends on individual polygons because the calculation of 3D is performed in a polygon-to-polygon basis.

As a result, in some cases the position of the object as a whole is correct, although only a portion of polygons runs off the object's edge. When this portion is small in relation to the whole object, it would look like a group of pixels instead of polygons. Therefore, it would look like some pixels are running off the edge of some objects.

Unintended objects are displayed at the front.

MascotCapsule : V3, V4(V3 compatible), V4
Platform : ALL

MascotCapsule V4 has adopted Z-buffer method for rendering to the frame buffer. On the other hand, versions older than MascotCapsule V4 used Z-sort method.
In Z-buffer method, depth detection is performed per pixel, and the object closest to the viewpoint will be rendered. Meanwhile in Z-sort method, z-values are sorted per polygon and rendered; as a result, the object closest to the viewpoint will not always be visible in the most foreground position, in terms of pixels.
Therefore, rendering results of MascotCapsule V4 and versions older than MascotCapsule V4 might be different. Especially when polygons are intersecting with each other, Z-sort method cannot render correctly, whereas Z-buffer method is capable of correct rendering because depth detection is performed per pixel.

[ Differences in rendering intersecting polygons ]

Proper settings for the near clipping plane and far clipping plane.

MascotCapsule : V4
Platform : ALL

When multiple objects are located in very close proximity, or when vertex positions of multiple polygons are very close to each other in a single object, the coordinate value in the depth direction (z-value) may become the same because of the error margin. In such cases, anteroposterior relationships of objects will not be rendered correctly.

This phenomenon tends to occur at a position far from the viewpoint, because of the z-value characteristics on the depth buffer. It is related to the fact that objects closer to the viewpoint are rendered larger, and objects distant from the viewpoint are rendered smaller in perspective projection. When rendering the objects that are located very far from the viewpoint, they will be scaled down not only along the x and y directions, but also along the z-direction.

In addition, this issue is related to the settings for the near clipping plane and far clipping plane. This is because the z-value to be written in the depth buffer will be adjusted so that the depths of the near clipping plane and far clipping plane become maximum and minimum z-value, respectively (the space between both clipping planes becomes the largest possible range for depth buffer values).

Therefore, even when two objects do not change their positions, the larger the distance between near clipping plane and far clipping plane, the closer their z-values on the depth buffer will become. If these values approach too near to be measured within the accuracy of the depth buffer, these z-values will become the same. In such cases, it is impossible to distinguish which object is located in the front.

Also, if a proportion of the distance from the viewpoint to near clipping plane and the distance from the viewpoint to far clipping plane becomes larger, there will be more likelihood of problems. This is because the accuracy of z-values in the vicinity of far clipping plane will be significantly deteriorated when the far clipping plane is distant from the viewpoint (in addition, rendering will be reduced along the aforementioned z-direction).

In order to avoid this issue, the general rule of thumb would be to set the near clipping plane and far clipping plane as close as possible. However, please note that when they are too close, objects will be clipped.
In general, it is preferable to place the near clipping plane slightly nearer to the viewpoint than the object at the very front, and to place the far clipping plane slightly farther from the viewpoint than the object at the far end.

Z-values are not applied to semi-transparent polygons.

MascotCapsule : V4
Platform : ALL

When semi-transparent polygons are included in the objects to be rendered, in some cases, anteroposterior relationships of objects will not be rendered correctly. This is because depth detection of the Z-buffer method cannot be applied to semi-transparent polygons according to the specification, and z-value will not be written in the depth buffer.
Therefore, when rendering objects that include semi-transparent polygons, please note that the result may not be rendered correctly depending on the order of rendering.