What's your 2.+ content pipeline like?

[mrmclovin]

I have been gaining some momentum on my multi year project that I usually work on at a slow pace. Additionally, I've learned to use Blender and created some content for my game, and spending more time in general on the visuals (models, material etc.) than game logic.

My current feedback loop for content testing is OK, but I'd like to invest some time and effort to improve the process. Current content pipeline:

Adding a new mesh

• Create the mesh in Blender. Save it.
• Invoke custom Bash script (I'm on macOS) that:
  • Runs the blender2Ogre script
  • Convert to .mesh using Ogre's XML mesh CLI
  • Package to zip and copy to my app's media directory
• Add the Zip file's path to a to Ogre's resource manager (yes, hardcoded)
• Create the PBS materials i JSON manually

Each time I make a change to the PBS json file I have to restart the app to see the changes. No live editing here..

Then when I want to bake a normal map, I have to do that in Blender and save it manually in my app's texture folder..

So I'm interested in hearing about your content pipeline setup, how you've made it as smooth as possible. Please share your experience and inspire with some cool ideas!

Examples of what I'm thinking about to improve/automate:
* Given a path to a media folder, in runtime, scan and discover different media files (meshes, material...) and add them as resources as necessary
* Somehow (if possible) package mesh, textures, normals maps etc. together and export it as a zip to my app
* Watch media files and auto-reload them when changed (perhaps restart the whole app as a cheap way to implement it)
* Find a clever way to live edit material params with instant feedback (either via a in-game GUI, or via an external GUI)

Cheers!

[Hrenli]

I use a very similar setup to what you describe but gradually and slowly trying to improve it. Not sure how helpful it might be, but here is what I did so far:

1. Switched to Blender 2.80 and wrote my own exporter plugin. For meshes it still spits out Ogre .xml but it follows the scene structure in terms of meshes and armatures (exporting as many meshes and as many armatures as selected by the user and it follows which armature is assigned for which mesh without stupid 1:1 scheme of the original exporter). But the main change is in the armatures. Instead of "rendering" each animation frame and exporting the result as original exporter did I am exporting bezier data for keyframes. And also pose library as additional set of bone transforms. And some bone constraints too (I use "muscle" bones on the character so instead of preanimating them I just keep information where those are stretching from and where to). I did not include .xml->.mesh step into the export yet because I am also fiddling with LOD generation for some of the meshes (and for now I do it manually playing with .xml and Ogre's meshlodgenerator).

2. As the above bullet implies, I wrote my own skeletal animation (ripped out v1 Ogre skeleton and mutilated it to my liking and needs) which uses bezier keyframe data to interpolate between keyframes and (the main reason for me) runs independently from Ogre so I have full control of it (useful when you have skeletons of skeletons, muscle bones, IK etc). In my case (I am not expecting thousands of animated meshes in one scene and I am targeting modern PC hardware, plus it might be slightly dependent on my exact style of rigging and animation) the changes turned out to result in a faster animation (just because animation data itself is now significantly smaller) which I did not originally expect so it's a nice bonus.

That's it for the "already done" part, unfortunately. Now for what I see/plan to do next:

I don't use PBS but own HLMS instead (which is of course is heavily based on PBS) because I am not aiming for a photorealistic look, wanted to use different approach to some aspects of lighting and when I started Ogre's PBS was not as flexible as it is now. Anyway, at the moment it uses own json descriptors which aren't runtime-update-friendly. I was planning to add some material editor into the engine at least for the most tedious to tune parameters. And it seems to be very reasonable step, but while I was fiddling with armature exporter for Blender 2.80 I started to think what if I try to recreate the look of my shaders in EEVEE and export the parameters from there. Not sure if it's a good idea, as it still gonna be different from the actual engine after all but the idea of having material editor directly in Blender sounds quite appealing.

The same with collision data. At the moment it's semi-manual process of defining some data in Blender and exporting it to a file. In a perfect world it should be either part of the mesh modeling workflow or part of that in-engine editor which I don't have.

If I was using PBS I think I'd use spookyboo's HLMS editor viewtopic.php?f=11&t=84816 much more than I do now. Sooner or later some sort of instant feedback material editor is really needed.

[xrgo]

we (my company when we started) started using gamekit (aka ogrekit) and we loved the fact that it opened blender files directly, so... since gamekit was already diying we started making our own engine that does the same but way better... so our pipeline is: blender! we use blender as our scene editor, modeling, materials, parenting, sound, physics, linking, almost everything but logic, no import/export needed

[dark_sylinc]

If you need something "quick", DERGO for Blender 2.79 may get you out of a pinch.

It's still not stable for every day use, but if you make sure you setup the async window exactly as shown in the procedure from the youtube video, you can edit Hlms materials in realtime and export them to JSON materials.

The tool could benefit from usability improvements e.g. it won't work if 'DERGO' engine in blender is selected before opening the server process, and you have to restart blender to fix the proper init order; if the server crashes you need to save your change, and restart the server process and then restart Blender, exporting meshes works but they don't have proper names, it's just '0', '1', '2'; but functionally speaking it works and once you get around those issues it feels great.

Nobody has actually dedicated time to improve those usability areas.