Thanks for the comments.
For the script part the truth is that i didn’t considered other languages: i just wanted to allow the injection of mutations to the scene graph and I picked up the first option i saw available in the JRE (the JSR 199). Using other languages shouldn’t be a problem: it’s just a java interface to implement and with the mentioned JSR 223 there are tens of languages that can offer that implementation.
The source code will be available with the program. I uploaded a snapshot of jupiter:
Jupiter11062009.jar
READ CAREFULLY
I have not tested myself this particular version.
How it is supposed to work.
Requires: JRE 1.6+
Put the jar file in an empty directory, double click it or (better) run it from the console with java -jar Jupiter11062009.jar. No installation is required: the jar file will extract the program files in the directory where it lies and will start the program. The program doesn’t read or write files outside its directory and it doesn’t require network connections.
What i’m expecting is to see the program starting in Windows, Linux and Mac. If so, it’s a major win.
The program save-load doesn’t work because i didn’t updated it with the terrain, script and…well I don’t even remember what.
The source code is included in the jupiter.jar but it is not really worth looking at: suffices to say that what the program does well is because of JME and other third party libraries, what doesn’t work is because the code you will find in that jupiter.jar.
So the first big question is: if you type “java -jar Jupiter11062009.jar” in the console, can you see the program window (after a while and withouth a splashscreen in the meantime)? If not, what the console says?
11092009 Obsolete download has been removed.
Update.
Updated the IOModule to keep track of the changes. Fixed something here and there, added splash screen with a mascot (very important), finished the script UI:
jupiter11092009.jpg
Added the jme-export module: the program exports the data in a jar file, that jar file must be put in the jme program classpath. Loading the data looks like:
import com.jme.app.SimpleGame;
import com.jme.scene.*;
import com.jme.util.export.xml.XMLImporter;
public class JMELoadTest extends SimpleGame {
public static void main(String[] args) {
JMELoadTest test = new JMELoadTest();
test.setConfigShowMode(ConfigShowMode.AlwaysShow);
test.start();
}
protected void simpleInitGame() {
display.setTitle("Load Test");
try {
XMLImporter importer = XMLImporter.getInstance();
Node root = (Node) importer.load(JMELoadTest.class.getResourceAsStream("/data.xml"));
rootNode.attachChild(root);
} catch(Exception ex) {
ex.printStackTrace();
}
}
}
The script engine is embedded in a custom node and the few classes needed to create it are also exported in the jar file so everything works out of the box (or so it seems).
There are a billion things to fix but it starts to produce somenthing.
update. changed the terrain editor tool. Height editor is a bit more “dinamic” and texture splatting uses alpha interpolation with predefined strokes of different sizes.
test (youtube video)
I love what you're doing with this editor pgi. I'm sorry I have been unable to give any feedback these past days, there's just been no gaps for it what so ever. Keep at it with your own unconventional take on scene editing, this is most interesting!
You haven't done a single thing the same way I've seen it in industry applications so far, which I think is a very good thing as there are plenty of alternative conventions yet to be explored.
Thanks!
Update.
Added a module to associate properties to spatials.
property panel.png
Thanks to the clever Savable interface and the smart set/get UserData method of Spatial the same properties are accessible in the JME application that loads the “exported jar world”.
Next step is “drawing water”.
Man, this keeps getting cooler!
pgi said:
Next step is "drawing water".
I assume you're using what was built for jME2 for this task? I'd be curious to see how this turns out as the water settings can be a tough thing to make look quite as good as in the jmetest packages
Hey,…it looks really great. Actually I missed the moment when you provided an executable version. I would really like to see it in real life. Is there a way you could give a snapshot so I can have a look this weekend?
Nevetheless keep on with that promising work.
ToM
ttrocha, there is a link in the first page to the most recent build of the program, packed in a standalone self extracting jar file. I haven't tested it outside my pc but it should work.
I did some preliminary test with the water settings. The resistance of WaterRenderPass is fierce.
pgi said:
I did some preliminary test with the water settings. The resistance of WaterRenderPass is fierce.
It may be fierce, but as they say... resistance is futile. One helpful thing to remember with the water is that it looks very pale and empty without a reflection set up... There's no character to just "water" aside from some color. Try the settings you've been trying with some other objects populating the scene (you'd definitely want at least a skybox)
pgi, thx! I finally found the link! Good work! Really cool!
I like this tool a lot–definitely a ton of potential. My only complaint right now is that navigation is a bit difficult. Any way to integrate a grid (so you can see where the ground would be), the unit-vector arrows, or a different method of navigation?
Thanks for the review.
I think that navigation is currently a pain.
Sometimes I get lost and I start turning around the camera seeking for a direction.
The editor should have both grid and unit axes, with a menu button to enable-disable it.
It also need a way to speed up camera displacement - if the environment becomes rich enough jut navigating from one point to another one via camera movement is a pain.
I think i will add a 2D view in a dedicated tab to display a minimap of the environment: clicking on the map will move the camera in that place. The map could also be used to mark places with notes ad alike.
The tools that can move the camera (terrain editor, camera tool, builder tool) should show to the user via custom cursors the effect of clicking the mouse in different part of the 3d canvas.
The camera tool should have a control panel to display the current location and a couple of control to change the location of the camera to a known position.
The editor also lacks UI hints (tooltips and helps).
The good news is that adding some feature to the editor is just a matter of choosing what to add. In fact the development process of the editor is: "hey, this looks cool, lets slap it in!" and JME just handles it with no complains.
Suggestions and critiques are very welcome.
How exactly does movement work right now? I clicked on the camera, which apparently allowed me to move around, but then the movement was only done with right and left clicks and based on where I was on the screen? Is that correct?
Tooltips would be a great next step (especially since your system lacks documentation).
I do want to throw in another huge kudos. The lack of editors like these is exactly what separates JME from the more successful game engines. Guys like myself (University students) with no time or money but a passion for game making just can't afford to write our own in-house editors–I feel like that's the real stopper for many games.
Thank you so much for your huge contribution to the JME community.
Update.
Added the “minimap” module.
minimap test (youtube video)
It just shows the boundaries of the terrain and a token for each element in the scene, with some info, plus the camera location and direction on the xz plane. The camera can be moved clicking on the module screen.
I spent the past weeks trying to create a few 3D models to use in the scene editor. The use of modeling tools like blender or maya to create a simple textured room clearly requires a brain that is totally different from mine. So, after a lot of frustrating days, i created another tool for jupiter. I dubbed it “extrusion tool” but id doesn’t really extrude anything right now. It is just a very very schematic way to build geometries made of quads.
http://www.youtube.com/watch?v=KMolx3SR4rs
The tool has two operation modes. In skeletal mode the user draws construction lines. The skeleton is just a visual sketch for the user that lies in the background, a sort of guideline. The shape is built in “join opposite lines” mode. Like the name suggests, the user draws two lines and the tool simply joins them in a quad. The quads are textured, there a couple of buttons to change normals sign, the quads shares a set of render states and so on.
I’ve made some experiment with random tree generation and grass but the result is not particularily good:
treegenerator.jpg
grasspainter.jpg
I tested the program under linux (where it didn’t work due to a missing slash, now it doesn’t work but for a reason that i don’t know).
I was pleased to find out that with the right block size the default terrain system of JME handles very biglandscapes, it’s all about having some ram to spare.
In the meantime i started using jupiter to make the environment for a FPS. It’ a funny way to discover what is necessary, what is not, what’s too complicated and so on.
I don’t think this tool will ever reach a stable state, sooner or later i’ll probably start another one from scratch using what i learned doing this one.
Hi,
nice to see progress. Is your program written in a way that separate modules can be "carved" out? E.g. the Treegeneration, The Gridhandling or the Grasspainter?
Regards,
snare
Dude,…that just looks marvelous! Good to see it is still running…good job