Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.
Ok, so basically an export support lib. I'd see no harm in it if you just draft one and present as an example of the kind of API calls you'd like to have. I think anything that the new 'export plugin API' would do, you can do in a py lib that have you for your exporter. Then if it makes sense for some parts of it, folks can consider having a C impl for it in Blender. But indeed is good to hear what the devs think of this. -Toni On Fri, Mar 5, 2021 at 1:43 AM Juan Linietsky 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 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 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@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@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
Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.
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@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 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 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 > 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@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@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
Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.
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 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 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 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@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@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
Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.
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 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 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@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@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
Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.
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 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@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@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.
Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.
> > 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@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@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@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.
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@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@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal: Export extensions for better integration with game engines.
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@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Spreadsheet editor design
Hi, As part of the geometry nodes project there is a need for a spreadsheet editor for a few use cases. However this is an editor that is not exclusive to the nodes pipeline however and can relate to many other projects (overrides, drivers, ...). We did the design taking other use cases into consideration, but I would like to invite the other modules to see if anything is missing or to plan ways to expand it for the other modules https://developer.blender.org/T86279 Thank you, -Dalai- Dalai Felinto - da...@blender.org - www.blender.org Blender Development Coordinator Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Clang-Tidy: Request for Feedback
Consider `clang-tidy-diff.py` and `run-clang-tidy.py` [1] to cut down time to run clang-tidy further. The latter is not incremental though. Editor extensions based on clangd + LSP can show clang-tidy violations live as the file is being edited. I've tried [2] and it's fine. There's one for VSCode too. [1] https://github.com/llvm/llvm-project/tree/main/clang-tools-extra/clang-tidy/tool [2] https://github.com/sublimelsp/LSP Ankit (ankitm) > On 04-Mar-2021, at 18:51, Bastien Montagne via Bf-committers > wrote: > > Hi, just my two cents, since I did not take part in this project in itself: > >> So here are some questions to the developers: >> >> - Do you have a strong feeling about leaving a .clang-tidy file as it is >> now (where file modification requires manual re-compilation) ? > I do not mind having to force clean rebuild once in a while if needed, no. > Having this handled automatically would be nice of course, but does not look > like a showstopper to me. >> - Shall we enable it by default? Maybe for `make developer` ? > > No, I don't think so, given the cost on building time. What I will likely do > is having a dedicated build for that (like I have e.g. for lite builds for > quick bisect, etc.), that I will run as part of clean-up & finalize process > before committing, but not during on-going development. > Indeed, enabling it on CI seems a very good idea though. > > Cheers, > Bastien > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Clang-Tidy: Request for Feedback
Hi, just my two cents, since I did not take part in this project in itself: So here are some questions to the developers: - Do you have a strong feeling about leaving a .clang-tidy file as it is now (where file modification requires manual re-compilation) ? I do not mind having to force clean rebuild once in a while if needed, no. Having this handled automatically would be nice of course, but does not look like a showstopper to me. - Shall we enable it by default? Maybe for `make developer` ? No, I don't think so, given the cost on building time. What I will likely do is having a dedicated build for that (like I have e.g. for lite builds for quick bisect, etc.), that I will run as part of clean-up & finalize process before committing, but not during on-going development. Indeed, enabling it on CI seems a very good idea though. Cheers, Bastien ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code Quality Day - 5/March
Hi, This Friday we have February's code quality day [1]. For the Clang-Tidy project we'll come up with a decision on which warnings we still want to address and support. ANd I would really like to see the WIP patches to be either finished or officially stated that we do not want to address the warning. The goal is: finalize the project! Note that there are still a lot of things to do from [2]. There are a couple of new entries there added since the previous quality day. There are also a lot of quality improvements possible in many areas which are not listed in the document. I would encourage all module owners and members to work on quality improvements in their areas! Best regards and see you all tomorrow! - Sergey - [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day [2] - https://developer.blender.org/T73586 Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Clang-Tidy: Request for Feedback
On Thu, Mar 04, 2021 at 09:52:52AM +0100, Sergey Sharybin via Bf-committers wrote: > - Shall we enable it by default? Maybe for `make developer` ? If nothing else, I think that it should be on by default on our CI builds. This way we will be able to tell when things slipped through the cracks. It will also be very useful when we eventually hook the CI system up to the review tasks. Then contributors will have clang tidy comb their code and they will get automated feedback. ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Clang-Tidy: Request for Feedback
On Thu, 4 Mar 2021 at 09:53, Sergey Sharybin via Bf-committers < bf-committers@blender.org> wrote: > - Do you have a strong feeling about leaving a .clang-tidy file as it is > now (where file modification requires manual re-compilation) ? > No, not really. Of course it would be nice if changes are picked up automatically, but I don't have a problem with an occasional clean + rebuild. > - What do you think we still need to do before we can call the project > done? > There are a few rules mentioned in T78535 that haven't been crossed off yet, but also have no clear status: - readability-non-const-parameter and modernize-use-equals-default: seem to still be in progress - modernize-loop-convert: I worked on that before, but probably won't have time to continue on it this Friday. I have some work for the studio that has a clear deadline; I'll catch up on code quality work after that's been delivered. - modernize-pass-by-value: needs a decision on whether we want it or not. I think these need a finalizing decision, to either continue & finish the work, or a decision that it won't be done. After that I think we can call the project finished. - Shall we enable it by default? Maybe for `make developer` ? > To see the impact of that, I did a quick (N=1) test on my machine. I'm using GCC 9.3 with CCache on the master branch. Both tests have had a full build with this combo before measuring the build timing, so the CCache cache is up to date. This to me is resembling my personal development situation more than doing clean builds without caching. Building without clang-tidy took 152 sec (wallclock time). Building with clang-tidy took 275 sec (wallclock time). This means that it's very roughly twice as slow to build with clang-tidy enabled. To me this means that I won't be using it for regular builds in my code-build-test cycle. If other developers feel the same way, that I expect them to disable it right after they run `make developer`, in which case it's probably better to just disable it by default. - Any other relevant feedback? > IMO we should configure the buildbots to run with clang-tidy enabled. That way violations of the rules are noted, even when most devs work with clang-tidy disabled. Case in point: I had to fix one error before I could run the above timing test. Sybren ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Clang-Tidy: Request for Feedback
Hi, During the past months we seem to cover the majority of the warnings from Clang-Tidy [1]. The remaining onbes either require a newer Clang-Tidy version, or have a patch, or are a bit controversial than it originally looked. I would say we have reached the point where we can declare the Clang-Tidy project as a "maintenance" -- there are always things to get addressed for new versions or new warnings in the code, but there is no need to keep it an ongoing project. One of the open topics is that modification of .clang-tidy file does not cause full source recompilation. Personally, I do not think this is a huge problem: the file is not being edited that often, and it is similar to the .clang-format. And there is an advantage to having the warnings defined in the file: it is easier to "override" or port them to different areas of Blender. So to me it seems the corresponding point in the T78535 we can just ignore. So here are some questions to the developers: - Do you have a strong feeling about leaving a .clang-tidy file as it is now (where file modification requires manual re-compilation) ? - What do you think we still need to do before we can call the project done? - Shall we enable it by default? Maybe for `make developer` ? - Any other relevant feedback? [1] https://developer.blender.org/T78535 Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
