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

[Juan Linietsky]

As I mentioned before, the problem with using properties, even if hidden,
is that having this information persistent serves no purpose.
I understand that Blender can save it (with an option), but there is no
point in generating this information at any other time than saving the
exported scene..

This is why, the Ideal API use case for this is every exporter calling some
sort of new internal function that asks export metadata plugins to generate
this information, at export time and during the export process.

I am a bit unfamiliar nowadays with Blender internals, but I can ask other
Godot contributors to create a more specific proposal for this.

Juan


On Thu, Mar 4, 2021 at 6:33 PM Toni Alatalo <toni at playsign.net> wrote:

> 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
>>>
>>