There are Giant Androids in the City !
It appears that the process has gotten more simple, and it might not be necessary to use jmonkey sdk when converting the pretty common blender format files into j3o format.  Many 3D image warehouses 

Find a toy, download it to the special directory, and virtual inmoov will have something new to play with ... that is the goal ...

Its been fun playing email tag with Gael .. we are trying to figure out a easy, maintainable process of going from   Gael's Brain --to--> Blender --to--> JMonkey SDK --to-->  MRL  

Maybe even have a python script that does it in one shot (not sure about Gael's brain...)

I had a several issues with the latest InMoov_V6 .. specifically InMoov is too small and the bounding box is borked in the assets/scene/InMoov2.j3o  (so this is unusable by me) ... however .. the "parts" in the assets/model directory might just be perfect ! The bounding boxes on them look good, and I didn't know they would be in all the correct places when they loaded !!  YAY !

In fact I think going from the parts to the single InMoov2.j3o file is an extra step we dont need in the 3D-pipeline.

I'll work with these model files for a while and see how things go ... Right now InMoov is HUGE .. (the green cube is 1m x 1m x 1m.  Which I think makes InMoov about ~40 feet tall, but I also think it perferable to have a set of files, and I can scale all these parts in one line in MRL.  Also, having individual parts makes it easier for substituions - e.g. if i want to drop in a replacement head ..

Time to see if I can bind all the parts together and shrink mrl to 1.8 meters...

More work on the menu system, seeing what Lemur UX has to offer.  Tabs are always a nice to have. 

 

 

 

Gael figured out a excellent process to get virtual InMoov to MRL (or for that matter, any blender file)
Looking very worky now.  I used a simple single j3o from Gael, vs the many files which needed to be repositioned in a downstream application (JMonkey SDK or MRL).  Oop .. I guess were still missing that pesky right hand :D

You can see things being selected by the mouse too ...
The VinMoov > KinectMidBackV1.001 > homoplatetopV2-1.02364 
is a path in the scene graph of the last thing touched by right clicking the mouse.  It's done through ray-casting and lots of matrix math ... fortunately JMonkey handles nearly all of those details.
The slick "glass" menu is courtesy of pspeed from JMonkey. It has the ability to show itself in fullscreen mode (although I haven't got that part fully worky yet)

The nav button I was thinking of putting it in "navigation mode" - vs other modes.
I think there should be a navigation mode, and a way of selecting things, and a way of dropping things :)
This are basic necessities to mess around with inmoov and play "Hide the Beer"

Walls will soon be going up, and then kinect data, etc ...
To navigate through this 3d world on a 2d computer screen we need some nice controls..

If you have some ideas let me know :

Sim Control

Ahahaha .. the Blender keys :D

The two files Gael sent me VInMoov.j3o (full body) and TestHead.j3o - both loaded fine..  The head has a good bounding box...  Vishnu VinMoov !  (nee more arms !)

But the bounding box of VinMoov is HUGE .. I think maybe his hand and few other pieces have flown off and that's what makes it so big

Yay - we have a framework now for our JMonkey service.  The display which JME uses is different than a "normal" display - so its necessary.  Swing won't work on it, but pspeed from JMonkey created Lemur UX a system similar to Swing but capable of displaying on the JME Screen.  I've been looking for something like this for a while.  Initially I looked at a project called "Nifty Gui" - but found that very cumbersome and bloated.  Its purpose was to make GUIs from xml files, which is not necessary for our use case.

What I want to do is have TextBoxes where you can search for parts - similar to blender, and they will become selected.  I want at least "some" capability of doing scene composition in MRL. Then maybe I can get that floating hand glued back together ;)

https://github.com/jMonkeyEngine-Contributions/Lemur

Humpty Dumpty Not So Bad

This is InMoov with "cleaned" j3o files .. i was afraid i was going to lose a lot of positioning information (imagine InMoov exploded) but its not nearly as bad as I thought it was going to be.

Also all the files can be dynamically loaded and there is no hardcoded positioning or reference  information in MRL anymore (worke-branch)  ... meaning anything potentially can be put in, just need to drop the image files on the file system.

Heh, looks like I forgot to scale his top torso, and now he lives in it ! .. Interesting room .. very modern ;)

Ouch - Broken Virtual Legs

Gael kindly sent me a blender file of InMoov's legs, which I imported into JME .... Ouch !  The import process sent many errors and as you can see lots of stuff dropped on the floor.  The import process was not nice, it broke his leg !

