Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (467)
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  
  Ferox-gl Announced  (Read 2447 times)
0 Members and 1 Guest are viewing this topic.
Offline lhkbob

JGO Knight


Medals: 32



« Posted 2009-03-25 03:25:04 »

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.

Offline gouessej

« In padded room »



TUER


« Reply #1 - Posted 2009-03-25 08:38:28 »

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.

Offline VeaR

Junior Member





« Reply #2 - Posted 2009-03-25 14:45:08 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #3 - Posted 2009-03-25 16:52:01 »

1st screenshot - normal/specular mapped cube using a diffuse, normal, and specular texture and glsl

The lighting looks a bit weird on that. The light looks like it's coming from completely different directions on all three sides.

Play Minecraft!
Offline lhkbob

JGO Knight


Medals: 32



« Reply #4 - Posted 2009-03-25 20:14:51 »

The lighting looks a bit weird on that. The light looks like it's coming from completely different directions on all three sides.

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.

No need to be so offensive, the more Java 3D engines, the better. ... 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.

Thanks

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.

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.

Offline gouessej

« In padded room »



TUER


« Reply #5 - Posted 2009-03-26 01:36:11 »

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.
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.

No need to be so offensive, the more Java 3D engines, the better.
Sorry if you found me harsh.

Its very hard (impossible?) to contribute new ideas to existing engines,
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  Cry

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.
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?

Offline lhkbob

JGO Knight


Medals: 32



« Reply #6 - Posted 2009-03-26 04:37:53 »

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?
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.

Offline cylab

JGO Knight


Medals: 34



« Reply #7 - Posted 2009-03-26 16:25:04 »

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.

I disagree - the more the better Smiley

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.

Mathias - I Know What [you] Did Last Summer!
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.

xsi3rr4x (81 views)
2014-04-15 18:08:23

BurntPizza (73 views)
2014-04-15 03:46:01

UprightPath (84 views)
2014-04-14 17:39:50

UprightPath (67 views)
2014-04-14 17:35:47

Porlus (84 views)
2014-04-14 15:48:38

tom_mai78101 (107 views)
2014-04-10 04:04:31

BurntPizza (167 views)
2014-04-08 23:06:04

tom_mai78101 (263 views)
2014-04-05 13:34:39

trollwarrior1 (214 views)
2014-04-04 12:06:45

CJLetsGame (223 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!