Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
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 4057 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej
« Reply #30 - Posted 2014-07-30 19:47:21 »

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.
Some scenegraphs support cells and portals, JMonkeyEngine supports BIH trees:
https://jmonkeyengine.googlecode.com/files/Scene%20Partitioning.pdf

jKilavuz can be used with JPCT to compute portals and "sectors":
http://www.jkilavuz.com/features.html

IsoSurface demo uses JMonkeyEngine 3:

I don't find it ugly.

Offline Roquen
« Reply #31 - Posted 2014-07-31 08:42:28 »

That's generally the issue with 3D games by indies... quality content production is the bottleneck, not necessarily the engine.
Sure.  That's not the context of my comment which was targeting "tech".

A game industry TD who links to other long time game industry TDs and leads...who's gonna listen to folks that that?  They must all be old and set in their ways or something.
Offline gouessej
« Reply #32 - Posted 2014-08-01 19:57:24 »

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.
You criticize JMonkeyEngine whereas "opengl.gui" within Clyde GUI is derived from ... JMonkeyEngine Banana User Interface (JME-BUI):
https://github.com/threerings/clyde/blob/master/README.md

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2014-08-01 20:24:46 »

Anyway, where I was going with this...

were one to start from scratch with an idea to make an engine that might compete, say, with Unity - at least on the desktop - what might be an overall design for it? Given that all these different techniques exist - such as BSPs, octrees, portals, scenegraphs, etc - what overall architecture might be able to throw everything in and get it working together?

Cas Smiley

Offline Catharsis

JGO Coder


Medals: 9
Projects: 1
Exp: 18 years


TyphonRT rocks!


« Reply #34 - Posted 2014-08-01 21:15:02 »

To get anything close to Unity functionality from the tooling perspective and runtime flexibility a component architecture is pertinent.

Unity itself licenses and integrates various 3rd party middleware. SpeedTree being an example. If your effort was commercial I'd look at various 3rd party industry standard middleware to integrate. Sundog's SilverLining (sky rendering) and Triton (ocean / wave rendering) could be good additions to SpeedTree.

For indoors I'd do a patchwork of separate BSPs (to my understanding this is what the Unreal engine does; haven't looked at Unreal 4 / recent source) which can be streamed.

Outdoors indeed would be Octree plus heavy streaming.. Try and work out an editor like Grome (http://www.quadsoftware.com/index.php?m=section&sec=product&subsec=editor). Don't know if that company would license editor code.

Pulling together an editor for outdoor / indoor would be a challenge.


Offline gouessej
« Reply #35 - Posted 2014-08-01 21:53:21 »

I prefer not talking about component architecture as this is something I don't know enough to judge whether it's relevant or not for gaming.

I challenge you to find an intelligible open source implementation of portal culling and "portalization" (creation of the cells and the portals) whereas there are tons of examples of partitioning trees on the web. Grome is used in some commercial games to create realistic terrains, it seems to be quite good.

I can speak about what I really know. Whatever you will do, you'll need to use partitioning trees, even to generate cells and portals. If your geometries don't change a lot, partitioning trees should be enough, they are generally faster to visit but modifying them can be sometimes very expensive. If you want to manage fully destructible environments, you can go on using trees and cheat a lot (manage destructive objects separately and keep a static tree) or you can use a graph of cells which is more expensive to visit but a lot less expensive to modify.

Some other kinds of culling might be interesting, I think about back face culling, contribution culling, view frustum culling and occlusion culling (with anti-portals). Back face culling and view frustum culling are often supported by major 3D engines written in Java.

Offline pitbuller
« Reply #36 - Posted 2014-08-02 08:40:11 »

Some other kinds of culling might be interesting, I think about back face culling, contribution culling, view frustum culling and occlusion culling (with anti-portals). Back face culling and view frustum culling are often supported by major 3D engines written in Java.

When you are talking about backface culling do you mean precalculcated lists depending on view direction or just gpu flag?
Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #37 - Posted 2014-08-02 09:49:08 »

These are all solutions to unspecified problems. What are the problems? What queries do we need to be able to perform on the data?

For example: we want to draw the diffuse lit scene. We need to be able to efficiently know what is potentially in the scene; so we have a frustum cull.

Another example: we want to know if two "things" collide. What are things? How many of them are there? Do we need perfect collision or approximate collision?

And so on.

Cas Smiley

Offline gouessej
« Reply #38 - Posted 2014-08-02 16:02:20 »

When you are talking about backface culling do you mean precalculcated lists depending on view direction or just gpu flag?
I was talking about that which is very rudimentary. Facet culling is disabled by default. Personally, I prefer using separate meshes and the OpenGL flag, for example when entering a building.

@princec Something outside of the view frustum might influence the scene, for example a source of light, a lamp.

There are several kinds of tests that can be done to avoid doing useless heavy computations when looking for collisions, you can benefit of spatial subdivisions and bounding volumes to eliminate obvious cases. Imagine that the player is the entrance of an hotel at the ground floor, you don't need to check whether he collides with an enemy in the 6th floor.

You can detect collisions a priori or a posteriori, you can use a physics engine (JBullet, Jinngine, ...) if you don't want to reinvent the wheel. Keep in mind that if two things make a move greater than their respective bounding volumes between 2 instants, you might miss some collisions when using a posteriori collision detection and multisampling can become very expensive if they move very quickly. Sometimes, we can cheat, you can use a simple ray to represent the trajectory of a bullet but it becomes really weird when shooting a guy very far from the player.

Offline gouessej
« Reply #39 - Posted 2014-08-06 18:16:14 »

The sweep-and-prune algorithm allows to avoid testing collisions between all possible combinations of objects:
http://www.codercorner.com/SAP.pdf

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #40 - Posted 2014-08-06 18:33:12 »

SAP is basic, easy to implement, brute-ish force and can be more than reasonable.
Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #41 - Posted 2014-08-06 19:48:52 »

Well, physics and such notwithstanding... let's assume for the moment we'd just want to deal with rendering a scene.


Cas Smiley

Offline arnaud_couturier
« Reply #42 - Posted 2014-08-12 12:47:27 »

Unity is quite a beast.

The overall architecture seems really well thought, at least from the outside. To me, its biggest advantage is that everything in a scene is component-based, it gives an amazing amount of flexibility, both for us users, but also for the Unity dev team. They just keep adding new components version after version, such as the somewhat recent 2d physics and 2d rendering components, and soon the reflection probes.

In terms of rendering, I'm not sure if that answers the question, but they use a mix of frustrum culling, static batching, dynamic batching, and occlusion culling (using Umbra). For the underlying problems all those solutions are trying to solve, I'd start looking at the theory behind each of them.
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.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (44 views)
2014-10-16 15:22:06

Norakomi (34 views)
2014-10-16 15:20:20

lcass (38 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (68 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (87 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!