PocketMatrix

I have two questions, most likely they are unrelated.

First -

The codebase I am working with uses a transparent fixed-point format that is currently set to 16.16 representation internally. (In code it is treated as a float, e.g. we can set a value to 1.0f but it is stored as 65536.)

Edgelib seems to use multiple fixed-point formats, however - it appears that most numbers are 16.16 but 3D coordinates and rotation arguments are 20.12, and there may be others I don't know about.

Could you possibly explain which formats are used throughout Edgelib? We are running into issues when converting from our fixed-point format into Edge's, since the exact format each function takes is not documented well. (Searching the forums, it seems that texture coordinates and scale arguments are 16.16, but translation and rotation arguments and the internal matrix format are 20.12.)

Would there be any adverse effects from directly using 16.16 fixed-point translations/positions as if they were 20.12? Obviously things would appear 16 times larger than they actually should be and we would still have to convert rotational arguments from 16.16 to 20.12, but it seems as if that's it.

Second -

Is there any way to see the values for the perspective matrix that is being used? We are possibly getting some strange perspective distortion - a bounding box in the shape of a cube, for example, seems very flat in the z-direction (into the screen) until the camera is directly over it, at which time it starts to appear more regular. Has anyone else experienced issues like this?

It's possible this issue is just me being more used to a view frustum with a wider field of view - could you explain the values the default perspective matrix uses for construction?

Thanks for any help you can provide.

Hi Alan,

Most of the internal 3D structures are 20:12 fixed point values with the exception of texture coordinates (those are 16:16) and vertex normals (these go from -128 to 127 and are stored as signed characters). The reason for using 20:12 instead of 16:16 is to make smaller lookup tables and to prevent data overflow. Is it possible to change your class to use 20:12 fixed point values? 16:16 fixed point values are used as parameters to Scale() and return values from Cos() and Sin().

Regarding the perspective:
Are you using the internal 3D engine? If you are: For the internal 3D engine we're currently using a specific formula for the perspective which doesn't use a matrix. We plan to change this however, to make it more similar to OpenGL. This is planned for one of our future EDGELIB releases.

Are there any planned improvements to the internal renderer?

I ask because it seems as if there are several show-stopping issues that could be remedied by adding in guards against integer overflow and zero-division.

I am assuming that instead of a matrix you are using some simpler perspective calculation that involves division by depth relative to the transformed world zero point (i.e., the camera point.)

When a transformed triangle intersects the zero point on the depth axis, the possibility exists for some portion of the triangle to be rendered at a depth of 0. When this happens, the application crashes.

Sometimes a triangle is in front of (or behind) the zero point, but has a very small transformed depth - I suspect that the range on this is not checked because what seems to happen is that the calculated X/Y screen-space coordinate overflows, resulting in the triangle getting drawn over the screen.

This is a problem for me because my project is a racing-type game in which the camera follows a player object around the track - at any given moment the camera moves past several triangles of track, which gives rise to this problem. We have chopped the track up into small tiles and we cull to a "near plane" in order to prevent these sorts of errors, but if we cull too aggressively it's visible on screen and if we don't cull aggressively enough we get incorrect perspective projections as detailed above.

So, again - are there any plans to improve the renderer by at least checking and guarding for zero-divide and overflow errors, or is it going to remain in its current state until we all have hardware-accelerated renderers to work with?

Hi Alanhorne,

We're currently working hard on improving our software 3D renderer. We're aware of the issues you're having, they're part of the engine improvements we're working on. The new 3D software engine is planned for EDGELIB 4.0.

This will be announced soon.