Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  So... state of the art 3D "engines" in Java  (Read 3707 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2014-07-30 08:16:52 »

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 Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #1 - Posted 2014-07-30 08:36:49 »

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
Offline Roquen
« Reply #2 - Posted 2014-07-30 08:44:46 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2014-07-30 08:56:35 »

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

Cas Smiley

Offline Kefwar

Senior Member


Medals: 5
Projects: 1



« Reply #4 - Posted 2014-07-30 09:04:06 »

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

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

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2014-07-30 09:13:43 »

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

Cas Smiley

Offline Roquen
« Reply #6 - Posted 2014-07-30 09:20:33 »

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.
Offline basil_
« Reply #7 - Posted 2014-07-30 09:35:26 »

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

JGO Coder


Medals: 32
Exp: 3 years


White-bearded OGL wizard


« Reply #8 - Posted 2014-07-30 10:41:25 »

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

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

My Blog | Jumpbutton Studio - INOP Programmer
Can't stress enough: Don't start game development until you haven't got the basics of programming down! Pointing
Offline Roquen
« Reply #9 - Posted 2014-07-30 10:55:05 »

Portals are dead simple and near optimal for any scenes that have high occlusion.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Evil-Devil

Senior Member


Medals: 2


Fir Tree Master


« Reply #10 - Posted 2014-07-30 11:16:03 »

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.
Offline gouessej
« Reply #11 - Posted 2014-07-30 12:37:25 »

Hi

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

Ardor was sadly abandoned.
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).

Xith and Java3D are ancient.
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.

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.

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.

Offline Roquen
« Reply #12 - Posted 2014-07-30 13:09:57 »

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).
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 801
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #13 - Posted 2014-07-30 13:13:42 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Roquen
« Reply #14 - Posted 2014-07-30 13:21:39 »

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.
Offline PandaMoniumHUN

JGO Coder


Medals: 32
Exp: 3 years


White-bearded OGL wizard


« Reply #15 - Posted 2014-07-30 14:11:36 »

@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.
Huh What does this have to do with what I said?

My Blog | Jumpbutton Studio - INOP Programmer
Can't stress enough: Don't start game development until you haven't got the basics of programming down! Pointing
Offline gouessej
« Reply #16 - Posted 2014-07-30 14:17:23 »

Huh What does this have to do with what I said?
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.
If they don't know your game is written in Java, they can't complain  Grin

Offline Roquen
« Reply #17 - Posted 2014-07-30 14:25:17 »

@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.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #18 - Posted 2014-07-30 14:28:18 »

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.
Offline Roquen
« Reply #19 - Posted 2014-07-30 14:35:06 »

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.
Offline gouessej
« Reply #20 - Posted 2014-07-30 14:47:24 »

The development of the above mentioned 3d java engines aren't really driven by any (or many) actual products or companies that use them.
Then, what is it? JMonkeyEngine showcase

http://jmonkeyengine.org/showcase/

Fleshsnatcher uses JMonkeyEngine too (its author is registered here Wink ).

and this? A few games using Ardor3D

http://www.youtube.com/watch?v=iWikbwTPP8g

Offline Longor1996
« Reply #21 - Posted 2014-07-30 14:55:15 »

and this? A few games using Ardor3D


Isn't that Manic-Digger (which is written in C++)?
It looks just like it, and if its not MD, what game is that?

Sorry for my bad English! That's because i am from Germany.
Offline gouessej
« Reply #22 - Posted 2014-07-30 15:05:18 »

Oops, you're right, sorry Longor1996. I took the wrong image.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #23 - Posted 2014-07-30 15:32:44 »

Then, what is it? JMonkeyEngine showcase
http://jmonkeyengine.org/showcase/
Most of those listed there are tech demo's, using old engine code, abandoned, unfinished or WIP's.
Offline gouessej
« Reply #24 - Posted 2014-07-30 15:58:56 »

Then, what is it? JMonkeyEngine showcase
http://jmonkeyengine.org/showcase/
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.

Offline Roquen
« Reply #25 - Posted 2014-07-30 16:48:17 »

The word here is: underwhelming.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 801
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #26 - Posted 2014-07-30 17:37:20 »

That's generally the issue with 3D games by indies... quality content production is the bottleneck, not necessarily the engine.

The only real shortcut is picking a specific visual style and focus on gameplay, or go 2D like a sane person.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #27 - Posted 2014-07-30 19:20:22 »

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.

Compute shaders and OpenCL is very important. Particle engines will all be compute based. In fact the first demo I'm going to port to Java is this one:
http://docs.nvidia.com/gameworks/index.html#gameworkslibrary/graphicssamples/opengl_samples/computeparticlessample.htm

For other modern GL demos check out all of them:
https://developer.nvidia.com/gameworks-opengl-samples

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. Wink 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.. Cheesy

The only real shortcut is picking a specific visual style and focus on gameplay...

Gameplay is king at the end of the day. From an indie perspective one could consider procedural content generation and have great gameplay.

The first example that pops to mind in regard to picking a specific visual style and procedural content is Love:
http://www.quelsolaar.com/love/

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.



Offline EgonOlsen
« Reply #28 - Posted 2014-07-30 19:30:21 »

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.

Offline Danny02
« Reply #29 - Posted 2014-07-30 19:41:45 »

I really liked this blog post:

c0de517e.blogspot.nl/2014/04/how-to-make-rendering-engine.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+C0de517e+(c0de517e)

Quote
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.
Pages: [1] 2
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (44 views)
2014-09-23 14:38:19

radar3301 (25 views)
2014-09-21 23:33:17

BurntPizza (62 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (39 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!