Ferox-gl Announced

Engines, Libraries and Tools Tools Discussion
#1

I’ve mentioned it a few times here and there across the forums that I’ve been working on a JOGL graphics engine. Now it’s finally come to a point where I’m happy with the API and I think it’s reasonable stable. I’ve done some minor testing (only on my Mac) so if it doesn’t work I’m not surprised. I’ve been busy lately and don’t have any webstart apps to give you, but I’ve attached some screenshots.

Site: http://code.google.com/p/ferox-gl/

Features [taken from Google Code page]:
* Easy to implement back-end.
* 2D, 3D and cube map textures with many supported data formats
* GLSL shader support
* DDS and TGA loader
* Submission style Renderer engine that is fully interfaced (allowing for hypothetically many advanced, automated techniques).
* Scenegraph with a simple API allowing test scenes and mock-ups to be easily created.
* Separation of renderer from the scenegraph.

The main thing that I’d like to stress is that all geometry and appearance descriptions (as well as their JOGL backends) are separated from the description of the code used for scene description. The renderer doesn’t know about my implementation of a scene graph. I’ve included a simple scene graph, but it could be very easy to write a more application specific version.

Let me know what you think,
Thanks

1st screenshot - normal/specular mapped cube using a diffuse, normal, and specular texture and glsl
2nd screenshot - 10000 cubes with 4 different appearances, rendered into an FBO and then that texture is rendered into the window.

#2

Hi!

The subtitle is “Ferox is a high performance 3D scene graph written in Java”, why? What does your engine do that others don’t? When I watch com.ferox.scene.Node.java, it looks like JMonkeyEngine, especially for the culling and the handling of the transforms. I have found some bounding volumes, some loaders, some states… Ok it is nice but what is your aim? If you do it in order to improve your skills in OpenGL and in 3D, it is an excellent idea. However, if you do it to compete with other engines, I’m not convinced, you lose. I like the separation of concerns in your engine but for the moment, I have not seen anything really different. There are already some other engines that work quite fine and that rely on JOGL, I think about Xith3D, Aviatrix, Avengina and JMonkeyEngine 2.0 (this last one still needs some deep fixes to be reliable with JOGL). Do you use any new algorithms or do you suggest another implementation of an existing algorithm? Good luck.

#3

No need to be so offensive, the more Java 3D engines, the better. Its very hard (impossible?) to contribute new ideas to existing engines, if the owner thinks differently about those ideas, so if someone isn’t happy with what/how a 3D engine does something, its logical to write a new one. From the first look at the code, i got the impression that the engine is well structured. Its BSD licensed open source, so no reason not to be influenced by other BSD code, but it doesn’t look like a rewrite of anything.

#4

[quote=“lhkbob,post:1,topic:33220”]
The lighting looks a bit weird on that. The light looks like it’s coming from completely different directions on all three sides.

#5

Yeah, I see that too. I think it’s a bug with my shader code or how I’ve set up the normal map texture. I was trying to use tangent space normal-mapping and I may have goofed it up a bit.

Thanks

Alright, rebuttal time. The tag-line is advertising, but it is high performance. For example, the 10000 cube scene runs 3 times faster than a similar scene in jME (but that’s tested on 1 computer). I’m glad that you looked at my scene code, but as I said in the first post, this was a simple scene graph that I wrote to use the rendering engine. A lot of it was inspired by the jME scene graph, of which I’m a fan. The reason that I do not like the jME engine as a whole is that their scene graph has been tied heavily to the renderer. Ferox has been designed to be very flexible and pluggable. Advanced effects are theoretically easy to do, and can likely be implemented using just the front-end of the engine.

I made Ferox because I had problems with the existing technologies. Perhaps this was because of ignorance of those technologies, and I will admit that this engine started out as a learning experience for me. I feel that this engine has a unique structure; I wrote it for my personal use, but I’ve open-sourced it for the benefit of those who happen to think like me. I do not intend to compete with existing scene graphs, I’m just providing a newer approach.

#6

You’re not ignorant, it is still difficult for me to use the JOGL renderer of JME 2.0; therefore I am as ignorant as you in a certain viewpoint. Open sourcing is a good idea.

Sorry if you found me harsh.

I find it currently hard but not impossible. I tinkered some things in my own engine and now I try to put this in JME 2.0 and it is a very difficult experience :’(

It is logical according to you but if everyone writes its own engine, it is less efficient than when people get concentrated on less engines. For example, if lhkbob and me decided to work together to repair the JOGL renderer of JME, lots of JME users would benefit of it. If I don’t put my small piece of innovation into JME and if lhkbob doesn’t try to put his own performance tricks into JME, I will probably be alone to benefit of my algorithms and him too, won’t we?

#7

Theoretically this is true, but I think graphics engines have a somewhat unique situation when it comes to collaboration. Engines are often large and bulky, and very technical. This makes it hard for a new programmer to learn enough of the internals to truly improve it.

Also, graphics technology and techniques advance quite quickly, making certain approaches obsolete. A mature engine is difficult to transform into a new technique, and it can be more efficient to start over or clean-house. That is why even the jME founders started Ardor3D.

#8

I disagree - the more the better :slight_smile:

The more (open source) engines are there, the more material is there for someone to pick up. Having different engines with different complexity also allows devs to learn from the sources they understand. Additionally, you can copy and paste code from one engine to another with respect to their license. Not everyone is interested in going the route of a managed source base, with coordination of multiple contributors and possibly even contribution agreements.

I am currently making my own engine with a friend of mine just for fun and to test out some things, I couldn’t just test out in the xith3d workspace, but maybe I will merge my ideas, concepts and code with the xith codebase once it matures.

Bottomline is, that it’s better to write your own engine than getting bored fiddling on an engine you don’t understand or you won’t feel significant progress. This way there is at least something to share at times.