Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option for cross-compatibility #95

Open
BrendanParmer opened this issue Mar 8, 2024 · 1 comment
Open

Option for cross-compatibility #95

BrendanParmer opened this issue Mar 8, 2024 · 1 comment
Labels
enhancement New feature or request
Milestone

Comments

@BrendanParmer
Copy link
Owner

  • Add an option to generate code for both Blender pre-4.0 and 4.0+ NodeTree interfaces
@BrendanParmer
Copy link
Owner Author

Blender 4.1 introduces some breaking changes with NodeSockets that complicates things a little bit here.

In previous versions of Blender it was necessary to use the index of the node socket for setting defaults or linking sockets together, usually because the node would have multiple sockets of the same name, but different types. This was annoying and somewhat illegible.

In Blender 4.0, they introduced changes intended to make string lookups the primary way of accessing node sockets, but indexing was kept backwards compatible.

With Blender 4.1, several nodes now use dynamic declaration, and sockets no longer necessarily have the same indices as in previous versions, and previous scripts aren't forward compatible if using indexing.

Indices aren't reliable going from 4.1 to previous versions. Really, string lookups are necessary in both cases, only Blender will handle it for us post-4.0, getting us something like

if bpy.app.version < (4, 0, 0):
    for (key, socket) in node.[in/out]puts.items():
        if key == name and socket.type == type:
            #use this socket
else:
    if socket.enabled:
        # just use regular string lookup
    # otherwise don't generate

Defaults for unavailable sockets wouldn't be forwards-compatible, but this seems like an unlikely use case. NodeToPython probably shouldn't even be generating code for these unavailable sockets anyways

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant