vvopensource
vvopensource copied to clipboard
WIDTH and HEIGHT are ingored in passes declaration
I have noticed a difference between isf file I developed between the online editor from https://www.interactiveshaderformat.com and millumin (www.millumin.com/). The WIDTH and HEIGHT keywork are ignored in the passes definition in millumin, but workd correctly on interactiveshaderformat. Millumin developer think it''s a bug in this framework.
hi there-
-
please provide an example of the ISF file you're having problems with (or if that's a bother, just ask your contact at millumin to get in touch with me and we'll take it from there).
-
WIDTH and HEIGHT are optional keys recognized in a pass dictionary- the values stored at these keys are expected to be strings describing equations, and the strings are evaluated just before the pass is rendered to determine the render resolution (this is how you get passes to render at different resolutions).
-
i just checked a handful of ISFs that use the WIDTH and HEIGHT key to render passes at different resolutions, and they all worked as expected when rendered using this framework. i tested using both a simple sample app i threw together from scratch using this framework, and also using the cocoa ISF editor written using this framework- the WIDTH and HEIGHT keys evaluated as expected under all circumstances i've observed so far. that doesn't mean that there isn't a bug- just that i haven't seen the bug you described yet. including the sample ISF you mentioned would be helpful on this point.
thanks for looking at this problem. This the the isf file i'm working on. (sorry, it's not finished, so not very clean) it's a physical model of a 1d membrane used to distord an image. You should move the initialisation to 0, then click bang to get things to move. flaque_07.fs.zip If I remove the WIDTH and HEIGHT key, the shader did not work at all on https://www.interactiveshaderformat.com, so this key are used in some way in millumin, but it look like the physical model texture is not 50x50 as expected. If the line 260/261 are change to this : deforme.x = color2float(IMG_PIXEL(deriveX, coord50./640.)); deforme.y = color2float(IMG_PIXEL(deriveY, coord50./480.)); the shader look almost as expected. (640 and 480 being the image size).
according to the ISF spec, WIDTH and HEIGHT are expected to be strings, but they're numbers in the file you sent me. wrap them in some quotes to turn them into strings and i think you'll be back on the right track!
commit 19437f3698c1a30d4466c9fffee59e55d6fde7b8 updates the framework to recognize numbers in addition to strings- you still need to use strings, but if you forget, your ISF will work regardless in hosts that use this framework. (i checked, the more modern c++ framework already did this)
...i should probably make an ISF linter, i bet that would make it easier to head things like this off at the pass
Thanks for the clarification. I was mistaken because I did not get any error, and it was working elsewere... Thanks also for the commit, it will prevent other not to do the same mistake.