I am not having a heart attack over the rumors surrounding Java3D. Hopefully everyon architects their gaming projects which some abstraction over the rendering technology to protect them from these types of hiccups. Writing a renderer on top of opengl has been done 100's if not 1000's of times by programmers around the world. Just check out flipcode to see tons of screenshots from amateur programmers that have written "rendering engines" on top of opengl. And it is always the same stuff... organize your high level objects, break them down into textures and geometry, sort them in material order, etc and send them to the card. Then improve it to "cache" textures and geometry on the card. Then improve the pipeline further to include fov culling, then improve to add visibility culling. The again add dynamic lighting and shadows using a dymanic beam tree, etc.

Point is that writing a rendering engine on top of opengl has turned into a bit of a "timeconsuming, technically interesting but not challenging" exercise. Same thing for writing a text editor, database, compiler or any number of "turn-key" technologies. Point is, that it takes a long time and adds very little value. Now I know it has not been done much for Java, but that will come shortly I am sure.

I do think that whatever code is built in the next two years by us, Sun and other game programmers, it should be open source. While losing Java3d as a technology is not devestating for us, it will cost us 6-8 months of work to remove dependancy on Java3d and replace it with an Java/OpenGL renderer (unless someone pipes up now and say they have one).

I do seem to be reading some disagreements on the Java3d list and this site regarding what people "want" for their gaming projects. I am suprised at the number of people who think they just want opengl bindings and that a scenegraph architecture is too high an abstraction. Did you know that many commercial engines (sitting on top of Opengl) use a scene graph? Netfinity is one of the best engines out there and uses a scenegraph architecture. People want their games to have access to latest whiz bang graphics cards capabilities, but I wonder if they know what it will take to effectivly use these in a full game project.

Personally I think you need both a high level API like Java3d, coupled with the ability to access the rendering pipleline. Thats why we are going to stick with the Java3d scenegraph, even if we write our own rendering engine on top of JOGL, etc. If you are not organizing your scene in a graph, then you are organizing it in code (draw background, draw water, draw ground, draw objects, etc). This makes it "simple". But the more complex your scene, the more you have to have an "object view" of your world. You can't really escape the object view, if only to allow for rough culling at some point. You don't really want to be culling at the triangle level only do you? You don't really want to calculate the same transformation 1000's of times per frame which once with a hierarchy would have done just as well?

But if you want to do shadows or reflections or any optimizations, you need to at some point translate from your "object view" to your "rendering view". This is where the transforms, materials, textures and geometry become the building blocks of the rendering pipeline. This is where you start thinking more in terms of triangles and less in terms of objects. Here is where you can do all sorts of fancy triangle work incuding lightmapping, shadows, radiosity, environment mapping, vertex shading, etc.

Personally I think that Java3d was headed in the right direction with 1.4. I think it is taking a step backward to jump closer to the hardware and concentrate on JOGL and I don't see why these two things are being considered by Sun to be mutually exclusive. I think a lot of people have been screaming for game libraries and high performance API's without realizing they are still going to have to write some sort of high level library if they want to build any sort of complex game. You can't concentrate on the lowest level rendering and ignore the need for a high level organization of your scene. Thats why a lot of those fancy screenshots on gamedev and flipcode never turn into anything more than a screenshot.

Do we want to write games or do we want to write rendering engines? Writing a rendering engine is a lot of fun, but it is not game writing. 99 percent of magicosm's 250,000+ lines of code is *not* about rendering, it is about dealing with objects representing a virtual world. It takes 50 lines of code to "render" a sun, and about 1000 to calculate where the earth is relative to the sun, to calculate the changes in light and the reflections on the clouds and the atmosphere.

Perhaps many aspiring game programers can only think in terms of building a quake renderer, with a narrowly defined world using a BSP driven renderer, where they are seeking to emulate/copy Carmack and are more concerned on being able to render each triangle with 5 overpasses as fast as possible. That's fine, but is that game building or more of a fun technical rendering exersize?

