M3G format - 2006 GDC talk

Hi, I found this on the internet archive:
Mobile 3D Development and COLLADA Stephen Wilkinson 3/20/2006 4:00 PM - 4:45 PM

It points to the Khronos schedule for conferences. It’s really interesting. I don’t know if Stephen Wilkinson is still around these forums now? I’d like to ask 2 simple questions about the .m3g format regarding fog (distance planes) and vertex colors.

I’m aware of the m3g evolution from 2004-2009 up to the .h3t format.
However, I’d like to get into this topic with technical details (back to 2004).

Please let me know if anyone else has had the opportunity to code or work with the J2ME 3D .m3g format.

Cheers!
Pierre.

Incidentally, does anyone have screenshots of how the 3D Mascot Capsule game engine v.3 looked?

I was a member of JSR-184 which created the .m3g format and worked on Mascot Capsule v4, which was an M3G implementation and am somewhat familiar with Mascot Capsule v3. I do not have any screen shots from v3. I was also a member of JSR-297 which created M3G 2.0. The latter was overtaken by events so that no products were ever released.

It was all a long time ago. Not sure how much detail I will be able to recall.

1 Like

Hi @markc , it’s amazing to meet someone from the original .M3G format dev team!.:fire::fire::fire:

I think the format is formidable as it has so many things that definitely shaped the way we handle 3D data ( I saw a lot of similar things regarding USD and GLTF).

I picked up interest in this format to give original retro game developers a way to port their 3d meshes into the JSR184 J2ME format. I’m coding with the help of Claude, Gemini, a modern day M3G exporter using Blender 3.6. github().com/3dcinetv/M3G-Blender-Exporter

So far, the exporter does:

  • export .m3g byte complyant
  • bones + animation (1 action timeline)
  • Materials + alpha
  • World color (background), ambient light, point, and sun (omni / directional)

Next on the roadmap:

  • Vertex colors
  • Morph targets (blendshapes)
  • Fog (it’s there but I can’t assign the appearance)

I contacted Claus Höfele after I found out he wrote a whole book using Blender 2.49 and M3G API. This was last week.
For the past two years (before I found the book), I’ve been trying to put 2+2 together basically through trial and error. AI wasn’t “smart enough” back then. However things have changed for the better and I finally got work done in 1 month, what took me 2 years to slowly progress in regards of making the exporter.

I got a semi-final “Pre-release” version finished now.

I understand back in 2005, the original .m3g .py addon for Blender 2.49 also had a long journey of development. I read the notes inside the addon, and there were things left to be finished. I understand the .mbac/ .mtra formats evolved pass .m3g, and in 2006 the .h3t format took over.
I understand Blender 2.5 arrived, then no one updated the addon, the format was left behind in time. I contacted another CGI artist who used to work in 3DsMax back at the time, and he pointed a lot of interesting facts about the .m3g format in regards of custom attributes/(in blender 2.8+: Custom properties).

