QScripting Fragmentarium

[Patryk Kizny]

Would that be possible to expose also the custom screen buffer size  to be set from QS?
Actually, it would be also cool to provide some sort of onFrameChaged() handler that would execute an attached script on scrubbing.

[Patryk Kizny]

It looks like ther's something strange going on with the numbers rounding when coming from QTS to the interface widgets and then to the shader.

The following screen shows How the numbers do not fit at all.
Highlighted is a row that is applied to the sliders. sliders are all uniform vec3.
The columns are 123 --> js_Right, 456 --> js_Up, 789 --> js_Dir.

The problem is not that they are rounded at say 10th postion, but rather they are getting rounded randomly introducing unpredictable deviations.

[Syntopia]

My version of Fragmentarium used spinboxes with 5 decimals places, so something has changed. Internally, these values are floats (since thats what normal GPU's support anyway), so the precision is not high. Also, these sliders are auto-normalizing which might introduce some more inaccuracies.

[3dickulus]

yes, the precision is jacked up a bit,
going from 11 decimal places in the data array to 9 in the gui should introduce some rounding,
would moving back to 5 decimal places be helpful in this situation? or make it worse?

edit: reverted back to original code and applied more decimal places w/o messing with the widget logic, 7 decimal places seems to be the upper limit even though double type is used internally for tracking the value shared by slider and spinner. (in v1.0.10 source)

[Patryk Kizny]

Thanks for looking into that!

[3dickulus]

after some (more) testing I have set it up so that the slider sets the spinner and the spinner sets the slider and ComboWidget::setValue() sets them both but they don't interfere with each other ie:niether calls ComboWidget::setValue(), means you can type numbers into the value box unimpeded,  ComboWidget::setValue() is only used when reading parms from a file or editor to set both slider and spinner at once.

source code is available for testing w better exr handling too

[Patryk Kizny]

Great! What are your thoughts on the QS buttons I suggested earlier in this thread?

[3dickulus]

Sorry Patryk but that's just too much for me, just haven't got the time and I'm trying to keep it simple, the basic minimum is there for anyone to elaborate on, the current functionality allows me tor run it on several machines in an automated fashion, that's all I really wanted but as a bonus we get scripting abilities with full access to all user created variables that show up in the GUI, the other thing that it needs is network abilities so that I can control the process from one box.

[Patryk Kizny]

No worries. You made a huge effort already and I appreciate all the tools. Maybe it's time for me to get into Cpp.

[lycium]

No worries. You made a huge effort already and I appreciate all the tools. Maybe it's time for me to get into Cpp.

We should be working together for Martin anyway This weekend I'll do a bit more work on my fractal renderer, but my main problem is the Distance Estimators

[3dickulus]

Great! What are your thoughts on the QS buttons I suggested earlier in this thread?

study up on the QScript docs and, as I have mentioned before, you will find information on using QDesigner to create your own GUI plugin that uses the script interface to control Fragmentarium. This feature of QScript could be used for custom dialogues tailored to your specific VFX pipeline needs.

just for fun some stats... and a little speculation.

There are 15,227 lines of C++ code in the current incarnation of Fragmentarium
Out of all accesses to Fragmentarium-1.0.10-3Dickulus.zip on my website only 3 are identified as being from a computer based browser the rest are bots and iPhones

Those 3 accesses
 1 Virgin networks U.K. Infrastructure
 2 China Mobile Communications Corporation Beijing
 3 Unitymedia dynamic customer IP pool Germany

this leads me to believe that only one (#3) is a real person that has actually downloaded the source code and that is possibly only for a look at the OpenEXR and/or QScript stuff so they can write it into their own code. (just speculating)

If I could make a suggestion, Patryk, write your own VFX studio version from the ground up in C++ around the fragment shader code as the rendering engine, this way you will have exactly what you are looking for in your VFX pipeline, or use Synthclipse which is easier to modify via java than Fragmentariums C++. It should be able to load your .frag scripts too.

[3dickulus]

Would that be possible to expose also the custom screen buffer size  to be set from QS?

the current list of commands available via fqs...

    void loadFragFile(name)
    void setParameter(name, bool)
    void setParameter(name, int)
    void setParameter(name, float)
    void setParameter(name, float, float )
    void setParameter(name, float, float , float)
    void setParameter(name, float, float , float, float)
    void setParameters(parmList)
    void setAnimationLength(int)
    void setTileWidth(int)
    void setTileHeight(int)
    void setTileMax(int)
    void setSubFrames(int)
    void setOutputBaseFileName(name)
    void setFps(int)
    void setStartframe(int)
    void setEndframe(int)
    void setAnimation(bool)
    void setPreview(bool)
    void tileBasedRender()

    void selectKeyFrame()
    void addKeyFrame(name)
    void clearKeyFrames()
    void initKeyFrameControl()

    int getFrame()
    bool initializeFragment()
    void callRedraw()

    bool scriptRunning()

the bold ones determine the buffer size.

[Syntopia]

I have also had this feeling about Fragmentarium myself: it is a lot of effort to make new UI features, and people have wildly varying feature requests. In particular I found myself limited wrt to the scripting, and how to extend to more flexible buffer configurations (to allow e.g. shadow mapping, bloom, DOF by blurring depth information, etc.)

Therefore I decided to try some other approaches starting a year ago or so. I wanted to make an API (which I called FragAPI), providing simple access to the following features: (1) Setting up buffers and the flow between them (including support for accumulated rendering and tile rendering) (2) Handling 2D and 3D cameras. (3) Some means of reusing shader code (like the 'include' syntax in Fragmentarium)

I made a prototype testing in JavaScript (2D only): http://syntopia.github.io/fragapi/
And some similar experiments in Java (using JOGL): https://github.com/Syntopia/Meshia/tree/master/FragAPI/src/net/hvidtfeldts/fragapi

However, these projects seem to be progressing in slow-motion for the time being, though I still think there is a use for a simple API for setting up GPU pixel graphics. GLSL is a wonderful and simple language to write in, but setting up the OpenGL stuff is a pain.

[3dickulus]

setting up the OpenGL stuff is a pain.

indeed    things change fast too.

[3dickulus]

My version of Fragmentarium used spinboxes with 5 decimals places, so something has changed. Internally, these values are floats (since thats what normal GPU's support anyway), so the precision is not high. Also, these sliders are auto-normalizing which might introduce some more inaccuracies.

I think I fixed at least one thing, the Eye and Target values remained at 5 decimals while all of the other combo widgets happily operated at 7 decimal places after jacking it up a bit. This bothered me, a lot, because I couldn't figure out why, this may have been the source of the problem Patryk was having.

changed the slider min max from 0 and <a large number> to minimum*<a large number> and maximum*<a large number>
removed myValue and (myValue-minimum)/(maximum-minimum)
set slider from spinner with val*<a large number>
set spinner from slider with val/<a large number>

now the Eye and Target combowidgets use 7 decimal places.

the default precision in Qt is 6 decimals when converting between strings and floats so I also adjusted all conversions accordingly.

needs testing but it seems stable.