[SOLVED] BinaryExporter and materials


#61

Hang on about the gltf. I just reran it with sdk and it seems that this model may be a test that was having problems with export.

Edit: This was a test model, sorry about that. Probably screwed up beyond repair.

So the gltf all looked good.

Are you planning on doing blends and ogre?


#62

Found another cool way to sync assets.

project.sync {
   from '../PathToProject/assets'
   into 'assets'
}

With this statement in gradle, everything works like the SDK. May be to much though if large project but liked how it does automate things with no effort.

If you convert a model in the external asset project, you don’t have to do anything special. Just write your add statement as normal in you current project.

rootNode.attachChild(assetManager.loadModel("Textures/Rocket.mesh.j3o"));

Sync will do everything before compile. All the task and buttons work like the SDK now where clean just cleans with the added benifit of synching, build will sync first and build so the distribution zip works. the run button, build and clean, and build will work as it should and you wont have to move any models first.

Adding runtime files() statement to dependencies will add the external files to the project but using sync to me feels cleaner and you do not have to change statements around between build types. Sweep in the files you want, the runtimeOnly project(’:assets’) dependency will take care of the rest using excludes.

If anyone finds a problem with this let me know, I am new to this gradle stuff, just been a few days now using it proper.


#63

Should clarify, sync will copy everything everytime from the “from” directory before it removes anything not copied into the “into” directory. I am not sure how this will affect large projects. With today’s computers it might not be a problem.

Still, I like how this gives a gradle project the same capabilities as sdk. Can convert the models in sdk, move things around and they will work or are working for me just like SDK.

If Paul does his project, it would make this moot if it were a gradle dependency but until then this may fill in the gap.


#64

Blend and ogre should already be there. “OGG” is for music, not ogre. The jme3-blender library is in the distribution with its dependencies.


#65

I’ve updated the release of JmeConvert with some changes.

  1. It now writes build version and memory info to the console when running.
  2. I configured max memory for the startup script… set to 4 gig. (I was trying to load an fbx that kept running of of heap but I think it’s a JME FBX loader bug.)
  3. Fixed an issue with shared textures where only the last one was having its key reset.

So far, I can load and convert every gltf file that I’ve tried from Sketchfab.

I’ve tried downloading the original versions of some of them but I haven’t found one that works yet for obj or fbx. I don’t know if the SDK would have loaded them or not as I don’t have that installed anywhere.

Maybe I should create a new thread for the converter since it’s starting to turn into something “Real”. I’m certainly having a lot of fun playing with it.

Edit: and to be honest, if it only ever works 100% fine with GLTF I’m kind of ok with that.


#66

SDK does load and convert objs. Not sure about fbx.


JmeConvert tool
#67

I’m sure you’re aware @pspeed but for the others, too, obj is a bog standard format. I read some of Paul Burke’s paper on it a while ago. I don’t think the api has changed for it since Jesus woke up in a cave.

He describes the spec as good as any other paper I’ve come across.

http://paulbourke.net/dataformats/obj/


#68

I’m not saying that I don’t support it. I’m saying that the few models I’ve tried from Sketchfab that were originally in OBJ format fail because the JME loader doesn’t like them.