I'm sure if I spend some time I can figure out what the problem was ...  here are some of the errors ..

 Ooooh Noooo .. Out of memory ... we can't figure out how the legs go together ;)

Minimally, I'll need to split up some of the parts in blender and save them as units togethe, but I got more coding to do before ....

Bounding Box Worky

I'm working on a "selection navigation" where you can navigate & select different objects in mrl's JMonkey service.  The selected object is highlited by its bounding box, which also will become important in collisions.
Previously I was having problems with the bounding boxes and extra nodes, but now when you add nodes together, the bounding box correctly surrounds all "bound" nodes.  

Here, i01.torso.lowStom, i01.torso.midStom and i01.torso.topStom are attached, and the bounding box correctly expands.

Noobie Adventures into JMonkey Scene Composer

 
 

First I have to say I really appreciate Calamity's work on positioning and putting together the first virtual InMoov.  It obviously was a lot of work.

Recently, I wanted to work with JMonkey SDK editor and scene composer, but was thwarted by OpenGL errors on my main computer.  I came to the realization, it does not work on my main computer because I've downloaded the "latest"" NVidia drivers to support the Occulus Rift (DOH!)

However, I have gotten the scene composer to work on a different puter, and I'm just beginning to learn what you can do with it.  I'm interested in making a pipeline from blender or online 3d model wharehouses, so we can start populating our virtual world for virtual inmoov.

One of the first things I noticed was the InMoov objs (Jmonkey Object Files) are HUGE !  (huge if your world unit is 1 meter).  I tried dynamically scaling InMoov in MRL's JMonkey service (that was a mistake - crazy weird behavior was the result - e.g. parts disapearing, bounding boxes not working, and all sorts of other mishaps).  

So, I thought I'd re-scale everything in JMonkey's Scene Composer (make sure you have a mouse with a mouse wheel).

In JMonkey there are only two main things Nodes & Geometries.

Nodes - are the universal buckets.  You can stick Geometries into them or even other Nodes.  You manipulate a node and you effect all its children.  Its an all purpose handle.

Geometries - are thingies that display stuff.  You can manipulate them directly in a lot of the same ways as Nodes, but they don't have children.

Above I opened mtorso.obj.  

It contains : 4 chained nodes (scene node, Object.006, Object.006-entity, Object.006-ogremesh), 3 geometries (White_0.001, White.002, Black.002), a Lamp, Camera and PointLight

We don't need all these things, in fact the chained nodes can cause some confusion, because each can have its own scaling, rotation, or transformation.  And you can get lost or confused following the chain.

This mtorso has an embedded rotation. You can see the axis flip when I highlight a different node in the chain.

DELETE THE EXTRA STUFF !!

Now there is only 1 Node, and 3 Geometries.   The node that had -90 degrees rotation has been deleted, and it has been rescaled to 1 world unit = 1 meter ... goodtimes :)

calamity

5 years 10 months ago

lol, I did not even realized they was so much stuff in those file. I was a newbie at both blender and jmonkey

Those thingy came probably from where I got the part (gareth virtual inMoov). I delete all what I think was not needed, but look like some remain

So in blender, I separated the part (they where all in the same file) and adjust the origin of each part to be at the rotation point of the part. I did not change the scale of anything.

In jmonkey SDK I add materials because it did not render well without it (or maybe I miss something how to do it).

Look like vInMoov is getting better... great work Grog

 

Hi Calamity,

Did you or Gareth do the slicing and positioning of the objects?  If you did, could you describe what applications and how it was done ?

Thanks !

hairygael

5 years 10 months ago

Hello Greg,
I hope you are having a nice 2019 startup!
Great work in JMonkey!
I did a Blender file for your need with the legs which I have sent by email.
There is no rigging, it's been ages I didn't do that and I sincerely totally forgot how to do it.
 
I added the "butt" and "front" which are unreleased files.
We could maybe add the "rollNeck" tilting side way which could be good for future gestures?
 
Let me know if that is okay for you and if you need anything else, just let me know.
 

WOOHOO !

There are lots of possibilities from our friends at the open source JMonkey project.

Thanks Gael, sounds great..
Rigging is not necessary, as jme has its own rigging joint physics system, so nothing describing rigging, joints, or physics is needed from blender.

It looks like someone contributed a new physics wrapper to jmonkey too - https://bintray.com/stephengold/jme3utilities/Minie 

Ya its pretty easy to add more joints or pivot points in jmonkey, I just need to know "where" and in what axis it moves.