Anyway, as Brad, Shawn and others will tell you, if you concentrate on the rendering aspects of your game building then you will write crappy games. You can't close a blind eye of course, but it just is not as important in the long run.

To put it another way... ;-)Do you want to write a game, or make game technology?

Many final games do involve writing SOME new tech, or more likely new intergration of existing tech.

If you want to make game tech, then do it. You don't need a publisher for that. We wrote loaders, collision systems, particles, etc, and gave most of it away.

I think the problem is the people who are working on the problem are working on it and don't general stop to tell what and how they did what they did. The majority of people who are complaining about not having enough (free) underling tech (or the wrong tech) and (free) tools have the time to complain because they are not knee deep in developing a game. On the PS2, you got squat the first two years. Eventually engines appeared there (i.e. RenderWare) and you are welcome pick one up for a cool $50 Gs.On the PC, you do have DirectX. Now you also have JOGL/JOAL/JInput and JLWGL(nice job BTW guys, I never said it in the forums :-)) Beyond that, in many ways you are on your own just like every other game developer using any other technology.

Looking over this post it sounds a little harsh and I don't mean it so! I just mean to say...

Game development is difficult in any space, with any technology because players have incredibly high expectations and your job is to make them HAPPY!? If you knew how much work it was going to take, you would never start. ;-)

I do seem to be reading some disagreements on the Java3d list and this site regarding what people "want" for their gaming projects.

And there you've hit upon the reason why almost every man and his dog needs to re-invent some sort of scenegraph rendering method. So many compeating technologies (eg. shadow volumes vs. shadow maps), so many different conflicting techniques (eg. portals vs. precalculated vis), so many different needs (eg. low system requirements vs. whizz-bang-effect #42).

So in other words, its going to be a long time before we see systems that are capable enough to be used for pretty much every game genre and style.

What i'd like to see is a set of generic helper utils ontop of (say) Jogl for removing the grunt work. Loading textures, geometry intersection, math routines, etc. Then people would have many smaller low-level building blocks to accelerate the building of their own personalised engine. See it as a compromise between a full blown scenegraph and starting from scratch every time.

