Bake Wrangler - Node based baking tool set

I don’t see why not, it’s a pretty simple thing to add… Of course your script could totally break the process, but that’s not really my problem :stuck_out_tongue:

I’m thinking it will just run python scripts in the blender environment, then if you want to run other stuff you can figure out how to call it from your script.

1 Like

Rather than a text block, just add a text field in the config with an operator to call. That way it won’t be tied to the .blend file.

Users can either use something that already exists or register their own operator, either in the .blend file - via a text block - or in their own tiny addon.

:+1: Sounds good to me as long as you would still be able to execute scripts in any place during the “batch bake” execution in the node tree.

The only issue I can see with it, might be the working path being different when the script is executed to what you might expect… I will just add it to the next alpha and see if that’s an issue.

So I have a question about what you want out of running scripts…

The way BakeWrangler works, is to spawn a background Blender process that works on a copy of the blend file. This is to allow you to continue working and changing stuff without impacting the baking and also lets me make changes to the copy version as I wish to facilitate stuff.

That means that if I run your script in the background process and you want to make changes to the blend file, they won’t be made to your actual working file.

Alternatively I could run the script in the foreground instance (it would be slightly more complicated, but doable). In this case your script could make changes to your working file, but they would not have any affect on the bake passes after it as they are still working from the original copied file…

The second case could be worked around by overwriting the copy and reloading after each script, but that starts to make it a lot more complicated!

(The most simple thing for me to do is run your script in the background process on the copied file)

If the script was to run on the copied file would I still be able to access other installed Blender extensions and emulate button presses and such? If so I think the simple solution of running the script in the copied file might sound best (also see the last paragraph in this message).

On the other hand doing this would also prevent you from taking user input through Blender (I suppose unless I invoke the batch bake from within a script (which sounds feasible to me)) - but I cant say Im planning on taking any user input in the first place so for me I dont think this matters.

The only pre-bake stuff I had in mind was automating stuff like appliance of modifiers, UV unwrapping and packing (Smart project and packing with UVPack master 2).

and for post-bake I was planning on running Send2Unreal (An extension by Epic Games that automates fbx export/import from Blender to UE) and potentially running some other py script that tells Unreal Engine to create an instance of a master material and assign the correct texture parameter(s).

Im however honestly not 100% sure i Send2Unreal would act if its in a temporary file thats only open for a few seconds/up to a few mins. It works by sending remote instructions to Unreal Engine over a local port (everything is done through Python I believe) so Im a little worried that if you have multiple Blender instances things might breakl (I can try opening up several Blender projects with Send2UE tomorrow and see if it runs or not).

I think running the operator in the foreground instance is better because it’s more predictable.

But since that complicates code, I think limiting it to only two opportunities - pre-bake and post-bake - would be reasonable. I can’t really see a use case for running scripts mid-bake.

Only letting it run pre and post bake would solve all the issues with running it foreground, so long as your pre-bake script doesn’t return until all its tasks are finished.

Running background also has problems with some add-ons that fail to load when there is no UI.

Do you think it would be possible to allow for running a script after the baking process in the initial Blender instance (the one that the baking instance is called from) as well?

Yes, the two best times to let a script be run are before it starts and after it finishes. I can just add some properties to the batch node to let you set them.

This may not be the purpose of this tool, but…
I would like to have a node to export meshes to fbx or obj, since I often take the data to game engines after baking.
By the way, MapsBaker in houdini can export meshes.

Awesome, sounds good.

While you’re well messing with the batch bake node I wouldnt mind if you also added an option to start multiple bakes at once :stuck_out_tongue:

This is the kind of thing that allowing the system to run .py scripts would allow for :slight_smile:

Allowing for parallel baking isn’t super simple. I never designed things with that in mind as my expectation was that each pass would fully utilise the available resources given blenders render is multi-threaded already. Is there that much to gain in parallel tasks?

@hidesai Model exporting is sort of out of scope… But what are you imagining? The main problem is that the exporters (especially fbx) have a LOT of options… Maybe there is a way to use presets or something though…

I understand that it is out of scope.
I’m a little disappointed, but…
I’m aware that there are many options for exporting models, but on the other hand, it changes depending on the DCC or scene unit being passed on, so there is value in being able to keep track of it and reuse it.

I’m not saying no, I’m just wondering what you want? Like a node with all the export settings on it? Or what?

Exporting ought to be covered adequately by running a script post-bake. Exporters really do just have too many options, and they depend on context as well (like what is selected).

One thing that would be useful to better support exporting via script would be to expose to script Bake Wrangler’s sources and targets somehow. Perhaps simply by having a Select node, that merely leaves the input objects (and nothing else) selected after the bake?

If the parameters can be set in detail, the add-on can complete the whole process.
If it is too complicated, it would be very useful to be able to select the OperatorPresets of each node and export their states.

It would be nice to have a Select node as well.

Hmm… So the problems I’m having with putting an export node are that:

  1. I would only be able to support a small number of formats (I’m simply not going to spend the time to support and maintain many).
  2. While STL would be simple enough to support, others like FBX for example, has 32 properties that need to be set, many of which have 3 or more possible choices. I can probably read those properties from the fbx add-on, but I don’t think there is any way for me to easily draw them. At least not in a nice way and they won’t really fit on a node…

There is another option… I think I could probably search through the Export menu and collect all the Operators. Then collect all the properties of a selected Operator and just draw them in a column in the side bar. It probably wouldn’t be pretty… But it could work?

Users could also write their own export scripts using the post bake script option. There could even be some scripts included with the add-on if people wanted to contribute some, like an export to FBX or such…

That does mean having some way to expose the object lists to the script. I’m not totally sure about having a selection option? I don’t really like the add-on changing states in the active blend file, as it’s supposed to all work in the background. Maybe people don’t really use it that… The pre-bake script could do it and reset the selection before going modal… Bake information could instead be passed to the script through arguments…

The most important export formats are fbx, gltf, obj and collada for godot. The others, like stl don’t really get used much in the context of baking. I can maybe envision an OBJ node, but the others… nah.