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

[Toni Alatalo]

Fair points, thanks. BTW if there is an issue on the web or something for
this, am happy to study more there and maybe have extended discussions,
don't want to flood the list with learning the basics about this.

I was thinking, that if you need additional meta-data, you could maybe have
hidden custom properties, if they are for the export code only, and not
meant to be user facing. I don't know if Blender supports hiding custom
props nor whether I'd make sense. Maybe would work for the UUIDs for
example.

Now when you say that it's at export time, and with data that already
exists in Blender, I fail to see why an exporter can't do what you want
then.

So what is it that you are proposing exactly? Some kind of additional API
to Blender that would support getting info nicely for exporters?

Exporters already are 'metadata export plugins' and can do whatever is
necessary AFAIK. Of course if there is something missing in the API that
exporters need it's possible to add.

Anyway I think those were my points and I go silent here now to not spam
with clueless questions :)

-Toni



On Thu, Mar 4, 2021 at 11:24 PM Juan Linietsky <reduzio at gmail.com> wrote:

> So how is this not custom properties?
>>
>
> I don't think custom properties are the best for this use-case scenario,
> for the following reasons:
>
> * 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).
>
> Juan
>
>
> On Thu, Mar 4, 2021 at 3:53 PM Toni Alatalo via Bf-committers <
> bf-committers at blender.org> wrote:
>
>> So how is this not custom properties?
>>
>> https://docs.blender.org/manual/en/latest/files/data_blocks.html#custom-properties
>>
>> On Thu, Mar 4, 2021 at 8:05 PM Juan Linietsky via Bf-committers <
>> bf-committers at blender.org> wrote:
>>
>> > Hi Everyone!
>> >
>> >    Most exporters are working fantastic nowadays in Blender, so on the
>> > Godot Engine side, we are trying to figure how better to improve our
>> > experience to users when going back and forth between Blender and Godot.
>> >
>> >    So, this proposal consists on a very (pre-discussed) list of topics
>> that
>> > we would be glad to work together in ensuring Blender can support these
>> > somehow (which should hopefully happen with minimal effort).
>> >
>> >    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. Export plugins can then return generic
>> > metadata (Strings or what you believe is best) to embed in exported
>> scenes.
>> >
>> >   Here are use cases where these type of plugins would be very useful:
>> >
>> > * *UUID exporting*: When we import a scene on the game engine side, we
>> can
>> > only track objects by name. Blender uses unique names for objects, but
>> > artists will often rename them, causing data added on the engine side
>> (such
>> > as overriding materials, changing positions, setting children nodes to,
>> > etc) to be lost.  Ideally, Blender should be able to assign UUIDs to
>> every
>> > object at the time of creation (does not need to be global, can be per
>> > blender file). If not desired to be core in Blender, then the add-on
>> should
>> > be able to do this somehow.
>> > * *Material Exporting:* Exporting materials is very limited in any
>> format.
>> > Users often just want to model directly on Blender, set up the materials
>> > with nodes, and then expect them to work in the engine. To solve this,
>> we
>> > originally wrote a direct Blender -> Godot exporter, but this is very
>> > difficult to maintain where the main thing we need is just materials. On
>> > export, we convert Blender Materials to Godot Shaders, so they work
>> > automatically on the engine. If this can be saved as metadata in
>> > GLTF/DAE/FBX, it's much easier for us to maintain.
>> > * *Extra parameters for lights and cameras*: Sometimes, we want more
>> > parameters exported from lights, cameras, etc. in order to make sure
>> scenes
>> > just work.
>> > * *Extra types of objects:* Godot supports Splines, IK, Physics and many
>> > other types of objects that blender supports, but that no export format
>> > does. Being able to export those as metadata in the exporter would be
>> very
>> > useful. As an example, when making a racing game, exporting a Spline
>> used
>> > to create a racetrack helps make a better AI.
>> >
>> > 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.
>> >
>> > Best
>> >
>> > Juan
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > https://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>