if you get my drift. Nearly every single thing Sun has done to date with Java has been analogous to the Sirius Cybernetics Drinks Vending Machines from HHG2G - producing a liquid that is almost entirely but not quite unlike tea (and there's a deep, deep pun in there somewhere). There's only so many times you can get something almost completely wrong before people start to ridicule.

The only thing Sun can do for me, now, is start deleting stuff, because I have no faith whatsoever in anything apart from the basic idea.

+5 insightful, as the saying goes - I have been saying something very similar to what David is saying here for a while and I completely agree.

As a rank amateur who enjoys games programming but will never make a career out of it, I genuinely don't have time to write everything from the bottom up and I would rather be working on building an interesting game than triple-bump-mapping everything in my multipass render-cache-light-buffer vertex shaders. But even if I was, how many people do you know of who have written a brilliant engine, dropped a few models in it and ended up having their game noticed? Whereas people who have written really good games based on older technology ( Notably some of the half-life mods that have seen independant releases ) have ended up writing games for a job and fair play to them. Technical innovation is a world less important than good game design.

It seems to me that ultimately what it would be nice to do is to create an Open-Source, broadly Java3D compatible, scenegraph over Jogl or LWJGL or both. Something that can do at least most of the basic stuff that Java3D does but lets users reach down directly to the hardware interface if they need to. If I was technically adept enough, I would write it myself, but I don't believe that I am, never mind the complexities of starting a new java.net project

In the meantime it would be kind of nice to get a formal statement from Sun on what they are planning to do with Java3D. I mean the people on the ground have said it's going quiet and I have not reason to doubt them but it would just be polite if the company were to tell us something themselves.

In the meantime it would be kind of nice to get a formal statement from Sun on what they are planning to do with Java3D.

Judging from recent history, Sun will probably keep silent about it for 5 months during which David almost manages to implement all of Java3D's functionality in a public LGPL project, then Sun releases Java3D as open source.

Anyway, I really hope Chris and Doug can provide some kind of roadmap when they get back from their vacations, and you don't get very long vacations in the US so I don't see any reason to rush into any project that the Sun folks may already have lying around.

In the meantime it would be kind of nice to get a formal statement from Sun on what they are planning to do with Java3D. I mean the people on the ground have said it's going quiet and I have not reason to doubt them but it would just be polite if the company were to tell us something themselves.

As they old saying goes, "If we did, we'd have to kill you."

Seriously, theres not a lot many of us can say about this if you want us to stay at Sun.

I'll give you a general tip about Sun though. We are very BAD at keeping secrets. As a rule, if you aren't getting a clear signal in the outside world its usually because there isn't a clear signal inside yet.

JK

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

I had students use it here for projects and it was quite "full-featured" sim-oriented API, a perfect Iris Performer clone.

It is fairly plugable, so you could replace parts of it as you see fit, but you have to really know it well to do that.

scene graph -seperate from- render engine -seperate from- collision system -seperate from- animation engine, that's the model we are moving on.Actually the scene graph (or more likely the geometry arrays and vecmath) would be the one common API all others would be layered.

Also this allows you to have something working quicker with less dependancies.

Seriously, theres not a lot many of us can say about this if you want us to stay at Sun.

That's kind of why it would be nice to get a statement from Sun the entity (no, not the yellow one that lives in the sky, the other one that lives in workstations everywhere...) rather than hints from people who aren't really supposed to be talking to us at all, but do it anyway because they care about us developers. Which is in itself a rare trait with the consequence that we would rather they said less and kept their jobs...

It has been such a period of change that it is easy to forget that it is only a couple of weeks since JavaOne and that really, that is a very short time. I'm sure things will pan out, one way or another, and we will all sort it out eventually.

And it is always the same stuff... organize your high level objects, break them down into textures and geometry, sort them in material order, etc...Now I know it has not been done much for Java, but that will come shortly I am sure.

I've written at least 5 3D engines in java, probably more. This ranges from "very small compiled-size for game demos" through "academic research" to "proving that Java 1.1.x really can do a good 3D engine on a low-end Pentium-2".

I've got a project I occasionally add to (but has never been shown openly before) where I experiment with modular 3D-engine code. It's great for me; I use it to test a new 3D engine feature or algorithm which I'm about to use in some other project.

Ultimately, I have to agree with whoever said that there's too many arbitrary decisions to make over technology/algorithms, so that you cannot easily build a single API to cover "3D engines". However, Object Orientation is actually rather good at providing partial solutions to complex problems, and my most recent work suggests that a scenegraph API that was deliberately kept very generic at the edges, and used lots of interfaces, would work on almost any 3D engine.

It's a bit like the fact that a class-hierarchy for 3D-vectors, designed to be highly generic, could be used by every 3D engine. It's obviously true, and obviously useful.

Then again, architecting ultra-generic libraries is my specialism, so perhaps it isn't so obvious to everyone else .

Quote

I do think that whatever code is built in the next two years by us, Sun and other game programmers, it should be open source.

Possibly a bad idea. I occasionally have great trouble these days finding an OS project with a sensible OS license. But if it were the right form of OS license, I'd be happy to help (anything which prevents using the code inside a commercial application is totally unacceptable; even LGPL prevents this).

(anything which prevents using the code inside a commercial application is totally unacceptable; even LGPL prevents this).

LGPL allows you to use the code in commercial app. This just means that if you make modifications to given library, you need to open source them. But you can easily extends the classes, link against them etc with proprietary code and not be forced to do anything.

LGPL allows you to use the code in commercial app. This just means that if you make modifications to given library, you need to open source them. But you can easily extends the classes, link against them etc with proprietary code and not be forced to do anything.

Unfortunately, no. It would be nice if it were true. When you're dealing with contracts, you have to be careful to read them closely - judgements often decide that "precise wording" of the contract overrides "the probable intent".

This kind of confusion is one reason why many cautious people refuse to use OS stuff - it's too damn dangerous. The licenses are appallingly badly written (I've done a lot of work on analysing legal contracts, and I can assure you that the GPL etc could be made considerably clearer)

