Reference hashes

[Helveg]

When sending things back and forth I think it's best that to decouple from the simulator that sent the data we allow the simulator to send us a "reference hash" for that object; With such a hash that is supposedly unique on the client's side we can create our object, store the hash, and when we send something back to the client we include this reference. That way the client can map it back to its own object, without the need of coupling our identifiers to theirs.

An example:

NEURON creates a Section
NEURON's RPC client sends Blender the Section data, with its `.hname()` as "reference hash"
Blender creates the `Branch` object and stores its reference hash
When synchronizing or sending back data the reference hash is attached and NEURON can find the Section

[Helveg]

This should allow us to remove things like nseg from the Branch class

[JustasB]

I like the idea of using hashes to handle long names.

One of the features that is very useful for debugging NRN morphology is to see the name of the section when one clicks on it in Blender (e.g. to find out what those weird lines were in https://github.com/JustasB/BlenderNEURON/issues/15#issuecomment-760216555).

Another use case I've seen is pulling up the graph editor in Blender and looking at the evolution of a target section variable value over frames (e.g. v in soma vs v in dendrites over the course of a simulation).

For these reasons, we should try to preserve the NRN section names in the Blender object names so they could be understandable in the Blender UI.

However, we should shorten the names when the names are long to avoid the problem in https://github.com/JustasB/BlenderNEURON/issues/15. The issue is how to shorten the names AND be able to recover the original full-length names when needed.

Usually, the most specific part of the section name is at the end (e.g. blah.blah.foo.bar........MYCELL.dendrite[64]). To shorten the name we could keep the right-most 255 chars of the section name, and store an integer hash of the original section name in a custom property of the Blender object. Then, if we retain the hash<->full name mapping internally, we can recover the original full section name when needed (e.g. to send modified coords back to NRN).

SInce this is mostly an implementation-in-Blender detail, I would favor generating the hashes within Blender so the 255 char limit is (mostly) transparent to users. I'm also not sure that the .hname() in NRN prop is consistent across NRN/Python/OS versions. If we use our own hash function, this risk would be minimized.

[Helveg]

Good points! I was intending to keep a .name around which can be arbitrarily long! So for "identifiers" we'd have this:

• .id: unique int. We translate this with a naming convention into a unique blender object name such as f"_bn_obj_{id}" with additional suffixes such as _bezier for the curve etc. All our controlled objects (groups, cells, synapses) get an id so that they can register unique blender objects. Or inversely, anything that wants to create blender objects will need to register for an id :D
• .name: "This one cell I made" To be shown in any user interaction, the stuff that's shown in the UI now that in #15 was too long can become the name.
• .ref: "ae84ff75" Unique identifier the user can tag along, hopefully unique in the environment it came from ;) (NEURON, Arbor, ...). The NEURON RPC client can use this to map the data it receives back to what it came from.

Another option is to drop the ref and just send back the ids from any create operations and let the user map that to their objects?