[Bf-committers] Proposal: Export extensions for better integration with game engines.

Juan Linietsky reduzio at gmail.com
Mon Mar 8 15:43:05 CET 2021


@sybren let me clarfify again:

> What is exported? This seems like both data (camera/light parameters,
physics sim results) and metadata (like a name-invariant identifier).

* Data that is not supported by the export format (which are generally
limited), such are more advanced light/camera data, or unsupported nodes in
the export format.
* Data that the game engine will consume, in a format the game engine
understands. A good example of this is shaders, every engine uses shaders
different and there is no way to standardize this, so at the *time of
export *(there is no better time to do this than here), we convert Blender
graph based shaders to Godot text based shaders.

> How is it exported? Here you could indeed (mis)use free-form metadata
fields of the export file format to contain the data you're interested in.

Please re-read my comments about why the free form metadata is not
sufficient or even fit for this. I will paste them again here so let me
know if something is not clear:

* You need to generate this data *on export*. As an example, if you edited
the material nodes in Blender, you would only want to generate a target
engine shader at the time you are exporting the file, as this can be a
costly process. Doing it at any other time is unnecessary and inefficient.
* Custom properties are meant to be *user-facing*, there is zero benefit in
users seeing data meant *for the exporter*.
* Again remember, the use of this is to take data that *already exists in
blender* (not that was created by the user) and send it to a game engine.
It's a different use case (and hence, feature).

I don't know if I'm such a fan of "any add-on can add anything to any
exporter". More often than not, with an everything-should-be-possible
super-flexible design, things get very hairy.

> Why not work on the glTF or USD exporter, so that it gets more powerful
and
actually exports everything game engines like Godot (and others, of course)
need?

Because:
1. We need to export data that only Godot understands, likewise for other
game engines, they need to convert the data to something they need.
2. This means getting into politics with Blender and Khronos for every
thing we want to do, when all we want is to piggy back on existing
exporters and export our own data that is only useful for our engine.

> I don't know if I'm such a fan of "any add-on can add anything to any
exporter". More often than not, with an everything-should-be-possible
super-flexible design, things get very hairy.

That's not a good philosophy imo. If it helps, at Godot, our philosophy is
1) Cover the most common use cases and make them easy to use 2) Leave the
door open for the rare ones by providing a low level API.

It's either this, or an un-optimal solution from the human side, meaning
lots of duplicated effort or lots of politics deciding on universal
features that no one cares about.


Juan


On Mon, Mar 8, 2021 at 7:31 AM Sybren A. Stüvel via Bf-committers <
bf-committers at blender.org> wrote:

> Hi Juan,
>
> On Thu, 4 Mar 2021 at 19:05, Juan Linietsky via Bf-committers <
> bf-committers at blender.org> wrote:
>
> >    The main topic is the ability for Blender to have a "Metadata Export"
> > plugin. This means, that at the time of export,and for each object
> exported
> > (node, material, skeleton, mesh, etc) Blender should be able to ask for
> > "metadata" to the export plugins.
>
>
> Either I'm not understanding things well, or there is some inconsistency in
> the terminology. It seems that what you're describing is actually more
> "extra data" or "augmentation" of the exported file format. For example,
> what you descsribe in export of materials, splines, IK properties, etc.
> are, at least from Blender's point of view, data, and not metadata.
>
> What I mean is that I see a difference between:
>
>    - What is exported? This seems like both data (camera/light parameters,
>    physics sim results) and metadata (like a name-invariant identifier).
>    - How is it exported? Here you could indeed (mis)use free-form metadata
>    fields of the export file format to contain the data you're interested
> in.
>
> I think it's bad to focus on the last bit, though, because if a file format
> natively supports the desired data, it should be exported in that way and
> not crammed into some metadata string field.
>
> So, all this could be done if exporters polled export metadata plugins for
> > metadata at the time of export (so we ensure we convert from the most
> > recent version of the object) on any object, then added it in the
> exported
> > data. This is a minimal non-invasive change in Blender exporters, but
> adds
> > huge flexibility to engine export.
> >
>
> I don't know if I'm such a fan of "any add-on can add anything to any
> exporter". More often than not, with an everything-should-be-possible
> super-flexible design, things get very hairy.
>
> Why not work on the glTF or USD exporter, so that it gets more powerful and
> actually exports everything game engines like Godot (and others, of course)
> need?
>
> Cheers,
> Sybren
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list