It would seem that Java is woefully underserved in this area. JMonkeyEngine3 appears to be quite old and the result of many chefs, and supports all sorts of daft legacy rendering paths making it far more complicated than maybe it should be. Ardor was sadly abandoned. Xith and Java3D are ancient.

I'm looking at (specifically) how awesome Unity is. Plonk a camera here, drop a shader there, drop in a 3dsmax model and mask of bits of animation etc. It's great (although not exactly performant).

I was wondering what the current thinking is on 3D engines' design might be these days. Back in the day there were basically 2 main approaches: there was your generic "scene graph" based on hierarchical nodes, and there were specialised sorts of engines that did stuff like "indoor environments" and "outdoor environments" and such. I seem to recall that everyone pooh-poohed scene graphs as being the thinking of a diseased mind (not sure why, someone could maybe explain).

After all you clever sorts have explained the state of the art to me maybe we'll get on to discussion of the next bit, which involves Java.

Everyone i know uses Unity. So i dont' think anyone really thinks about it anymore. The few people not using unity seem to be using the steam one, whatever its called.

I always wondered what was wrong with scene graphs. I know they are still used a bit for CAD software.

I have found for my own stuff, opengl is so easy to just have a pretty basic ordered rendering list. Its really simple. The hard part would be adding GUI elements, and i use TWL for that. Of course i don't need to push the boundaries of what can be done. So no unlimited worlds or metatextures or anything like that.

I have no special talents. I am only passionately curious.--Albert Einstein

