Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  3d engine using openGL directly  (Read 2500 times)
0 Members and 1 Guest are viewing this topic.
Offline Morin

Senior Newbie




Java games rock!


« Posted 2003-04-02 11:03:16 »

Hi you all! I'm currently unsure what to do. My goal: I want to write a 3d engine. However, I am not sure which low-level API to base it on. AFAIK I have three options:

1. Base it on Java3D. This sounded very good to me at the beginning because it is portable and the API allows a lot of optimization in the background. However, I did not read any "performance success stories" yet (only about success in development time), and the API is not exactly what I need (maybe it works with some tricks though).

2. Base it on an OpenGL-for-Java binding (LWJGL, GL4Java, etc.). This leads to problems as well: When it comes to transferring all the data of a really complex 3d object down to OpenGL, the repeated JNI calls *seem* to be a performance problem (can anyone clear this issue?) But an OpenGL binding seems to be "almost good"

3. Write an own Java/native binding which uses OpenGL at the native side but offers a higher-level interface to the Java code. This would allow to create an API which is designed specially for Java (unlike OpenGL) and also does a lot of caching on the native side.

As you probably see, I favor the third option. Note that I understand the difference in Java3D vs. OpenGL as "scene graph vs. immediate-mode access". I would write the scene graph / management part completely in Java then (the native part would work at a lower level then scene graphs).

It also seemed to me that OpenMind is similar to what I want to do, but like Java3D its API is not what I had in mind.

My question is, does this sound like a reasonable approach?

Thanks in advance.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-04-02 12:00:16 »

2. You are right, it only seems to be a performance problem. The reality is that the JNI overhead is so small as not to be measurable. Don't reinvent the wheel, and use our binding Smiley Then your engine will be much more easily made to run on other OSs.

Cas Smiley

Offline Morin

Senior Newbie




Java games rock!


« Reply #2 - Posted 2003-04-02 21:12:59 »

Actually, I wanted to write a "lowest layer" (the only part of the program that contains native code), set it on top of OpenGL and provide a _different_ interface to the Java part. However, I have noticed that I don't get around providing some functions that are actually the same as OpenGL functions. So I could as well try an OpenGL binding Smiley

One thing would be important to me though: In case I find a part of your mapping that becomes a bottleneck because it works through JNI, is it then possible to replace only that part with a self-made native library?This native library would do nothing than to run some OpenGL functions in a kind of "batch mode" to avoid JNI. I think it should work, because OpenGL is designed to work that way, but I want to be sure.

Not that I expect such problems, but I don't want to change the binding again, should they appear.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2003-04-03 08:52:35 »

I think I can state with absolute certainty that there will be no such bottleneck. Any bottlenecks that do exist will be from using the GL API incorrectly in the first place. It has been extremely cleverly designed to make using it over an interface as fast as possible.

The next most likely bottleneck will be in your Java code and relates to memory bandwidth and floating point performance, separately. Vote for Structs!

Cas Smiley

Offline kevglass

JGO Kernel


Medals: 121
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2003-04-03 10:39:03 »

Morin,

Out of interest, what _other_ interface were you thinking of supplying to access your native layer? I assume its meant to be faster that JNI to avoid the bottle neck?

The other other interfaces that might let java access a native layer I can think of would be file or socket related which I would have thought would come out way slower than JNI.

Kev

Offline Morin

Senior Newbie




Java games rock!


« Reply #5 - Posted 2003-04-03 11:58:33 »

Just found out that LWJGL already supports what I need! In fact, your library looks very similar to what I had in mind. Looks like the right choice to me Smiley

@kevglass: I wanted to provide a higher-level API than OpenGL to the Java side, but still based on JNI. Like, transfer an array of vertex data to the native side at startup and then, at runtime, do something like "batch processing": one JNI call to a native function which sends all data to OpenGL in a tight loop. In other words, exactly what I found buffers in LWJGL to be Smiley
Offline Morin

Senior Newbie




Java games rock!


« Reply #6 - Posted 2003-04-03 12:37:16 »

And about structs: I'm not sure if that really speeds things up. Because, before you can access the members of a struct you have to set up the struct itself (as a window to the buffer). Either this takes more time than you gain, or you cache the struct itself and that takes a lot of memory when you do it everywhere.

You DO gain some cleaner code, but you could get that otherwise, like:

1  
2  
3  
4  
// normalize vector at position 20
buf.readVector3f (vec, 20);
vec.normalize ();
buf.writeVector3f (vec, 20);


This is nearly as clean. To solve the speed problem, I think another trick than structs is needed. Speed is only a problem anyway when you want to perform some operation on all elements of a big buffer - The term "batch processing" comes to my mind again.
Offline abies

Senior Member





« Reply #7 - Posted 2003-04-03 12:38:50 »

Cas already touched point 2, so I'll take a chance at 1.

Java3d is less portable than opengl. You have opengl bindings on every platform out there which has both java and opengl. For java3d, you need both of these, plus java3d itself - which is not so easy in some cases (see Mac).

Only thing you gain is ability to choose between opengl and DirectX on Windows platform. In theory it could be a good option, if some company provides a lot better DirectX drivers than opengl ones - but is it a case today for any cards ? On downside, you will have to fight with java3d incosistencies between these two bindings.

Java3d gives you easier interface and better performance for some projects. But at the same time you pay with portability and possibilities (at least before 1.4 will come out).

Artur Biesiadowski
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #8 - Posted 2003-04-03 13:49:21 »

Quote
Like, transfer an array of vertex data to the native side at startup and then, at runtime, do something like "batch processing": one JNI call to a native function which sends all data to OpenGL


You can go one better than that - with GL display lists or various extensions you can cache vertex data on the server side (ie, video card ram) and avoid having to shuttle data across not only the Java/native boundary, but also the physical AGP bus Smiley

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-04-03 14:19:05 »

(OT) Morin, Structs solves not only the ugly requirement that you read and write chunks of buffers in all sorts of irritating ways and have to position buffers all over the place, but it also solves the memory bandwidth issue as it allows you to operate directly on data in-situ, and with only one bounds check at that (which can be hoisted anyway if in a loop). Memory consumption of Struct instances is not an issue; you will typically only need 1 instance of a Struct to read all the elements in a StructBuffer, by virtue of its reusability.

Cas Smiley

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

Junior Member




There is nothing common about common sense


« Reply #10 - Posted 2003-04-05 03:43:07 »

Quote
Java3d is less portable than opengl. You have opengl bindings on every platform out there which has both java and opengl. For java3d, you need both of these, plus java3d itself - which is not so easy in some cases (see Mac).


I disagree with that comment whole heartingly.  Java does not come nativly installed on any OS maybe except for sun.  As I agrued before, if you are gonna use Java in any application, you cannot expect the user to have the latest jre that you might be using.  Hence you need to package this w/ your app.  Programs written in C most of the time don't have this problem; however, most retail games include the latest DirextX and OpenGL on the disk.  Whats the 5 to 13 mb for j3d when your game is most likely much more then that?

Ubuntu
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #11 - Posted 2003-04-05 04:21:32 »

Quote
Java does not come nativly installed on any OS maybe except for sun.


You forgot OSX. And several Linux distributions. And IBM mainframes. And HP-UX machines. And FreeBSD already has a contract to bundle the JRE.

You know, come to think of it, Windows is the real problem here...

Java Game Console Project
Last Journal Entry: 12/17/04
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

CogWheelz (12 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!