Improving Blender -> Jme Workflow

Contribution Depot
1

Available at: GitHub - TehLeo/JmeAssetImporter: A tool to automatically import assets from blender to jME

Current Workflow Outline:
Imagine you are making a game with a lot of models. To import them them to jme:

  • you create a separate blend file for each
  • convert each of those files to j3o
  • [if the models use custom materials] set material either in code or in editor for each object
  • you repeat the above process when you make changes to your original blend file

There are two workflow concerns with this:

  • lot of actions required to import a model
  • each different models requires separate blend file

Solution Idea

My idea is to create a simple text file that will contain what to import to jme automatically. See the below code as an example of such file.

global {
    in-path: "/media/leo/Kaiba/data/Codename Violet/Env"
    out-path: "/media/leo/Kaiba/workspaces/craft/Codename Violet/assets/Models"
    out-texture-path: "/media/leo/Kaiba/workspaces/craft/Codename Violet/assets/Textures"
    copy-texture: true
}
flowers {
    in-blend: assetimporttest.blend 
    out-j3o: [ 
               ["Blue Flower" "flower1.j3o" ]
               ["Pink Flower" "flower2.j3o"]
               ["Yellow Flower" "flower3.j3o"]
             ]
}
trees {
    in-blend: assetimporttest2.blend 
    out-j3o: [ 
               ["Willow" "tree1.j3o" ]
               ["Oak" "tree2.j3o"]
             ]
}

The above file first defines where to look for blend files, then where to create j3o files and texture files. Then, for each different blend file, multiple objects can be exported into j3o files.

One thing that is not present in the above example, is setting a custom material for imported object.

I am writing this to possibly receive feedback and any ideas you might have in regards with this. If you have any ideas what would be good if this accomplished, or how do you imagine the syntax of setting a material look like, feel free to share.

Currently I am implementing a tool that will do this job, as it will save me a lot of time when creating a game with plenty of assets. I also believe this will be useful to many of you, mostly if you are dealing with plenty of assets.

3 Likes
2

Nice try but what if I have Project folders in sub-folder of each model? :stuck_out_tongue:
Unusable for me but its great idea anyway.

3

I use such a tool for my builds, however it is greatly specialized to my specific workflow. E.g magic names in blender nodes ect. Also it does convert all textures to dds. I’m not sure a generic one size fits all solution is possible, but would be interested in exchanging ideas.

I would prefer a convention over configuration approach:
E.g without anything in that file it will do a strictly specified behaviour with fixe din out names, scanniing for file ect.
Then you can override any part of that if necessary, as if the convention is choosen sensible, most static simple models should not not any specific entry.

4

Thank you for your feedback.

@winhelp Could you explain by what you meant by having Project folders in sub-solders of each model? A model is a file, it cannot have sub-folders. Do you mean your project file is next to model file?

@Empire_Phoenix Yes, I am planning to make a generic tool. The texture conversion function is a good idea. In the end I can always let one property specify an interface a user can implement to preform the specific task optionally.

5

If we go one step further, I would probably say take a good look at the gradle build system.
All of what you want can probably be done with a plugin for it, and would allow a great integration into a pipeline, while maintaining a lot of power and customisability.

6

7

@winhelp I see your file structure, I think there is no problem with the tool to handle that.

The first version of the tool is online. :chimpanzee_amused:

Whoever would like, can check it out here, and leave feedback later.

1 Like
8

One thing I find a bit odd is why you would want multiple assets in one blender file for several j3os, why not 1:1?

Actually I was thinking about similar concerns: Most Scenes re-use the same models over and over, blender can link it models for that, I don’t know about jme. I think you can’t change the base file and have it apply to all the childs automatically. And then you can even have some copies in blender of that linked object which you modify which is unchangeable as well.

How to the pros handle that? Because: A) Maintainability and B) Categorized batching and C) Far less Diskspace usage, when only linking objects.

