So... state of the art 3D "engines" in Java

General Discussions
#1

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.

Cas :slight_smile:

#2

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.

#3

Scenegraphs are great for tools, awful for simulations. This is because logically a scenegraph represents everything as a (more-or-less) single rigid body system.

#4

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

Cas :slight_smile:

#5

What kind of other types exist beside scene-graph based engines, I’ve actually only seen scene-graphs (not looked for it much though).

#6

Well… for example there are space-partitioned things like Quake uses. I don’t really know :slight_smile: Hence asking. What is the state-of-the-art in game engines?

Cas :slight_smile:

#7

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

#8

what if I put regular grids into the leafs of a range-tree which implements a scenegraph node ?

#9

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. :frowning:

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

#10

Portals are dead simple and near optimal for any scenes that have high occlusion.

#11

I guess most of the modern engines uses the approach of the old fashioned scene graph model as a supporting role for the spatial system approach. Thus they can combine it with nearly everything.

#12

Hi

??? JMonkeyEngine 3 isn’t old. It is entirely shader based even though there are still some separate renderers based on the fixed pipeline which are unknown by most JMonkeyEngine users.

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 not sure whether Xith3D is still maintained. Java3D is still maintained but yes, it’s not modern, it’s far less capable than the 2 first engines you mentioned.

https://www.goocreate.com/img/product-shots/product-1-thin.jpg

I find Goo Engine (& Goo Create) interesting. Too bad its API is in Javascript. LibGDX has a 3D API too.

I confirm what delt0r wrote, some scenegraphs are used in CAD softwares. Sometimes, some corporations prefer their homemade ones :s

@PandaMoniumHUN End users aren’t always aware of the use of the JVM in a game especially when it doesn’t use the one of the system.

#13

No serious game engine now nor ever has used a scenegraph. And its not that old…roughly same time as quake (1 big bsp) and unreal (forest of bsp’s connected by portals).

#14

@Roquen: true (obviously)

The only upside of a scenegraph is the inherent support of a transform tree, which can easily be implemented outside of this scenegraph. It can help somewhat with culling efficiently.

Render states typically do not map well to this transform tree, yet all these hobby-project-engines try to piggyback on this structure.

#15

Not really. The bound volumes are problematic in practice. It’ll work, but it’s a pretty inefficient way to deal with potentially visible sets.

#16

??? What does this have to do with what I said?

#17

If they don’t know your game is written in Java, they can’t complain ;D

#18

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

#19

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.

#20

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.