That's only valid for the lifetime of the object, though (it uses the memory location of the object). If you restart Blender, delete the Python object, or create a new Python object that points to the same memory in C, then all the IDs will likely be different for the same object in C. Also, the C objects' memory locations will likely change between Blender restarts, and deletions.
On Thu., Nov. 12, 2020, 5:20 p.m. AMDBCG via Bf-committers, < bf-committers@blender.org> wrote: > Python has an id for each object that can be referenced in your Blender > importer > > https://www.programiz.com/python-programming/methods/built-in/id - where > id is the main id of the object > > -Robert Fornof (amdbcg) > > On 11/12/2020 9:24 AM, Juan Linietsky via Bf-committers wrote: > > Hi guys, lead Godot dev here. > > > > I wanted to discuss with you a problem we are often having that I am not > > certain how it can be solved entirely from our side, I add a proposal for > > this, but if you guys have a better recommendation, I'm very open to any > > ideas. > > > > Basically, Godot will import scenes (GLTF/FBX/DAE/etc) as they come from > > blender, and it generates the same object names, resource names, etc. as > > they come from Blender and the resource file. > > > > We use the same names so we can keep track of changes in the Blend file. > If > > an object is moved, a material is changed, etc. we detect on re-import > and > > everything is updated in Godot. > > > > This is especially more annoying in Godot than in other game engines, > > because Godot can read the whole Blender scene and keep it more or less > > intact, so users love using this for level design workflow (so they can > > design levels in Blender). > > > > So, the problem is that it often happens that for some reason, artists > want > > to rename the objects in Blender. Be it because they didn't care at the > > beginning and they want to become more organized later, or because the > > scene became bigger and they need to make their naming of things more > > precise to navigate it around. In this situation, when something is > renamed > > on the Blender side and re-exported, the game engines have no idea where > > this object went, so we need to either remove it (resulting in loss data) > > it or orphan it (resulting in duplicated data). > > > > While I do think that good practices solve this and this is probably not > > such an issue in a professional environment, truth is that game > development > > has become a huge hobbyist activity, and our users find this situation > > constantly and are annoyed with it, and there is nothing we can do from > our > > side. > > > > The obvious proposal to solve this would be to ask Blender whether it's > > possible to generate a unique object ID (UUID?) and make sure it does not > > change over time even if objects are renamed, then changing the > exporters a > > bit to (optionally if selected in the export settings) add this > information > > as extensions in the existing format (on GLTF it should be rather easy). > > > > If you guys think this is possible, it would be very helpful for us, if > you > > have other ideas on how we could solve this, we are very open to > discussion. > > > > 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
