-
-
Notifications
You must be signed in to change notification settings - Fork 38
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
Add iDate builtin to Shadertoy utility #428
Conversation
Hey, I believe I need a bit of help with a particular issue. iDate is a vec4 with 32bit floats. the best reference I found is this: https://www.shadertoy.com/view/ldKGRR (this shadertoy doesn't run due to an unrelated issue with I believe the syntax...), but another example that does work which I have been using to test this is here: https://www.shadertoy.com/view/MdVcRd. The straight forward idea was to just add a new object to the shader._uniform_data.mem.hex(" ", 4)
'00000000 00000000 00000000 00000000 00004844 0000e143 0000803f 88c55540 d6a09a3f 01000000 00e0fc44 00002041 0000a841 9788b945 00000000 00000000'
mouse-f-4, resolution-f-3, time-f-1,t_d-f-1, frame-I-1,date-f-4, pad?, pad?; In python everything looks correct, the offset makes sense, the views are correct etc. But I am not sure how it is handled on the c side. Since the order of fields in the UniformArray matches the data of shader._uniform_data.mem.hex(" ", 4)
'00000000 00000000 00000000 00000000 00004844 0000e143 0000803f 8a538d41 4695e43f 03000000 00000000 00000000 00e0fc44 00002041 0000a841 2612d545'
mouse-f-4, resolution-f-3, time-f-1,t_d-f-1, frame-I-1,pad-I-1,pad-I-1, date-f-4; I don't think that is a good solution and It feels like I might be breaking something else. |
Yes, alignment of fields in a uniform array is tricky 😄 See e.g. https://www.w3.org/TR/WGSL/#alignment-and-size It's usually best to put larger fields first. In fact, I think that if you put |
I added an example and it also passed all tests and examples. (mem_tests fail, but that seems to be unrelated). |
Seems like there is a lint failure, otherwise this looks good to me! 👍 |
looks like |
starting my list from pygfx/shadertoy#15 with the the
iDate
builtin.this seems straight forward, since time is already used in
_update
I was expecting this to be an easy add.the milliseconds via the perf_timer that is already there seem like a janky solution.
the format seems to be correct, and it's also correctly updated. But none of the shaders I tried work as expected.
Tasks:
._update
(isn't working correctly)(currently seconds are in iDate.y, but should be in iDate.w)found a solution that feels incorrectAddressed correctly and docstring added for guidance[ ] add the ability to freeze date fornot with this PR.snapshot
(maybe ?)