Search the Community
Showing results for tags 'procedural textures'.
Found 3 results
Is this possible with procedural textures code? Say the procedure is currently operating on pixel (1,2) but I want to know the red values of the pixels at (1,1) ánd (1,3) - how do I get that data? Is there any sort of array structure I can use to store and index a lot of different values? Can I directly access the pixel data of the image as an array? Also is there a way of shifting the entire image or perhaps the current row/column by n pixels procedurally (like "affine" but in code)? If not then please consider this a feature request.
I'd like to make some suggestions for making the creation and use of the procedural texture filter a lot easier. Allow the formula to be created in a text area, not just a single line. Making this area collapsible would be great so you could hide it if desired Instead of having to use the RGBA buttons to target a channel, just make those global variables. Then from any equation, if you set R = some value, it would affect the red channel. Documentation There really needs to be more documentation. Not just a list of functions but what those functions do and possibly an example of what they might be used for. Not teaching mathematics but at least giving the idea of what a function does. There is mention that you can't use a variable name that clashes with established function names but there isn't a list of all the function names. Yes, there are the functions like smoothstep, vec3, abs, etc. But it also says you can't use w but we aren't told clearly what w stands for. I know it is width but there is also h which is height and that isn't mentioned anywhere. And then there is rx and ry which are very important but never clearly defined. Having all these clearly defined with an explanation of how they are used is a must. And when would you use x and when would you use rx? I know some of these answers by trial and error but more straightforward documentation would be very helpful. Range inputs It would be really nice to have input ranges instead of just 0-1 and -1 to 1. Without this you have to put scaling variables in the equation which just makes things messy and difficult to read and control. Letting the user define they want the slider to be a real number slider between 1 and 100 (or whatever other range or number types) would be wonderful. Errors It would be really helpful for the system to highlight where the error is instead of just not applying the filter. This would make it easy to find an error quickly especially if it is just a simple error (missing a ; or putting in " instead of ', etc) That's it for now. It's really fun to play with the procedural texture feature but frustrating at the same time. Through trial and error I've been able to make some interesting things but it is very slow going partly because of the above issues and partly because my math education stopped in high school...