Known bugs in the Nokia M3G implementation

[taarnio]

Below is a list of known bugs in the Nokia M3G (JSR-184) implementation as of April 21, 2005. The bugs are listed in the order they were discovered and fixed, the most recent ones first.

These bugs concern the Nokia 6630, and some of them may concern our other M3G enabled phones as well, such as the 6255 (CDMA) and the 6680. We do not have the details on which exact firmware versions are affected, however: It usually takes several weeks or even months for our M3G engine releases to propagate into final products.

2005
====

* Duplicated SkinnedMesh nodes do not animate. The best workaround for most cases is to load the mesh multiple times, then copy the Appearance and VertexArray objects from the first instance to avoid multiple copies of large data elements. Fixed in the wk15 2005 release.

* SkinnedMesh vertices not attached to any bones may move erroneously. This can be avoided by attaching all vertices to at least one bone, which usually is the case with skinned models. Fixed in the wk15 2005 release.

2004
====

* Transformable.pre/postRotate does not work. This happens after setting an initial orientation with Transformable.setOrientation(0, 0, 0, 0), which is legal according to the spec but results in invalid values internally. As a workaround, any non-zero axis to setOrientation(0, ...) will work. Fixed in the wk05 2005 release.

* Loader fails to load compressed M3G files produced with HI's exporter. This is because of a bug in handling of empty compressed sections. As a workaround, do not tick the "Compress" checkbox in the M3G Converter tool. Fixed in the wk05 2005 release.

* Camera and light transformations are incorrect after a retained-mode render. There is no other workaround except to manually copy the camera and lights from the scene graph into the Graphics3D. Fixed in the wk51 2004 release.

* Sprites are not rendered correctly or at all. This occurs when using the Node variant of retained-mode rendering; with World rendering, sprites work as expected. Fixed in the wk51 2004 release.

* Loader ignores transparency information in PNG images. This bug affects Series 60 devices only. Nokia 6630 ignores all types of transparency; Nokia 6680 handles raw alpha channels correctly, but ignores color-key and palette transparency. As a workaround, use Image.createImage to load the PNG, then construct an Image2D from that. Fixed partially in the wk47 2004 release, fully on wk49.

* The background image may flicker on and off when scrolled. A wrapping background image is erroneusly not drawn if the crop rectangle is outside of the viewport. As a workaround, use a modulo operation to always put the crop rectangle within the viewport. Fixed in the wk45 2004 release.

* Depth offset works the wrong way around. Can be circumvented by changing the sign of the depth offset factors, but this is _not compatible with later versions_. This was a bug in the underlying OpenGL ES library and has been fixed in their wk43 2004 release.

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

Best regards,
Tomi Aarnio
JSR-184 Specification Lead
Project manager, Nokia M3G engine

[ant01]

cheers for this Tomi

[kufa_reason]

Good to have this kind of list!
Will you release such infos in a proper document?

I also encountered several other issues, like:

- Keysequences using slerp doesnt work work properly (nokia 6680/6630 - firmware 2.39.151 19-11-04 rm1)

- small float operation errors (even though it's a jvm bug, i guess it might influence alot when coding 3d stuffs)

- Image2D leaks. After re-creating one Image2D at every paint (using the Image2D( int, Image) constructor), the device will hang. Happens on a N90 firmware 2.0530.3.5 29-07-05 RM-42.

/kUfa

[taarnio]

The bugs are nowadays listed in the Forum Nokia Technical Library document, under Known Issues | Java.

As for the additional problems that you listed:

* The slerp thing is a bug in everyone else's implementations and tools except ours and Hybrid's. This has been clarified in the M3G Maintenance Release (v1.1) spec, see e.g. the change log at http://jcp.org/aboutJava/communitypr...-proposed.html.

* I know of a bug in float multiplication in the 6630 VM that causes values very close to zero (so-called denormals) to "wrap around" to infinity. Are you referring to the same bug? If not, or if you have found the bug in later phone models, please make a formal report to Forum Nokia with a test midlet attached.

* Image2D memory leak: Probably a memory management bug in the VM, that just happens to manifest itself with Image2Ds because they use relatively large amounts of memory. Please make a report with a test case attached.

Tomi

[kufa_reason]

Thanks for your answers,

concerning the slerp issue, basically only the 6680 and 6630 cannot render properly some scenes, all sonye phones and other jsr184 phones dont have any problem. Hybrid's j2se implementation works fine too.

I'll send test applets for the two other issues as soon as i find some time!

/kufa

[taarnio]

You say that slerping behaves the same way on all other phones except 6630 and 6680. Do those other phones include Nokia S40 phones, e.g. the 6230i? If slerping behaves differently from one Nokia device to another, then we need to investigate the issue further.

However, if slerping works the same way across all Nokia devices, then the problem is probably what I suggested before -- the fact there's a known bug in everyone else's implementation. I might've been wrong about Hybrid; maybe they have the bug, too.

The latest HI Corp exporter for 3ds max (released in late October) should fix the slerping issue once and for all. I haven't tried it myself, but supposedly it adjusts the keyframes so that they work properly on all devices.

Tomi