Title: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 01, 2013, 11:37:25 PM Hi, I finally got some time to improve on Fragmentarium.
I have redesigned the UI in order to simplify it. This should solve some fundamental problems in Fragmentarium. (http://blog.hvidtfeldts.net/media/frag1.jpg) Now there are only two modes: - Progressive, for creating accumulated images (e.g. as multiple samples per pixels). An uniform named 'subframe' keeps track of the current frame (and replaces the old 'backbufferCounter' uniform). - Animation, where a single 'time' uniform can be used to control dynamics. The buffer size no longer needs to be locked to the window size, although it is possible to do so. This means it is now possible to work with buffers with different aspect ratio and size than the OpenGL window. The old 'Animation Controller' window is gone. Instead the time variable may be controlled by a new slider in the main UI. In order the render animations to disc, the new 'High Resolution and Animation Render' window must be used: (http://blog.hvidtfeldts.net/media/frag2.png) As can be seen, it is now possible to render animations at arbitrary resolution and using multiple subframes, if so desired. There is also a progress dialog making it possible to actually stop the renders. It is also possible to open a preview in a dialog window inside Fragmentarium. The code has also been cleaned up. The prefered build environment is now Qt Creator 2.7 together with Qt 4.8.5(a project file has been added), though the old VS2008 project has been updated and is working as well (and the Debug configuration now works). (As a side note, Qt Creator has really matured to become a great IDE for C++ programming) The plan is to remove the worst bugs from this in the next couple of weeks, and then release this as version 1.0, since Fragmentarium is becoming somewhat stable. So please report bugs and/or suggestions to me. After version 1.0, my plan is to start working on integrating some of the key frame interpolation into Fragmentarium. Also, if you have any frags you think should be part of the standard distribution please send them to me. The latest build can be downloaded here (Windows only): http://hvidtfeldts.net/Fragmentarium%20-%20Windows%20-%20V1.0%20beta%203.zip Title: Re: Fragmentarium 1.0 Beta 1 Post by: eiffie on August 01, 2013, 11:55:08 PM Thanks for these updates Syntopia!
Title: Re: Fragmentarium 1.0 Beta 1 Post by: knighty on August 02, 2013, 12:02:04 AM Argh! eiffie was faster!
Thank you Syntopia! :thanks2: :worm: Title: Re: Fragmentarium 1.0 Beta 1 Post by: knighty on August 02, 2013, 12:36:23 AM I'm having a lot of flickering due to clearing the buffer to white, especially with slow scripts.
The rendering window is not redrawn automatically when it goes from background to foreground and when it is partially hiden by a foreground window. Title: Re: Fragmentarium 1.0 Beta 1 Post by: slon_ru on August 02, 2013, 01:08:36 AM Very thank you!
Should it work with NODE-Raytracer ? br Title: Re: Fragmentarium 1.0 Beta 1 Post by: cKleinhuis on August 02, 2013, 06:55:03 AM great! too bad i dont have a computer right now :(
Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 02, 2013, 07:42:40 AM "Excellent!" (Mr. Burns voice)
Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 02, 2013, 10:16:41 AM I'm having a lot of flickering due to clearing the buffer to white, especially with slow scripts. The rendering window is not redrawn automatically when it goes from background to foreground and when it is partially hiden by a foreground window. OK - I'll look into that. I actually ignore some update signals which is probably a bad idea. It works on my machine however - no flickering, and no tearing. My guess is that Windows 7 does some extra buffering / composition before rendering. What Windows version are you using? Have you disabled Aero? When I disable aero I get the failed redraws, but no flicker, though. Very thank you! Should it work with NODE-Raytracer ? br I think so. But you might have to replace 'backbufferCounter' with 'subframe' in the code. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 02, 2013, 10:24:16 AM had the same white flash fixed by turning on QGLWidget doublebuffering also fixes other windows drawing into the render area, turning on QDB doesn't seem to have any negative impact on rendering or other operations but I haven't tested exhaustively, works on my box :D
OS Information OS: Linux 3.1.10-1.29-desktop x86_64 System: openSUSE 12.1 (x86_64) KDE: 4.7.2 (4.7.2) "release 5" Display Info Vendor: nVidia Corporation Model: G92 [GeForce 9800 GT] 2D driver: nvidia 3D driver: NVIDIA 304.88 Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 02, 2013, 11:10:03 AM Yes, double buffering also solves the problem, but on my machine the CPU usage increases from 25% to 50% when rendering animations (I wonder why there is any CPU usage at all, but that is probably a driver thing).
I have updated the drawing code to better respond to update requests. In earlier versions of Fragmentarium I supported direct renders, where the shaders where drawn directly to screen, but now I always require that the heavy shader write to a FBO, which is then rendered to screen using the buffer shader (which is a very fast operation). This means I can do faster updates by just rendering the last drawn buffer to the OpenGL window. Here is a patched version (replace the exe by this one) - let my know if it works for you. [Use link in first post in this thread] Title: Re: Fragmentarium 1.0 Beta 1 Post by: JosLeys on August 02, 2013, 11:22:20 AM I opened a frag file that uses a HDR image as a background, and the image is not showing up.
(I did transfer the image to the Inc directory under Examples. Fragmentarium is not complaining that it cannot find it) Then I loaded another image, which did show up. Switched back to the image I wanted and it did show up also, but as I start an animation, it loses the image again. Title: Re: Fragmentarium 1.0 Beta 1 Post by: slon_ru on August 02, 2013, 11:57:26 AM replace 'backbufferCounter' with 'subframe' in the code. Very thank you! It works!! :beer: :beer: :beer:Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 02, 2013, 12:43:35 PM I opened a frag file that uses a HDR image as a background, and the image is not showing up. (I did transfer the image to the Inc directory under Examples. Fragmentarium is not complaining that it cannot find it) Then I loaded another image, which did show up. Switched back to the image I wanted and it did show up also, but as I start an animation, it loses the image again. I cannot reproduce this, so I need a bit more information here: Can you run the "Examples \ Tutorials \ 25 - Image Based Lighting" example? Does switching backgrounds here work? How do you switch images: do you use the texture combo boxes in the "Parameters (uniform)" panel? Does the "Run" button turn yellow after a change, and did you press it to apply the changes? When the texture disappears from the animations, is that in the main window (by pressing "Animation (time)" button)? Or animations done in the "High Resolution and Animation Render" dialog? Are the HDR images very large (in pixel dimensions)? Btw, in preferences you can extend the include path to a suitable image folder, e.g. my include path is: "Examples/Include;f:\hdr". This way images do not need to be copied into the include folder. Are anyone else experiencing problems with textures? Title: Re: Fragmentarium 1.0 Beta 1 Post by: JosLeys on August 02, 2013, 12:57:52 PM Quote Can you run the "Examples \ Tutorials \ 25 - Image Based Lighting" example? Does switching backgrounds here work? Yes, it works, and I can change the background to any other image.Quote How do you switch images: do you use the texture combo boxes in the "Parameters (uniform)" panel? Does the "Run" button turn yellow after a change, and did you press it to apply the changes? Yes to all.Quote When the texture disappears from the animations, is that in the main window (by pressing "Animation (time)" button)? Or animations done in the "High Resolution and Animation Render" dialog? Main window. The texture disappears when the animation starts running: in other words, it is there in the current frame, but disappears as of the next frame of the animation.Quote Are the HDR images very large (in pixel dimensions)? The one I was using is quite large : 8000*4000 86 MbQuote Btw, in preferences you can extend the include path to a suitable image folde OK, thanks!I sent you the frag file in a personal message. You just need to change the image to one of yours. Title: Re: Fragmentarium 1.0 Beta 1 Post by: Tim Emit on August 02, 2013, 05:27:46 PM Huge thanks..look forward to having an explore later :D my fave frac prog atm :D
Title: Re: Fragmentarium 1.0 Beta 1 Post by: knighty on August 02, 2013, 10:58:30 PM OK - I'll look into that. I actually ignore some update signals which is probably a bad idea. It works on my machine however - no flickering, and no tearing. My guess is that Windows 7 does some extra buffering / composition before rendering. What Windows version are you using? Have you disabled Aero? When I disable aero I get the failed redraws, but no flicker, though. I'm still using XP. :embarrass:It also looks like the redering is recomputed for each mouse event (when changing view location). This gives it an inertia which is more noticeable with slow shaders. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 03, 2013, 02:04:15 AM compiling...
line 49 in DisplayWidget.h causes error... Code: boolean isContinuous() { return continuous; }Code: bool isContinuous() { return continuous; }line 246 in MainWindow.cpp the primitives = QRegExp has an entry "greaterThanqual" should this be "greaterThanEqual" ? Code: ThirdPartyCode/hdrloader.cpp: In static member function ‘static bool HDRLoader::load(const char*, HDRLoaderResult&)’: no effect on CPU usage when enabling QGL doublebuffering for this version of linux Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 03, 2013, 05:26:15 PM compiling... line 49 in DisplayWidget.h causes error... Code: boolean isContinuous() { return continuous; }Code: bool isContinuous() { return continuous; }line 246 in MainWindow.cpp the primitives = QRegExp has an entry "greaterThanqual" should this be "greaterThanEqual" ? Code: ThirdPartyCode/hdrloader.cpp: In static member function ‘static bool HDRLoader::load(const char*, HDRLoaderResult&)’: no effect on CPU usage when enabling QGL doublebuffering for this version of linux Thanks, 3dickulus - I've updated the code. Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 03, 2013, 05:28:48 PM I opened a frag file that uses a HDR image as a background, and the image is not showing up. (I did transfer the image to the Inc directory under Examples. Fragmentarium is not complaining that it cannot find it) Then I loaded another image, which did show up. Switched back to the image I wanted and it did show up also, but as I start an animation, it loses the image again. I think I got this fixed now - could you try downloading this new build: [Use link in first post in this thread] Title: Re: Fragmentarium 1.0 Beta 1 Post by: JosLeys on August 03, 2013, 05:49:03 PM Yes, it works.
Just one thing, when opening the frag file I had to manually reload the hdr image before it became visible. After that everything works fine. Thanks! Title: Re: Fragmentarium 1.0 Beta 1 Post by: Roquen on August 03, 2013, 09:04:42 PM DepthBufferShader.frag:230 & ZBufferShader.frag:187
Vec3 -> vec3 Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 03, 2013, 10:38:26 PM DepthBufferShader.frag:230 & ZBufferShader.frag:187 Vec3 -> vec3 Thanks Roquen, it has been fixed. I should probably mention that earlier versions of Fragmentarium supported writing built-in types with upper-case, e.g. Float, Vec3, Mat3 and so on. These upper-case types would be converted to either single (float, vec3, ...) or double (double, dvec3, ...) depending on a preferences setting. But I have now removed this functionality, since it raised a lot of other problems. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 04, 2013, 04:13:25 AM a couple of other warnings at compile time, compiles and runs here but may be an issue for other OSs...
Code: Fragmentarium/GUI/MainWindow.cpp: In member function ‘void Fragmentarium::GUI::MainWindow::clearTextures()’: Code: Fragmentarium/GUI/VariableWidget.h: In constructor ‘Fragmentarium::GUI::SamplerWidget::SamplerWidget(Fragmentarium::GUI::FileManager*, QWidget*, QWidget*, QString, QString)’: do these show up when compiling with Windows? Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 05, 2013, 09:07:14 AM Syntopia, in the source file MainWindow.cpp at line 1110 you ask the question "Isn't there a Qt function to copy entire images?"
yes there is, change the XY pixel loop from this ... Code: for (int i = 0; i < maxTiles*maxTiles; i++) {Code: QPainter painter(&finalImage); QImage is a QPainterDevice O0 Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 06, 2013, 08:35:21 PM Syntopia, in the source file MainWindow.cpp at line 1110 you ask the question "Isn't there a Qt function to copy entire images?" yes there is, change the XY pixel loop from this ... Thanks, 3dickulus - I really did not expect any answers to this :-) Works fine! Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 06, 2013, 09:20:10 PM do these show up when compiling with Windows? No, but they should be fixed now. On Windows the only (harmless) warnings are in HDRLoader.cpp, which I did not write myself. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 07, 2013, 12:25:08 AM I've noticed that animating the "Up" vector has some issues, when any one component transitions 0.0 or reaches +/-1.0 the rendering goes sideways...
by that I mean it doesn't render any more at all. the GL area goes blank and nothing short of a restart will fix it, I tracked the problem down to variablewidget.cpp where Float3Widget values get normalized if they are -1 to 1, when one of them reaches 1.0 the other two snap to 0.0 causing a divide-by 0 error somewhere?, I haven't tracked it any farther than this, my fix is not to "normalize" the "Up" vector and everything seems to work smoothly. so a question: if the max and min values of the sliders are 1 -1 is that not, in effect, already normalized? edit: I know it's not a "unit sphere" but will a unit cube do? Title: Re: Fragmentarium 1.0 Beta 1 Post by: Roquen on August 07, 2013, 01:21:45 PM Without looking at the source I'd guess that this is a look-at formulation which is degenerate for straight-up and straight down (speaking roughly here). I'll take this opportunity to repeat that it would be nice to additionally have a roller-ball like interface.
Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 09, 2013, 08:04:52 AM nope, it's the up vector, lookat is tracking target spline path perfectly
Title: Re: Fragmentarium 1.0 Beta 1 Post by: Roquen on August 09, 2013, 08:21:24 AM I'm lazy...can you point me to the code in question?
EDIT: I was talking about a lookat matrix like formulation...creating an orthogonal basis via cross products. Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 09, 2013, 06:22:54 PM I've noticed that animating the "Up" vector has some issues, when any one component transitions 0.0 or reaches +/-1.0 the rendering goes sideways... by that I mean it doesn't render any more at all. the GL area goes blank and nothing short of a restart will fix it, I tracked the problem down to variablewidget.cpp where Float3Widget values get normalized if they are -1 to 1, when one of them reaches 1.0 the other two snap to 0.0 causing a divide-by 0 error somewhere?, I haven't tracked it any farther than this, my fix is not to "normalize" the "Up" vector and everything seems to work smoothly. so a question: if the max and min values of the sliders are 1 -1 is that not, in effect, already normalized? edit: I know it's not a "unit sphere" but will a unit cube do? I can set my 'Up' vector to any value in the UI without problems. Does this only happen when you are animating the Up-vector or also in the UI? The Up vector does not need to be normalized (it must have a length>0, though). The "3D.frag" used by most shaders will make sure the Up vector is made orthogonal to the Direction view vector and normalized after that. Notice that proper interpolation of orientations in 3D space is subtle: you cannot just interpolate the individual components of the Eye, Target, and Up vector and expect everything to be fine. Ideally, the (Target-Eye) and Up should be orthogonal at all frames - indeed, if they are parallel the shader cannot posibly construct an orthonormal basis for the camera. Title: Re: Fragmentarium 1.0 Beta 1 Post by: Syntopia on August 09, 2013, 06:35:07 PM I'll take this opportunity to repeat that it would be nice to additionally have a roller-ball like interface. Virtual sphere and arcball interfaces are mostly suited for rotating objects, not for moving the camera. I don't think they are very usable for navigating a 3D world (unless there is a way to specify the pivot (rotation center)). Notice, that when pressing shift in Fragmentarium it is possible to "rotate" around origo - the rotation here follows the screen space axes, which I find to be an adequate way of rotating objects. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 09, 2013, 08:45:30 PM In the variable editor, when I move any component of the up vector to +|- 1 the other two 'snap' to 0 and the one I moved will only go to -1 or +1 and not between ie:0.25 as if the step rate has been set to 2. (code from Syntopia github, unmodified, not when animating, no other Float3Widgets are affected)
The widget is created with Max == Min as a flag to normalize or not (in VariableWidget::Float3Widget), I think this is the problem, I adjusted the max/min to be -1 & +1 rather than 0 & 0 in 3D.frag and the components of the Up vector no longer 'snap' to 0 or get restricted to +1 and -1 If the components that need to be normalized are handled in the GLSL code it seems unnecessary to normalized them at the widget input level and from a GUI programming standpoint I don't think using the Max/Min widget settings as a flag is a good idea. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 09, 2013, 11:01:46 PM The "Up" vector is generated from the relationship between eye and target, understood. I don't try to set the "Up" vector independently of Eye|Target when animating, rather, I save the "Up" vector generated as a result of moving the Eye|Target. The problem shows up when the camera does a roll, pitch or yaw that transitions through 0.0 or goes more than 180deg.
this animation was no possible when the "Up" vector widget has Min & Max == 0 enabling normalize() in Float3Widget. http://www.fractalforums.com/index.php?topic=16765.msg64281#msg64281 (http://www.fractalforums.com/index.php?topic=16765.msg64281#msg64281) Title: Re: Fragmentarium 1.0 Beta 1 Post by: marius on August 10, 2013, 01:38:03 AM The "Up" vector is generated from the relationship between eye and target, understood. I don't try to set the "Up" vector independently of Eye|Target when animating, rather, I save the "Up" vector generated as a result of moving the Eye|Target. The problem shows up when the camera does a roll, pitch or yaw that transitions through 0.0 or goes more than 180deg. You'll find that splining over the up and direction vector values individually does not play nice with rolls etc. You probably want to use quaternions and even then convert those to a representation that splines nicer (and back). I use https://code.google.com/p/boxplorer2/source/browse/trunk/interpolate.cc#177 (https://code.google.com/p/boxplorer2/source/browse/trunk/interpolate.cc#177) for the latter. The other conversion routines in that file, from matrix to quat and back, are pretty specific with respect to handedness of your setup. Not sure what Fragmentarium uses. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 10, 2013, 02:48:23 AM It's not a problem when "Up" Max/Min are set to 1 and -1 or when the "Up" vector is not normalized at the widget input level. I don't think it's the normalizing that causes the problem I think it's Qt widget getting Max == Min so Range == 0, not sure yet so a little more investigating is in order.
Title: Re: Fragmentarium 1.0 Beta 1 Post by: Roquen on August 10, 2013, 01:45:31 PM Virtual sphere and arcball interfaces are mostly suited for rotating objects, not for moving the camera. I don't think they are very usable for navigating a 3D world (unless there is a way to specify the pivot (rotation center)). Yeah I was only thinking in terms of UI and not really animating a camera. The "shift" input is adequate (although the rotation is IMHO opposite direction to my expectations) for bringing the desired surface into view. What I find troublesome is getting the desired orientation...so the equivalent be begin able to rotate about an axis straight out (or into) the screen. Of course I can get this behavior via some GLSL code so I'll stop whining on this subject.Notice, that when pressing shift in Fragmentarium it is possible to "rotate" around origo - the rotation here follows the screen space axes, which I find to be an adequate way of rotating objects. For something completely different I have a quasi-random thought: What about having the engine provide a uniform (say vec4) which the components are the ith value of a low-discrepancy sequence, say Halton, where 'i' is the subframe number. The thought is that this could be used to replace random number generation in some situations and would actually have better properties that uniform pseudo-random for some usages and zero shader overhead. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 14, 2013, 06:36:02 AM I still get the following warning...
Code: Fragmentarium/GUI/VariableWidget.h: In constructor ‘Fragmentarium::GUI::SamplerWidget::SamplerWidget(Fragmentarium::GUI::FileManager*, QWidget*, QWidget*, QString, QString)’: the fix is not in the order of occurrence in the implementation but in the order of occurrence in the declaration. in VariableWidget.h file, private section, move "QString defaultValue;" to be after "FileManager* fileManager;" prevents "initialized after reorder" warning. I don't know if this causes any problems, the compiler should sort it out but best to be on the safe side. Title: Re: Fragmentarium 1.0 Beta 1 Post by: Alef on August 15, 2013, 03:47:33 PM Hi, I finally got some time to improve on Fragmentarium. I have not quite a frag file, but maybe this could be fragmentalised. Also, if you have any frags you think should be part of the standard distribution please send them to me. It would require brute force or NODE raytracer. It is the attempt on Infernal Grail, at least it have some features of what 3D mandelbrot could have, it have simple formula and are pretty zoomable. (http://www.ljplus.ru/img4/a/s/asdam/3D_mandel_3.jpg) http://www.fractalforums.com/new-theories-and-research/few-steps-behind-perfect-3d-mandelbrot/ (http://www.fractalforums.com/new-theories-and-research/few-steps-behind-perfect-3d-mandelbrot/) I have lots of stuff like this in chaos pro, but this seems to be the most well grailish. http://www.chaospro.de/formulas/display.php?fileid=222 (http://www.chaospro.de/formulas/display.php?fileid=222) And there were some guys wanting support of colour pallettes, maybe fractint map file support. Title: Re: Fragmentarium 1.0 Beta 1 Post by: Alef on August 15, 2013, 04:23:13 PM But textures are fare better in 3D than colour pallettes + orbit traps.
Title: Re: Fragmentarium 1.0 Beta 1 Post by: vinz on August 17, 2013, 06:36:04 PM HAhaha Amaizing to see Fragmentarium growing... ;D
Title: Re: Fragmentarium 1.0 Beta 1 Post by: slon_ru on August 29, 2013, 02:43:36 PM Hi!
NODE-Raytracer works in the preview window only. Can you help me ? Thx! br Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 30, 2013, 09:14:41 AM I had a blank white screen until I changed "backbufferCounter" to "subframe" as mentioned on the opening page of this thread
Title: Re: Fragmentarium 1.0 Beta 1 Post by: SCORPION on August 30, 2013, 11:33:33 AM Yes, I confirm, after replacing the white window disappeared and it worked, but not rendering - always after rendering a black screen. At any resolution.
How to fix this problem? Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 30, 2013, 01:20:09 PM in the NODE-Raytracer.frag file, change the last line in the trace routine (around line 452)
from... Code: return vec4(newc,r); Code: return vec4(newc*2.0,r);
NODE-Raytracer doesn't seem to be up to date with the current version of Fragmentarium GLSL scripts, your results may vary. double check, make sure you changed ALL of the occurrences of "backbufferCounter" to "subframe" hope this helps. :beer: edit: disclaimer = this is just a hack so you can see what's going on, it's not a fix for the problem Title: Re: Fragmentarium 1.0 Beta 1 Post by: slon_ru on August 30, 2013, 02:22:13 PM From "High Resolution and Animation Render" with Node-Render get black screen out :(.
newc*2.0 and rename "backbufferCounter" to "subframe"does not help. Title: Re: Fragmentarium 1.0 Beta 1 Post by: 3dickulus on August 30, 2013, 05:23:33 PM hmm... sorry I couldn't help but at least I can see that it is rendering, that's a start. edit: I think it's because NODE-Raytracer doesn't use 3D.frag or BufferShader.frag and was written when a single buffer was ok, now Fragmentarium requires a number of buffers and uses the buffershader for post-render effects. a little hacking and it should go :) |