Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (707)
Games in Android Showcase (208)
games submitted by our members
Games in WIP (781)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Planetary terrain rendering  (Read 8519 times)
0 Members and 1 Guest are viewing this topic.
Offline mirko27

Senior Newbie

Java games rock!

« Posted 2008-04-16 22:06:33 »


I`m working on a procedural planets project. Implementation details are
resolved and most of them tested in C++.
But since I got interested in Java lateley, I want to complete my project
in J2SE. So my question to you is - which library to use?

I see that most obvious options would be:
Ogre4J - it`s being updated again and the logic in c++ should give some speed gain(less calls through JNI). But it should also lower flexibility.
JOGL - too low-level, since you need to write all culling / scene graph yourself
Java3D - don`t know much
jME - didn`t make a good impression, looked too specialized and in the other direction of my needs

Offline bienator

Senior Devvie


« Reply #1 - Posted 2008-04-16 22:55:22 »

I think Java3d wouldn't be the best choice for terrain experiments (to high level) its more a general purpose scene graph and VERY java like.

It always depends what you like to accomplish. You said pure OpenGL is to low level, if you focus on procedural terrain, any of the options you mentioned would probably be good enough to render your generated mesh (in this case i would recommend jME or Xith - I never used orge maybe its good too). But if you focus on terrain rendering techniques (or both) you will need pretty low level coding.

I would even say 90% of the code you will write for terrain rendering will have something to do with specialized scene graphs/space subdevision (including culling and similar things), triangulation and questions like how to update the terrain fast enough when you move Wink

here is my (pretty old) procedural planetary terrain engine using JOGL for rendering.

Offline mirko27

Senior Newbie

Java games rock!

« Reply #2 - Posted 2008-04-17 07:37:54 »

I also would like an opinion on Ogre4J.
By the way, is your source code free?
It`s always interesting to look at different approaches.
I myself will go for quadtree continious LOD, where I
will make a cube of 6 2D planes and map it to a sphere.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Kernel

Medals: 154

« Reply #3 - Posted 2008-04-17 10:12:34 »

You will probably be interested in this: Lot's of resources and papers there. Also there is a MIT licensed Chunked LOD Terrain available on sourceforge:

Last year I created a quadtree Terrain engine for Xith3D which is still in progress, but might be interesting to you (or you might want to contribute Wink) It can load and display L3DT terrains by the way ( This is what it looks like:

Mathias - I Know What [you] Did Last Summer!
Offline mirko27

Senior Newbie

Java games rock!

« Reply #4 - Posted 2008-04-17 11:38:19 »

As I said, I had a working prototype and implementation idea already set. Right now I`m looking ways to do it in Java.
Can anyone comment on Ogre4J?

 But is a very good resource. When I worked on the prototype then I got tons of useful information there.
Offline bienator

Senior Devvie


« Reply #5 - Posted 2008-04-17 18:51:07 »

no, sorry my engine is not open source. I used the project mainly for experiments, it was never intended to be a open or commercial project and I simple have not the time to maintain an other open source project.

>I myself will go for quadtree continious LOD, where I
>will make a cube of 6 2D planes and map it to a sphere.
similar to my approach Wink my terrain engine is a mix between several techniques. I use quadtrees for space subdivision and ROAM for continuous triangulation. The default ROAM implementation does not scale very well (esp. if you are moving fast), thats the reason why i decided to use a more memory intensive structure to traverse the mesh what simplifies normal calculation as an nice side effect. (what you really want is to access all triangles around a vertex or iterate through all triangles in a quad, right? ;-) ).

The first version was a infinite (procedural) terrain, later I added a box2sphere mapping mode which uses 3d perlin noise for terrain and texture generation.

respect! Now I have to improve my texture mapping :/

Offline DzzD
« Reply #6 - Posted 2008-04-17 20:32:46 »

maybe you will find interristing stuff in this simplified ROAM sample applet , source code are available

code snipet to  build the terrain in Animator class:

4 Landscape3D();,w,h,14,4);;,h/2);

rendering is done by public void render(Graphics g) in Landscape3D class

I have improved this version in 3DzzD (that is still planned to be opensourced... just need time Sad ) using different technic for variance computation that take care of terrain silouhette and use a faster tesselation system using more memory and two methods :  tesselate that build/precompute all possible triangle at a given quality and render that give the list of triangle for a given point of view with lowest impact on terrain silhouette. doing that should allow you infinite terrain rendering.

Offline Riven

« JGO Overlord »

Medals: 1249
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #7 - Posted 2008-04-22 09:08:14 »

ROAM's and continious-lod's (constantly varying) datastructures are not optimal for modern GPUs.

Chunked LOD is one of the best algorithms, atm. Inside the 'chunk', you can use ROAM to get rid of most tris at initialization time.

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

Senior Devvie


« Reply #8 - Posted 2008-04-22 10:22:55 »

I agree with Riven, you won't be lucky if you use the full ROAM implementation since it was designed to run in "immediate mode". But ROAM is more or less the mother of most terrain rendering algorithms. The triangulation part with the binary triangle tree and the idea of the "variance" (triangle error) computation is found slightly different in may other algorithms.

Today you should always try to keep your geometry on the GPU and plan updates carefully.

Offline Conzar

Junior Devvie

There is nothing common about common sense

« Reply #9 - Posted 2008-05-01 20:06:40 »

Here is an example for Java3D

Their code is open so you should be able to look through it to see what they did in Java3D.

Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Galdo (490 views)
2017-01-12 13:44:09

Archive (644 views)
2017-01-02 05:31:41

0AndrewShepherd0 (1115 views)
2016-12-16 03:58:39

0AndrewShepherd0 (1040 views)
2016-12-15 21:50:57

Lunch (1170 views)
2016-12-06 16:01:40

ral0r2 (1404 views)
2016-11-23 16:08:26

ClaasJG (1500 views)
2016-11-10 17:36:32

CoffeeChemist (1469 views)
2016-11-05 00:46:53

jay4842 (1551 views)
2016-11-01 19:04:52

theagentd (1261 views)
2016-10-24 17:51:53
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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‑
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!