[dead][middleware] Unnamed 0.0001 (beta)

Great to hear!

Keep up te good work!  :slight_smile:

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.

Yeah, but editing these kinds of options would be entirely unnecessary if they were properly exported from the modeling tool. A world editor is not responsible for editing materials or models, it is responsible for placing them in the world and adjusting their entity properties.
Momoko_Fan said:
A world editor is not responsible for editing materials or models(...)
Well, it comes down to the extent I suppose. If resizing and possibly making simple manipulations of materials are considered editing then yes, to a small extent they are responsible for it. I can think of many situations when I might need to stretch a couple faces and tweak some vertices in order to attain my desired level. The biggest concern for me being functionality, e.g. avoiding small steps that have to be jumped on to.

Update N


I’m “shaping” the terrain editor tool.

Terrainbuilder.avi Xvid, 6.88mb

What i have to do now is to extract a smooth surface from that axis aligned cube-soup. Suggestions on suitable algorithms are welcome. I’m trying with some edge analisys.

Wow, very interesting approach to terrain shaping, never seen anything quite like this before! After you're done with your squares shape, what happens next? Do they join into one mesh?

Right now it's all "in theory" because in practice what the tool does is all in the video.

When the boxes are set up i have to use them to create the terrain section that is edited. I think this could be done with some edge parsing magic (I'm still trying to figure out how to exactly do it).

After that the user will move to an adiacent section, extending the terrain in that direction using the same system.

Then I will find some way to join all the 3D sections of the terrain.

I think the "edge parsing magic" you're looking for is isosurfaces, also known as metaballs and scalar fields.

It works on the same concept, except you get actual shapes instead of squares.  :slight_smile:

There's a scalar field triangulator in jME2, that uses the marching tetrahedrons algorithm, it is available in the package jmetest.scalarfields.

The metaball demo looks great. Painting the terrain extending a "blob-like" mass would look very cool. It's something i will look at in the future.

Creating the terrain section from the box was relatively easy. After trashing all the edge-connection idea i simply check for each cube if its faces have another cube in front: if it's "free" then i slap it as a quad in the mesh.

The resulting geometry is not a shining example of efficency, optimizing it is another entry in an infinite to-do list.

I didn’t find a solution to the smoothing problem yet but it turned out that the box-terrain editor is a very funny way to build assets. Here’s a fast-test video:

Test004.avi XVid 14.3mb

The panel on the right side is just a sketch of the UI for the tool.

Could you upload the new videos to Youtube?

It is just a bit more comfortable.


Still exploring the “terrain” builder tool that now is no more a “terrain builder” but a general “assets painter”

“Terrain” builder, test (youtube video)

It’s like drawing tiles in 2D, the only difference is that here tiles are 3D objects. The geometries are merged when the user presses the “make mesh” button.

I didn’t show the imported-models part of the program yet but that is just because i suck so much in 3D modeling that i have nothing to import. Handling importer models works exactly the same as using primitive boxes: import, copy, paste, cut, transalte, set appearance and so on, all the same. There is still no support for animated models, somenthing that i plan to add when i’ll introduce the node editing and the scripting interface (in 2039 or so).

No luck with the terrain section creation (for now).


Inserted a separate tool for terrain editing. Plain old “2d” terrain.

Terrain Editor Tool, test 6


…and basic terrain painting.

test 007, (Youtube)

I just added interactive alpha masks to the texture splatter demo. Unfortunately the splatted tiles hide shadows casted on the terrain.


+Script framework (script language: Java). I have to desing some kind of visual script editing. For now there is just the java-coding UI.

scripttest (YouTube)

1010 visits and 16 replies.

Say something!  :smiley:

I appreciate critiques and suggestions.


pgi said:

1010 visits and 16 replies.

Say something!  :D

I appreciate critiques and suggestions.


I like the idea of scripts, but why not use a GOOD scripting language (which I dont think java is) like Python...that would be awesome.
Btw, will there be a download available at one time ?

Looks really nice, i must say :smiley:

But switch to Python as scripting language!

I don't think it will be hard, since JSR 223 and Jython are availabe.

So you have a complete Binding mechanism and Interpreting mechanism,

for compile-time known scripts you could even compile them to Java Byte Code.

You could also have a look at JME Game Console with it's BeanShell support.

All in all, well done!

Will you release the source code? It would be very helpful!

I'm just speechless in what speed your Jupiter is growing and growing! Really amazing and I can't wait to try it out when you release something.

Great job…

Whops. I forgot to include the osx dynamic libraries (thanks ant!) so the program shouldn't work on Mac.