|
Feline
|
 |
« Reply #15 on: June 14, 2013, 06:11:09 AM » |
|
Nope - I still get the diagonal line with the "triangle" version. Dang.
Meanwhile, just to keep y'all on your toes, I dug up an older version (0.8.0) and lo: I do NOT get a diagonal line in that one.
I guess that's consistent with the fact that I think I only get that line in any of the accumulating ("progressive") raytracers,
which 0.8.0 didn't have (FWIW: eiffieGI.frag has that line as well)
|
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #16 on: June 14, 2013, 11:54:03 PM » |
|
I tried again Nope - I still get the diagonal line with the "triangle" version. Dang.
Meanwhile, just to keep y'all on your toes, I dug up an older version (0.8.0) and lo: I do NOT get a diagonal line in that one.
I guess that's consistent with the fact that I think I only get that line in any of the accumulating ("progressive") raytracers,
which 0.8.0 didn't have (FWIW: eiffieGI.frag has that line as well)
I tried again on the 570GTX and yep, the line is still there. So much for my hypothesis. Some more digging around: I can write 1.0 to all channels in my texture, e.g.: gl_FragColor =vec4(1.0); But when I read from it: vec4 tex = texture2D(frontbuffer, vec2(x,y)); the alpha channel (tex.a) is 0.5, not 1.0 - but only if I sample on the diagonal (x==y), and only if the buffer type is 8-bit or 16-bit integer, and only for the alpha channel. |
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #17 on: June 15, 2013, 12:43:38 AM » |
|
|
|
|
|
|
Logged
|
|
|
|
marius
Fractal Lover
Posts: 206
|
|
« Reply #18 on: June 15, 2013, 04:37:42 AM » |
|
I tried again
I tried again on the 570GTX and yep, the line is still there. So much for my hypothesis.
Some more digging around:
I can write 1.0 to all channels in my texture, e.g.:
gl_FragColor =vec4(1.0);
But when I read from it:
vec4 tex = texture2D(frontbuffer, vec2(x,y));
the alpha channel (tex.a) is 0.5, not 1.0 - but only if I sample on the diagonal (x==y), and only if the buffer type is 8-bit or 16-bit integer, and only for the alpha channel.
Offset the reading position by vec2(0.5/xres, 0.5/yres) to sample the middle of the texels? But, yeah that sounds suspicious with the whole texture all 1.0. Not a normal texel edge sampling issue. |
|
|
|
|
Logged
|
|
|
|
|
Feline
|
|
« Reply #19 on: June 15, 2013, 05:24:11 AM » |
|
Ahh! Excellent. With the "Triangle2" version, I do not get that line any more. Hooray!
So what solved it?
(And major kudos for the customer service here: I gripe about it on a forum and a few days later it's fixed. Wish most companies out there were as responsive as that...)
|
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #20 on: June 15, 2013, 09:26:46 AM » |
|
Ahh! Excellent. With the "Triangle2" version, I do not get that line any more. Hooray!
So what solved it?
Well... It turns out the the "Triangle" version, was actually still using the old two triangle approach to draw the quad. I had reverted the code to test whether the new single triangle approach was slower, and then I uploaded the wrong version :-) So it was an issues along the edges of two triangles. I believe I have disabled all blending and disabled MSAA, so I not sure what caused it, but at least I have a workaround. Offset the reading position by vec2(0.5/xres, 0.5/yres) to sample the middle of the texels?
But, yeah that sounds suspicious with the whole texture all 1.0. Not a normal texel edge sampling issue.
Yes, I also thought about that, but I'm not sampling near the edges of the texture - the problem was along the diagonal. |
|
|
|
|
Logged
|
|
|
|
knighty
Fractal Iambus
Posts: 819
|
|
« Reply #21 on: June 15, 2013, 02:49:53 PM » |
|
A silly question  : What happens if one goes to NVidia's configuration pannel and set in 3D parameters the option "let the 3D application take the decision" (or so, I have it in french)? I say that because I suspect that the application settings (like anti-aliasing) are overrided by the CG drivers by default. |
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #22 on: June 15, 2013, 10:45:30 PM » |
|
A silly question : What happens if one goes to NVidia's configuration pannel and set in 3D parameters the option "let the 3D application take the decision" (or so, I have it in french)? I say that because I suspect that the application settings (like anti-aliasing) are overrided by the CG drivers by default. A good question. I tried restoring my drivers settings to default, and with my drivers at least, the default setting is: "Anti-Aliasing mode: Application Controlled". Interestingly the drivers allow you to enable FXAA and even screen space ambient occlusion. I tested this on a couple of scientific OpenGL applications after setting the Anti-Alias mode to overwrite the application settings, but nothing seemed to happen. Perhaps these are Direct3D only. |
|
|
|
|
Logged
|
|
|
|
|
Feline
|
 |