So my concern is actually the opposite of yours, how can I re-assemble something out of multiple j3os :stuck_out_tongue: But it might be similar: The logic which you use to spread the files in combination with some .jsons which actually assemble those to the map again.
On the other hand that might be a bit obfuscation.

I don’t know what you want to do about the material though since you can only export the material files from the j3o, but how do you handle overwrites? But then: You might only want such a Material if you change something the importer does wrong.

9

It’s workflow! Imagine you are making lot of assets for a game. Many of these are very similar and it makes no sense to have separate blend files for them. Let’s say I have five types of flowers. In blender I can model flowers, and grass and see how they look together. If I had separate files for each flower and grass, it would take more time to do changes to these, and then I would also need another blend file to see how those objects look together.

Yes, in jME you have eg. AssetLinkNode, which loads the model from pointed base file.

Let’s say I have a grass, and I write custom shader and material in jme3 which animates the grass. Is there a way for the jME blender importer to use a custom material for your grass object?
If no, then this tool will also need to support that as well. Since if I will be frequently modifying assets in blender, I do not want to be manually setting the material each time. I’ll do it just once for each object in the property file.

1 Like
10

Hi there,

May this advise change the way you think about the assets importing problem. Or not :slight_smile: … but I tell you, there is another way around.

Import and export is a headache, especially when you working with a lot of tools and imcompatible formats. The ugly truth is you can not have an universal way to beat this puzzle. I’ve work as the engineer for Gameloft specialize in tools, mostly in import/export and compress. We did convert a lot of things from Maya, max, blender, c4d… various kind of textures to varioys in-house format, compress, encoded configurations… you know that kind of job.

So what I learn is, (wait for it)… The workflow should be very, very, very, very simple but …expandable. You may ask WTF is this kind of confusing riddle I raised here. For example Blender to jME as concerned here, what I did is to create Hooks (function that ready for extend)and Pipes (sequence or parallel convertions methods). That’s the key.

In my Blender importer (my version is different from one of @Keathas), I create a lot of hooks, hooks when the blender file reader touch a Mesh, a Texture, a Node, a Shader, a Contraint… So the importer take a configuration file (like the one you have here) and work like an irterator over interested nodes. The hook will be process through a filter (a condition) to see if its need futher process, for example: we only want to import the floor object. Then the data pushed into the MeshReader for example to procedure a jME Geometry and saved it into ConversionResult (in memory). The pipe can be continue as I let the jME spatial be saved into a file in a folder, ziped it, push to git or Drive… The whole system need an Assets server which may be run from the jME SDK, but also can be run from gradle or maven because it’s actually a jar. More amazing our team managed to integrate also Nodejs stuff to convert and push packages online, procedure an delta for Mobile device to download lastest version. And do it automaticly with Jenkin :slight_smile:

So what you doing here is called a Scriptable Asset Server. You can use Gradle as the Scriptable part and should write another Blender importer (like i do, its pretty simple) with hooks.

You can also wait for me to release the AtomAssets workflow (again), which actually opensourced in the past but then removed because we trying to do commercial thing with it but un successfully :slight_smile:

Cheers,

2 Likes
11

You can also check this library:
http://homac.cakelab.org/projects/JavaBlend/index.html

It used generic approach that will work with what ever version of Blender, not connected to jME3 yet of course.

You can use it to get the raw data of Blender and use it somewhere later :slight_smile: Small tip: That’s what I do in my importer.

1 Like
12

@atomixnmc Thank you for your informative post. From what you have written, I can see that you have had your share of experience with such tools. And I agree, the workflow got to be simple and expandable.

The idea of using hooks and pipes really makes it into an expandable tool. Currently, the tool does allows to set one custom ‘Filter’ to do modifications to spatial or texture conversion. Yes, for next version I’ll implement it with your advice in mind. My motivation for creating this tool is that I am currently making a game that requires a bunch of assets, and I remember how much time I spend converting assets in my previous one.