Mobile 3D Graphics API

[swpalmer]

Read the spec that started this thread.. it is very much like Java3D... so learning Java3D was likely a good thing.

It will be interesting to see exactly how this mobile 3d API and Java3D fit together.  Will one be a subset of the other???

I'm just hoping that J2SE isn't abandoned as a gaming platform.  I mean, if we want to target PC's for gaming will be out of luck, because Sun's effort will be entirely in the J2ME space?

I think it is possible to run J2ME stuff on a PC.. but I haven't figured out

[Mithrandir]

There are a lot of similarities between JSR184  and Java3D, but they are similarities, and nothing more. It's like the similarities between the OpenSceneGraph/OpenSG and Java3D (not to mention X3D/VRML). They are scenegraph-based APIs that allow both retained and immediate mode rendering.  Structurally, they all look similar. There's only so many ways that you can describe transformations, shapes, appearances etc. They're Well Known(TM) terms in scenegraph-world.

Knowing J3D isn't exactly a definite requirement or help in learning JSR184. If you have any experience with any reasonably modern scenegraph system, you should be right to go. There are some minor differences (the scene tree structure rather than scene graph I mentioned earlier). If you understand the basic concepts, picking up JSR184 isn't that hard. You could consider it as a Java3D v2  - learning from all the things that didn't go right in J3D and applying those lessons to the new API - but also with a large focus on the mobile market.

which it would have through the Xj3D-loader if apps like Maya started to support X3D more completely

There is some of that already happening. However, in our experience, it seems that the majority of developers are using MAX, not Maya. The Web3D Consortium's Source Code Taskgroup is running an open source project for the MAX exporter. It's doing reasonably well already and supports X3D (not XML though, IIRC).  The group is looking to start up a Maya exporter too, but they need someone to take on the responsibility of starting it up and getting running with the code. The Maya SDK has a slightly older exporter for X3D already that could be used as the basis for the project.

Said that, java3d in current form has a lot of deficiencies - especially if you want to use it for gaming. But for me, correct sentence is 'java3d is doing this and this wrong', not 'nobody needs java3d, everybody can write their own, better scenegraph'.

I'd agree there. Audio support is shocking, and the texture system is really bad.  One of the things that has pissed me off really badly right from the start is the complete lack of integration with any of the other Java Media APIs.  That has been a huge drawback for doing stuff like compositing and layered applications - things that should have been trivially easy, but are close to impossible to do with the setup today.

[abies]

It is a subset as far as functionality is concerned (with addition of skeleton-based meshes). I think it is absolutely acceptable for constrained devices, but porting it to PC would be a crime against humanity - it is so... constrained... if you compare the capabilities against current hardware.

Unless I'll have to program cell phone quake, I'm not going to touch this mobile API even with 10 foot pole. Java3d was already very late with support for even rudimentary options like stencil buffer - another API, which starts from place behind one that java3d were few years ago... plus idea of minimal-supported-set aiming for cell phones, instead of current PC hardware - it is going to make it next to useless for non-ME development.

Games published by our own members! Check 'em out!

[princec]

Like I say - we'll have OpenGL ES in LWJGL before you can blink. We'll always be on the bleeding edge, and always be what you need to write games in Java.

Cas

[kevglass]

The bleeding edge <of graphics>.

And that you need the bleeding edge of graphics to write games is only your opinion..

There are so many more elements that make up a game.. we could go back to the old arguments, do graphics really make a game?

Kev

[Breakfast]

From what I have heard of the thoughts about where J3D could go, a lot of the ideas were to make it very extensible so that people could drop in new features as graphics cards made them available, bringing it closer to the cutting edge if necessary.

I suppose all will be revealed at the weekend anyways. I suspect for the limited 3D stuff I do it would be feasible for me to switch over to lwjgl if I could bring myself to learn another api and another way of working, so I'll concentrate on making models and textures for a while and deal with stuff when it happens.

It seems to me that the need to be at the cutting edge is another question entirely - if you look at the Doom 3 screenshots the amount of texture and model detail they need will basically mean that you need teams of artists and animators along the lines of the Pixar type joint. I don't think you can really be at the cutting edge of 3D world creation and still be an amateur doing it for fun...

[Mithrandir]

Like I say - we'll have OpenGL ES in LWJGL before you can blink

Will you have true ES implementation, or just something that layers over existing OGL calls? As someone that is fairly deeply involved in the spec process for OGLES, I can guarantee you that it is not just a simple binding straight to OGL calls. There's a lot of extra stuff, and also a lot of restrictions on what can and cannot be permitted to be used by the author. For example, a lot of the OGL extension are not going to be permitted, so when someone does a query for the extensions available, you can't just return the string provided by OGL.  The EGL bindings are also quite a different story too and they are a required part of the spec now.