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 < [email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 < > >>> [email protected]> 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 < > >>>> [email protected]> 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 > >>>> > [email protected] > >>>> > https://lists.blender.org/mailman/listinfo/bf-committers > >>>> > > >>>> _______________________________________________ > >>>> Bf-committers mailing list > >>>> [email protected] > >>>> https://lists.blender.org/mailman/listinfo/bf-committers > >>>> > >>> > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
