Timeline for OSL trace() : how is the "shade " parameter used?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 21, 2018 at 6:09 | comment | added | Robin Betts♦ | Phew.. that's almost a relief. A lot of trial and error avoided. | |
| Apr 21, 2018 at 6:08 | vote | accept | Robin Betts♦ | ||
| Apr 20, 2018 at 22:21 | comment | added | Rich Sedman | @RobinBetts see my edit - I've pretty much convinced myself that the 'shade' option isn't implemented (as is with the 'traceset' option). | |
| Apr 20, 2018 at 22:20 | history | edited | Rich Sedman | CC BY-SA 3.0 |
added 602 characters in body
|
| Apr 20, 2018 at 16:20 | comment | added | Rich Sedman | I see what you mean - and re-reading the OSL spec does seem to indicate potential recursive shading - so if it was the same shader it could potentially get trapped indefinitely unless your code sets some kind of bounce limit. | |
| Apr 20, 2018 at 16:01 | comment | added | Robin Betts♦ | I'll have to try it ... but what I don't understand is, if 'the shader' to be executed is this shader, but at the hitpoint, that's a recursion, and would have to be bottomed out somehow .. (by a threshold value, condition, or message). Even if the hitpoint executes its own assigned shaders, from its own material, it seems to me that would still be calling a shader twice on the same point? Once by us, and again during the renderer's normal progress? | |
| Apr 20, 2018 at 14:43 | history | answered | Rich Sedman | CC BY-SA 3.0 |