@markc there are some things that are cryptic to me in regards of volume detection (they call it raycast - nikita36078.github(.)io/J2ME_Docs/docs/jsr184/index.html. Question: if I create an empty#1, assign custom properties: location, size; these properties can be passed on to Java by Object3D.find() <–Id of “1” in this example, and in Java we can create a “trigger event” if the raycast hits, right?

Another thing I wanted to ask is about LODs. There’s nothing on the current internet that talks about how J2ME handled .m3g LODs at the time. The little I know it’s only through other retro developer forums or old podcasts about the J2ME games era, but not really any details about how they handled/passed these kind of attributes (load?) at a given distance from the camera/player. If you could share something about this, it would be amazing.

You mentioned you are familiar with Mascot Capsule V3: was this an authoring visual environment like Unreal Engine or Unity? Even a vague sketch of what it looked like would be awesome. I understand it had an Eclipse integration, so I really don’t know if it had its own “tool panel” or it was just an easier way to import classes from it (dependencies / code)?

Anything you can share on these topics, I’ll be great to progress in this exporter for Blender 3.6
Regards!

Pierre.

@markc just chimining in, in case you’ve not seen this thread.
Also: Was mascot capsule just an API or an actual (visual) environment to develop games?




:star:The modern Blender 3.6 .M3G exporter is finally completed.

The exporter covers all the API features of the JSR-184
Including Bones, Mesh deformation (vertex weights), Parent-children transforms, textures, lights, world color/ambient light, vertex colors, animation, blendshapes, CUSTOM PROPERTIES, FOG and many other interesting features.

I will be publishing a video soon.
Hi. I am happy to communicate the modern Blender 3.6 .m3g exporter is now completed.
-Pierre.

I am truly sorry for my long delay in responding to your questions. For now I will limit myself to a few brief points. Congratulations on your Blender exporter.

MascotCapsule was the brand name for a 3d graphics engine initially for games created by HI Corporation which became part of ArtSpark and is now part of Micware which makes in-vehicle software.

HI was a game company. Around 2000 they wanted to make games for Japanese cell-phones and created MascotCapsule. All phones at that time ran J2ME (or similar) so the engine was used through a Java API connected by JNI. It supported only affine transformations and they obtained a patent on a method of doing these affine transformations without division. The engine was licensed to all Japanese cell phone makers and became part of DoCoMo’s iMode.

Up until v4, it had a proprietary, comparatively simple API that had some similarities to M3G’s immediate mode. It supported only affine transformations and had a single node type - Figure - similar to a SkinnedMesh. There was no scene graph. Everything was fixed-point. Despite its simplicity people did some amazing things with it. I remember an awesome simulator of Tokyo’s Keihin-Tohoku line from Tokyo to Yokohama around 2003 - 2004.

We had a 3DSMax exporter for creating the model (.mbac) and animation track (.mtra) files. We also created an exporter for .m3g. There is absolutely no connection between .mbac/.mtra and .m3g.

V4 supported both the proprietary API and M3G. The proprietary API ran a bit slowly on v4 because it was layered on the M3G implementation. (It would have been better to have implemented it with shaders but the investment, both time and money, to develop a compiler was a stretch too far.) Because of the performance another engine supporting just an improved proprietary API was created around the same time that Nokia and JSR297 (M3G 2.0) were imploding. This engine continued to evolve for use in device UI including in vehicles and this is where .h3t came in. This is also the time I retired so I do not have much familiarity with .h3t.

I’ll stop for now. I’ll come back later to try and answer your questions.

Where do you run the .m3g files you are creating with the Blender exporter?

1 Like

The spec. seems quite clear to me. Only Mesh and Sprite3D objects can be picked. You can use one of the pick methods on a Group. If the ray intersects a Mesh or Sprite3D, that does not have picking disabled or is out of scope, the pick method fills in a RayIntersection object from which you can retrieve the intersected object. From that you can retrieve any of its properties.

1 Like

I don’t recall any specific support for LODs in M3G v1. If you are talking about textures, the implementation was responsible. For Mesh, I suppose you could use submeshes and some application logic to pick which one to enable or use multiple meshes and application logic to render-enable or scope them so only the intended level gets rendered.

1 Like

Hi Markc. Thank you for your reply. I’ve waited months, never lost the hope you may reply to the technical questions I had. Specially since EVERY post I made in JS stack exchange was REJECTED by any of the (kids) admins there. I had no where else to look for technical answers.

I use WizzWorks and HiCorp viewer to test my .m3g.
It would be of great help if you could answer some technical questions about Sprite3D in HiCorp. Because right now, the viewer “freezes” if the camera goes beyond the world position location of the Sprite3D. I don’t know if that’s a “known” behavior? My goal is to document “this is a known behavior” so everyone else can understand how the viewer works, what to expect and what not.

Regarding on the .m3g development: I’ll thread a little context:
In 2022 at the beginning of GPT era, I wanted to know if AI was already “smart enough” to code. So this .m3g API recovery was a side project in between months. I was filtering valid data through Claude. At the end of 2024, I decided to go full coding with Claude. However all the Sony Ericsson internet forums or Nokia forums were dead (I know all the technical and infrastructural reasons why), so I was never really hopeful I could pull this on my own. 6 Months go by, practically walking blind with one brazilian link about the API; also yeah, I downloaded the .m3g official documentation from the JP source links, checked on Oracle; I literally bought a 2004 Windows XP Laptop and a Sony Ericsson W550 phone + cables to go full dev (with real hardware) and Software on this adventure. From November 2025 - January 2026, I got the opportunity to code the remaining 60% modern porting of the API into Blender 3.6 thanks to Claus Höfele and his code book “Mobile 3D Graphics - Learning 3D graphics.” This was eye-opening to me as I finally got a systematic approach to the format’s header, compiler, (deferred) immediate render mode and the “blending modes” (aka: Compositing nodes).

I’m a 3D animator with 20+ years exp, and as I was reading the book and doing the code it was very insightful how modern things we take for granted were slowly evolving from the .m3g approach to scenes’ hierarchy nodes and processing methods for faster shading / graphics.

About the 3DsMax .m3g exporter: I found an old presentation in scribd.com from someone in Malaysia. They did an outstanding slider presentation, this is where I learnt about the Blender’s 2.35 original .m3g code exporter, later to be ported to 2.49b by Gerhard Völkl. There was a 2004 Blender conference presentation where the expositor mentions “they took a solid year” to use the .m3g exporter in real world projects as a mobile game company. This is the only “surviving” crucial expo about how Blender managed to work with .m3g. The Scribd slider show from the Malaysian user, went as far as revealing the tagging methodology in the original Blender exporter. Something I wasn’t aware until I got Clause’ book. There’s a brief paragraph about it, but enough to spark what I believe is one of the best features of the coding port to Blender 3.6.

(Continuing my original reply / breaking this into part 2):
In January 24 2026, I was hitting a wall with the 95% completion of the entire .m3g 1.1 api (specially with Sprite3D and the LOD system), this is when I decided to reach in this forum, as the Malaysian scribd .ppt pointed “some of the Khronos group” people participated in that conference. I had to take a long shot. I’m glad you have replied @markc .

In February 2026, I finally finished porting the .m3g API into Blender 3.6, with the help and feedback of 2 other .m3g coders (original game developers). One from FB (Russia) and one from Discord (Brazil). Their feedback was super brief, probably a paragraph or so about “compositing mode” (which are just the modern equivalent of Blender’s blending modes), and how the .m3g “custom properties” could send parameters/values from the model to the .java code. This was astonishing to me. With the coding book examples from Claus, and these other programmers, I was finally to map out 22 years of silence about the .m3g format and complete a fully working 2026 exporter in Blender 3.6.

I am aware the format is in “open source”. And I want to give every original java game coder the opportunity to access it with better visuals from Blender 3.6 to create new games.

2 Things worth mentioning about this digital archeology restoration, @markc :
We’re not limited to hardware anymore, and the format loads faster than anything out there in 3D at the moment.
There is a J2ME emulator running on Android phones with the entire potential of modern hardware. Sound, videogame length or longer gameplay is now possible, and I’m working some demos to showcase.

Please let me know if I can tag you/email you about these things, since there’s no one else left from the original team that remember more details. (yes, I went as far as writing to the company in JP -the one making car UI dashboards) to see if I could get a copy or archived file of the “mascot capsule 3D” software. I’ve seen the compiled api in github, but it’s something I don’t understand, as there is no documentation.

Regarding the mtra, btra, exporters from fbx to those formats or the evolution of .h3t to converting to those formats, yes, I’m aware. I went as far as checking the entire Japanese userbase and got the .m3g exporter for metasequoia. Unfortunatelly it needs a paid Metasequoia version to make it work. So it was back to 3ds max old forums, specially mobilefish website that got the spark going when I hit another dead wall in the .m3d development when I was testing FOG and other things.

During this process, I learned about the Sony Ericsson SDK and how midlets work and sync from the laptop to the phone, which, by our 2026 standard, is pretty much “plug and play”. But with real hardware you need to deal with additional layers of troubleshooting hardware and software.

As for the github where I’m putting it all together, you can see it here>>
About your long replies: Don’t worry, be as detailed as you can. I appreciate the brief walkthrough of the evolution of the .m3g format and the companies around it.

I’ll keep checking this thread regularly as I make progress or in case you reply.
Thanks!

Pierre.

Thanks for your reply.
When I asked about this, I thought it was an innate API call for “LODs”.
But later, I discovered in some games and the insight of the Russian java videogame developer, that it’s a “visibility” trick they use in Java, with raycast sphere volumes.

If you can break down the system, or process, that would be really helpful.
Thanks!

I use WizzWorks and HiCorp viewer to test my .m3g.

I’ve no idea what WizzWorks is. How did you get the HiCorp viewer?

I literally bought a 2004 Windows XP Laptop and a Sony Ericsson W550 phone + cables to go full dev (with real hardware) and Software on this adventure.

If you somehow got the MascotCapsule V4 SDK, the viewer in that, V4 Examiner, will run on Windows 11, even Windows 11 ARM. Amazing! It will play v3 files as well as v4.

Sony Ericsson licensed HI’s M3G implementation so that is what will be in the phone. As I mentioned the V4 engine supported both M3G and the MascotCapsule V3 API. I can’t recall whether the version in the SE phones included V3.

My memory about .h3t and .h3g was wrong. I found some minimal documentation. .h3t is a textual version of a .m3g file exported by HI’s 3DSMax plug-in, and there was a tool to convert them to .m3g. I don’t recall what .h3g is but it seems related to .h3t.

Do you have the M3G 1.1 specification and the API Javadoc? I provided a link in my reply yesterday. Those should answer most of your M3G questions. I am happy to try to answer any remaining.

There is a J2ME emulator running on Android phones with the entire potential of modern hardware.

Actually MascotCapsule v4 could render via OpenGL ES 1.1, or its own software renderer, and, back in 2003 or 2004 we received the first phone that included OpenGL ES 1.1 hardware, a flip phone made by Sharp.

1 Like

HiCorp viewer - someone mentioned in an article on the internetarchive.org - I got to download it from one of those old websites that offer old files (like filehippo), but I don’t remember where exactly.

WizzWorks was also available in another old-software website download. The BR coder told me he used that to test some of his early .m3g. But it is a limited testing software, it cannot represent FOG or Sprite3D and some other API calls. (no animation tracks, though it shows the data, but cannot animate in viewport). No vertex colors. I need to make the full list of features between these two when I update the github. :sweat_smile:

Markc says: If you somehow got the MascotCapsule V4 SDK
-I reply: I didn’t even know there was an SDK. I only read it on the Sony Ericsson page from the WayBackMachine cache, but no real links. But yes, I run the HiCorp viewer on Win10 without issues.

Markc says: Sony Ericsson licensed HI’s M3G v4 in all SE phones.
-I reply: AWESOME! I can test the MascotDemos in my SE directly then! (I got the files, I just never really tried testing them in the hardware, only on the SE J2ME emulator for W550i).

Markc clarifies about .h3t and .h3g
-I reply: I never heard or read about .h3g, but the .h3t converter came along in the CD that came with Claus’ book. You can imagine my surprise to actually run, install and convert my own .m3gs after 22+ years. That’s when I felt the implemented API was solid to release.

Markc asks about M3G 1.1 specification and the API Javadoc.
-I reply: I read them on the Japanese website commission for .m3g, yes. (I read them recently in December 2025). I know how Sprite3D should work inside the midlet, what I didn’t know (still don’t) is if the HiCorp viewer has a limitation for the camera, when navigating and passing beyond where the sprite3d is in the world (the viewer freezes /like it gets stuck).

Markc says: Actually MascotCapsule v4 could render via OpenGL ES 1.1, or its own software renderer [..]
-I reply: WOW! full openGL ES 1.1?! . Also what do you mean “its own software renderer”.
You see: In my mind: Mascot Capsule is a headless API, which installs on an IDE and it’s just “code”. I don’t really understand if it’s got a GUI in of itself or if it runs with its own .dlls or installers, depending on the graphic hardware of the PC/Laptop.

I don’t know what this HICorp viewer is you keep referring to so I can’t answer. I am not aware of any such issues in the software I remember we developed but it was a long time ago.

MascotCapsule, and any other M3G implementation, is a game engine, a library of code with, typically, a C API that was typically linked into a device’s Java virtual machine and connected to the M3G Java API via JNI. It implements the M3G API as documented in the specification. An M3G implementation can be thought of as having 2 parts: the implementation of the high-level object and scene graph API and the implementation of the low-level triangle rendering API that renders the meshes to the screen. We designed M3G so that the OpenGL ES 1 API could be used for the second part. If a device had OpenGL ES 1 hardware HI would license a version of MascotCapsule that used OpenGL ES and did not include the software renderer. For devices without hardware, a software renderer is required. This could be a software implementation of OpenGL ES 1. However at HI we decided to use a slightly different API to our software renderer tuned directly for M3G. Since it was never exposed to game developers it did not matter that it was not exactly OpenGL ES 1.

The devices in those days were not fast enough to support programming a game in Java that directly used a low-level API like OpenGL ES and carriers, who maintained strict control of what went on the devices, would generally not allow native apps, only Java.

All of this has nothing to do with IDEs. If someone wanted to provide an IDE to develop MIDlets, it would sit above the JVM and MascotCapsule.

1 Like

Thank you, Markc, that clarified my question.