Hello,
I am porting a java application to TouchDesigner
I can not set a Uniform value of “5.46875e-06” in the “Vectors” page of my GLSL Top.
It automatically reverts to the value 0.
A value of “5.46875e-05” works.
I know “5.46875e-06” is supposed to work because it’s working on my java program.
In the GLSL I have set
//precision highp float;
Pixel format is 32 bit float RGBA
Any idea on how to have the value “5.46875e-06” work as a uniform value on a GLSL Top ?
Thanks
If you need to use the value 5.46875e-06 in the body of your shader code, you may want to declare it as a constant instead:
I see what you mean about the rounding of parameters in the Vectors page, this looks like it’s an issue with the input field, not with GLSL.
AFAIK this directive does nothing:
the leading slashes // are used for comments in GLSL code, not for compiler macros.
Thanks for the help.
I definitely need it to be a uniform.
Do you imply to mean that even though 0 is displayed, the actual value is correctly forwarded ?
It is not the case it seems.
How do I provide the value 5.46875e-06 to my GLSL code using a uniform ?
It doesn’t look like the manual float input field supports that degree of precision. This may be a bug.
You could certainly route it into the shader using a different sort of input than the numerical entry fields in the vectors (ie: using a float32 texture, or a CHOP).
Why does it need to be a uniform instead of a constant? Does it change? What is the source of the data?
As you can see in the screenshot, the constant approach successfully gets the value into the shader.
It has to be uniform as it is coming from some OSC source and it is constantly updated
Using float32 texture would not work since the issue is that 64 bit float is required
CHOP does not work either, it’s 32 bit float too
OSC uses 32-bit floats. At least according to the spec that I just went and looked up here:
https://opensoundcontrol.stanford.edu/spec-1_1.html
I don’t believe that the value you specified requires more than 32-bits of precision for accurate representation. Maybe there are other values that you need to send via OSC that have greater required precision.
You’re right about the field truncating very small values though. It would be good to have a moderator or developer cite info about at what point parameter fields round very small values to zero.
Maybe they can provide better guidance. Good luck 
Do you mean that 5.46875e-06 can be represented using 32 bit float?
OSC allows strings, you can send a decimal number requiring 64 bit floats when parsed into non-string representation
and there are implementations with the format “d” (double) floats
and it really is beside the point
I can/could be setting the value via a python callback, with 64 bit python floats
I’m not sure they reply to already replied posts.
Hi @sdtouchdd,
you can always call us in by mentioning us.
Let’s see what opinion @rob or @malcolm have on this.
cheers
Markus
Thanks for the tip!
The problem here is that our parameters clamp really small values to 0 to avoid roundoff errors resulting in ugly UI behavior, especially when you are using the value ladder to move from 0 and back.
One way to get the values as-is into the GLSL nodes is to keep the data in DATs and CHOPs, and use the ‘Arrays’ page to pass the CHOP arrays into the shader as-is, without going through our parameter UI workflow.
Thanks for the explanation.
2 follow-up questions if you can
Is there a way to set array values directly using Python? Something like
op("glsltop").par.array1[0] = 0.1
Or do I need to specify a CHOP in the CHOP parameter ?
Array type is shown as “float”, is it 16, 24, 32 or 64 bit float ?
I am using (and need) 64 bit floats in Python and in the double float variables I use in the shader.
Cheers
You need to specify a CHOP in the CHOP parameter. float means 32-bits in this case. CHOPs are also 32-bit floats. There is currently no pathway to get 64-bit doubles into GLSL, sorry.
Since @sdtouchdd is already considering processing 64-bit values in exponential notation as osc strings, they could pass in the exponent component and base separately and integrate them in the shader, ie:
The values would still be 32-bit floats in the shader, and any 64-bit precision would be lost, but it would allow you to integrate with that data to see if working with the 32-bit value space is feasible.