Well these legs are the non motorized version.

So no axis to actuate at this stage. Unless you prefer to already set them now, I can provide with those informations.

I downloaded in installed jMonkey for to have a look at how it works, lots of things to learn and discover!!

Hello Greg,
I modified the Blender leg file in order to apply location and rotation to all files, maybe that was the issue you had during the import into JME.
Let me know if that works better for you. Beware that the file has exactly the same name than the previous.
Sent by email.

Heehee ...

now right leg damaged ;)

I could not go directly from .blend convert to j3o in jme ... jme would lockup and die.

I had to use blender and go .blend -> wavefront .obj -> jme -> .j3o
(looks like he broke his right leg in that process)

I'm going to pause on trying to solve the legs problem until I get the "new" virtual InMoov top half re-assembled with the cleaned j3o files ... then I'll come back to this problem 

Hi Grog, 

 

I used a bounding box concept in BioMight that I would like to share.  Add Lego connectors at points on the boxes.  These are the connectors that allow components to pass through the 3D bounding space.  Now pick one connector on one side of the box, and a connector on the other side, for instance, connecting Shin and Thigh, you know femoral artery comes into top and bottom of both structures. 

The connector 'lego' point are the source and destination.  Now you can write routines that randomize that path and create all possible paths (to a given limit).  This way your bounding boxes can become connected and hierarchial - bounded boxes that can be summed.  Not directly applicable, but a nice trick I use.  Uding this method, BioMight can dynamically generate the pathway and collision detection of any bioplogical structure.

Ahoy SurferJim !

I'm working with JMonkey and utilizing a lot of their hard work - in some cases you have to play by their rules.  But it seems their rules are similar to what your describing.  

You might be interested in reading up on JMonkey docs or better yet trying out the JMonkey SDK.

This I know :

JMonkey has a Scene graph - and it is hierarchial

https://wiki.jmonkeyengine.org/jme3/the_scene_graph.html#scene-graph-an…;

everything connects to the root node.

Graphical stuff is in Geometries - but these are attached to nodes.
A bounding box of a node is the combination of all bounding boxes of children nodes & geometries (very cool)

I suspect that collisions are optimized first to the highest node - e.g. I have two InMoovs and their big boxes - do they collide ? If yes find out where ... 1st inmoov left arm bounding box with 2nd inmoov right leg ... its Twister !

 

 

Okay I got myself a bit into JME and found some interesting things regarding behavior with the Blender files.
The complete Blender for the legs was too heavy for the CG memory.
Then I rebuild some new files via appending in Blender and made some seperated parts for each legs and the top of the legs.
I also reset all locations and rotations. Clean up the meshes that were inverted once imported into JME.
I can now import the models into JME without getting errors, so I guess you should get the same result.
The only thing you will need to do, is to define the scale. Blender by default has no scale applied.
So if you work with centimeters or with inchs it will give something different once exported.
5 Blender files in total sent by email.
 
I hope this helps.
Regarding the complete top, there is a lot of work to get the same than for the legs because there is a totol of 290 parts to clean up and check if they are not inside out or being not correctly triangulated. (This functions, I normally do it on each stl with another software, to make the parts clean for 3D printing)
 
Results that I have now in JME:

Hey Cool Gael !

Your now the new resident guru of JMonkey :D

I'm glad you took to it so quickly.

For scale, I suspect Blender & JMonkey both have "world units" which is an abstraction - and you can say it's "anything", mm, inches, feet, miles, light-years...

JMonkey, however, has a physics engine which expects 1 world unit = 1 meter, and the unit I have seen imported into JME from Blender is on the order of 1 JME roughly unit = 400 Blender units if we think InMoov physically is around 1.8 m.

