User properties are set up during script execution, so can't affect script execution. They can only affect the per-frame callback. This means that they can't affect shader compilation (which happens at script execution, not per-frame). So you can't have a user property, for example, change a shader #define. That kinda sucks.
To support this changing the user property would have to trigger re-execution of the script. If done naively, that could of course mean that the user property would cease to exist. So we would need some new kind of scoping mechanism. Maybe a shader compile callback similar to the per-frame callback? That would mean that you couldn't use user properties to change, say, texture generation, however. Maybe user properties need to be declared up-front using some other mechanism? Or an explicit scoping mechanism, like ri.WithUserProp({...some code...})?
Done in 6afa82095af31104b13afa36461483849eaa03fe. By pre-compiling the scripts we can re-execute them with minimal risk, meaning that we can allow this without any additional API or work in the script. Yay!
User properties are set up during script execution, so can't affect script execution. They can only affect the per-frame callback. This means that they can't affect shader compilation (which happens at script execution, not per-frame). So you can't have a user property, for example, change a shader #define. That kinda sucks.
To support this changing the user property would have to trigger re-execution of the script. If done naively, that could of course mean that the user property would cease to exist. So we would need some new kind of scoping mechanism. Maybe a shader compile callback similar to the per-frame callback? That would mean that you couldn't use user properties to change, say, texture generation, however. Maybe user properties need to be declared up-front using some other mechanism? Or an explicit scoping mechanism, like
ri.WithUserProp({...some code...})
?Needs investigation and experimentation.