10 randomise selected properties per frame#35
Conversation
sfmig
left a comment
sfmig
left a comment
There was a problem hiding this comment.
Works great!
Since it was easy to implement, I'd suggest we add it to the materials panel in this same PR. Let me know thoughts.
There was a problem hiding this comment.
it's not randomising the material properties for me (was it for you?) - EDIT: I fixed it here
I also get this error:
rna_uiItemO: operator missing srna 'opr.apply_random_transform'
/Users/sofia/Library/Application Support/Blender/3.4/scripts/addons/randomiser/transform/ui.py:45
I think because it is actually using the operator defined in transforms.py (hopefully fixed here).
Can we delete that script to avoid confusion/error?
|
|
||
|
|
||
| @persistent | ||
| def randomise_per_frame(dummy): |
There was a problem hiding this comment.
I suspect you need to call the functions with different names, for the transforms operator and the materials operator? Otherwise I suspect they'd be overwritten right? (that's why I suggested calling this randomise_camera_transform_per_frame earlier)
although that doesn't seem to fix the issue
Co-authored-by: sfmig <33267254+sfmig@users.noreply.github.com>
ruaridhg
left a comment
ruaridhg
left a comment
There was a problem hiding this comment.
Can we merge this now?
ruaridhg
left a comment
ruaridhg
left a comment
There was a problem hiding this comment.
Can we merge this now?
|
I've managed to sort out the merge conflicts now and include the update main with the global seed working properly so should be fine to merge now. |
|
Sorry @ruaridhg I missed the comments in this PR! There was a small issue with the operator name for the material nodes (merging artefact?), but I fixed it. Another thing I noticed is that if the seed is set, the sequence of random numbers will be deterministic, but we are still randomising the values every time a frame change is executed. This means that if we have some values in frame 1, then switch to another frame, and then go back to 1, the values won't be the same. So the random values are not linked to a frame number. The result is that if we want to reproduce a specific sequence of numbers, we also need to register the frame transitions. I am happy to merge for now as I think maybe it is fine as it is, but maybe we need to check with @tdowrick if having values linked to specific frames is the intended behaviour. |
|
actually the issue above may be related to the latest seed PR not being already merged... will keep an eye on it 🤔 |
2 participants
When frame is changed apply_random_transform operator is called