My pipeline has been :

  • "hope" 1 j3o file corresponds for a degree of freedom ... I don't need more j3o files than I have "movable" thingies 
  • Clean all the excess nodes, cameras, lights out of the file
  • In the single node make sure localRotation is [0, 0, 0] (localTranslation has so far always been [0,0,0]
  • Name the file and the node for the most dominant servo .. e.g. i01.head.rothead.j3o - In JME we can add more nodes for more servos and degrees of freedom .. but you got to start somewhere
  • Within the single node - I have to set scale to 1/400th or [0.0025,0.0025,0.0025]

I've done this with all files that were references in the current virtual inmoov - and uploaded them to google drive here .

The work I hope to do soon, is change MRL's JME Service so that all inmoov files can be dropped in a single folder called i01 and all initial position, translation, rotation and even re-scaling can be done in an easy to edit json file i01/i01.json .   If I do this correctly, I can see where people (like kyle.clinton) can drop their own head replacing i01.head.rothead.j3o with their own head and adjusting the i01.json slightly if necessary.  

Also nothing will be "hard coded" in MRL's JME - mappings, and keys, and associations between servos and files will all be dynamic - so my InMoov will have a worke-wheelchair base, and the differences will only be in j3o files and that json file (outside of Java land)
 

I still need to figure many things...

The positionning and manipulation parts is not very clear to me and is very challenging for to align parts correctly.

You say: In the single node make sure localRotation is [0, 0, 0] (localTranslation has so far always been [0,0,0]

But I wonder how this is possible when you need to rotate the part and move itto be aligned...

So I have added the legs to see if  I could get that done.

Also the bounding boxes are not rotated correctly for now, well a lot to discover yet...

 

I like the idea that parts can be changed via json j3o, it s definitely necessary for possible improvments and modifications.

 

Aye, new things for sure !

But I wonder how this is possible when you need to rotate the part and move itto be aligned...

The json file will provide the data, but yes, I don't know the best tool to align it visually and get the data for the json file.  That's why I was asking Calamity, but Gareth might have done this too .. not sure.

There are so many export/import paths too :P

well, the tool I used is called trial and error... I did not found any other tool

 

but the placement was close to the real measurement, so it was mostly sjusting things so it look visually the right way

I'm guessing you did this in jmonkey sdk scene composer ?

What was your input - blender files from Gareth ?  Did he do the original slicing and dicing of body parts ?

make everyting visible (a lot of parts a set as not visible

select the part you want

invert the selection

delete

only the part you want should remain

I think I export it using OgreXml

But all seem far away, I'm not sure I remember everything

It sounds like the rotation/translation axis/origin of "some" parts have been lost in translation.

From what I remember from the original ViMoov it was quite a job to set up rotation axis and exact pivot point for each part.

Caution :- Blender "UP" axis is Z  orientated  (many other systems use Y axis as "UP")

This can be one reason for rotational errors.

For traslation errors i.e. Jaw is translated 5cm left .. It can be that the rotation axis works correctly but the position of it is skewed left or right .

If you send/link me to the "current" working model I can check to see if this is the case.

It may be possible to optimise the model (Split up)  further to reduce "The number of Triangles!!!" and speed things up a tad and reduce memory overloads.

To my knowledge JMonkey does not accept nor understand the pivot points in Blender.  
JMonkey has its own linkage system.  You might want to download the JMonkey SDK on your new fast computer ;)  - http://jmonkeyengine.org

We had a Blender service a long time ago ... the reason why JMonkey is a better choice for us is its all written in Java which means we have more control with fewer challenges, and it was desgned from the beginning to be a "Game Engine"  .. and we want to play games with InMoov's head !

I'll be focused on trying to make MRL's JMonkey service an interface to a robot's consciousness - a place were we can examine what it "thinks" its current surroundings are, and its current contextual state information.  For example, I have the beginning of it accepting Kinect point clouds realtime, so at some point it can build the 3d imagery around it in its consciousness and begin to interact with it, by playing simulations and acting on them.

I'm calling for all the Blender & JMonkey Gurus to come up with a smooth process to get stuff from Blender to JMonkey.  Currently, I've found out that the import process Calamity used adds a whole bunch of nodes that should be cleaned out. (Too many nodes creates hidden rotations & translations - and it gets crazy to maintain).  For positioning, I we can't use Blender, however, we can use JMonkeySDK and/or MRL.  I don't know exactly how to position Node axis in JMonkeySDK (but will have to learn).  In MRL I know how to move and rotate the pieces and add new Nodes & Geometries.  

I'm also curious of what kind of interface makes it "easier" to position parts.  Blender has a way of navigating  in 3D and JMonkey has a slightly different way.  They both have ways of manipulating axis.  Which is better, should MRL behave the same way ?  What would be the "best" way to move things ?

With the new Lemur UX functionality I will minimally be able to report x,y,z yaw, pitch & roll - but now I can add more stuffs like controls.  What controls in Blender work well ? What don't ? 

Have the Jmonkey sdk up and running ... quick tests workio... elves are RTFM.

Recommend import/export for Jmonkey is blender with the "Ogre" add on...

The Ogre addon works with latest 2.79b Blender (not yet with 2.80 beta, or any version below 2.75).

Currently experimenting with gaels models....

.... exciting first glance of the documentation ...it looks like "Ogre" will import blenders skeleton as well..

This might be a very useful link from Gael - 

Regarding the top half, I need to clean up my files before sending it because it has a 7 year's mess... 
Lots of modifcations above each other which you do not need. Also many parts aren't mirrored, so this needs to be done before sending them.
On the other hand, If you have Sketchup, maybe you could use the assembly of my STL to import them into Blender.
That might save some time for us, but if you cannot work it out this way, let me know.
 
I'll start looking to see if I can import stls into jmonkey sdk ... the end goal is to get everything into j3o file format (native jmonkey) - and to proficiently align and set axis there ..

Hello Greg,
I have completed the VinMoov in JM3.
All rotations are (0.0,0.0,0.0)
All ocations are (0.0,0.0,0.0)
Colors are added.
Angles of parts are ready all at their "rest" positions, but you need to do the definitions of axis rotations, I didn't get the time to learn that yet.
Attached is the complete robot, sent by email in JM3 format.
If you rather get the Blender files of each part, let me know.
I have decimated to a point, that the surfaces are starting to really show the triangles. The VinMoov done by Calamity was about 120Mo without legs, the VinMoov_V2 is 64Mo with legs.
Hopefully this is good enough.
The main issue is that parts are compiled together, for exemple the torso represents many parts together which have surfaces that touch or intricates each other, therefore we get double triangles that are not necessary. But in order to remove those triangles it represents days and days of work because I do not know any software that can do it automatically. Maybe via retopology?
 
Anyway, here is an exemple of how it should be done to get something clean with a high reduce of triangles:

We have three cubes that are next to each other:

 

In this image it represents the surfaces that are touching and overlaping, which should be removed:

 

This is how it should look to be clean and it would remove two extra faces:

 

 

 

Blenders "Remesh"  is one way to remove these manifold irregularities.

Manifold errors can lead to all sorts of unexpected problems, particulaly during the slice_ing process for 3D printing.... many odd things have happened to me.

 

If you are not sure if your model has Manifold errors in Blender :-

Select object and go into edit mode , use either vertex or edge select and  deselect every vertex shortcut "a" once or twice generally does the trick

...then with the shortcut  "ctrl shift  alt m"   to select the manifold error checking routine... and Bingo all the errors are highlighted on the object.

 

Manifold errors in my opinion should be removed before decimation/triangulation/subdivision.

 

This is one way to get ride of those extra bits inside gael..... yes it does increase the vertex/edge count however decimation can be done after this stage.

In the graphic below I have only removed the front faces off the object so you can see the clean result inside using this approach.

 

GroG

5 years 10 months ago

Downloaded  & unzipped contents into JMonkey SDK assets directory, open scene, right click scene/VinMoov.j3o .. Booya !

Worky ! (at least in JMonkey SDK ;)

I can see the tree you created - and also the re-scaling is one node below the Scene Root.

So this is exciting.. Let's see what MRL will do .....
I just drop the VinMoov.j3o (and no other files) in the correct mrl directory and

BOOYA !!! 

That was easy .. (actually was about to cry with chasing the whole lost children node thing)
OMG - this is a huge load off ... I don't have to turn MRL into an object editor !  Yay .. Thank You !

 

@Gareth,

Thanks very much for your input!

I already use a lot the function crtl+shift+alt +m in Blender in order to have a clean 3D files ready for 3D printing during the concept of InMoov. There is even an extra addon dedicated for 3D printing which can detect even better some more errors for your mesh.

But in game engines it is not an issue to have meshes that intersect, the only problem is the extra vertices that are totally unnecessary.

Anyway, i found a reasonable process to decimate even though the parts intersect.

@Greg,

I have sent you a new version which contains both hands with the possibility of actuation ready positioned for VinMoov with all agles and rotations.

-All bounding boxes are worky

-All sub directories ready and renamed, both in the blender file and in the j3o file.

 

-All angles and rotations for each finger is also done.

 

Now maybe I could do the eyes to be able to move as well, that could be nice for VinMoov tracking...Mmmh we would need a virtual camera in his eye for to see what InMoov sees in his virtual environment!!

UPDATE:

Okay I added each eyes for independant movement for those who build a seperate servo for each eye to look like Marty Feldman.

 

 

This is from running mrl as a jar and dropping the latest InMoov2.j3o from Gael in the 
{mrl install dir{/data/JMonkeyEngine/assets/Models

I'll start documenting how to fly around and select things and what butotns are worky so people can begin checking it out ...