Is this ever going to happen? :o

I can confirm that Shaderforge breaks on the second 'play'.

Fair enough, I have not had much experience with arrays, I've learned most of what I have through shader forge so I'm not sure on the limitations and such. What about, say, a heatmap? I have a strategy game with resources underground, represented as an array of vector3 positions for where each patch of ore is under ground. It woukd be nice to pass this to a shader and render out a heat map.

Float4 arrays keep coming up again and again for me. Id like to be able to pass, say, an array of World positions to my shader.

An example: foliage being deformed/moved around by characters walking around the world. I was able to put this together by encoding positions as pixels in a global texture. This shader was made in SF for an aquarium game I never actually finished https://gfycat.com/InfantilePersonalArchaeocete

It works, but it's clunky. I pass the texture source in to a code block and just iterate and sample all pixels and compute an offset for each vertex using 2 for loops. Its clunky and requires lots of texture lookups. Not to mention having to maintain some texture by changing the pixels and reuploading it to the gpu when something moves.

Again, I'm happy to wait for a polished solution, but some form of preliminary experimental support for them would be nice.

Same here

The video OP posted looks like a slightly different issue to what is visible in the screenshot he posted above. I wanted to chime in and say I am alsoe experiencing an issue that puts my shader forge in to a similar state to the screenshot he posted.

There are shader forge editor related errors in the console, the SF editor window is completely unresponsive and i can't Close the window. (mind you, the editor is still responsive). To correct the issue I have to restart Unity or alternatively kill the SF editor window by restoring the editor layout to default.

I'm not in the office right now but I'll try and remember to post repo steps when I get in to the office on Monday.

It is a very annoying bug and happens in between game start/stop. (For me anyway). Its really killing productivity, because I can't make changes, run the game, make more changes, stop the game, continue tweaking the shader, etc. It really breaks the workflow. Every time I want to change the play state I have to close the editor window for SF to make sure it doesn't break.

Again sorry I don't have note details right now. Will get back to you on Monday.

Bump.. I keep budding heads with this restriction, please atleast provide some way for us to make use of global arrays in code blocks, maybe something like what I mentioned in the comment above. I totally understand that adding node graph support for arrays is going to be a beast of a feature for you to implement. I'm happy to wait for a official solution but in the meantime let us make do with code blocks. Maybe an experimental array input node (which can be toggled to "global" like other input nodes), and make it so that it can only connect as an input to a code block or something.

I don't know the cleanest or nicest solution here, but something would be better than nothing...

hey buddy,

Maybe it would be a good idea to give us the power to inject snippets of code in to the shader. I keep running in to issues I could solve using code blocks but I end up needing to declare some variables, and that is impossible to do within shader forge. You need to edit the shader manually. Which sucks.

If in the side bar we could type in some code and have shader forge inject that into the part of the shader where variables are defined, we could work around issues like this where you are unable to keep up with new features. :)

For example, to get array support,i could just tell shader forge to inject "uniform float arrayName[2];" in to the area where variables are defined, and then I can make use of this in a code block. Boom, preliminary array support. I was also just reading a feature request on here regarding projection shaders. The user got it mostly working except that he needer to use a place holder node which he had to later swap out with the correct projection UVs. (I assume by declaring the projecttion UV variable and replacing his place holder variable with that instead). If we had this feature, that issue would be solved too. I am no shader expert but feel that this could be easy to implement and offer good "bang for buck" for you when it comes to deciding which feature will be most useful versus how much effort you have to put in to achieve it.

Bump

Bump