Roquen, would you care to elaborate on that a bit? (Ie. what is a single rigid body, why's it no good, etc)

It's the whole parent-child relationship which result in great things for tools and dumb for simulation (well in 3D).

Paperboy (child of bike, child of, say, world) holding paper (child of paperboy). Throws paper: make paper child of world (transform into world from paperboy) sails through window of cabin (child of world)..paper now child of cabin (transform into cabin space) hits table (errr...child of living room? cabin? err...nevermind...transform into table space) <snip> boulder (child of world) rolling into stilts of house which breaks causing house to tilt. Everything is house is superglued in place...no! no! wait! Traverse the entire graph of house's children and apply local space forces to run physics.

Of course people don't do that...they make everything as flat as possible, which results in very big list of "child of world" nodes and is pretty much purpose defeating. Also bounding-volumes of these nodes are not efficient and require constant updating...pita all around.

Now, limited usage...like the thing really is a rigid (like) body, then it's all good.

This is an interesting topic. While I'm not planning to make the next Crysis game, it would be nice to know what's going on under the hood of nowadays' AAA game engines.I know UDK4's source code is semi-open (open to the subscribers) but I'm rather interested in the techniques and their explanation instead of browsing through tens of thousands of lines in the source code that I'm likely won't understand anyways without the explanation.

Problem is, when it comes to 3D everything becomes so much more complex compared to 2D that you can't really be a jack of all trades anymore and that's bad news for the likes of me who feels an urge to understand everything that he deals with. Every area (physics, collision detection, lighting, level design, shaders, etc.) requires you to be an expert, or at least decent at the given topic and learning all of that takes up years.

About why there is no such engine in Java I can think of 2 things: Portability and performance.These monstrous game engines must have the ability to export games to a huge variety of devices, and that includes consoles as well. While I don't know much about developing for console I doubt that running Java on them or converting Java to something they can use would be easy. But who knows what x86 brings to the table with the new console generation. About the performance part: Java used to have bad reputation in the old times because it's "so slow compared to C++ and the rest" plus it doesn't give access to low-level features. While maybe that was true back then I think that the language and the JVM has evolved so much over time that I don't think JIT would be noticeably slower compared to compiled languages and we have JNI now that gives access to low-level features so that isn't a valid point either. However, people still likes to think that Java is a slow language and it is a common thing to troll Java developers with such statements.

Renanse abandoned Ardor3D but I still maintain a subset of this engine. However, I have to admit that it isn't a "trendy" engine with a large community. It's robust but currently not very modern even though some advanced features have been implemented (and you disagree with my "unorthodox" ideas about game programming anyway).

I'm looking at (specifically) how awesome Unity is. Plonk a camera here, drop a shader there, drop in a 3dsmax model and mask of bits of animation etc. It's great (although not exactly performant).

I was wondering what the current thinking is on 3D engines' design might be these days. Back in the day there were basically 2 main approaches: there was your generic "scene graph" based on hierarchical nodes, and there were specialised sorts of engines that did stuff like "indoor environments" and "outdoor environments" and such. I seem to recall that everyone pooh-poohed scene graphs as being the thinking of a diseased mind (not sure why, someone could maybe explain).

After all you clever sorts have explained the state of the art to me maybe we'll get on to discussion of the next bit, which involves Java.

@Riven: I intended to say I get what you're saying. I guess a perceived upside is if you're rolling from scratch a world tool and an engine then it might seem like less work to go this route...but is almost insured to be more work in reality.

IMO 3D engines written from scratch to be 3d engines without being driven by an actual game are rarely very good or useful. All the best engines UnrealEngine, idTech, Source Engine, etc all started of as code for actual games, the reusable parts and tools of which were later re-factored into the standalone engines they are today and continue to be developed by needs of actual products. The development of the above mentioned 3d java engines aren't really driven by any (or many) actual products or companies that use them.

One choice that is rarely mentioned but might be worth looking into is Clyde (seems more like a collection of useful libraries rather than a full blown engine). Its the code that powers the impressive looking Spiral Knights, contains all the useful bits like GUI, working MMO networking code, distribution, model loading, maths, etc.

Absolutely true. This part of an engine should be designed to a specific type of environments. Although it would be possible to use a hybrid approach to widen the set. It's no surprise that elder scroll isn't using idtech for instance.

Most of those listed there are tech demo's, using old engine code, abandoned, unfinished or WIP's.

More than half of them are using JMonkeyEngine 3. None are abandoned as far as I know. A few of them are WIP. Boardtastic, Fleshsnatcher and 3079 aren't unfinished. The only pure tech demo is ArdorCraft. Spaced is unfinished but already very complete, it's much more than a tech demo.

I was wondering what the current thinking is on 3D engines' design might be these days.

I'd say there are many dimensions to this and I'll answer from the perspective of what I'd build..

For outdoor environments I'd focus on octree partitioning with an emphasis on texture / geometry streaming and further tessellation for enhanced detail. For indoors / non-destructive you simply can't do better than portal/bsp/pvs to my knowledge. One could still support some level of streaming & dynamically loading BSP and other data for expansive indoors environments.

Technologically speaking especially for outdoor and streaming data parallelism is crucial. This means supporting multi-threaded GL and CPU side architecture. From a Java perspective I personally would really like to start using the Disruptor on the CPU side of things which would handle anything routing between the disk and the network to threads streaming through to GL. I am bit sad though that the Disruptor doesn't work on Android due to its reliance on sun.misc.Unsafe. If Android is a target and it should be this means sticking to OpenGL ES for the time being though that could be different a couple years from now and things may properly converge to just OpenGL across all mobile SoC/GPU vendors. This means though supporting OpenGL ES 3.0 and the GL threading API and while one is at it all the other goodness 3.0 brings.

OpenGL AZDO is important of course. There are many aspects there that support texture streaming / binding concerns. I'd figure out the limitations of MultiDrawIndirect. I really wished that the first Android Extension Pack covered AZDO extensions. I'll be able get started with them on the K1 though since it supports OpenGL 4.x too. Though I'll have to think about how the majority of the engine work must remain compatible with GLES 3.0 right now.

To have any chance at maintaining an engine now and into the future modularity must be a concern from the get go or go the way of all past Java engines. Component architectures (CA) are key in this direction IMHO. If you don't think so, well, I can't help you there much. A CA is flexible to support structuring both the engine subsystems at a high level that is compatible with data parallelism in addition to other aspects like entity systems. It also happens that it supports various rendering paths and hardware diversification concerns which is quite important for long term evolution of an engine. It is what is going to make relatively painless my efforts to support OpenGL ES 3.0 for the majority of Android devices and have a GL 4.x path compatible path with the K1. It also makes tooling possible hence the nice user experience Cas also mentions when he speaks favorably of Unity.

I'm so excited that I get to start down parts of the rabbit hole above tomorrow when my Shield Tabby arrives..

I never have gotten around to checking it out though so, I'm not sure about game play.

-----

What I think would really benefit the larger Java game dev community is as many folks as possible getting their hands some of the leading tech today (Right at this moment on Android that is the Tegra Shield Tabby, desktop there are various high end GPUs to pick) and start building new engines that may not be compatible with the wider ecosystem. OpenGL ES 3.0 should be the absolute minimum supported for new engine development right now and experiments with OpenGL 4.x should occur on mobile and if you are on the desktop only ignore anything that isn't the latest GL 4.x point releases.

JMonkeyEngine3 appears to be quite old and the result of many chefs, and supports all sorts of daft legacy rendering paths making it far more complicated than maybe it should be. Ardor was sadly abandoned. Xith and Java3D are ancient.

...and jPCT/jPCT-AE are being ignored...as usual. Anyway, 3D for desktop Java isn't very common these days, but for Android it is. For jPCT, i would estimate that the ratio between desktop Java and Android projects is somewhere between 1 to 10 and 1 to 20.

Today I was chatting on twitter about an engine and some smart guys posted a few links, that I want to record here for posterity. Or really to have a page I can point to every time someone uses a scene graph.

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