GLSL Shader Actor : 'parameter setting window'
-
I notice the 'parameter setting window' of the GLSL Shader Actor takes settings from the Isadora created input parameters in the GLSL code. Any tweaking of the 'parameter setting window' is lost when compiling the code again, navigating away from the GLSL scene or closing the Isadora file - as it is replaced by the range specified in the code the next time the GLSL shader is activated. Apart from limiting the range in the code, is there a way to retain the 'parameter setting window' input range?
CheersBonemap -
I don't have a way of testing it right now - but I would suggest trying an enter scene trigger-> trigger value actor. . . Hopefully that will get the right numbers in there at the start.
-
Hmmm...but if you are talking about a setting in the sub-menu window that pops up when you double click the glsl actor and not an actual setting in the code that you have used one of the //Isadora * methods for interacting with - then this may be a feature request / bug report.
-
Thanks @Aolis,
Yes - it could be that I need to use 'limit scale' actors if I want to keep the variable ranges in the GSLS code less specific. Or perhaps I haven't got the //Isadora float inputs quite right?Cheersbonemap -
Dear @bonemap,
Yes, this is a bug in fact. I've got it on my list of stuff to fix. But thanks for pointing it out!Best Wishes,Mark -
Hi @Mark,
Another issue I am having with entering code into the GLSL actor is - getting it to save. A number of times updates to my code have not saved with a command 's'. I have resorted to copying and pasting into a .txt file to ensure I retain the changes. Could you also outline how the actor is dealing with iterations of GLSL code. For example, are there any foreseeable issues with multiple instances of GLSL actors in the same or adjacent scenes?Can I assume a user GLSL actor in the toolbox can only be modified by pasting over the text file that defines it? I notice there is not the save/replace options similar to the User actors in the toolbox.Cheersbonemap -
Dear @bonemap,
Well, I saw this save problem at the Werkstatt but was never able to recreate it. But this was only dealing with shaders that were local to the file, not with ones that were loaded from .txt files.Do you have any sense of a pattern here? I tried again just now and was not able to recreate this bug. But I'm pretty sure you're right that it's there.As for the .txt file, right now, I think we should add an option to update not just the shader you're editing, but the .txt file and all instances of the same shader (i.e, ones that came from the .txt file.) This would essentially be the same behavior as a user actor. That's a feature request which I might not get to for the release of v2.5, but would add as soon as I can manage.Best Wishes,Mark -
I will enter this as a feature request right now.
-
Hi @Mark,
There is a pattern, and I think it is a creep over time. For example, I start to notice the code box not completely refreshing around the 'compile' and 'OK' buttons. These symptoms then appear to be accompanied by save failure. The code box may be open for extended periods - there tends to be a lot of tweaking and compiling or periods with the box open for longer. I am also using multiple wave generators at low Hz to animate the attributes of a shader. The frame rate and cycles can fluctuate widely rendering some code. The save failure has happened on very short code and longer.Cheersbonemap -
Dear @bonmap,
Thank you for these comments. I'll take a look at it.One note regarding your statement "The frame rate and cycles can fluctuate widely rendering some code." This is probably not Isadora but the code itself. If the code has "for/next" loops (e.g., for (i=1; i<20; i++) ) these are very expensive in terms of GPU performance. If/then statements are also suspect in this regard. Running multiple instances of these will only make the situation worse.It's good to remember that, while GPUs are astonishingly fast, they are not an unlimited resource.Best Wishes,Mark -
Thanks @Mark,
This is good advice. It is important to get a feel for the limitations and performance of the shaders in the mix. The detailed shaders offer more allure as they approach representational simulations. Gaining an understanding of control inputs into those visual worlds is worth investigating and mastering. To understand the point where a shader is unviable for the GPU is a necessary lesson. The Isadora inputs might not be in themselves taxing the GPU, however the parameters supplied by these inputs can have a dramatic effect on the performance of some shaders - And it looks like the shaders I am most drawn to investigating may be the ones prone to limited realtime manipulation. We shall see.cheersbonemap -
This shader, for example, wants more than what it can get from my GPU. The fps fluctuate with the amount of detail generated by the Isadora input parameters. 571d3d-bonemap_glsl_test.izz
-
Thanks for posting this, but "swaying strands" actor is empty, so I can't give it a look. John
-
@JJHP3 Thanks for letting me know. If you are interested I will post the .txt file. Perhaps it is not possible to share a patch file with a GSLS shader embedded? Cheers Bonemap
-
Hmmm, this does seem like a bug. When I try opening the file, I get an error that the Swaying Strands actor can't load. I see it in the patch - but when I double click the actor it minimizes as though it were a normal actor and not a GLSL one. . . .
-
I have created a new Isadora file and pasted the GLSL code into a new instance of the GSLS Shader actor. I notice that the generic GLSL actor no longer has its badge - there is no GLSL logo or Creative Commons logo displaying on the actor node.I have attached here the new Isadora file and the .txt file for Swaying Strands.Let me know if you have any suggestions for the code to become more efficient or for some frame rate gains.cheersbonemap -
as Mark said, the for loops are tieing things up.
You could add published Int inputs to set these dynamically.. (one is hard coded to 256 and another to 8)Changing the 256 to 128 still has a similar effect, while 64 loses the thru/cutout sections.. but is interesting in its own way.I can run the file at my more than 1080p screen resolution for about 30secs before my gtx 870m starts to over heat... then I have FPS dropping drastically. I use 'TechPowerUp GPU-Z' to check the status of GPU. Its for PC, not sure of a Mac equivalent. -
Thanks Ryan,These overhead issues are going to require quite a bit of understanding. I am pretty sure that I don't have the coding ability to resolve them. Might have to look at asking for help from my programmer friends.I get what you are talking about - I am just not there in terms of being able to go straight to a solution.Cheersbonemap -
Well, the simple answer is this: if a shader drops your FPS, then it's a 'heavy' program. There may not be a way for non-coders to solve this, as the loops are part of what makes the image look the way it looks.The simplest rule of thumb to say if you see a "for" or an "if" or an "else" then you can rest assured that this shader is suspect in terms of its performance impact.If you want to dig further, look for statements like this: "for (x=0; x<**256**; x++)" The number in bold is the top limit of the loop. This example shows that the loop will repeat 256 times. My guess than anything greater than 8 or 16 at the most is going to cause trouble. (Remember, that those 256 iterations are going to be performed on every pixel of the image. If the image is 1920x1080, that's 530 million calculations!)Best Wishes,Mark -
Thank you for your time to provide additional advice about the use of the GLSL Shader and confirm the warning signs to look out for. Each investigation can only lead to a better understanding.Regardsbonemap
