ScalarField JME3 porting


I will try to port the ScalarField polygonizator metaballs code to JME3, I need this on my application.

I wonder if someone has already worked on this?

EDIT 30/8: mmm… I got a flu, I attached the current sources that work with JME3, it has a clear visual bug that can be seen at MeshBugged.png, I have no idea yet what went wrong… any tips? Ugh… the code is already optimized, cool :).

EDIT 29/8: ok, it is now working but seems very bugged, the mesh has some weird triangles, not sure what happened…; if someone wants to test and help to fix, I will post the changes I made; I updated everything to make to work with JME3;

Seems you've been making some progress since you first posted. We have no problem whatsoever with some thread-bumping around here you know, so long as there's news in some way or another. Only the forum-addicted beyond saving will notice updates like these, eherm…

Looking…, interesting! ;D

Hi Erlend!

Yep, was it, I didnt want to bump my own thread :smiley:

Anyway the ideas are still maturing in my mind…

Despite I made it run on jme3, I played a bit with it and didnt like the results in case of you set too low weight to the metaballs, the mesh gets weird…; also if they are too near (several lined up), the mesh seems to inflate like a bread :D… well that is not what I am looking for. May be a slime in the game could use it up tho :slight_smile:

I think on DMM (digital molecular matter), but I must think realistically, it is not available and is just a vapor promise by now afaik…, in java even least… damn :frowning:

Back again I think on boolean operations, the most precise way to "cut" a 3d object. I think may be I should spend time on it with jme3; but I must be sure its changes will cope with physics collision in a fast way. So, the collision shape (right?) should be updated together with the mesh; think on a big terrain, where a spot was shot/cut, the entire mesh/collision shall not be updated, just that spot.

Another way would be to code something to dress a matrix of cubes with a surface mesh (not exactly the cube edges, but joining its centers, too look good with bumpmaps etc…), but it would require a big mass of cubes data, and if the cubes are too big it wont look good I think. And the very matrix idea pushes me to a imprecise world. It is not what I would like for a long term "lone" project development… (btw DMM seems to be some kind of deformable pyramidal matrix per model as far it seemed at the videos I saw…)

I must search more and find out what is already implemented. Or wait to see in what I will believe as the right path to follow :D.

PS.: the idea behind all this is a fully destructible world, that wont take ages to implement :>

Right now I am very inclined to the boolean operations; I will study the collision shapes as soon I can to see its capabilities :slight_smile: