Added back set_sync_settings #86

Closed
Bogdan Nagirniak wants to merge 2 commits from hydra-sync_settings into hydra-render

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.

Purpose

set_sync_settings() are used to provide specific settings for Hydra scene delegate required for some render delegate addon, e.g. https://github.com/bnagirniak/RPRHydraRenderBlenderAddon/blob/add-lightToken/src/hydrarpr/engine.py#L44 .

Technical steps

Added back set_sync_settings() to HydraRenderEngine. Made them more specific.
Added struct HydraSceneDelegate::SyncSettings.

Note

Works with https://github.com/bnagirniak/RPRHydraRenderBlenderAddon/pull/26

### Purpose `set_sync_settings()` are used to provide specific settings for Hydra scene delegate required for some render delegate addon, e.g. https://github.com/bnagirniak/RPRHydraRenderBlenderAddon/blob/add-lightToken/src/hydrarpr/engine.py#L44 . ### Technical steps Added back `set_sync_settings()` to `HydraRenderEngine`. Made them more specific. Added `struct HydraSceneDelegate::SyncSettings`. ### Note Works with https://github.com/bnagirniak/RPRHydraRenderBlenderAddon/pull/26
Bogdan Nagirniak added 2 commits 2023-08-03 19:26:12 +02:00
Bogdan Nagirniak requested review from Brecht Van Lommel 2023-08-03 19:26:27 +02:00
Bogdan Nagirniak requested review from Brian Savery (AMD) 2023-08-03 19:26:28 +02:00
Bogdan Nagirniak requested review from Georgiy Markelov 2023-08-03 19:26:28 +02:00
Bogdan Nagirniak requested review from Vasyl Pidhirskyi 2023-08-03 19:26:28 +02:00
Brian Savery (AMD) approved these changes 2023-08-03 19:33:22 +02:00
Brian Savery (AMD) left a comment
Collaborator

The name is kinda weird IMO. "sync_settings"?
Also could we just pass a dictionary rather than doing one at a time?

The name is kinda weird IMO. "sync_settings"? Also could we just pass a dictionary rather than doing one at a time?
Author
Owner

The name is kinda weird IMO. "sync_settings"?

Maybe set_hydra_settings ?

Also could we just pass a dictionary rather than doing one at a time?

Yes, but it requires to parse python dict on C++ side instead of python side. Not hard, but not sure if this really need here.

> The name is kinda weird IMO. "sync_settings"? Maybe `set_hydra_settings` ? > Also could we just pass a dictionary rather than doing one at a time? Yes, but it requires to parse python dict on C++ side instead of python side. Not hard, but not sure if this really need here.
Author
Owner

Seems this PR opens more questions, there is another approach of how to provide some custom settings to hydra prims, not to use sync_settings, so we can look at approach with USD hook in blender/blender#108823. But we'll start thinking about it after hydra-render merge.
Therefore, I'll close this PR.

Seems this PR opens more questions, there is another approach of how to provide some custom settings to hydra prims, not to use `sync_settings`, so we can look at approach with USD hook in https://projects.blender.org/blender/blender/pulls/108823. But we'll start thinking about it after hydra-render merge. Therefore, I'll close this PR.
Bogdan Nagirniak closed this pull request 2023-08-04 13:34:02 +02:00
Collaborator

Besides hooks, if performance is a concern then an alternative would be to provide a mapping to Blender properties.

So for example we have built-in Object.visible_camera, which could be mapped to rpr:object:visibility:camera. But not just built-in Blender properties, also any custom properties registered by the renderer could do this. Perhaps even with wildcards from e.g. scene.rpr.* to rpr:scene:*.

The advantage is that this mapping could be done in C++, with all the strings interned and hashed already, RNA properties looked up and validated. On the other hand a Python hook could do more complicated logic which may be required in some cases, I'm not sure.

Besides hooks, if performance is a concern then an alternative would be to provide a mapping to Blender properties. So for example we have built-in `Object.visible_camera`, which could be mapped to `rpr:object:visibility:camera`. But not just built-in Blender properties, also any custom properties registered by the renderer could do this. Perhaps even with wildcards from e.g. `scene.rpr.*` to `rpr:scene:*`. The advantage is that this mapping could be done in C++, with all the strings interned and hashed already, RNA properties looked up and validated. On the other hand a Python hook could do more complicated logic which may be required in some cases, I'm not sure.
Collaborator

Besides hooks, if performance is a concern then an alternative would be to provide a mapping to Blender properties.

So for example we have built-in Object.visible_camera, which could be mapped to rpr:object:visibility:camera. But not just built-in Blender properties, also any custom properties registered by the renderer could do this. Perhaps even with wildcards from e.g. scene.rpr.* to rpr:scene:*.

The advantage is that this mapping could be done in C++, with all the strings interned and hashed already, RNA properties looked up and validated. On the other hand a Python hook could do more complicated logic which may be required in some cases, I'm not sure.

I think the "other hand" of flexibility needed for render engines defined in Python is going to be needed. But for sure there is probably a better way to do this.

My point I made offline is that there is some overlap with what is being done here with the "python chasers" PR and should be made as close as possible.

> Besides hooks, if performance is a concern then an alternative would be to provide a mapping to Blender properties. > > So for example we have built-in `Object.visible_camera`, which could be mapped to `rpr:object:visibility:camera`. But not just built-in Blender properties, also any custom properties registered by the renderer could do this. Perhaps even with wildcards from e.g. `scene.rpr.*` to `rpr:scene:*`. > > The advantage is that this mapping could be done in C++, with all the strings interned and hashed already, RNA properties looked up and validated. On the other hand a Python hook could do more complicated logic which may be required in some cases, I'm not sure. I think the "other hand" of flexibility needed for render engines defined in Python is going to be needed. But for sure there is probably a better way to do this. My point I made offline is that there is some overlap with what is being done here with the "python chasers" PR and should be made as close as possible.

Pull request closed

Sign in to join this conversation.
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: BogdanNagirniak/blender#86
No description provided.