Why OGRE wasn’t chosen as the rendering back-end in jME?

Just out of curiosity…why OGRE wasn’t chosen as the rendering back-end in jME? Isn’t this way the development would have been much easier with a lot of functionality pre-built?



or there are some technical issues that I am missing?

Yeah, that jme is a java engine maybee…

2 Likes
@EmpirePhoenix said:
Yeah, that jme is a java engine maybee.......


8)

Lol, Ogre is basically going the same direction as jME, its also using OpenGL and gives you a bit more convenience around it. Though jME3 gives you a lot more convenience, not to mention its java :wink:

@iamcreasy:

I once tried ogre4j ( http://ogre4j.sourceforge.net/ ) which wasn’t that bad. But it is more or less abandoned…



Code looked like this: http://sourceforge.net/projects/ogre4j/forums/forum/707387/topic/3727158

:?



Guys, there is the word back-end in my question. :roll:

Dude, there is nothing to “backend” to jME3 but OpenGL, I don’t know what you want… :?

1 Like

Me too :?. The only renderer on this history is OpenGL.

1 Like
@iamcreasy said:
:?

Guys, there is the word back-end in my question. :roll:


In other words, they do use the same back end.

The real question here is “why in the hell would we have done that”?

Yeah, then we could have used ogre in the first place. (Also we have stuff ogre does not, ogre is just a rendering backend , we have physics, network, and more)

@normen said:
Dude, there is nothing to "backend" to jME3 but OpenGL, I don't know what you want.. :?


Its about having a higher level wrapper.

@nehon said:
The real question here is "why in the hell would we have done that"?


So, we start with a already well made rendering part. We just needed to integrate the other(animation, physics, audio) libraries for turning into a fully working game engine.

I thought the question was obvious.

I guess @Momoko_Fan knows why. :)

…ok…you know the whole idea in JME3 is to make a java 3D engine, not to make a java wrapper over a C++ 3D Engine

@nehon said:
...ok...you know the whole idea in JME3 is to make a java 3D engine, not to make a java wrapper over a C++ 3D Engine

...not 'C++ 3D Engine' but 'C++ Rendering Engine'.

When we are already using 'C++ Physics Engine'(native bullet) then what's the issue when talking about 'C++ Rendering Engine'?

As a matter of fact even LWJGL is a Java wrapper of low level C library of Opengl and OpenAl. So, everything in jME is a Java warpper of low level C/C++ library.

This front end ,which always remains Java, is not related the issue I am talking about. I am talking about the ease and advantage of using a more sophisticated and mature underlying rendering library.

Hope this revokes the down vote and confusion.

A native call is really expensive. It’s important to compartmentalize them as much as possible. Having written my own Java wrappers around C++ back-ends before, JME and LWJGL gets this one right, in my opinion.



The higher you make this interface, the more inflexible and/or less performant the API is.



Besides, as others have mentioned, 98% of the work is really OpenGL. The only way to raise the level up any higher would have been to have a scene graph in C++ that we interface with in Java… that’s a non starter for a dozen different reasons.

1 Like

No, iamcreasy it doesn’t ^^ Its like saying “Lets put a Mercedes car into a General Motors car” instead of saying “Lets put a Mercedes engine into a General Motors car”. They both use the same engine, called OpenGL.

@iamcreasy said:
...not 'C++ 3D Engine' but 'C++ Rendering Engine'.

When we are already using 'C++ Physics Engine'(native bullet) then what's the issue when talking about 'C++ Rendering Engine'?

As a matter of fact even LWJGL is a Java wrapper of low level C library of Opengl and OpenAl. So, everything in jME is a Java warpper of low level C/C++ library.

This front end ,which always remains Java, is not related the issue I am talking about. I am talking about the ease and advantage of using a more sophisticated and mature underlying rendering library.

Hope this revokes the down vote and confusion.


Oo i didn't down voted you, we're just talking.

you're right about bullet, but a physics engine is not mandatory to make a game, it was easier and faster to use than to make a proper physic engine in java. Though some chose to make their own (like Paul with Mythruna).

Ogre is not only a rendering engine, i guess it has a scene graph and all the scene partitioning, culling, etc..the we have...basing JME on ogre is taking out a the very purpose of JME...then better use directly ogre...
Also native calls can be expensive so i doubt it would be better on the performance side....


EDIT : erf i'm slow...
@normen said:
No, iamcreasy it doesn't ^^ Its like saying "Lets put a Mercedes car into a General Motors car" instead of saying "Lets put a Mercedes engine into a General Motors car". They both use the same engine, called OpenGL.

-.-

Also native calls can be expensive so i doubt it would be better on the performance side….


Got a point here.

anyway, whoever is down voting, thank you. its freaking annoying!

It’s not me I nearly always forget voting.



Btw the main reson to ALSO offer a c++ physic and not only a java based one is, because the c++ is faster due to use of better algorithms, porting them over to jme would probably be a task for like a few years to understand them, and then start converting them.



Sidenote, in multiplayer often only the server uses physic, or is the one with the most physic load. Making a native for your root server is far more trivial then making a native that runs everywhere java runs. (The lwjgl guys do a great job there to archive this !)

1 Like

I think what @pspeed explains exactly where we are and why we’re there. Having the system where you do much of work (the scene graph) available as a wrapper is asking for trouble. Not only do yo incur the cost of the native calls but you have a higher learning curve for using the engine!