Mobile 3D Graphics API

Engines, Libraries and Tools Java 3D
#21

Then, j3d.org might be a good place to start a lobby or something more appropriate, if necessary.

I’d be willing to do that. Recently I haven’t been paying as much attention to the site as I should be. One of the thoughts I’ve been musing over is turning j3d.org into an Anything Relating to Java and 3D Graphics site. That would require a considerable amount of effort, so having some more volunteers to help would be really useful. I also have some qualms in doing so because the site is hosted on my personal machine, which happens to also host vlc.com.au, xj3d.org and the company website yumetech.com. Maybe CVS commit priveleges just to update the site and that’s it…

Other things to consider about the process - Java3D is a “formal” Java extension API. It uses the javax. package name space. Just turning it into an arbitrary open source package would be extremely difficult from a process perspective. Sure we could take the 1.3 code and do bug fixes, but extending it with new capabilities and keeping it labelled “Java3D” would be difficult to say the least. Sun’s lawyers aren’t known for being friendly in this regard.

My company (Yumetech) has had some initial discussions with Michael Schulmann, the manager in charge of the J3D and other Java media stuff about where to go from here. They are open to the possibility of someone purchasing the code from them to then make further improvements, and specifically with the ability to do a proper OSS license (ie not the bastardised SCSL-style license). Nothing concrete yet, but keep in mind it may be possible to do something like a Blender project, where a large number of people get together to contribute funds to purchase the codebase from Sun and then turn it into a OSS project.

Obviously there are some licensing issues to deal with as Sun has licensed some parts of the codebase from third-parties, which would make it hard or impossible for them to release those bits (and therefore we’d need to replace them to get a functional codebase). However, Sun at least seem to be willing to part with some of their IP too. We’ve had separate discussions as part of the Web3D Consortium process about RF licensing some of their patents with geometry compression and they seem to be quite willing to discuss it.

So in general, it looks like a mixed bag of prospects for the future. I hold close to zero hope that any further development will happen with Java3D beyond occasional bug fix releases of the 1.3.x line. Kelvin and Mark Hood are still floating around the list and registering bug IDs, which is a marginally positive sign.

#22

I’m thinking about something more in line of lesstif and MesaGl. Everybody knows what they are for, they work even better than originals, but do not use the ‘real’ name.

[quote] We’ve had separate discussions as part of the Web3D Consortium process about RF licensing some of their patents with geometry compression and they seem to be quite willing to discuss it.
[/quote]
Has ANYBODY used java3d compressed geometry for anything in real application ? AFAIK, it is a failed experiment, dead end which is not maintained since a long time, just nobody was brave enough to deprecate it in java3d. Great idea, which has not ignited hardware support and thus became not-really-useful.
I would suggest to not worry about graphic compression.

Real question is if Sun wants java3d to continue. I don’t know how big money is involved in this mobile 3d API - is it only a non-profit effort to get more java exposure, of Sun is actually thinking about licensing mobile api to various vendors for big bucks. In latter case, it is highly unlikely they will want to give java3d code away.

As for the Blender option - I doubt if there is enough java3d developers out there wanting to spare enough money, given the fact that cost will be probably quite high (if Apple has not managed to license it so far).

In ideal world, Sun could just pick some company, which would pick up java3d codebase, open it up and earn money from support, while managing ‘official’ releases - and in case of trouble, anybody could just fix their favorite bug. In fact, anybody could do their own forks, they just could not name it java3d. But we do not live in ideal world…

I think we should wait till the end of JavaOne, see what Sun holds inside a sleeve and later start to lobby them to do one thing or another. Anything is better than situation throughout last year, when everybody was thinking 1.4 is in the making, counted stages of JSR and it turned out that it will not be there after all…

#23

[quote] Has ANYBODY used java3d compressed geometry for anything in real application ?
[/quote]
I know of a few. The Web3d Consortium is more interested in the patents aspects for the work done by Deering - in particular normal compression and a couple of others. These are generally useful in any compressed geometry format, particularly for streaming geometry, such as what X3D or MPEG-4 would use.

