Odin integration for Node Inspector Property Editor

[wqaetly]

Hello, respect of open source framework, the author, I am a computer science student in China, a while ago was shocked by this framework, and into the framework of the study, the framework is very powerful, but I also found a problem, that is the Node data in the Inspector panel display support is not friendly, so I, with the help of Odin plug-ins do a Demo。
Here are two links
https://gitee.com/NKG_admin/visual_skills_editor.git
https://gitee.com/NKG_admin/NKGMobaBasedOnET
I would be happy to contribute to this framework if you think my proposal is enough of a branch！I'll rewrite a little Demo and post it to you

[Seneral]

Hello!
You can already customize the Node Inspector by overriding DrawNodePropertyEditor, if that wasn't clear. From what I understand you use Odin to automate the GUI for both the NodeGUI and the inspector?
Pretty cool if you ask me, but Odin is a commercial asset, and as such only really useful for inhouse tools/scripts where every developer has Odin. Distributing software that relies on Odin is pretty much impossible since few people actually have it.
Even in a general perspective, the amount of nodes types usually stays manageable (<<100) so coding a GUI for each Node is fine and usually does not justify the overhead of a generalized UI system ontop (although that could vary for each use case).
So I don't see the benefit of creating (and managing, that's a lot of effort) a complete branch for Odin right now - although it does sound interesting (unfortunately I can't even test it since I don't have Odin)

[wqaetly]

Hello!
You can already customize the Node Inspector by overriding DrawNodePropertyEditor, if that wasn't clear. From what I understand you use Odin to automate the GUI for both the NodeGUI and the inspector?
Pretty cool if you ask me, but Odin is a commercial asset, and as such only really useful for inhouse tools/scripts where every developer has Odin. Distributing software that relies on Odin is pretty much impossible since few people actually have it.
Even in a general perspective, the amount of nodes types usually stays manageable (<<100) so coding a GUI for each Node is fine and usually does not justify the overhead of a generalized UI system ontop (although that could vary for each use case).
So I don't see the benefit of creating (and managing, that's a lot of effort) a complete branch for Odin right now - although it does sound interesting (unfortunately I can't even test it since I don't have Odin)

Well, I'm sorry

[Baste-RainGames]

Pretty cool if you ask me, but Odin is a commercial asset, and as such only really useful for inhouse tools/scripts where every developer has Odin. Distributing software that relies on Odin is pretty much impossible since few people actually have it.

Note that while the Odin inspector is a commercial asset, their serialization backend is open source. See here https://github.com/TeamSirenix/odin-serializer. So it would be possible to add it as a dependency and use it for all serialization.

I have no clue if that's a good idea or viable (I haven't used it myself), just wanted to clarify that it's not a commercial tool.

[wqaetly]

Pretty cool if you ask me, but Odin is a commercial asset, and as such only really useful for inhouse tools/scripts where every developer has Odin. Distributing software that relies on Odin is pretty much impossible since few people actually have it.

Note that while the Odin inspector is a commercial asset, their serialization backend is open source. See here https://github.com/TeamSirenix/odin-serializer. So it would be possible to add it as a dependency and use it for all serialization.

I have no clue if that's a good idea or viable (I haven't used it myself), just wanted to clarify that it's not a commercial tool.

Cool！

[Seneral]

Hm didn't know that. But serialization and GUI is a different thing, and as far as I understood it's about replacing/changing how GUI is handled in the framework (if only in the inspector or also in the node body, I don't know).
Maybe I didn't fully understand your changes and use cases, since again I can't really test it as I don't have Odin. I just had to guess by what information is available. If you explain what benefits it might bring to people using Odin, it might be viable to create a branch.

[wqaetly]

In fact, Odin's Inspector panel visualization is just one thing, and its own serialization function is very powerful, which can sequence various types of words, including actions, events, delegates.If you want to see the effects of Odin with the Node_Editor_Framework, I did two demos with links I mentioned above, but they're not on GitHub, you need to copy and paste the links into the browser's address input area to access them.We can first create an Odin branch, but do not provide Odin plug-in, prompting users to download, so as to avoid infringement problems.(like xNode's Odin branch)https://github.com/Siccity/xNode/tree/experimental/odin-inspector-support
Below are some effect pictures I used in Odin



My access to github is very slow, if possible, I hope we can contact via email :1778139321@qq.com

[Seneral]

Ok that convinces me:) Haven't done alot with such complex nodes tbh. I see the advantages of automating the UI in these cases.
I'll have a look at your fork / diff it and try to work out how the integration works. From xNodes's version I see it isn't too much code at all, so if this works out to be good, I don't see a reason to not merge it at some point.

[Seneral]

Ok I'll have to back down on this one. Trying to find my way through code changed this much without being able to run it is a bit freakish. If you can separate a more or less clean version only with the changes required for Odin however, that's a different story. I assume the actual changes required are not nearly as much.

[wqaetly]

Fact don't need to change any code, only need to remove or block this framework you bring two Inspector to plot, and then the relevant class inherits - SerializedScriptableObject Odin serialization of class,

and remove several clashes with Odin [Serializable] features.If you feel it is really necessary, I will be happy to provide you with a minimal version and send it to you by email for your review.

[Seneral]

That would be best, without being able to test it would be pretty useless for me to try anything.
If you zip it you can send it to me here or to contact@seneral.dev, or just make a repo/branch somewhere.
Thanks for your suggestion!

[Neovariance]

I m pretty sure the Odin dev would grant you a voucher for a free license of Odin if you ask them!

[wqaetly]

I checked many issues and found that many people have problems with the Unity 2020 version. I guess it is because the caching mechanism of Node_Editor_Framework and the rollback mechanism do not match 2020. Of course, it may also be caused by serialization, but I used it. Odin, and removed the cache mechanism, rollback mechanism, works well in Unity 2020