Mobile 3D (M3G) Chapters Online

Java on Mobile Devices J2ME
#1

Dear All,

I’ve been adding chapters about the Mobile 3D API
for J2ME to my “Java Graphics and Gaming” online book at:

http://fivedots.coe.psu.ac.th/~ad/jg/

There are three chapters there at the moment, with
more to follow. The links are near the bottom of the
page.

Comments appreciated.

  • Andrew
#2

:DWOW! that’s very nice! keep us updated! ;D

#3

Hi there, I’ve just read through the chapter and its refreshing to see a clear writing style in a resource like this!

I’m really intrested to know why you took this appropach in particular though? I could understand:

a) Writing a loader for M3G for OBJ files which natively read the file and displayed and manipulated the model. This would give you flexibility without lots of maintainence issues.

b) Converting the OBJ file into some common format. This would means the M3G code to load the model could be the same for all external model formats.

Converting the model into code that displays the model seems slightly clunky… is this some J2ME related issue?

Keep up the good work with the book, its been a really interesting read so far.

Kev

#4

Dear kevglass,

I guess you’re talking about M3G chapter 1 where I generate
Java methods from the OBJ file, and then paste them
into the M3G code.

There’s two reasons why I took this approach:

  1. Having the vertices, normals, tex coords, etc. as Java code
    gives me a lot of flexibility as to how to use them. For example,
    this proved useful when I was building a skinned mesh
    example for chapter 4, where I wanted to combine
    several VertexBuffers into a single mesh.

  2. Java 3D has some great tools for extracting model
    data, and it was very simple to reuse those tools to
    build ObjView. ObjView is actually fairly simple.

I don’t think ObjView has many maintenance issues
for users. The greatest drawback is that you need
to have Java 3D installed.

I am translating the OBJ file into a common format
– Java! I wouldn’t call it clunky, perhaps “low-level” :).
But it gives the programmer a great deal of control
over how to use the data that’s extracted.

  • Andrew
#5

Sure, sorry didn’t mean any offense, I just didn’t understand. Clunky was probably a bad word, best I could come up with on short notice.

I’ve just seen in the past that the easiest way to give the programmer flexible control over the data is to expose it to him/her through a set of data classes. i.e. Vertices object (or Vertex and Vertices although I suspect this would be considered over engineered in the J2ME world).

Kev