Hello. I would like to fix this issue. I remember there was another thread where this was talked about but I don’t think it was the exact same thing.
Currently, for most of the nodes’ inputs, resetting their values simply gets them back to 0. Is this a technical limitation or does it simply require a lot of manual labor (populating a giant table with the default values) ?
Ideally it could then be expanded to the entire program, but the nodes seem like a sensible place to start.
I think it is indeed a bit of manual labor. There is a task outlining the general issue: ⚓ T80164 Missing DNA Defaults ("Reset to Default Value" sets to 0)
There you’ll also find a few commits fixing this in different areas to cheat off of.
Good luck!
It’s important to note that this system (and the task linked above) won’t affect the defaults for node sockets, just node properties. That’s valuable too, but it’s a bit less important long term, since the general goal away is to make almost every input a node socket.
Also, there’s another complication unfortunately. The system works well for unique types like Mesh, but it doesn’t work when there’s a single DNA type that corresponds to many node types. Lots of nodes store data in custom1, custom2, in bNode. It’s reasonable to think that the defaults system (or at least the “Reset to Default Value” operator) could be extended to support situations like this.
Yeah, I was slowly arriving at that conclusion after digging a bit more into the code. Obviously not as detailed as you put it, so that’s appreciated.
So if I understand correctly, the idea would be to make the system aware of the bNodeTypes? Or rather making the nodes more uniquely recognizable as a sort of sub-dna types?
This would be in addition to the other changes, right? Or do you think the entire problem could be solved with this approach of extending the reading logic instead of modifiying the architecture?
I’m still trying to understand how it all ties together, so apologies my questions are a bit strange or off-beat.