Thanks.
snareoj2, the answer is “maybe”. You can find the source code here:
src.zip
The “logic” of each tool resides in a specific class of the “it.tukano.jupiter.tools” package. The tree builder is in the TreeBuilder class, the grass painter in the GrassPainter class and so on.
The problem is that the code is a real combat field, pure “chaos driven development”.
a really pretty tool.
why dont you host your tool on sourceforge.net than you could upload the app in use of SVN and everyone (like me :D) , who have interest in it could acces the newest code.
go on working on it. very good.
I have uploaded the project on kenai
http://kenai.com/projects/jupiter
Unfortunately the code isn’t really meant to be read. Sometimes I look at it and I ask myself: who wrote this sh###?
I have removed the project from kenai, uninstalled subversion and thrashed anything called “sub, svn or version” i found on my hd. For a second, I was tempted to set fire to my PC as well.
I have removed the project from kenai, uninstalled subversion and thrashed anything called "sub, svn or version" i found on my hd. For a second, I was tempted to set fire to my PC as well.
Too many bugs in that code, eh? Didn't want the infestation to spread? Oh well, at least you learned something from prototyping it :P
Just to say “still alive”.
Working on animations. Create skeleton, bind vertices, define key-frames, stuff like that.
Youtube refuses to accept videos (a bit weird since i haven’t changed the way i capture-encode them).
Not much to say. Here’s a screen of a model with a skeleton built with the “animate” tool
skeleton001.jpg
and a screen of the same model deformed by the skeleton
skeleton002.jpg
I have to find a way to interpolate between keyframes and pack everything in a replayable animation (i haven’t really understood the bindingmatrixquaternionslerp way of doing it).
VERY NICE!!!
You're doing some great stuff, glad to hear you're "still alive" 
Cool, cool, cool! I shall have to write a new blogpost on project showcase soon and include this. Think I'll also do a slight push in ways to approach 'featured projects / project portals', so I hope you'll have your say in that.
As for videos, go with Vimeo if youtube is giving you trouble. Vimeo looks better anyways 
incredible…just incredible…
Thanks.
Here’s a video of the tool in action:
vimeo video
Its a really cool tool. A mix of SceneWorker and this is how I imagine the scene explorer / builder for a jme3-gde.
The problem is between me and subversion: commit, update, things that doesn't commit… it was a brief but rather unpleaseant experience (my fault, i should read something about subversion before to start using it).
For bugs, the program itself started to become a giant bug long ago.
Well, it works.
vimeo video
There area couple of problems to solve. The test ends with an attempt to alter the skeleton while an animation is in progress (the animation really didn’t like it): just details.
The program uses what history will recognize as the most inefficient animation system ever seen (the one i built). It would be a lot wiser to use the anmation library that comes with JME but i need to do a couple of separated experiments to see how to map my cheap skeleton to the more advanced one available in jme.
Next challenge is painting. It is relatively easy to build structures with that cad like tool that joins lines in quads.
level sample
I should say relatively easy for me because the tool is tailored around my feelings but having difficulties modeling cubes i take myself as the absolute rookie in 3D content creation.
The hard stuff is painting. Creating render states and applying them to objects or groups of objects doesn’t really work: it’s too boring.
I think someway the user should be able to “drop” textures on surfaces, like painting with an image as stroke in gimp. The program should take care of texture coordinates, normals and things like that. Well, just random thoughts.
I like the painting idea, well if I understand what you mean by it anyhow. I think you should be able to do it by making a triangle's object's uv coordinates an exact copy of the triangle itself; just compute the distance between the points and you can create a triangle from that and have the programm distribute all the triangle's neatly next to each other on a plane. This will leave a mess of a UV-map to work with but if the painting is done in 3d the uv-map isn't required by the user. Deciding what points on the triangle should be colored or "elevated" (for bump maps, so you can paint surface details in 3d, think photoshop layer effects) can then be done through a form of raytracing.
But then again I'm not sure if that's what you meant…
It is still unclear to myself what I really want :D. I'm searching for an "easy" way to interactively apply one or more texture layers to a 3D surface. The first problem is "easy": it is a subjective metric. Of course everything boils down to planes, points, UV coordinates and so on but that isn't as important as the user experience.
The current way this program creates and applies render states can be taken as an example: i will not suggest to do it that way to my worst enemy. To apply a simple texture the user has to select the spatial, create a texture state, create a texture unit, drop an image into the unit ui, scroll down, set the magnification filter, set the minification filter. It's a nightmare because the goal is so simple: to splat an image on a thing i see here in the window.
In fact most of the program is not even decent from an HCI point of view. I think in 2010 one has to do much much better that this (yap, i'm re-starting from scratch :D).
That's perfectionist to you then seeing how UDK is hardly (read: not, but it comes with a few fancy textures) easier to use in that regard 
I think we were not talking the same though, I was thinking about a "program" to paint the texture directly onto a mesh instead of on a uv wireframe.
btw, just ran jupiter and - after seeing some of it's awesomeness - the 3d vierport froze when trying to set bilinear interpolation for my chewbacca texture. It went black after resizing, everything else still worked, is it a known issue or just me?
Edit: tried it again and no problems this time, bah.
Edit2: found the problem, I tried to make the cube water… silly me wanting a chewbacca cube made out of water…
The cube-water is a program fault, due to unimplemented checks. Strange things also happens if you try to use the undo-redo buttons (the undo-redo module hasn't been updated to keep track of later changes) and…well almost everywhere. I can pretty muich guarantee that the program will crash due to a NPE or some other easy fixable and mostly known problems.
I don't plan to fix it. I will use this version of the program as a tool-tester while i write the "jupiter - alternative take" version.
I see. Will it by any chance be made for jME3?
I think I'll use a pluggable engine interface this time.
pgi said:
I think I'll use a pluggable engine interface this time.
Now THAT would be cool ;)
Few preliminary tests with JME2, JME3, Java3D, Ardor3D and Xith3D showed that a pluggable engine is a piece of cake (at least if one doesn't worry about security)
I'll also switch from Java to Scala. (The technical reason behind this choice is: it's a very funny language)