FragM 2.5.0 update

Applied a few fixes to texture handling and internal shader initialization, hopefully will handle shader fails and warns nicer.Also added #include MathUtils.frag and made a few small adjustments in the Examples collection (most will probably have done these things already)FragM 2.0.5-181202 winex package and linux deb + rpmAttached results of automated test run...

Finally I could be able to compile it from source on Antergos (Arch Linux). There's is an old version (1.0) at AUR repositories but too old, imho.You provide .deb and .rpm packages wich won't work on other distros. Here are the steps I followed to compile:git-clone https://github.com/3Dickulus/FragM.gitcd FragMcd Fragmentarium-Sourceqmake Fragmentarium.pro

@3dickulus re compiling with qt creator: it moans about all the imps it cannot find and will only compile in there when I edit out all those lines. Attached the compile output in case it might be helpful (had to zip it as txt is not allowed;) )

@batjorge Good to see you! And so nice to read you're using FragM again

Thank you very much for your help!I've followed the indications and it compiled without issues. I was just missing the ExtraCMakeModules and included the missing paths. Being on Xfce4, the interface can be "adjusted" with qt5ct plugin for a better integrationSeems to work smooth, despite some flickering when transforms are applied but very happy to see it working finally

PD, AUR uses tar.xzI attach a first attempt with menger, done in some seconds.

lovely I'm glad you haven't been attacked by the latest bug (raaaaarrrrrr!!!)

okokok made a a really dumb booboo

conflict between GUI and GL thread caused random (and incredibly annoying) crashes where FragM would just quit after rendering, animating, editing just fine, and the backtrace made no sense... until now , sorry I didn't see it sooner my humblest apologies to the brave souls that dare to run my coding on their precious machines

freshened the binary packages and sources on git, seems to be more stable now

A suggestion (request) for anyone that wants to help with this, a definitive test suite using scripting to render all of the default examples and basic things like file, parameters, texture/image loading and saving. The FQS script is basically JavaScript. This is the linux shell script (requires conversion to bat file if on windows) I used to render all of the thumbnails, the lines that are commented out are frags that don't render from script control and required an actual click on Build or some other intervention to make them work ...

That is if someone else doesn't beat me to it as am slightly under the weather after jaw operation with complications which turns my brain into mush for the moment So if anyone wants to give this a go right away, go ahead, might be some days before I can tackle this

@3Dickulus Sorry, maybe I misunderstand what it is you are after! Do you need some sort of 'generic' script that looks into the Examples-folder, finds all files that are 'renderable' and then renders them to a certain folder?

Or do you just want all frags that are in there now rendered for a contact sheet? The latter is ready...

update: the more I look at your message the more I am convinced I am not getting it Brain really IS mush atm...

take it easy Sabine, get your rest, this is just something to play with

Ideally it would be nice to...

run a single fqscript that renders all of the frags that are in the distribution (that are renderable via script control), call them the default examplesfor the animation tutorials, 10 second lores animations, say 640x360 or something (complete to a playable mpeg file <<< might have to add some commands for this to work, test for mplayer?)along with, perhaps at the beginning, a tilesize benchmark and use that tilesize for the rest of the testsmaybe write a parameter file and read it back for comparison, if == then OK, sort of thing

and of course time the entire run, it should start from cmdline and go through all steps with no intervention, there is a script command to close tabs, app.closeTab(int id); so that FragM doesn't have to do a start->run->exit cycle for every frag just app.closeTab(0); before calling app.loadFragFile(fileName);

a well rounded fitness test is the idea, if you need "getter" functions in the fqScript just add them to MainWindow.h public slots section like a function that returns the animation length would be...

int getAnimationLength() { return timeMaxSpinBox->value(); };...and it would get used in fqScript as animlength = app.getAnimationLength(); you can also return values from the QSettings object this way for checking #include paths and tool paths etc. for reporting EXR command availability and ffmpeg/mplayer status etc. etc. etc.

That's definitely the best advice I've had these past few days! Such a shame to have all the time in the world for a week or so and then a brain that's off to the Bahama's or somewhere (not quite sure where, didn't leave a note...)

But, to take your scripting idea a bit further: it would be nice to be also able to let the script read all .frag-files in the Examples folder, check if they have a line #donotrun, else put the filneames into a list/index/array-thingy and then render them with smart filenames. Full automation is the thing we need ;}

Oh well, you will maybe have to remind me of this, once I have completed the logtofile-lesson But: had good fun getting the scripting going, I only had taken a look at that ages ago, so was great to edit the script to get this working in general on my win-machine. BTW: All files did just render an image here(?!), except three by Matt Benesi which seem to have problems with DE-Raytracer (menger-ones)