Quote (from LGPL, current version):" However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."

Hence, the moment you create the executable, your software has just been swallowed by the LGPL, even though the preamble to the license suggests it won't. Now, it depends on how you interpret various ambiguous statements within the rest of the LGPL, but one interpretation is that you have just lost the right to control your own software, because it has become a "derivative work" of the original (this is using the exact words from the license). I could certainly find a lawyer who'd be willing to argue the case (even if the chances of success were not high).

There are other OS licenses which don't have this confusion. One of the aims of free software is to give the user more choice - well, I exercise that choice and dump the software whenever this particular clause is a potential problem.

[...]Quote (from LGPL, current version):" However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."

Hence, the moment you create the executable, your software has just been swallowed by the LGPL, even though the preamble to the license suggests it won't. [...]

The part you'vs quoted there just means that you can dynamically link it (like a dll or a jar) without having to worry. Static linking (source+dll=single exe) on the other hand will making you programm OS by itself.

A single jar won't make a programm OS by itself, since it's just like zipping.

DISCLAIMER: I am not a lawyer, and I am not qualified to give legal advice.

I agree with oNyx.

You quoted paragraph two of section five. Here's paragraph one and two:

Quote

5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

It seems crystal clear to me that paragraph 1 is referring to dynamic linking, such as linking to a jar file, and paragraph 2 is referring to static linking.

And, no offence, but saying you could find a lawyer who'd argue the case isn't itself a strong argument against the LGPL. In the States especially you'd be able to find a lawyer to argue pretty much anything.

DISCLAIMER: I am not a lawyer, and I am not qualified to give legal advice.

I'm sorry; I wasn't trying to start a debate about the enforceability or whatever of the LGPL. I've unintentionally dragged this topic completely OT. I didn't intend for my post to sound as much like flame-bait as it did; I was in a bit of a rush, and wasn't careful what I wrote

Can we leave it at "lots of people don't use OS who would like to, exept that the licenses are too scary"?. If you're EA, and have a battalion of lawyers, no problem. If you're a development studio, you may or may not be prepared to risk working with a license that is less than 100% clear.

When I made my post, I was thinking of the fact that there are currently, IIRC, something like 20 or 30 "Open Source" licenses in general use, and picking the right one should be done carefully.

When I made my post, I was thinking of the fact that there are currently, IIRC, something like 20 or 30 "Open Source" licenses in general use, and picking the right one should be done carefully.

Agreed.

Personally, the LGPL isn't even my favourite license, mainly due to its length and complexity. I prefer an Apache style license. Straightforward and too the point; less than a tenth the length of the LGPL.

Can we leave it at "lots of people don't use OS who would like to, exept that the licenses are too scary"?. If you're EA, and have a battalion of lawyers, no problem. If you're a development studio, you may or may not be prepared to risk working with a license that is less than 100% clear.

Yes indeed........And if you're an independent developer you don't have theluxury of a battalion of lawyers to interpret the license for you...Actually, even a single lawyer would be extravagant I guess

Well David, I have a question for you. Are you planning on leading the charge, or are you just here to bitch? It seems to me that what everyone would really like is some kind of high level scenegraph API similar to Java3D that could sit on top of JOGL, LWJGL, or better yet, both. Further more, we'd like it to be layered such that a developer could decide how much or little of it to be used for his own project.

If there's one thing I've learned from LWJGL, it's that sitting on your hands waiting for Sun to implement features you want gets you one thing: warm hands. How long was LWJGL around before Sun finally got around to making JOGL? And now that they have, which is the better API? (Don't answer that last one, I don't want another thread devoted to that!)

My point is, if you just suck it up and rework your engine to run on top of JOGL or LWJGL, you've spent a couple months to make your game work again, and done exactly what you're arguing against. What happens when you've moved on to your next game? Are you not stuck writing yet another scene graph?