[quote]Sun is actually thinking about licensing mobile api to various vendors for big bucks. In latter case, it is highly unlikely they will want to give java3d code away.[/quote[

My understanding is that they are not even related. The Mobile API does something quite different. At its most simple difference - geometry is represented by a scene tree, not a scene graph. There are other major architectural differences, meaning that the mobile API couldn’t be based on the J3D codebase.

[quote] As for the Blender option - I doubt if there is enough java3d developers out there wanting to spare enough money, given the fact that cost will be probably quite high (if Apple has not managed to license it so far).
[/quote]
The Apple issue is political, not financial. Right now, we have no way of knowing exactly how much Sun would be interested in selling their code for. We’ve proposed a number of different options to them. This was late Friday so they haven’t had a chance to give us a considered response. But, the one thing I would say, is that we wouldn’t be looking at overly large sums of money. That is, Java3D is not worth anything like the 100K that was paid for Blender. I doubt we’d be able to pick it up for $5K either, so pick a number in between.

[quote] In ideal world, Sun could just pick some company, which would pick up java3d codebase, open it up and earn money from support
[/quote]
That is one model that we suggested to them. The reply was “how much would you be willing to pay for the codebase”. ie They won’t be giving it away.

[quote]I’m thinking about something more in line of lesstif and MesaGl. Everybody knows what they are for, they work even better than originals, but do not use the ‘real’ name.
[/quote]
The problem that you have there is the package naming. Where Mesa could get away with using the same API calls, a Java3D project could not. Remember that the java.* and javax.* package names are exceedingly jealously guarded by Sun. Mind you, the JBoss project so far has managed to get away with this, so it could be interesting project to try and see what happens. If people are interested in giving it a shot, j3d.org is the place to make it happen. All the facilities, except for a set of message boards, are there.

Also, have a dig around for the old jFree-D project. That was an OSS clone of J3D 1.1 a while ago. It hasn’t done much for a very long time though. IIRC it was based on GL4Java. With the forthcoming formal APIs for OpenGL then we have some standardised work to go with (or do a lot of native code wrapping using some of the ideas from LWJGL (but couldn’t base it on it because of the need for DX support)

#24

[quote](but couldn’t base it on it because of the need for DX support)
[/quote]
There is no dependency on DirectX in LWJGL. It is totally platform agnostic.

The J3D code is basically worthless. Anyone could write J3D. It doesn’t even need to exist.

Cas :slight_smile:

#25

You’ve got it the wrong way around. People want the DX support of Java3D, that LWJGL doesn’t have (for obvious reasons). For example, the GL drivers on my Radeon 9700 are really bad. Lots of nasty bugs in them, so I run the DX version of J3D.

Sure J3D needs to exist. It exists for the same reason Performer or OpenSG exist. People like either to get stuff done quickly with minimal effort or having their hand held. It does many things simply for those that want to do things quickly and easily. Some of it you can replicate fast, but the high-performance tweaks it includes are hard to replicate in a short amount of time.

If you want to turn this into a “anything highlevel sux and the only Good Programmers code in OpenGL” thread go for it. I’ll happily rip you apart. The fact is not everybody wants to spend their time pushing polygons, nor are they interested in getting to know the vagaries of a couple of dozen different driver implementations and their bugs. That’s why JSR-184 was put together and why J3D is popular.

#26

Is this a “Cas Troll” I see before me? Tut tut.

#27

With all due respect, I do NOT think that everyone could write J3D. Look at openscenegraph - it is more or less similar to java3d, is developed for quite a long time now, but I doubt if they have out-of-the-box support for head tracking or CAVE.

I agree, that for the games alone, probably any sane programmer could came up with acceptable scenegraph implementation. I doubt if many people could create efficient state sorting, but maybe for specific application it can be a bit easier then in generic case.

For me, openscenegraph is very good example. It is developed as open source for 4 years now and it started from already working version back then, a lot of people work on it AND it still lacks some functionality compared to java3d (while java3d lack another functionality from OSG of course). So yes, everybody can write their own scenegraph, as long as they have umpteen opengl developers working for 4 years on it…

One year ago when I was developing java3d application (NWN Model Viewer), other people were doing the same in opengl (in C++ and in Delphi, but it is not important here). I have looked at their code when our functionality was similar, and complexity was similar. They had to implement some things I had in java3d from start, I had to workaround java3d quirks while in opengl it was not a problem. Looking from this point, java3d might be useless - if you can do the same, with same effort in opengl, then why care. But there is ONE big difference. Anybody using java3d can take my loader, and with 2 lines of code, load fully animated model in their application. One person actually replaced md2 loader with my loader - no problems at all. Imagine how much work it would require to fit somebody’s load/render code inside your opengl application, when all the logic, rendering etc are mixed in same functions ? What with precious state sorting you have developed trying to create MyOwnScenegraph and now it is not working with other guy code, because he just throws all opengl statements directly at GPU ? Certainly, amount of work needed to integrate it will be greater than in java3d, possibly requiring quite heavy refactoring of loader/renderer code. And now, the other guy releases new version of loader and you go through all this route again…

Yes, java3d sometimes suck. I was shocked when I have seen nvidia shadows demo source - in few pages of code, they have done fully animated, realtime shadow volume, which could work with almost any models. Doing the same is not possible in java3d because lack of access to stencil buffer/etc and even if it is not a case, it would take considerably more code. But for me, benefits of having common scenegraph are very big - it really allows to reuse components, instead of ‘not-invented-here’ syndrome.

I think this goes exactly back to software reusability. For example C++ - they lack the standard library, some people use STL, some don’t, every library define their own ‘Object’ superclass - and thus, most reuse I have seen is at level of C (not C++) libraries - simple calls to specific functionality. Look at java on other side - by having common library, I’m able to take any code out there and it will integrate well with my own. I can just take any Swing component or layour manager and use it - not need to recode entire event handling manager to accomodate somebody’s else point of view.

Why people license Unreal engine ? They still end up with a lot of coding for their games. Going with your way of thinking, anybody could write their own engine. Think about java3d as Unreal for scientific community - for people, how want to get things done, plug in ready components (for example loaders in case of java3d, Karma engine in case of Unreal) and focus on part of application which is really their job.

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’.

Oops, a bit too long and probably redundant… sorry for that.

#28

Whoops, sorry, troll slipped out again. It’s back in its box now.

What I meant to say was, there is nothing in Java3D that a normal team of programmers couldn’t come up with within reasonable time. It’s not like the genius that’s behind JPEG compression, OGG, or the current design of 3D rendering APIs - it’s just a bunch of code to make life a bit easier doing certain tasks. So I stand by the adjusted statement that anyone could write the features they need from J3D within a short enough timeframe, and that this makes its intrinisic value relatively low. Useful it may be, but valuable, it is not.

Not so trolly but a bit impish maybe :wink:

Like I said, I want to pick at the model loaders for my own ends.

Cas :slight_smile:

#29

I have been involved in two projects where the timeframe has not allowed me to use OpenGL, but where Java3D has saved the day. The presentations of one of those projects and another project that I wrote in both GL4Java and Java3D (a terrain rendering engine that I quickly ported from GL4Java to Java3D’s immediate mode) were also saved by the DirectX support in Java3D when the platform’s OpenGL support did not work.

I agree that it is probably worth writing everything in OpenGL if you are working on a really tech-intensive title with a two-year timeline, but for most other games there are quicker solutions, such as Director and its Shockwave3D.

During the last year I have been in contact with a lot of people who develop and produce children’s games and games based on TV shows (such as the Swedish version of the American Gladiator show) and all of them work in Director. This leads me to think that there’s a big game market for Java3D out there, but it really requires that Java3D gets its sound and media integration worked out as well as better integration with popular 3D-modeling tools (which it would have through the Xj3D-loader if apps like Maya started to support X3D more completely).

Edit: Btw, some producers of such games talked about wanting to build and sell their games for consoles, but right now they would have to go with C++ to do that. It will be very interesting to see if JavaOne brings any news in that area for Java.

#30

Typical, I’m just starting to get the hang of something and it goes into a holding pattern. Fantastic. :frowning:

Verily am I the master of picking losers to back…

#31

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

#32

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™ 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.

[quote]which it would have through the Xj3D-loader if apps like Maya started to support X3D more completely
[/quote]
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.

[quote] 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’.
[/quote]
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.

#33

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.

#34

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 :slight_smile:

#35

The bleeding edge .

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

#36

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…

#37

[quote]Like I say - we’ll have OpenGL ES in LWJGL before you can blink
[/quote]
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.