Had a quick glance @ the MIDP1 Diet3D implementation.
It won’t be very scalable for complex scenes (or for any rendering more complex than flat shaded triangles), as it uses Graphics.drawLine to perform the rasterization of triangles.
For MIDP1 devices a more scalable solution is to rasterize the scene to a byte[] (with the necessary png formatting wrapper).
This avoids the overhead of the many calls to Graphics.drawLine (replacing it with far cheaper array accesses), but adds a fixed cost of having to regenerate a png image every game frame. (and for phones that check the png’s CRC, the added cost of having to recalculate the CRC value every frame also)
Once you have eliminated the overhead of calling Graphics.drawLine to perform a single pixel change, you can consider adding better effects to your rendering engine. (lighting, gouraud shading, zbuffering etc etc)
Infact, using this approach is a great advantage from a development perspective also, because you can simply adapt code from software 3D renders designed for the Java1.1 J2SE platform. (as these are all designed to operate on pixels in int[]'s).
For example, it would not be a huge task to write a J2ME interface for the Anfy 3D Software Renderer. (This is just an example, as the Anfy Engine is ofcourse licensed. There are other Open Source Java1.1 3D engines.)