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

[Jacob Merrill]

Upbge fork has object property's restored, and they are used on UPBGE in
game,

You could use this as a basis, it's kept in sync with blender master.

Upbge.org

On Thu, Mar 4, 2021, 3:46 PM Juan Linietsky via Bf-committers <
bf-committers at blender.org> wrote:

> We can probably pull request this functionality into Blender ourselves, or
> at least generate a detailed proposal but for this I would like to see if
> Blender contributors can agree that this is something wanted and how it
> would be wanted.
>
> Best
>
> Juan
>
>
> On Thu, Mar 4, 2021 at 8:43 PM Juan Linietsky <reduzio at gmail.com> wrote:
>
> > 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
> >>>>
> >>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>