What we need is someone to lead the charge and start up an opensource project to make this nice, generic, universal scene graph API for all of us to use. Then the rest of us need to get off our laurels and help it grow. And if all this happens, we can finally sit back and enjoy the fruits of our labor, and never have to write another scene graph again.

I know, ultimately, that this post is horribly hypocritical. Who am I to ask others to lead a charge I'm not willing to lead myself? But maybe it's not quite that bad. I'm certainly willing to jump in and do my part if someone starts such a project. Perhaps first I can test the waters and see how many "hell yeahs" I can get.

Hmm, it seems perhaps I should've read all the replies to David's post before writing my own. It seems I may be simply reiterating the same sentiment that this thread is already rife with. Everyone's willing to contribute, but nobody wants to be in charge. Sounds like a typical open source endeavor.

Lucky you !!! My experience with open source projects was that everybody wanted to be in charge and no people actually contributed any useful code

Yes, what I'm referring to are all the projects that never even get started. The ones where everyone is willing to put in a little time implementing some small details, but nobody wants to do the high level design and administration. If somebody were to set up some space in sourceforge and check in a nice fat design spec, I bet the code would start to fill in pretty quick.

Well, at least I wouldn't mind taking a stab at some bits here and there.

Well, I guess I can say that my group of developers, Full Sail fellows as well as a couple outside, are in the process of writing a Java3D compatible scene graph targeted for gaming and that will be open source. We are planning to use it for examples of how to make one and why and for content import in a Java game programming book we are working on for Charles River Media that is due out at next GDC.

Unfortunately, we have expertise to set up and maintain a real public modifible and accessible repository, a' la JLWGL.

Our path is non-renderer specific, that is independant of the render engine, so our example JOGL renderer could be replaced or ported to JLWGL as well, but our main goal is to be able to use exist J3D loaders with little or no changes to them - which may ultimately involve conversion utils for loaders that won't link to our classes...

When we have a 0.1 release we will examine our options again.

In any case, we will be happy to release what we can and perhaps even intergrate into another project should another public project pop up in the meantime.

If you are working on similar stuff or are interested, I suppose we should all speak up so we can at least exchange ideas, and perhaps even share in actually forming a standard spec.

Glad to hear from you. I was hoping to provoke responses like yours. I was also hoping Alban from OpenMind would chime in as well, but nothing so far. David's posted something over at puppygames.net intimating that he's working on something that will ultimately be freely distributable, so I would have also liked to hear from him.

It sounds like everyone who really knows what to do is off doing it by themselves. Unfortunately this leaves people like me unable to pitch in until after the various libs are done, at which point it's probably moot anyway.

[...] our main goal is to be able to use exist J3D loaders with little or no changes to them - which may ultimately involve conversion utils for loaders that won't link to our classes...[...]

Do you have any specific loaders in mind ?

Compatibility with existing java3d loader will come at great price, if you want to be really compatible.

If we are talking about geometry+material-only loaders, then it is not worth it. Writing such loader takes few days and it is a lot easier to recreate it for any particular scenegraph, then to go in hoops to make your SG compatible with java3d line-for-line.

On the other hand, if we are talking about a bit less trivial loaders, I don't think you have any chances of being compatible without emulating entire java3d. For example, for my NWN loader, you would have to emulate behavior sheduling (for animations and emitters), entire viewplatform/view/canvas/world hierarchy (for particles), and most of texture handling/modes. Plus scenegraph cloning and io, at least proxies. A lot of work. A lot more that it would take me to rewrite this loader on top of any reasonable scenegraph, especially if it would be more open than java3d.

Please rethink this route. Make a list of all loaders out there which you really want to use. Check which of them will never work without full java3d support (xj3d is one of them I suppose and only one really worth the effort, I'm afraid). And then look again on this shorter list and ask if your effort in staying java3d compatible is going to pay off.

Unless you are aiming at creating full java3d clone at some point. In such case, in addition to supporting loaders, you would support all applications out there - and this is certainly something which would be A Good Thing(tm). But again, do you really want to do it ?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org