« Reply #23 on: June 22, 2013, 11:42:58 PM » |
|
Finally having some time to tinker over the weekend, I find that the "workaround version" introduces a bug somewhere in the vicinity of " uniform float time;". As a simple test, open Examples|DrosteGrid.frag and hit "continuous". In the regular version of Fragmentarium.exe this animates the spiral. In the "fixed version" ("Triangle2"?) there is no animation. In the same vein, I seem unable to animate anything else either. Still more work to do for Syntopia, I fear...  |
|
|
|
|
Logged
|
|
|
|
|
Kali
|
|
« Reply #24 on: June 23, 2013, 01:14:28 AM » |
|
The older versions of Fragmentarium used "continuous mode" to animate time variable, but now it's used for progressive renders (backbufferCounter variable)... you must use the "animation" render mode instead. If you want continuous animation mode, set a large amount of seconds and let it play. However, I must say that I miss the quick continuous animation function at one click.
|
|
|
|
|
Logged
|
|
|
|
|
Feline
|
|
« Reply #25 on: June 23, 2013, 01:48:09 AM » |
|
But the regular 0.9.12b does still have the regular animation via "time - or are there multiple versions of 0.9.12b? The version that I downloaded just two weeks or so ago sure seems to animate in "continuous" mode for Examples|2D|DrosteGrid or Examples|2D|DomainDistortion. I do understand that some of the newer raytracers do progressive accumulation - and that's fine with me. If I want to use continuous mode for on-screen animation I just use one of the older ones like FastRaytracer (Or, really, my own - that was what was called "DE-Raytracer" in 0.8 and has since been hacked up into unrecognizability). Except that it looks to me as if time doesn't progress in the recent workaround version (from Jun-15). Or am I completely misunderstanding something somewhere...  |
|
|
|
|
Logged
|
|
|
|
|
Kali
|
|
« Reply #26 on: June 23, 2013, 02:44:23 AM » |
|
You are right, 0.9.12b version animates via "time" variable in continuous mode, this another version 0.9.12 (without the "b") that I'm currently using works like I mentioned, because it has the support for rendering animations using progressive renders (in previous versions you must use old raytracers to animate).
|
|
|
|
|
Logged
|
|
|
|
|
Feline
|
|
« Reply #27 on: June 23, 2013, 03:31:51 AM » |
|
Ohhh - yet another wrinkle I didn't know about. Indeed - in "animation" mode time seems to flow just fine. Man - every time I think what I'm doing I realize I'm just scratching the surface...
|
|
|
|
|
Logged
|
|
|
|
|
Kali
|
|
« Reply #28 on: June 23, 2013, 04:29:33 AM » |
|
Don't worry, it seems like as humans, we are doomed to always scratching surfaces, revealing different layers but never reaching the core. Sorry, totally off-topic, this is not the philosophy section  |
|
|
|
|
Logged
|
|
|
|
|
Syntopia
|
|
« Reply #29 on: June 23, 2013, 04:30:34 PM » |
|
The current four rendering modes in Fragmentarium is a mess.
I need something that the able to support both progressive rendering, animated rendering, and even animated progressive rendering. Some animations may be driven by the 'time' variable, and some simply by flipping the buffers (for instance the game-of-life or RD type systems).
I'm thinking of having just two different rendering modes buttons:
[Progressive (subframe)] and [Animation (time)]
In Progressive mode a 'subframe' integer uniform is incremented (previously known as the 'backBufferCounter'), and time is kept fixed.
In Animation mode, the 'time' variable is a uniform float with time in (fractional) seconds (same as now). The 'Animation' controller window (the timeline window) would be removed. Instead a new 'Timeline' windows could be spawned from the application menu. Rendering an animation would need to be done from the 'High-resolution render' window, where progressive rendering could be enabled, and the FPS could be set.
Image size
The image output size is also clumsy. I'm thinking of having some top-panel widgets, where you could specify buffer size in pizels (or keep it synchronized to the current viewport size), e.g:
Buffer size: x: 640px Y: 400:px [Lock to view size]
Where [Lock to view size] is a drop-down menu, with the following options:
[Lock to 1/2 view size, Lock to 1/4 view size, Lock to 1/6 view size, Preview tile (2x), Preview tile (4x), Preview tile (6x), Custom]
The custom size should be able to have different aspect ratio than the view, but should not be allowed to be larger than the view - hires images still need to be 'tile' rendered in order not to time out. The 'Tile Preview' and 'Preview' sliders could then be removed.
|
|
|
|
|
Logged
|
|
|
|
|
February 26, 2012, 11:53:43 PM
Dilber MC Theme by HarzeM