I posted this to the Javagaming site, but thought I should post this here also.
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 unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
