-
-
Notifications
You must be signed in to change notification settings - Fork 430
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
More Subprocess Refactoring and Cancel Generate Operator #274
More Subprocess Refactoring and Cancel Generate Operator #274
Conversation
main() was getting cramped so moved clutter to a new Backend class. Intents get their own generator methods that also allow for lazy loading their dependencies and models.
I assume this is meant for the stop generation action, but I also tried testing upscaling while the generator was running. This did not work:
So perhaps we can either disable the UI for the upscaling panel while generator is running or look into a fix for this. |
I wasn't quite able to replicate your error case but looks like I didn't make it properly wait if it had more than one intent in the queue. That should be okay now. There is still an issue of multiple operators polling the action queue at the same time that will need addressed. I'll see what I can do about that later. Either disabling the operator while another is running or perhaps attaching a unique id to link each action to the intent that caused it.
|
Blocking operators is the most practical for now. Intent session id tracking could be useful if the subprocess would split tasks up between multiple GPUs, but just an idea to save for later. |
bpy.context.scene.dream_textures_progress = 0 | ||
bpy.context.scene.dream_textures_info = "" | ||
if not hasattr(context,'scene'): | ||
context = bpy.context # modal context is sometimes missing scene? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's odd, since the scene is supposed to be in the global context, so all other contexts would be built on that (i assumed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may have mixed up where it was getting context from, or completely forgetting what caused the issue in the first place. There actually seems to be a problem with the context that kill_generator()
gives it, the default context argument is somehow different from bpy.context
when called. It should stop being an issue if I just leave the default as None
and replace with bpy.context
when that is the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
…i#274) * subprocess refactoring main() was getting cramped so moved clutter to a new Backend class. Intents get their own generator methods that also allow for lazy loading their dependencies and models. * fix non-automatic precision always reloads model * cancel generator operator * small changes * prevent stopped action from being sent when it shouldn't * move property resets out of if timer block * clear event before waiting * block operators while subprocess is in use
send_intent()
method toGeneratorProcess
that mirrors whatsend_action()
doesBackend
class to clean upmain()