Irrlicht with Java

elander · Post by **elander** » Sat Feb 25, 2006 8:46 pm

Im not talking about a binding here but rewriting the entire API in Java using JOGL and the Java api. What do you think of this?

Independently of how this being a good idea or not what will be the first classes to rewrite if someone wanted to port Irrlicht to a different programming language?

Eternl Knight · Post by **Eternl Knight** » Sat Feb 25, 2006 11:52 pm

I personally think that it is not worth the effort honestly. Java is not the speediest language at the best of times, and given the general use of Irrlicht (real-time 3D graphics) I don't think there would be much reason for people to use the Java-Irrlicht.

I also think that certian features of the engine would ot be very amenable to good use of the Java garbage collector.

Last but not least, I cannot see much USE for a Java version. Aside from the dubious* use in a web browser (which would still require the user to download and install the JOGL libraries) - there isn't really a call for Java-based engines of the type Irrlicht is based on. I've seen some great uses of 3D in Java applications, but their mainly scientific/statistical visualisations - not quake-like environments.

I actually debated posting this as I thought that you might take it the wrong way. I am not trying to diss you or such-like. I am trying to explain why you might not find many/any people using or helping develop the project.

--EK

* By "dubious" I meant that most game developers have agreed that 3D engines and web browsers don't mix. The closest most people get to using web browsers for 3D worlds is the rare Flash-based isometric. The kind of bandwidth associated with client/server based online 3D engine applications is generally not suited to the "request/response" style of web-browser network communication

elander · Post by **elander** » Sun Feb 26, 2006 2:36 am

It may still be interesting even if it's just for scientific/statistical visualisations and univ projects which are mostly done in Java these days. JOGL is just basicly opengl in Java. It needs a scenegraph on top of it and Irrlicht looks like a well designed and simple to use api for the task. I know theres Jirr but it's not the same thing as a pure java irrlicht engine.

PS: By the way there is a version of quake made completely in java that is faster than the original quake.

Eternl Knight · Post by **Eternl Knight** » Sun Feb 26, 2006 6:16 am

By the way there is a version of quake made completely in java that is faster than the original quake.

That is not surprising - the original quake was firstly a software implementation, and even if comparing GLQuake with then - drivers have been optimised alot more. For example, we now have vertex buffers and hardware T&L... something that was missing back then.

In any case, if YOU are really interested in doing it - there is no reason for YOU not to. I'd even be curious to see how it turns out.

--EK

elander · Post by **elander** » Sun Feb 26, 2006 7:09 pm

I see people here are not very entusiastic about this, no problem I will do it a test to see how it works and update this thread ocasionaly.

The packages:

net.sf.irrlicht
net.sf.irrlicht.core
net.sf.irrlicht.gui
net.sf.irrlicht.io
net.sf.irrlicht.scene
net.sf.irrlicht.video

I like the dusty engine so i will just add these because i believe if irrlicht provides a scene graph for the game structure it should also provide a more complex means to deal with the game dynamics.

net.sf.irrlicht.task

And also clanlib way to handle signals or events: http://clanlib.org/docs/Overview/signals.html

net.sf.irrlicht.signal

Ill update this when i have something done.

jam · Post by **jam** » Mon Feb 27, 2006 12:29 am

elander wrote:I see people here are not very entusiastic about this

I wouldn't go that far!

At the moment I don't have a need for a Java based 3D engine, but I have seen at least a good 6-8 3D engines based on pure Java so I would think it is very doable. The speed difference between Java and C continues shrink with every compiler or VM release.

In short go for it! The more people who can get their hands on Irrlicht the better, in my opinion.

zenaku · Post by **zenaku** » Mon Feb 27, 2006 1:43 am

Im not talking about a binding here but rewriting the entire API in Java using JOGL and the Java api. What do you think of this?

It's not a bad idea, but it's a huge undertaking. I've been hacking on IrrLua in my spare time for almost a year now and I'm still not done, and that's just a binding, not a re-write.

I thought about rewriting Irrlicht using just Lua + LuaGL, but ultimately I thought it would be slow due to OpenGL being a fine-grained API. There would simply be too many calls going from Lua -> GL -> Lua -> GL in what would have been the 'CIrrlichtDeviceLuaGL.lua' object.

I think you would have similar problems in Java at the JOGL level. The real OpenGL driver is not written in Java so you are going to be going back and forth between the real gl driver and java a lot.

If your pure java irrlicht and Jirr both have basically the same API (irrlicht), how are they really different besides implementation? If performance is the only reason, is a pure java version going to give the maximum performance over something like Jirr? I don't think it would, but you don't really know until you try it.

IMO a partial binding to irrlicht.dll would give the best performance. Some parts like irr::core::* would be pure Java and some would fall back to the irrlicht.DLL when the granularity wasn't so bad. Maybe it would be better to modify Jirr in this way than to rewrite it entirely? I'm not sure.

Regardless of performance issues, it's not a bad idea, and I wouldn't let other comments here detract from it.

The real question of why you should write your own toolkit/binding/library/whatever is, would YOU actually use it?

elander · Post by **elander** » Mon Feb 27, 2006 6:48 am

zenaku wrote: I thought about rewriting Irrlicht using just Lua + LuaGL, but ultimately I thought it would be slow due to OpenGL being a fine-grained API. There would simply be too many calls going from Lua -> GL -> Lua -> GL in what would have been the 'CIrrlichtDeviceLuaGL.lua' object.

Have you tried LuaJIT?

http://luajit.luaforge.net/

It isn't as fast as the Java JIT that can even surpass C++ sometimes but it can give you a good speed boost.

The real question of why you should write your own toolkit/binding/library/whatever is, would YOU actually use it?

That depends on the final Benchmarks. It's good to be able to add new nodes or new loaders to the api, for example, using Java code.

Andi|xng · Post by **Andi|xng** » Sat Mar 04, 2006 11:22 am

I'm working with Jirr (Java binding for Irrlicht) for quite a while now and it works very good. I can see no real reason why it has to be rewritten in Java. But if someone would do the work, I think I would use it!
I just think that it is not worth the effort, since the binding to Java with JNI works very good.