Project name: unnamed
Game type: a middleware to build 3d environments
Recruiting: no
Status: dead
License: MIT
Current build and source code snapshot: Jupiter (executable jar file)
Required libraries to run (included in the linked jar)
JME 2.0
jme ogre file loader
Berkeley DB Java Edition
Substance Look And Feel
A JSR 199 implementation (such as the OpenJDK one)
Right now i’s just a prototype (of a pious wish). As a UI geek, I started looking for an “interesting” gui to make and from that point of view a 3D middleware certainly is because there is a wonderful amount of things that the user must be able to do.
This is a screenshot of the main window of the program (Raven Graphite Glass LookAndFeel from Substance)
main window.jpg
The UI is a SDI one, structured around tabs. The following image shows the tab of the image archive:
image archive.jpg
The scene graph manager is a composer: the user creates raw models with an external editor (like blender) and then imports those models in the program. From an interactive point of view most of the stuff work with the mouse: instead of opening image files the user drops images from the OS window manager to a branch of the image archive tree or in the image archive branch viewer. When the user want to use one of those image for a model he drags it from the image archive to the image “hot spot” for a texture unit of that model.
model texturing.jpg
A customized model - that is a model that has been imported or a primitive that ha been created inside the program - can be “archived” by draggin its “model tab” into the model archive tree tab.
model to archive.jpg
The program will then create an horrible button that when pressed will add a clone of the archived model in the scene graph - in front of the camera.
There is the classic “drag the arrow” translation tool and the copy-cut-paste triple that make really easy to build scenes by replication of building blocks
building blocks.jpg
All that said, the program still lacks thousands of features - archives for render states, shaders, render pass, effects, terrain, sound and so on - but considering what can be squeezed out of JME in two weeks of spare time i’m fairly optimistic.
As a side note, programming with JME is definitely great fun.
looks fantastic…
good luck with it…
Amazing looking GUI man, up to professional standards. I certainly hope you will be sticking around with the JME community 
Do you by any chance know of the Blender to Java port project? It’s in active development, heading towards a 2.5 port, and I’ve been briefly in touch with the developer who also showed interest in JME. We might find a way to start a collaboration. I’m sure you are skillful enough to get involved should you be interested, so let me know
Thanks all.
I didn't know about the Blender to Java port, i think it's a great idea both for Blender and Java. I'll keep an eye on it when the source code will be released but right now I prefer to stay focused on this "unnamed-jupiter" i'm writing - just to see if it can be pushed to a decent state, in terms of practicality, functions and code (obviously open sourced).
Very nice, are you using SWT for that?
Thanks.
It’s a Swing GUI. This is how it looks with Nimbus look and feel:
nimbus.jpg
With nimbus it looks more clear because of the increased size in font and spaces, but the amount of components required made me choose a more compact look and feel.
For example, a single TextureUnit has about 34 editable values that the UI groups in 5 horizontal-paging containers and a few others boxed components. With Nimbus that part of the UI requires three page scrolls whereas substance stops at two.
It’s a hard and funny fight between the lack of space and the practicality.
pgi said:
Thanks.
It's a Swing GUI. This is how it looks with Nimbus look and feel:
nimbus.jpg
With nimbus it looks more clear because of the increased size in font and spaces, but the amount of components required made me choose a more compact look and feel.
For example, a single TextureUnit has about 34 editable values that the UI groups in 5 horizontal-paging containers and a few others boxed components. With Nimbus that part of the UI requires three page scrolls whereas substance stops at two.
It's a hard and funny fight between the lack of space and the practicality.
I think it looks excellent in a darker color tbh, definitely keeping my eye on this ;)
Hi pgi!
I know, you work alone :D, but still I must say we work pretty much on the same project (in my case Sandbox).
Therefore, I hope it's not that absurd to ask, if we work together?^^
Hi DarkPhoenixX,
I don't feel skilled enough with JME or the 3D in general to start a cooperation. I'm still exploring the framework and filling holes (lots of) in my knowledge.
Me too 
Well, it was an idea
Update n
Update n
looks really good…
Wow this is shaping up to be pretty impressive looking! It's odd, I had my mind stuck on '3D modeler' ala mini-Blender at first, but naturally, '3D environments' makes so much more sense as there's not even anything around for JME for that yet. We're sorta talking bare-bones Unreal Editor here then?
Are you familiar with the 'subtractive' and 'additive' methods commonly in use in the industry today?
If you can already disclose this app's license, please add that to your top post.
Thanks.
For industry standards, I'm a hobbyst so I must admit that addictive and subractive methods are absolutely new to me.
Honestly i don't know what kind of license to use. Something like "here's the code, here's the program, do whatever you want with it, change it, sell it, claim its yours, I do not care" will be perfect.
What I want to build is a program that relies on external applications for the creation of the "small blocks" like a cave door or a tree or a bridge section or an character with its animations and so on. The blocks will then be used to compose a more complex environment, applying a (hopefully) rich set of "dynamic" effects.
The output of Jupiter should be a dynamic 3d world with bells and whistles. Basically, if there is a JME test that shows an effect than that effect should be applicable to one or more parts of the environment that the user is building with Jupiter. Then that world should be loadable in a different JME+(JME Physics?) program with no jupiter-dependecies.
It's a long (long) term project.
For what you’re looking for, I would recommend the MIT license. If you’re putting your project up on google code you’ll find it there in the default listing. This license is compatible with JME’s ‘New BSD’, but with less confusion.
So it’s a long term project huh. Are you doing it all for yourself, or are you in it for a group, study project or such?
Finally, have you checked out Scene Worker yet? From what you have shown and told us so far, I for one can’t exactly tell whether your app has a different vision or not. If it so happens that you could achieve everything you’re aiming for by building off of what nymon and ncomp have created already, I would strongly urge you to attempt a collaboration with the two of them, as they are both highly competent developers and have always been open to contributions.
Looks -very- promising! When do you plan on releasing something, so we can play with it as well?
The editor looks very user friendly, and you're really productive so far
I think you concentrate too much on being able to edit jME class properties. Since your objective is to make a world editor, you should concentrate on the higher-level, such as terrain editing, texture splatting and entity placement, rather the low-level jME-tied concepts.
erlend_sh said:
For what you're looking for, I would recommend the ...
Thanks for the MIT license link. I like it very much, it's clean, simple, perfect for me. Top post updated.
I used SceneWorker and i think it's a good, proper, well written scene graph editor. I don't want something different in the final result but in the path to that result. And i like a lot to reinvent the wheel.
Thanks. I plan to release a preview in the second half of november. The only real "operative" problem the program has right now is in the drag and drop of files: in windows the datatrasfer is known to be a javaFileObjectList while in KDE, if I remember well, is a string with URI paths separated by a new line. I coded and tested the file list transfer, i have to code and test the uri strings trasfer (hoping it works in Solaris, Gnome an Mac).
Absolutely true. But i have a reason for that. I'm learning what a "specular" component of a material is using the interface i'm writing. Is it useful to be able to change it? I don't know. The same stands for every single property of every render state. I'm slowly realizing that some render states should probably not be parte of the standard UI (like Shade or Stipple) and some values could be omitted. My fear is that removing properties I think are irrelevant some kind of effect will be unreachable. It's a try-and-hope approach. It would be wise to stop and read some 3d graphics book but...well, i'm not wise.