November 17, 2014 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
November 17, 2014 [00:00:57] *** Codex_ has joined ##OpenGL[00:02:09] <Langdal> I have another question now: I have written a cylinder vertices generator, and I use a VBO of colours to colour the cylinder. But I need an awfully big colour VBO if the cylinder has a lot of vertices (if I use many slices). Is there a way to instead just use 3 colours in my VBO and then somehow repeat them?[00:02:24] <Smilex> HuntsMan2: http://sprunge.us/EHaJ <- A bit late, but here's the frag shader[00:03:12] *** MinFarshaw has quit IRC[00:03:39] <Smilex> I'm not using modf there, but I'm trying to find the correct UV coordinates, based on which tile the current fragment belongs to[00:04:12] <Smilex> Langdal: What about using Uniforms?[00:07:13] *** suppahsrv has quit IRC[00:07:33] *** suppahsrv has joined ##OpenGL[00:08:21] *** Misu has quit IRC[00:08:43] *** Misu has joined ##OpenGL[00:09:44] <Langdal> In what fashion do you suggest using Uniforms for this? Sorry I'm pretty new to openGL. Currently I'm only using uniforms for my MVP.[00:09:58] <chrisf> Langdal: for `material color`, which this appears to be.[00:10:51] *** bb010g has joined ##OpenGL[00:11:13] <newguise1234> you could also use gl_vertexID and mod by some number for repeating colors[00:12:12] <Smilex> Langdal: I'd use glUniform3f(loc, 3, colors)[00:12:41] *** hamsham has joined ##OpenGL[00:14:54] *** Orion] has quit IRC[00:16:22] <Langdal> Thanks guys, I'll just finish the vertex generator and then I'll look at my shaders.[00:17:58] *** razieliyo has joined ##OpenGL[00:22:39] *** ablepharus has joined ##OpenGL[00:24:18] *** clauswitt has quit IRC[00:25:49] *** Suchorski has quit IRC[00:26:52] *** zajfy has quit IRC[00:29:51] *** void256_ has joined ##OpenGL[00:31:44] *** luxigo has quit IRC[00:31:46] *** void256 has quit IRC[00:32:01] *** void256_ is now known as void256[00:32:47] *** Keniyal has joined ##OpenGL[00:32:50] *** zgreg has quit IRC[00:33:23] *** zgreg has joined ##OpenGL[00:33:24] *** Codex_ has quit IRC[00:36:21] *** shintah has quit IRC[00:36:29] *** zgreg has quit IRC[00:36:54] *** quovadis has quit IRC[00:37:02] *** BitPuffin has quit IRC[00:37:27] *** luxigo has joined ##OpenGL[00:37:52] *** zgreg has joined ##OpenGL[00:41:39] *** stefkos has quit IRC[00:42:12] *** luxigo has quit IRC[00:44:16] *** ragecryx has quit IRC[00:44:21] *** zgreg_ has joined ##OpenGL[00:44:21] *** zgreg has quit IRC[00:48:14] *** BitPuffin has joined ##OpenGL[00:49:17] *** apoc_ has quit IRC[00:49:21] *** zgreg_ has quit IRC[00:49:58] *** luxigo has joined ##OpenGL[00:51:00] *** TunnelCat has joined ##OpenGL[00:53:13] *** Orion] has joined ##OpenGL[00:56:41] *** tcsc has joined ##OpenGL[00:57:08] *** slime has quit IRC[00:58:44] *** bkre_ has quit IRC[00:59:16] *** Zupoman has quit IRC[01:05:05] *** Apeiron` has quit IRC[01:05:10] *** magicthing has joined ##OpenGL[01:05:29] *** Apeiron` has joined ##OpenGL[01:06:54] *** zgreg has joined ##OpenGL[01:07:20] <magicthing> do you guys have any links to a good explanation of quaternion rotations? mainly i'm interested in the parameters to give into the quaternion class i have, i'm wondering whether they take radians or degrees or what. My quaternion function is Quaternion(x,y,z,w) so would i be completely off to say I want an x-axis rotation by 90 degrees, i'd write Quaternion(1,0,0,pi/2) ?[01:08:14] *** apoc has joined ##OpenGL[01:09:35] *** paul424 has joined ##OpenGL[01:13:06] *** apoc has quit IRC[01:13:40] *** zgreg has quit IRC[01:14:36] *** apoc has joined ##OpenGL[01:15:50] *** Smilex has quit IRC[01:17:34] *** zgreg has joined ##OpenGL[01:17:39] <Langdal> newguise1234: Now I combined your answers and use a uniform vec3 array for the colours, and then I use a gl_VertexID % 3 to select a color (3 is the number of colors atm). Thanks.[01:21:57] *** cr`nge has quit IRC[01:23:32] <paul424> http://fabiensanglard.net/quake2/quake2_opengl_renderer.php[01:23:57] *** DolphinDream has quit IRC[01:24:09] <paul424> You may think that the low number of polygons in an alias would have allowed to calculate normal and dot product normal/light in real time....but NO. All dotproduct are precalculated and stored in float r_avertexnormal_dots[SHADEDOT_QUANT][256], where SHADEDOT_QUANT=16.[01:24:22] <paul424> Quantization is used: The light direction is always the same: {-1,0,0}.[01:25:08] <paul424> ehem , is there something I do miss ? What I mean is how it is possible to quickly rotate those two vectors so the light position is as mentioned[01:25:25] <paul424> SO IT even PAYS OFF to use the look - up table ?[01:25:48] *** slime has joined ##OpenGL[01:26:07] *** luxigo has quit IRC[01:27:44] <paul424> no idea >_>, Euler angles could be used for that particular representation, but as all knows normal vectors ain't stored in such a way[01:31:04] *** indefini has quit IRC[01:31:08] *** ablepharus has quit IRC[01:32:06] *** luxigo has joined ##OpenGL[01:32:20] <paul424> Bloodust: ?? :)[01:36:23] *** cr`nge has joined ##OpenGL[01:36:34] *** Khlorghaal has quit IRC[01:37:22] *** DaGardner has quit IRC[01:39:07] *** charlie5 has joined ##OpenGL[01:44:54] *** Misu has quit IRC[01:45:20] *** luxigo has quit IRC[01:45:53] *** Crehl has quit IRC[01:49:45] *** foreignFunction has quit IRC[01:51:15] *** void256 has quit IRC[01:54:17] *** alhsekufahlsief1 has left ##OpenGL[01:56:23] *** lenarhoyt has joined ##OpenGL[01:59:14] *** MinFarshaw has joined ##OpenGL[02:02:48] *** stef has quit IRC[02:04:16] *** BitPuffin has quit IRC[02:04:28] *** stef has joined ##OpenGL[02:05:04] *** fatalhalt has joined ##OpenGL[02:09:07] *** MinFarshaw is now known as centrinia[02:15:49] *** Tha_grid has joined ##OpenGL[02:16:00] *** indefini has joined ##OpenGL[02:16:51] *** centrinia is now known as Report[02:16:54] <Tha_grid> What happens when you call glTexImage2D without pixel data?[02:17:01] *** Report is now known as centrinia[02:17:28] <newguise1234> magicthing: I felt as if at least the glm quaternion constructor did something to the values I tried to pass in, so I ended up setting the values manually based on what I wanted.[02:17:58] <newguise1234> magicthing: x*sin(theta/2) y*sin(theta/2) z*sin(theta/2) cos(theta/2)[02:18:12] <newguise1234> gives you theta rotation around vector x,y,z I believe[02:18:21] <newguise1234> preferably using normalized values[02:19:10] <newguise1234> I didn't look into what it did though, and I kind of just wanted it to work, so I'm sure there is a more consistent and better way than to set that manually[02:20:39] *** zgreg has quit IRC[02:20:43] <glYoda> "What happens when you call glTexImage2D without pixel data?" …well passing TexImageND a NULL pointer will give you a uninitialized allocation[02:20:44] *** zgreg has joined ##OpenGL[02:21:07] <glYoda> so you'll effectively get garbage[02:23:19] *** Tha_grid has quit IRC[02:23:41] *** qeed has quit IRC[02:23:49] <newguise1234> thanks Langdal I was afraid it was a stupid suggestion haha[02:31:54] *** DolphinDream has joined ##OpenGL[02:33:29] *** TyrfingMjolnir has quit IRC[02:35:51] *** glYoda has quit IRC[02:36:01] *** glYoda has joined ##OpenGL[02:36:36] <paul424> glYoda: may the force of GL be with you[02:37:01] <glYoda> it is :)[02:37:04] <glYoda> heheh[02:38:11] <paul424> Quake 2 was not fully 3D : the d lights onto models where projected in doggy fashion[02:39:02] <paul424> hmm applied*[02:39:23] <paul424> each ID engine is always pretending to do much more stuff than it is doing in reality[02:40:06] <paul424> The best quote of Carmac was , the one before the Q2 premiere[02:40:36] <paul424> An journalist asked whether they want to support the Direct3D -- shiny new lib from M$[02:41:17] <paul424> ANd he said , no cause everything what the 3D chipset is helping with for the CPU , is going to be wasted anyway[02:41:28] <paul424> for the expensive API calls on the CPU side :P[02:41:44] <paul424> M$ -- FTW ![02:43:12] *** Garner has quit IRC[02:56:31] *** Langdal has quit IRC[02:58:16] <bodie_> how hard is it to alter an object's mesh while it's being rendered? say I want to have an arbitrarily complex terrain mesh that can be deformed[03:02:03] *** Zerflag has joined ##OpenGL[03:03:43] *** hdon has quit IRC[03:08:44] <roboman2444> bodie_, very easily[03:08:49] <roboman2444> vertex shaders are perfect for this[03:09:25] <roboman2444> paul424, the DLights in quake 2 and q1 are done the same way that most dlights in source are done[03:09:42] <roboman2444> do some weird trickery math and shittily modify the lightmap[03:09:53] <roboman2444> then the entitiy just samples from the nearest point on the lightmap[03:09:59] <paul424> source ?[03:10:20] <roboman2444> i think in more modern systems, the lightmap also encodes the average light direction as xyz, so you can get a fake spec from it as well[03:11:01] <roboman2444> source as in valve's shitty engine that they've been using for the past 10 years[03:11:43] <roboman2444> OFC they have a few lights that dont use this method, such as the flashlight[03:11:52] *** meoblast001 has joined ##OpenGL[03:11:55] <roboman2444> but everything else is the quake 1 style of writing to a lightmap[03:11:59] <bodie_> roboman2444, wouldn't that only work for displacing individual vertices/[03:12:07] <roboman2444> bodie_, yeah[03:12:19] <bodie_> I'm talking about a mesh with changing content[03:12:23] <roboman2444> yeah?[03:12:31] <roboman2444> you mean more/less verts and faces?[03:12:34] <bodie_> yea[03:12:34] <paul424> http://www.youtube.com/watch?v=J7KCzRtplNY atari quake !!!!![03:12:38] <roboman2444> either use the cpu or geometry shader to do it[03:15:03] <bodie_> roboman2444, so you'd suggest stacking deformations via geometry shader instead of altering the vbo's contents with GL_DYNAMIC_COPY or some such?[03:15:14] <roboman2444> geometry shader can be slow[03:15:19] <bodie_> yeah, that sounds expensive[03:15:27] <roboman2444> for simplicity sake, i would suggest first get it working in CPU[03:15:45] <roboman2444> if you are aiming for a gl4 platform, maybe add code for a compute shader to do it instead[03:15:47] <bodie_> I'm trying to find out whether it's feasible[03:15:52] <bodie_> hm[03:16:00] <roboman2444> compute shader method will end up better than geo shader method, most likely[03:16:50] <bodie_> could you do something like putting a set of points in as vertices, having them go into the compute shader, and having geometry come out?[03:16:59] <roboman2444> yeah[03:17:04] <roboman2444> err[03:17:08] <roboman2444> well, maybe[03:17:17] <roboman2444> you want to have it connect the verts?[03:17:25] <bodie_> right[03:17:31] <roboman2444> that might not be possible in geo shader[03:17:34] <bodie_> I think, unless there's a better way[03:17:40] <roboman2444> you want terrain LOD?[03:17:41] <bodie_> I was also thinking of using a depth field somehow[03:17:46] <bodie_> not necessarily, no[03:17:58] <roboman2444> CPU side or compute shader might be best for you[03:18:09] <bodie_> but it's reasonably possible?[03:18:09] <roboman2444> especially since compute shader can push directly into a vbo[03:18:16] <bodie_> hm[03:18:21] <roboman2444> well anything is possible on the cpu[03:18:23] <bodie_> lol[03:18:40] <bodie_> yeah if you have a nondeterministic machine[03:18:52] <bodie_> :P[03:19:09] <bodie_> "just render that thing I was imagining" done[03:19:18] <bodie_> (it's bigger on the inside)[03:19:24] *** hdon has joined ##OpenGL[03:21:31] *** zgreg has quit IRC[03:21:55] *** zgreg has joined ##OpenGL[03:23:49] *** Textmode has joined ##OpenGL[03:25:58] *** Martty_ is now known as Martty[03:26:28] *** paul424 has quit IRC[03:31:44] *** roboman2444 has quit IRC[03:34:15] *** oberstein has quit IRC[03:34:39] *** Gamecubic has joined ##OpenGL[03:37:14] *** Lucretia has quit IRC[03:37:55] *** oberstein has joined ##OpenGL[03:38:01] *** Lucretia has joined ##OpenGL[03:39:38] *** TyrfingMjolnir has joined ##OpenGL[03:41:00] *** faty has joined ##OpenGL[03:41:52] *** hahuang61 has quit IRC[03:46:17] *** charlie5 has quit IRC[03:46:18] *** roboman2444 has joined ##OpenGL[03:49:15] *** Hunts2 has joined ##OpenGL[03:50:57] *** Zerflag has quit IRC[03:52:29] *** charlie5 has joined ##OpenGL[03:52:51] *** HuntsMan2 has quit IRC[03:55:50] *** TyrfingMjolnir has quit IRC[03:56:00] *** DapperPixpy has joined ##OpenGL[03:56:49] *** TyrfingMjolnir has joined ##OpenGL[03:59:47] *** b4b has quit IRC[04:00:44] *** luxigo has joined ##OpenGL[04:02:07] *** slidercrank has quit IRC[04:07:33] *** SleekoNiko has quit IRC[04:07:41] *** Orion] has quit IRC[04:09:56] *** TunnelCat has quit IRC[04:19:51] *** SleekoNiko has joined ##OpenGL[04:20:40] *** xissburg has quit IRC[04:25:52] *** b4b has joined ##OpenGL[04:27:20] <ra4king> wow, I'm uploading 411MB of data to a mapped buffer storage every second at 200 FPS[04:27:48] <ra4king> each frame contains about ~2MB of data that needs to be uploaded, and it's so fast[04:30:36] *** razieliyo_ has joined ##OpenGL[04:30:51] *** razieliyo has quit IRC[04:31:08] *** asdtrfygjhknklm has joined ##OpenGL[04:32:50] <Textmode> :/[04:33:08] *** samrat has joined ##OpenGL[04:33:22] <bob_twinkles> the throughput of the PCI bus is insane if you can saturate it[04:34:35] <ra4king> yeah I'm in awe[04:35:06] <ra4king> the crazy part is uploading 411MB of data within a second takes a total of ~0.5ms![04:35:10] <ra4king> HALF A MILLISECOND![04:35:22] <bob_twinkles> it's a like 100+ bit parallel bus[04:35:29] <ra4king> that's 125 memcpy's![04:36:01] <ra4king> I'm going to try to push it until I stop getting 200 FPS[04:36:07] *** linuxuz3r has quit IRC[04:38:26] *** HaltingState has quit IRC[04:42:19] *** nimitz has joined ##OpenGL[04:48:58] *** Cabanoss- has joined ##OpenGL[04:49:46] *** telex has quit IRC[04:50:38] *** telex has joined ##OpenGL[04:51:17] *** TyrfingMjolnir has quit IRC[04:52:01] *** Cabanossi has quit IRC[04:52:02] *** Cabanoss- is now known as Cabanossi[04:53:56] *** paperManu_ has quit IRC[04:55:10] *** urraka has quit IRC[04:55:36] *** luxigo has quit IRC[05:00:54] *** zgreg has quit IRC[05:01:01] *** zgreg has joined ##OpenGL[05:03:12] *** luxigo has joined ##OpenGL[05:03:52] <chrisf> ra4king: how exactly are you measuring that to take ~0.5ms ?[05:15:37] *** linuxuz3r has joined ##OpenGL[05:18:20] *** linuxuz3r has quit IRC[05:21:06] *** Voidwalkr has quit IRC[05:21:12] *** zgreg has quit IRC[05:21:29] *** zgreg has joined ##OpenGL[05:21:32] *** Voidwalkr has joined ##OpenGL[05:22:27] *** Serus has quit IRC[05:23:43] *** samrat has quit IRC[05:24:10] *** Serus has joined ##OpenGL[05:25:04] *** slime has quit IRC[05:25:17] *** shingshang has joined ##OpenGL[05:27:15] *** slime has joined ##OpenGL[05:31:58] *** Zerflag has joined ##OpenGL[05:46:11] *** icedev_ is now known as icedev[05:55:48] *** BreadProduct has joined ##OpenGL[05:59:49] *** luxigo has quit IRC[06:08:08] <Domx> iOS SDL GUI?[06:08:41] <Domx> text boxes and buttons really[06:13:30] *** tcsc has quit IRC[06:16:32] *** RockLee has quit IRC[06:24:21] *** OliverUv has joined ##OpenGL[06:24:37] *** samrat has joined ##OpenGL[06:30:37] *** RyanPridgeon has quit IRC[06:31:59] *** b4b has quit IRC[06:32:57] *** RyanPridgeon has joined ##OpenGL[06:32:58] *** razieliyo_ has quit IRC[06:33:00] *** fatalhalt has quit IRC[06:33:33] *** Zerflag has quit IRC[06:35:03] <OliverUv> Hello! Can anyone tell me why this function only works as I expect it to when strobe_red is an as of yet undefined uniform? https://gist.github.com/2833cba3e42d19b0fcc8[06:35:10] <OliverUv> when I define it, everything turns dark[06:35:45] <OliverUv> setting powr = vec3(4.0) or such will also make it not work[06:35:55] <OliverUv> the purpose is to brighten all pixels[06:36:56] *** Thrzsh has joined ##OpenGL[06:37:31] *** b4b has joined ##OpenGL[06:38:04] *** jdolan has quit IRC[06:38:42] *** jdolan has joined ##OpenGL[06:39:22] *** b4b has quit IRC[06:39:53] *** Zupo has joined ##OpenGL[06:41:38] <OliverUv> hm, works if I manually do sum_mod * sum_mod and divide by 3[06:41:43] *** mat^2 has quit IRC[06:42:08] *** Zupo2 has quit IRC[06:46:03] <newguise1234> OliverUv: if powr = 2, it would be sum_mod^2 and sum_mod/(1)[06:46:29] <newguise1234> change line 9 to powr+1 and you'll have what you just described[06:48:01] <OliverUv> hm, doesn't help[06:48:52] <OliverUv> btw, I can assume that `vec3(1, 2, 3) = vec3(2, 3, 4) - 1`, right?[06:48:54] *** meoblast001 has quit IRC[06:49:11] <OliverUv> so I don't have to wrap the 1 in vec3(1) ?[06:49:20] <OliverUv> (as long as I write 1.0 when I need floats)[06:49:34] <newguise1234> or 1.0f I think[06:49:56] <OliverUv> hm[06:50:28] <OliverUv> works with neither 1.0f, 1.0, 1 or vec3(1.0)[06:50:39] <OliverUv> all give the same result, whether i've got an addition or subtraction at line 9[06:51:00] <OliverUv> everything looks fine and dandy until the uniform strobe_red becomes defined[06:51:19] <newguise1234> what are you passing in to strobe_red?[06:51:28] <OliverUv> a value [0.0,1.0][06:51:38] <OliverUv> a float[06:52:39] <OliverUv> oh also, everything work if I switch `sum_mod = pow(sum_mod, powr)` to `sum_mod = sum_mod * sum_mod`, and divide by 3 on line 9[06:52:52] <OliverUv> so I know the algorithm is correct, it is just some of my usage of the pow function that is wrong[06:53:02] <newguise1234> when strobe_red is defined as well?[06:53:19] <OliverUv> and that somehow it also works correctly when strobe_red is undefined[06:54:03] <OliverUv> oh whoa holy damn[06:54:05] <chrisf> does anyone have a copy of the extension spec for GL_NV_viewport_array2 ?[06:54:05] <OliverUv> huh[06:54:13] <OliverUv> no it stops working when strobe_red is defined[06:54:16] <newguise1234> OliverUv: might be that pow doesn't work with vecs[06:54:18] *** Voidwalkr has quit IRC[06:54:18] <OliverUv> even though it isn't involved here at all[06:54:28] <OliverUv> no it should work with vecs: https://www.opengl.org/sdk/docs/man/html/pow.xhtml[06:54:49] <OliverUv> it seems there's a problem elsewhere in the shader where strobe_red is used[06:55:27] <OliverUv> hah!!! weird[06:55:31] <OliverUv> I have updated the gist:[06:55:32] <OliverUv> https://gist.github.com/2833cba3e42d19b0fcc8[06:55:34] <OliverUv> that code work[06:55:36] <OliverUv> works[06:55:38] <OliverUv> all the time[06:55:48] <newguise1234> nice[06:56:04] *** asdtrfygjhknklm has left ##OpenGL[06:56:04] <OliverUv> but if I uncomment line 3, it breaks, but only if strobe_red is defined[06:56:27] <newguise1234> does strobe_red affect sum at all?[06:56:33] <OliverUv> no[06:56:37] <newguise1234> does it throw any compile/link errors?[06:56:58] <newguise1234> is your code actually binding to the attribs/uniforms?[06:57:06] <OliverUv> i've never seen a shader produce output when it has errors[06:57:09] <OliverUv> but i'll check![06:57:15] <OliverUv> oh yeah, it is binding[06:57:21] <OliverUv> i am using the strobe for other things and that works fine[06:59:34] <OliverUv> hm no, no errors or warnings[07:00:09] <newguise1234> 1000.0f * strobe_red?[07:01:10] <OliverUv> same result[07:02:04] <OliverUv> should be noted that neither sum_mod nor powr are used outside of this context[07:02:08] <newguise1234> what if you said: float power = 1000.0f * strobe_red[07:02:19] <newguise1234> sum_mod = pow(sum_mod, vec3(power))[07:02:33] <newguise1234> low_brightness = sum_mod / (power+1)[07:03:38] *** Zupo2 has joined ##OpenGL[07:03:47] *** Zupo has quit IRC[07:04:10] <OliverUv> worth a shot[07:04:53] *** hahuang61 has joined ##OpenGL[07:05:50] <OliverUv> btw, this works while using power: https://gist.github.com/2833cba3e42d19b0fcc8[07:05:55] <OliverUv> while not using strobe_red[07:07:07] <OliverUv> your suggestion did not work[07:07:41] <newguise1234> is your strobe red a float? or a vec3[07:07:54] <newguise1234> I'm really not sure TT____TT[07:08:09] <newguise1234> and I'm afraid I'm just filling your head with stuff that'll run you around in a circle[07:08:13] <OliverUv> strobe_red is float[07:08:27] <OliverUv> ok so i got it working[07:08:30] <OliverUv> sort of[07:08:31] <OliverUv> https://gist.github.com/2833cba3e42d19b0fcc8[07:08:53] <OliverUv> look at that p[07:08:57] <OliverUv> ridiculous[07:09:03] <newguise1234> lol[07:09:28] <newguise1234> so the other didn't work if you said power - 1.0f?[07:09:38] <newguise1234> or power - vec3(1.0f)?[07:09:48] <newguise1234> man, I probably steered you wrong on that one[07:10:41] <OliverUv> nope[07:10:52] <OliverUv> well it's good to exhaust options, so don't worry[07:11:02] <newguise1234> well I'm at a loss, glad you got it working though lol[07:11:37] <newguise1234> does it break if you set p to a value?[07:11:48] *** Ad1_RnR has joined ##OpenGL[07:12:08] <OliverUv> yeah[07:12:24] <OliverUv> actually wait no[07:12:33] <OliverUv> it makes everything back if i set it to a large value[07:13:06] *** MLM has quit IRC[07:13:46] <newguise1234> nice[07:13:59] <OliverUv> btw i have verified the algorithm here: https://gist.github.com/aef85881b2ef4dc0636b[07:14:18] <OliverUv> it should work for powers up to 100[07:14:21] <OliverUv> at least[07:14:37] <OliverUv> produce brighter and brighter images the higher one goes[07:15:56] *** Ad1 has quit IRC[07:16:49] *** Budd has quit IRC[07:16:55] <OliverUv> (and, for powers >= 2, will ensure that every value becomes larger, but always stays within [0,1] - also ensures that values closer to 0.5 grow more than values closer to 0 and 1)[07:17:01] <OliverUv> (so it is pretty much perfect)[07:17:52] *** Zupo2 has quit IRC[07:18:02] *** Zupo has joined ##OpenGL[07:18:10] <newguise1234> nice[07:18:13] *** HaltingState has joined ##OpenGL[07:18:27] <OliverUv> oh shittttt i am doing it wrong when going from python to glsl[07:18:39] <newguise1234> lol[07:21:46] <OliverUv> ok, got it working now :D[07:22:26] <newguise1234> what part of the translation was wrong?[07:22:40] <OliverUv> hold on, doing some testing[07:23:09] <OliverUv> updated: https://gist.github.com/2833cba3e42d19b0fcc8[07:23:14] *** foreignFunction has joined ##OpenGL[07:23:20] <OliverUv> note line 11[07:23:32] <newguise1234> oh nice[07:23:34] <newguise1234> haha[07:23:52] <OliverUv> so nice![07:23:53] <OliverUv> :D[07:24:25] <OliverUv> with p = 200 it the algorithm doesn't work[07:24:39] <OliverUv> idk if it's due to wacky floating point arithmetic or if it is mathematically inherent[07:24:46] <newguise1234> chrisf: I'm sorry, I can only find stuff related to ARB_viewport_array[07:25:07] <OliverUv> probably float arithmetic, since it is easy to verify mathematically what the bounds for the values are[07:25:08] <chrisf> newguise1234: yep; it looks like there is no publicly available spec.[07:25:14] <newguise1234> OliverUv: 32bit float you get 24bits for your mantissa[07:25:46] <OliverUv> ┐(´ー｀)┌[07:25:47] <newguise1234> I guess thats not directly related[07:25:53] <OliverUv> newguise1234: thanks for the help btw[07:26:05] <newguise1234> haha, it was all you man[07:26:19] <OliverUv> yeah but without discussion i would probably have stared myself blind at this[07:26:19] <chrisf> newguise1234: (it's a new feature on 970/980 which allows you to cheaply broadcast a primitive to layers or viewports without needing a GS emitting N copies of the thing manually)[07:26:47] <newguise1234> I know how you feel OliverUv[07:27:11] <newguise1234> chrisf: that sounds nice, but I'm working with gl 2.1 and 3.3 if I'm lucky, sorry I can't share in your excitement :/[07:27:15] <newguise1234> I'm also pretty new at this[07:27:36] *** narcan has quit IRC[07:27:41] <newguise1234> I can see how that may be helpful, due to just implementing instances for the first time though[07:27:56] <newguise1234> so I do understand how much easier something like that can make life :p[07:28:14] <ra4king> chrisf: I took the time before and after the ~125 memcpys[07:29:00] <chrisf> newguise1234: is definitely in 'extra nice to have path' territory, not something you can rely on[07:31:34] <chrisf> newguise1234: im not actually looking to use it; just want to read the spec :)[07:31:46] *** Thrzsh has quit IRC[07:31:59] <newguise1234> lol, how is it different from ARB_viewport_array?[07:32:37] *** kuldeepdhaka has joined ##OpenGL[07:32:42] <chrisf> newguise1234: from the one sample ive found: you get a new builtin gl_ViewportMask[07:33:16] <chrisf> newguise1234: the primitive goes to all viewports whose bit is set in the mask[07:34:11] <chrisf> newguise1234: and a new qualifier for outputs: layout(viewport_relative), which appears to cause the viewport index to be added to that output, in each copy[07:34:45] *** luxigo has joined ##OpenGL[07:34:47] <newguise1234> so, instancing for viewports? sounds pretty handy, especially if you have multiple people looking at the same thing from different angles[07:34:58] <newguise1234> pretty cool man[07:35:59] <chrisf> can put layout(viewport_relative) on gl_Layer, to broadcast into layers of a layered framebuffer[07:36:34] *** hdon has quit IRC[07:37:10] <chrisf> the example given was faster filling of cascaded shadow maps, but would also work for rendering into cubemaps or voxel grids[07:37:33] *** damir__ has quit IRC[07:37:43] <chrisf> but, no spec, so im piecing things together[07:38:03] <newguise1234> where are you finding the code samples?[07:39:59] *** luxigo has quit IRC[07:40:20] <OliverUv> (in python i can verify that the algo works until p=1024)[07:40:32] <OliverUv> (guessing they use more bits than glsl for their floats!)[07:40:36] *** luxigo has joined ##OpenGL[07:40:51] <newguise1234> are you on a 64bit machine?[07:42:50] <OliverUv> yes[07:42:51] <OliverUv> wow[07:43:10] <OliverUv> at p=200 it doesn't work at all (black image)[07:43:26] <OliverUv> but at p=195, I get cool effects[07:43:50] <OliverUv> I take the bright image and do outputColor = mix(ouputColor, bright_image, brightness)[07:44:02] <OliverUv> when brightness = 0.5 i get an extra bright image[07:44:16] <OliverUv> when it is = 1.0, the brightest colors go from white to weird shades[07:44:19] <OliverUv> strong reds, greens[07:45:05] <OliverUv> oh wait actually it only depends on the brightness of the input to the brightening function[07:45:06] <OliverUv> cool[07:45:08] <OliverUv> so it's like an overflow[07:45:19] <newguise1234> nice haha[07:45:22] *** DaGardner has joined ##OpenGL[07:46:06] <OliverUv> actually getting overflows at 100 too, but input has to be almost entirely white[07:47:19] <OliverUv> actually getting overflows already at 10, but only if used in conjuction with my saturation increasing method[07:47:35] <OliverUv> so probably only for values that diff from 1.0 with like .99[07:47:41] <OliverUv> i mean .01[07:48:18] <OliverUv> the contrast function is really simple though, so nothing wrong there: https://gist.github.com/2833cba3e42d19b0fcc8[07:48:23] <OliverUv> just overflows :)[07:48:44] <OliverUv> wait i'm stupid, that should obviously overflow[07:48:51] <newguise1234> thats kinda cool man, abusing hardware effects lol[07:49:42] *** Chais has quit IRC[07:49:47] <XMPPwocky> newguise1234: oh check this out[07:50:56] <XMPPwocky> newguise1234: https://www.shadertoy.com/view/4sfGDj[07:52:15] *** Chais has joined ##OpenGL[07:52:44] <newguise1234> haha nice[07:53:04] <OliverUv> p = 6: getting nice sublte overflows in brightest areas when maximizing both contrast and brightness[07:53:13] <XMPPwocky> newguise1234: crank up maxiters to 200 and it's really neat[07:53:20] <newguise1234> oh, I can't actually view it :/[07:53:20] <OliverUv> gonna keep it at that :), doing VJ software so it's a cool effect to have[07:53:27] <newguise1234> was excited solely about the site[07:53:56] *** luxigo has quit IRC[07:55:27] <XMPPwocky> https://www.shadertoy.com/view/XdjGzR there's also this neat effect, where you can actually get the correct behavior for cubemaps[07:55:29] <newguise1234> sorry XMPPwocky I've got an old version of chromium, probably combined with some other aspects of my system, I can't view it[07:55:34] <XMPPwocky> when the object is not in the center of the cubemap[07:57:25] *** luxigo has joined ##OpenGL[07:57:26] <OliverUv> XMPPwocky: that first shader you pasted was cool[07:57:55] <XMPPwocky> OliverUv: yeah[07:58:04] <OliverUv> how do I increase max iters ?[07:58:13] <XMPPwocky> OliverUv: see it in the source code, change it[07:58:18] <XMPPwocky> and hit the play button[07:58:20] <OliverUv> ah nvm got it[07:58:23] <OliverUv> cool[07:58:25] <OliverUv> too[07:58:47] <XMPPwocky> if you have a back buffer you can actually do cellular automata using only the derivatives[07:59:13] <XMPPwocky> the way they actually work, on real hardware, is by asking the other fragment shaders executing in the same group of 4[07:59:19] <XMPPwocky> what *they* got for that value[07:59:26] <XMPPwocky> and subtracting[07:59:40] *** DapperPixpy has quit IRC[08:00:25] <OliverUv> what do you mean by gorup of 4 ?[08:00:39] <XMPPwocky> OliverUv: groups of fragment shader invocations run in parallel[08:00:55] *** Twinklebear has quit IRC[08:00:56] <XMPPwocky> executing on nearby fragments[08:01:21] <XMPPwocky> so you have one shader unit running (0,0), one on (1,0), one (0, 1), one (1,1)[08:03:00] <newguise1234> that sounds pretty cool[08:03:44] *** luxigo has quit IRC[08:05:13] *** hahuang61 has quit IRC[08:05:22] <OliverUv> didn't know they could ask each other about data![08:05:36] <OliverUv> if they depend on each other, who gets done first?[08:05:54] <OliverUv> or do you just keep the current state in one of the four, and the other three contain the state for the last 3 iterations ?[08:07:31] <OliverUv> XMPPwocky: just created an account to fave that shader[08:07:37] <OliverUv> mind if I use it in a project later on?[08:07:44] <XMPPwocky> not at all[08:07:50] <XMPPwocky> OliverUv: they run in lockstep[08:07:50] <OliverUv> (will release it with MIT license when APIs stabilize)[08:07:57] *** CainJacobi has quit IRC[08:08:14] <XMPPwocky> that's why you sometimes can't branch in shaders[08:08:34] <XMPPwocky> it breaks dfdx/dfdy and also most texture lookups[08:10:09] <OliverUv> hm[08:10:29] *** jbud has quit IRC[08:11:05] <OliverUv> https://www.shadertoy.com/view/lslGDS[08:11:07] <OliverUv> hahaha[08:11:11] <OliverUv> fudge fudge fudge fudge[08:12:28] *** luxigo has joined ##OpenGL[08:12:45] *** Bigpet_ has quit IRC[08:12:46] *** zgreg has quit IRC[08:12:54] *** zgreg has joined ##OpenGL[08:14:54] <OliverUv> cool effect though![08:15:20] *** lenarhoyt has quit IRC[08:15:39] *** DrSkyLizard has joined ##OpenGL[08:16:35] <OliverUv> well this was a very fun evening, but now it is 8am and i have work tomorrow :v[08:17:18] *** slidercrank has joined ##OpenGL[08:18:44] *** BitPuffin has joined ##OpenGL[08:20:09] *** Khlorghaal has joined ##OpenGL[08:20:18] *** luxigo has quit IRC[08:22:10] *** diegov_ has quit IRC[08:23:02] *** luxigo has joined ##OpenGL[08:23:56] *** cr`nge has quit IRC[08:25:13] *** Beetny has joined ##OpenGL[08:26:22] *** Jack_ has joined ##OpenGL[08:28:19] *** clauswitt has joined ##OpenGL[08:29:22] <neure> hi[08:29:24] *** Zupo has quit IRC[08:29:30] <neure> anyone done HDR bloom?[08:32:00] *** clauswi__ has joined ##OpenGL[08:33:32] *** slidercrank has quit IRC[08:34:20] *** clauswitt has quit IRC[08:35:09] *** Gamecubic has quit IRC[08:35:33] *** puerum has quit IRC[08:37:59] *** Jack__ has joined ##OpenGL[08:39:00] *** DolphinDream has quit IRC[08:39:43] *** luxigo has quit IRC[08:40:50] *** Tag_ has joined ##OpenGL[08:40:57] *** Jack_ has quit IRC[08:41:00] <Tag_> hello[08:41:30] *** zzuegg has quit IRC[08:42:08] *** Zerflag has joined ##OpenGL[08:43:00] *** luxigo has joined ##OpenGL[08:44:23] *** zzuegg has joined ##OpenGL[08:44:55] *** Garner has joined ##OpenGL[08:45:52] *** BitPuffin has quit IRC[08:48:03] *** hamsham has quit IRC[08:55:10] *** damir__ has joined ##OpenGL[08:58:14] *** DrSkyLizard has quit IRC[08:59:18] *** PasNox has joined ##OpenGL[09:03:10] *** Waynes has joined ##OpenGL[09:04:06] *** BitPuffin has joined ##OpenGL[09:05:32] *** konom has joined ##OpenGL[09:05:45] *** Lemml has joined ##OpenGL[09:08:11] *** slime has quit IRC[09:09:48] *** slime has joined ##OpenGL[09:11:59] *** lenarhoyt has joined ##OpenGL[09:14:22] *** luxigo has quit IRC[09:15:23] *** HunterD has joined ##OpenGL[09:15:53] *** Zupo has joined ##OpenGL[09:16:54] *** lenarhoyt has quit IRC[09:23:47] *** robot-beethoven has joined ##OpenGL[09:24:39] *** Zerflag has quit IRC[09:25:15] *** Zerflag has joined ##OpenGL[09:25:28] *** shintahW has joined ##OpenGL[09:27:20] *** BitPuffin has quit IRC[09:30:12] *** Zerflag has quit IRC[09:31:25] *** luxigo has joined ##OpenGL[09:34:12] *** erhan_ has joined ##OpenGL[09:35:54] *** luxigo has quit IRC[09:36:22] *** HunterD has quit IRC[09:38:18] *** Waynes has quit IRC[09:39:53] *** charlie5 has quit IRC[09:39:57] *** Folkol has joined ##OpenGL[09:41:52] *** Jack__ has quit IRC[09:41:59] *** luxigo has joined ##OpenGL[09:44:07] *** HunterD has joined ##OpenGL[09:44:34] *** HunterD has quit IRC[09:44:51] *** HunterD has joined ##OpenGL[09:45:19] *** HunterD has quit IRC[09:46:43] *** HunterD has joined ##OpenGL[09:46:52] *** DrSkyLizard has joined ##OpenGL[09:48:32] *** HunterD has quit IRC[09:50:37] *** HunterD has joined ##OpenGL[09:51:47] *** RyanPridgeon has quit IRC[09:51:49] *** zajfy has joined ##OpenGL[09:58:53] *** mat^2 has joined ##OpenGL[10:05:09] *** AlexRussia has quit IRC[10:08:57] *** redeemed has joined ##OpenGL[10:12:48] *** AlexRussia has joined ##OpenGL[10:12:48] *** lenarhoyt has joined ##OpenGL[10:13:36] *** k_sze has joined ##OpenGL[10:14:07] <k_sze> I need help understanding perspective projection.[10:14:25] <k_sze> I have a general idea of how it works with the pinhole camera model.[10:14:35] <k_sze> It's just that the confusion on wikipedia seems weird: http://en.wikipedia.org/wiki/3D_projection#Perspective_projection[10:15:18] <Hunts2> what confusion[10:15:20] <Hunts2> ?[10:15:35] *** antognol` is now known as antognolli[10:15:36] <k_sze> It says that e[x,y,z] is "the viewer's position relative to the display surface which goes through point C representing the camera"[10:17:16] *** mat^2 has quit IRC[10:17:36] <k_sze> What does it mean by "viewer"? I thought we have a camera and a scene.[10:17:59] *** Hunts2 has quit IRC[10:18:02] *** lenarhoyt has quit IRC[10:18:03] <k_sze> It would be great if these variables could be put on an illustratoin[10:18:04] *** wutata has joined ##OpenGL[10:22:34] *** centrinia has quit IRC[10:23:07] *** mat^2 has joined ##OpenGL[10:23:56] *** shintahW has quit IRC[10:24:17] *** HunterD has quit IRC[10:25:20] *** Zerflag has joined ##OpenGL[10:25:26] <wutata> morning[10:31:09] *** shintahW has joined ##OpenGL[10:34:31] *** Ad1_RnR has quit IRC[10:34:59] *** Sirolf has joined ##OpenGL[10:35:16] *** centrinia has joined ##OpenGL[10:36:24] *** narcan has joined ##OpenGL[10:37:06] *** Zerflag has quit IRC[10:38:21] *** Ad1_RnR has joined ##OpenGL[10:40:14] *** james4k has quit IRC[10:40:23] *** Garmine has quit IRC[10:47:42] *** narcan has quit IRC[10:48:17] *** narcan has joined ##OpenGL[10:51:01] *** snakenerd has joined ##OpenGL[10:55:01] *** snakenerd has quit IRC[10:55:13] *** robot-beethoven has quit IRC[10:56:12] *** zzuegg has quit IRC[10:58:00] *** zzuegg has joined ##OpenGL[10:59:56] *** Textmode has quit IRC[11:00:27] *** Zerflag has joined ##OpenGL[11:01:21] *** ManDay has joined ##OpenGL[11:05:07] *** Zerflag has quit IRC[11:06:55] *** luxigo has quit IRC[11:13:31] *** lenarhoyt has joined ##OpenGL[11:15:06] *** Garmine has joined ##OpenGL[11:15:29] *** Garmine is now known as Guest52087[11:16:00] *** Portals has joined ##OpenGL[11:18:29] *** lenarhoyt has quit IRC[11:19:16] <Portals> My program crashes when I use glBufferData, but not when I use glBufferSubData. Anyone got any idea as why this might happen?[11:19:29] <Portals> I had always used glBufferSubData[11:19:52] <Bloodust> crash as in segmentation fault?[11:19:57] <Portals> Yup¨[11:20:06] <Portals> Used glBufferData to set size[11:20:17] *** Demon_Fox has quit IRC[11:25:14] *** Portals_ has joined ##OpenGL[11:26:15] *** doev has joined ##OpenGL[11:26:31] *** Portals has quit IRC[11:26:38] *** ManDay has quit IRC[11:30:33] *** razieliyo has joined ##OpenGL[11:30:33] *** razieliyo has joined ##OpenGL[11:31:03] <Portals_> Any ideas bloodust?[11:31:16] *** Portals_ is now known as Portals[11:31:23] <Bloodust> pastebin?[11:34:51] *** shintahW2 has joined ##OpenGL[11:35:47] <Portals> Tested it on a other computer real fast. Seemed to work then. Damn graphics cards.[11:37:48] *** shintahW has quit IRC[11:37:48] *** shintahW2 is now known as shintahW[11:39:43] *** RyanPridgeon has joined ##OpenGL[11:43:45] *** Crehl has joined ##OpenGL[11:44:22] *** Portals has quit IRC[11:47:18] *** tm604 has quit IRC[11:49:51] *** k_sze has quit IRC[11:52:02] *** Jack_ has joined ##OpenGL[12:10:57] *** indefini has quit IRC[12:13:38] *** centrinia has quit IRC[12:14:18] *** lenarhoyt has joined ##OpenGL[12:19:11] *** lenarhoyt has quit IRC[12:25:20] *** serengeor has joined ##OpenGL[12:28:08] *** Guest52087 has quit IRC[12:28:08] *** Guest52087 has joined ##OpenGL[12:28:12] *** Guest52087 is now known as Garmine[12:33:59] *** Crehl has quit IRC[12:39:25] *** centrinia has joined ##OpenGL[12:42:23] *** DrBenway has quit IRC[12:44:48] *** mat^2 has quit IRC[12:50:47] *** charlie5 has joined ##OpenGL[12:52:06] *** Folkol has quit IRC[12:54:43] *** indefini has joined ##OpenGL[12:55:13] *** rmelo has joined ##OpenGL[12:56:49] *** Folkol has joined ##OpenGL[13:00:12] *** Folkol has quit IRC[13:01:21] *** samrat has quit IRC[13:06:13] *** mat^2 has joined ##OpenGL[13:06:43] *** Beetny has quit IRC[13:14:32] *** narcan has quit IRC[13:15:05] *** lenarhoyt has joined ##OpenGL[13:15:30] *** narcan has joined ##OpenGL[13:20:00] *** lenarhoyt has quit IRC[13:20:17] *** paperManu_ has joined ##OpenGL[13:27:02] *** Bigpet_ has joined ##OpenGL[13:27:24] *** Portals has joined ##OpenGL[13:27:38] *** paul424 has joined ##OpenGL[13:35:16] *** snakenerd has joined ##OpenGL[13:37:13] *** katu has joined ##OpenGL[13:38:08] *** katlogic has quit IRC[13:42:07] *** Codex_ has joined ##OpenGL[13:48:43] *** Keniyal has quit IRC[13:49:16] *** wutata- has joined ##OpenGL[13:49:36] *** mat^2 has quit IRC[13:50:19] *** lenarhoyt has joined ##OpenGL[13:50:45] *** tm604 has joined ##OpenGL[13:52:31] *** wutata has quit IRC[13:52:40] *** AbigailBuccaneer has joined ##OpenGL[13:53:12] *** hdon has joined ##OpenGL[14:03:00] *** xissburg has joined ##OpenGL[14:05:42] <jophish_> AbigailBuccaneer: here?[14:06:14] *** tha_grid has joined ##OpenGL[14:06:25] <jophish_> Does anyone know how to get cpu access to a texture on the gpu without causing a stall using DirectX11?[14:06:37] *** DrSkyLizard has quit IRC[14:06:53] <tha_grid> http://pastebin.com/cCyr8xWq << why is this line commented as //glActiveTexture(0),[14:07:57] <ClaudiusMaximus> tha_grid: because it's wrong (more correct would be glActiveTexture(GL_TEXTURE0) but it's the default anyway so no need to set it if it isn't changed elsewhere)[14:08:16] <Bloodust> jophish_ on directx11 ? wat[14:08:16] *** jdolan has quit IRC[14:08:46] <jophish_> Bloodust: yeah, I'm assuming that some people here have some interest in DX[14:09:41] <tha_grid> thanks claudius,[14:09:58] <tha_grid> anyone have a good book or blog to suggest?[14:10:21] <tha_grid> ive already viewed the ones in the topic[14:10:38] <jophish_> tha_grid: Ken Perlin's blog is pretty good[14:11:47] <Bloodust> book on what?[14:11:48] <Bloodust> opengl?[14:12:17] *** zzuegg has quit IRC[14:13:17] <tha_grid> yeah that would be nice, ive looked at opengl es 2.0 book from wiley, ugh nothing useful in it that you cant find online[14:13:27] *** jdolan has joined ##OpenGL[14:13:28] *** Portals has quit IRC[14:13:40] <Bloodust> well opengl superbible is one[14:14:22] <Bloodust> I suppose the latest red book is nice too[14:14:27] <Bloodust> you can find that on google[14:15:20] *** paperManu_ has quit IRC[14:15:23] <Bloodust> I belive its called opengl programming guide 8th version or something like that[14:18:38] *** zzuegg has joined ##OpenGL[14:21:47] *** urraka has joined ##OpenGL[14:24:11] *** narcan has quit IRC[14:24:31] *** samrat has joined ##OpenGL[14:26:18] *** jdolan has quit IRC[14:27:08] *** Thrzsh has joined ##OpenGL[14:41:44] *** jdolan has joined ##OpenGL[14:42:37] *** Chais has quit IRC[14:42:53] *** BitPuffin has joined ##OpenGL[14:44:28] *** Chais has joined ##OpenGL[14:44:29] *** RockLee has joined ##OpenGL[14:46:42] *** jdolan has quit IRC[14:46:53] *** AlexRussia has quit IRC[14:50:37] *** Thrzsh has quit IRC[14:52:48] *** tehrain has joined ##OpenGL[14:52:49] *** tehrain has joined ##OpenGL[14:54:00] *** AlexRussia has joined ##OpenGL[14:57:00] *** miyabe_ has joined ##OpenGL[14:58:52] *** HunterD has joined ##OpenGL[15:00:04] *** HunterD has quit IRC[15:01:21] *** HunterD has joined ##OpenGL[15:01:49] *** HunterD has quit IRC[15:02:37] *** HunterD has joined ##OpenGL[15:02:55] *** HunterD has left ##OpenGL[15:09:22] *** jdolan has joined ##OpenGL[15:14:50] <ikarus> without resorting to OpenCL, what is the best way of using the output of a vertex and/or fragment shader as the input to a second vertex shader ?[15:16:28] *** ripper93 has joined ##OpenGL[15:19:10] *** centrinia has quit IRC[15:20:03] <neure> transform feedback[15:20:27] <neure> that works vs to vs, and is sort of poor mans compute[15:20:39] <neure> or how about using compute shaders?[15:21:30] <rmelo> I guys[15:21:34] <ikarus> neure: need to support stuff on which I can't actually use compute shaders[15:21:42] <ikarus> and yeah, transform feedback was what I was thinking of[15:21:55] <Codex_> fbo would work?[15:22:08] <rmelo> I was wondering, is it possible for a normal graphics card to somehow output a signal to a 3D display in order to view stereoscopic video on the 3D display?[15:22:15] <ikarus> Codex_: can't feed a FBO back into a vertex shader, well, not without headaches[15:22:44] <Codex_> ikarus: cant you bind it to a texture?[15:23:12] <ikarus> Codex_: readingf from a texture is fun in the vertex stage[15:23:52] *** samrat has quit IRC[15:26:58] *** AlexRussia has quit IRC[15:28:06] *** AlexRussia has joined ##OpenGL[15:29:12] *** Zupo has quit IRC[15:31:50] *** lenarhoyt has quit IRC[15:33:33] *** telex has quit IRC[15:34:07] *** Tag_ has left ##OpenGL[15:34:37] *** telex has joined ##OpenGL[15:34:38] <ikarus> btw, anyone know if GL_POINT is still a valid thing in 3.3 and above ?[15:34:58] <Codex_> yes[15:35:34] <ikarus> shared knowledge ftw[15:35:49] <ikarus> thanks :)[15:43:49] *** stefkos has joined ##OpenGL[15:46:01] *** TyrfingMjolnir has joined ##OpenGL[15:52:49] *** ripper93 has quit IRC[15:53:42] *** cden has joined ##OpenGL[15:53:44] *** HuntsMan has joined ##OpenGL[15:55:39] *** Folkol has joined ##OpenGL[15:57:01] *** TyrfingMjolnir has quit IRC[16:00:19] *** TyrfingMjolnir has joined ##OpenGL[16:07:01] *** Orion] has joined ##OpenGL[16:08:04] *** damir__ has quit IRC[16:09:13] *** DrBoneStrong has joined ##OpenGL[16:11:39] *** TyrfingMjolnir has quit IRC[16:11:56] <Yaniel> rmelo: what do you mean by "normal" graphics card?[16:12:11] *** clauswi__ has quit IRC[16:12:47] *** TyrfingMjolnir has joined ##OpenGL[16:13:35] *** samrat has joined ##OpenGL[16:13:54] *** lenarhoyt has joined ##OpenGL[16:14:37] *** doev has quit IRC[16:17:05] *** sveale_ has joined ##OpenGL[16:17:12] *** sveale__ has joined ##OpenGL[16:17:22] *** sveale_ has quit IRC[16:17:22] *** sveale__ has quit IRC[16:20:09] *** Waynes has joined ##OpenGL[16:24:41] *** CrizMobius has joined ##OpenGL[16:25:26] *** SleekoNiko has quit IRC[16:26:18] <rmelo> Yaniel: I mean a graphics card other than the NVidia Quadro for example. A graphics card that has no specific driver/features for 3D display[16:26:59] <Yaniel> depends on the display then, I guess[16:27:20] <Yaniel> oculus rift for example just takes a normal signal[16:27:33] <Yaniel> (as far as I know anyway)[16:28:06] <Yaniel> and opengl has support for left and right back and front buffers[16:28:46] <Yaniel> in theory it is just up to some driver to actually put the image on screen[16:28:55] *** paul424 has quit IRC[16:29:33] *** paul424 has joined ##OpenGL[16:30:13] *** paul424 has quit IRC[16:30:54] *** paul424_ has joined ##OpenGL[16:31:34] *** doomlord_1 has joined ##OpenGL[16:36:19] *** hahuang61 has joined ##OpenGL[16:37:42] *** samrat has quit IRC[16:39:23] *** Keniyal has joined ##OpenGL[16:42:24] *** samrat has joined ##OpenGL[16:43:56] *** hahuang61 has quit IRC[16:46:07] *** Waynes1 has joined ##OpenGL[16:46:17] *** Waynes has quit IRC[16:47:09] *** samrat has quit IRC[16:50:33] *** RyanPridgeon has quit IRC[16:50:59] *** samrat has joined ##OpenGL[16:51:01] *** stefkos has quit IRC[16:53:54] *** clauswitt has joined ##OpenGL[16:56:10] *** TheLorax has joined ##OpenGL[16:57:11] <TheLorax> does it matter what order I bind/use vaos and shaders when drawing? Should I bind the vao first, or use the shader first?[16:57:40] *** doomlord_1 has quit IRC[16:57:42] <Yaniel> doesn't matter[16:58:12] *** serengeor has quit IRC[16:58:41] *** clauswit_ has joined ##OpenGL[16:59:20] *** clauswitt has quit IRC[16:59:34] *** Jack__ has joined ##OpenGL[17:01:23] *** Keniyal has quit IRC[17:01:57] *** Jack_ has quit IRC[17:02:05] <ikarus> is there some "defacto" way to deal with generating pseudo random on the GPU (and any papers referring to it)[17:02:20] <HuntsMan> ikarus: perlin and simplex noise[17:03:03] <ikarus> HuntsMan: those are smoothed noise, I need random noise (normal and/or linear distributed) and consumption of it in shaders[17:03:49] <HuntsMan> uniformly or normally distributed?[17:03:57] <HuntsMan> mmmmm, that will be hard[17:04:01] <HuntsMan> since they require a global state[17:04:49] <ikarus> HuntsMan: nah, there are distributed generation of them possible (namely random functions that can produce the n'th random number without looping), but I was wondering on the state of research on it[17:06:02] <Madsy> ikarus: A well-known method is to use perlin or simplex noise where the window cooordinates is the seed[17:06:16] <ikarus> Madsy: but I don't WANT smoothed noise[17:06:24] <Madsy> ah, okay[17:06:40] <Madsy> Can't you still use the same approach though?[17:06:56] <ikarus> Madsy: not really, most of them calculate the initial non-smoothed randomness on the CPU[17:07:03] <ikarus> and then smooth and chain it on the GPU[17:07:38] *** Ad1 has joined ##OpenGL[17:09:12] *** MLM has joined ##OpenGL[17:09:53] <ikarus> Madsy: which is typically linked with what the HuntsMan says, most people don't even know that distributed pseudorandom noise generation is a thing[17:13:45] *** PasNox has quit IRC[17:15:41] *** DrSkyLizard has joined ##OpenGL[17:16:42] *** Zupoman has joined ##OpenGL[17:17:07] *** linuxuz3r has joined ##OpenGL[17:17:53] *** clauswit_ has quit IRC[17:18:08] *** serengeor has joined ##OpenGL[17:18:47] *** redeemed has quit IRC[17:19:49] *** Jeanne-Kamikaze has joined ##OpenGL[17:19:53] *** serengeor has quit IRC[17:22:28] *** samrat has quit IRC[17:22:59] *** wutata- has quit IRC[17:25:03] *** DrSkyLizard has quit IRC[17:25:19] *** DrSkyLizard has joined ##OpenGL[17:25:27] *** samrat has joined ##OpenGL[17:27:33] *** damir__ has joined ##OpenGL[17:28:46] *** tha_grid has quit IRC[17:36:21] *** clauswitt has joined ##OpenGL[17:43:59] *** samrat has quit IRC[17:50:29] *** DrBoneStrong has quit IRC[17:51:14] *** Thrzsh has joined ##OpenGL[17:55:47] *** forests has quit IRC[17:57:04] *** CainJacobi has joined ##OpenGL[17:57:13] *** forests has joined ##OpenGL[18:03:02] *** samrat has joined ##OpenGL[18:03:36] *** Sirolf has quit IRC[18:16:40] <newguise1234> is there overhead if you use glDrawElementsInstanced regularly for single instances?[18:16:59] <newguise1234> or should I just use a non-instanced call for drawing my terrain[18:17:45] <AbigailBuccaneer> newguise1234, most likely there's almost no overhead whatsoever[18:18:04] <AbigailBuccaneer> (if i were a driver writer, glDrawElements would just call glDrawElementsInstanced(...,1)[18:18:35] <newguise1234> Thanks, I would think there wouldn't be? But I'm also unknowledgeable of some of the black magic lol[18:20:27] <roboman2444> newguise1234, in some drivers there might be, but in my experiances, dont even bother writing a seperate thing to detect if you are only drawing one instance[18:20:52] <newguise1234> sounds good thanks.[18:21:14] <newguise1234> I had one written before I added instancing, and I may just remove it now then[18:23:00] *** CrizMobius has quit IRC[18:23:24] *** mat^2 has joined ##OpenGL[18:24:12] <roboman2444> newguise1234, might be a problem if you want to be able to support older gpus[18:24:30] <roboman2444> but if you already require gl3+ features for other things, go for it[18:24:43] <newguise1234> Well I'm writing it on my laptop which only has gl 2.0 support, but it has the instancing extension[18:24:58] <roboman2444> instancing, without ubos?[18:24:59] <roboman2444> oooooh[18:25:02] <roboman2444> painful[18:25:24] <Bloodust> what no its not[18:25:28] <newguise1234> I figure writing for an intel hd graphics card thats a couple years old will cover a decent amount of computers?[18:25:36] <Bloodust> just use "instancing arrays"[18:25:52] <katu> newguise1234: kinda[18:26:04] <katu> newguise1234: more like mobile[18:26:08] <newguise1234> oo[18:26:21] <katu> (though the architectures are quite different, overall performance sucks on both)[18:27:15] *** stefkos has joined ##OpenGL[18:27:47] <newguise1234> well, at least with just cubes being instanced, my cpu updating an octree is the bottleneck atm[18:27:57] *** clauswit_ has joined ##OpenGL[18:28:14] <Bloodust> throw more cores at it[18:28:25] <newguise1234> lol[18:29:07] <katu> make it hexadecatree[18:29:19] <katu> more leaves, more minecraft[18:29:46] <Bloodust> Id imagine octree should scale pretty well to multithreading[18:30:05] <newguise1234> lol, I don't really know what I'm doing, but I think I'm going to have a generated terrain, split into sections that have bvh computed for it[18:30:07] *** foreignFunction has quit IRC[18:30:18] <newguise1234> then when the terrain is deformed in a "chunk" recompute the bvh[18:30:25] <newguise1234> for other objects I'll toss them into an octree[18:30:34] <roboman2444> are you mostly flat?[18:30:45] <roboman2444> (terrain)[18:30:49] <roboman2444> err[18:30:51] <newguise1234> I just started reading this http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html[18:31:02] *** clauswitt has quit IRC[18:31:17] <roboman2444> try using a quadtree that keeps track of the upper and lower bounds of all the items in each leaf, and each leaf in it[18:31:21] <katu> newguise1234: sounds like ok start for generic open world.[18:31:34] <roboman2444> usually works better for mostly flatter areas[18:32:17] <katu> newguise1234: if you do basic grid/chunks, you dont really need an octree, though. just keep lists of entities per cell of a grid.[18:32:48] <katu> basically very dumb octree. this stuff involves a lot of overdraw already, so it does not matter if there will be more for entities.[18:32:48] <newguise1234> the octree would be changed to be used for inter-moveable object interaction[18:34:01] *** rmelo has quit IRC[18:34:01] <newguise1234> roboman2444: makes sense, no need for an octree if you aren't using a lot of the information[18:34:17] <roboman2444> yeah, you usually dont have a lot of stuff going vertically[18:34:37] <roboman2444> mostly its spread out horizontally, with some varying levels of elevation.[18:34:57] *** RockLee has quit IRC[18:35:14] *** Gamecubic has joined ##OpenGL[18:36:21] *** shingshang has quit IRC[18:36:46] *** ablepharus has joined ##OpenGL[18:36:59] <newguise1234> katu: there might be a better way than I was planning, I think I understand what you're saying though, just reduces the N to your chunk/grid so your N^2 check is much smaller anyways[18:39:03] *** shintah has joined ##OpenGL[18:41:13] *** erhan_ has quit IRC[18:41:57] *** FrodoTheHobbit has joined ##OpenGL[18:43:14] *** Jack_ has joined ##OpenGL[18:45:17] *** Jack__ has quit IRC[18:45:18] *** radr has joined ##OpenGL[18:47:03] *** Ad1 has quit IRC[18:48:34] *** Ad1 has joined ##OpenGL[18:48:47] *** BlackPhoenix has joined ##OpenGL[18:49:23] *** slidercrank has joined ##OpenGL[18:49:47] *** Sos has joined ##OpenGL[18:52:05] *** BlackFox has quit IRC[18:53:49] *** FrodoTheHobbit has quit IRC[18:54:26] *** Thrzsh has quit IRC[18:55:58] *** clauswit_ has quit IRC[18:58:51] *** clauswitt has joined ##OpenGL[19:02:12] *** Misu has joined ##OpenGL[19:04:29] <TheLorax> do VAOs save which texture object is currently bound?[19:06:26] *** FrodoTheHobbit has joined ##OpenGL[19:07:20] <HuntsMan> no[19:10:24] *** ShadowIce has joined ##OpenGL[19:10:38] *** PasNox has joined ##OpenGL[19:12:05] *** TheBunnyZOS has joined ##OpenGL[19:16:11] *** PasNox has quit IRC[19:18:21] *** BreadProduct has quit IRC[19:19:23] *** zzuegg has quit IRC[19:27:06] *** bkre_ has joined ##OpenGL[19:28:39] *** Jeanne-Kamikaze has quit IRC[19:29:09] *** jdolan has quit IRC[19:34:16] *** jdolan has joined ##OpenGL[19:36:04] *** ablephar` has joined ##OpenGL[19:37:17] *** jdolan has quit IRC[19:38:07] *** DapperPixpy has joined ##OpenGL[19:40:05] *** clauswit_ has joined ##OpenGL[19:40:05] *** ablepharus has quit IRC[19:40:38] *** jdolan has joined ##OpenGL[19:43:24] *** clauswitt has quit IRC[19:45:10] *** clauswit_ has quit IRC[19:47:18] *** sedeki has joined ##OpenGL[19:50:59] *** lenarhoy1 has joined ##OpenGL[19:52:14] <lenarhoy1> hi. before the fragment shader the hardware transforms each coordinate by +1 and then divides by 2, correct?[19:56:27] <lenarhoy1> oh and it scales by vec4(viewport_x, viewport_y, 1, 1)?[20:01:45] *** PasNox has joined ##OpenGL[20:01:46] *** Crehl has joined ##OpenGL[20:06:06] *** foreignFunction has joined ##OpenGL[20:06:06] <derhass> lenarhoy1: yeah, rasterization is done in window space, for obvious reasons[20:07:04] <lenarhoy1> derhass: but I have no access to these transformations, right? (other than passing separate vectors and use them insteadc)[20:07:43] <derhass> lenarhoy1: what exactly do you mean?[20:09:02] <lenarhoy1> I'm rendering to a framebuffer without attachments and I would like to bypass clipping and these transformations[20:09:20] *** Jack__ has joined ##OpenGL[20:09:31] <derhass> well. what would your fragment shader do in such cases?[20:09:36] <derhass> it doesn't really make sense[20:10:33] <derhass> you might want a compute shader or something like that[20:10:49] <derhass> but fragments are always tied to the pixel raster of the framebuffer[20:11:01] <lenarhoy1> hm, yeah I'll look into compute shaders[20:11:01] <derhass> even if you don't plan directly outputting naything[20:11:46] *** Jack_ has quit IRC[20:11:55] <derhass> *anything[20:14:22] *** Ranis has quit IRC[20:17:22] *** Khlorghaal has quit IRC[20:21:21] *** japro has joined ##OpenGL[20:21:28] *** zzuegg has joined ##OpenGL[20:23:45] *** Thrzsh has joined ##OpenGL[20:26:31] *** hahuang61 has joined ##OpenGL[20:31:01] *** asdtrfygjhknklm has joined ##OpenGL[20:35:32] <paul424_> OK, I am back here, are there any techniques of rendering the scene to higher resolutions and then filtering to lower resolutions ?[20:36:01] *** mayankmadan_ has joined ##OpenGL[20:36:11] <Stragus> A huge frame buffer object, but ordinary multisampling wouldn't be good enough?[20:39:25] *** derhass_ has joined ##OpenGL[20:41:35] <paul424_> I mean how the bilinear filtering was done , .... couldn't I just use draw_to_nearest for a texture filter , and then bilinear filter the whole framebuffer picture ?[20:41:44] *** Syzygy_ has quit IRC[20:42:01] *** Syzygy_ has joined ##OpenGL[20:42:04] *** derhass has quit IRC[20:42:42] <derhass_> paul424_: lol, no[20:42:54] <derhass_> that would look horrible[20:43:03] <paul424_> he he[20:45:00] *** carvite has quit IRC[20:46:04] <mayankmadan_> hi[20:46:06] *** carvite has joined ##OpenGL[20:46:42] *** Keniyal has joined ##OpenGL[20:47:08] <mayankmadan_> i just started with opengl today and i fell into some trouble. http://pastebin.com/8YKUD2K3[20:47:32] <mayankmadan_> this is the program that i wrote but all it does is show up a window with red background[20:47:45] *** Jack_ has joined ##OpenGL[20:47:48] <mayankmadan_> i expected a white triangle on red background[20:48:12] <mayankmadan_> could someone just guide me a bit[20:49:55] *** samrat has quit IRC[20:50:22] *** Jack__ has quit IRC[20:50:42] <Bloodust> good start even tho you still dont have shaders[20:51:04] <derhass_> well. he uses a compat profile[20:51:25] <Bloodust> the thing is[20:51:36] <Bloodust> you cant use vertexattribpointer without shader[20:51:37] <Stragus> I have no idea what the default values are for the transformation matrices, but you probably should define them somewhere[20:51:41] <derhass_> Bloodust: you can[20:51:43] <Bloodust> you can?[20:51:56] <derhass_> Bloodust: generic attribute 0 is guaranteed to alias gl_Vertex attribute[20:52:01] *** pizthewiz has joined ##OpenGL[20:52:20] <derhass_> the funny thing is that this code in principle could even work[20:52:34] <derhass_> although I strongly recommend to not use it[20:52:47] <Bloodust> hmm[20:53:10] <mayankmadan_> is this in reply to my question? i cant really make out[20:53:24] <Bloodust> yes[20:53:35] <Bloodust> also, you should split your rendering function to two[20:53:47] <Bloodust> 1 function to initalize all the GL buffers and 1 function to draw from them[20:54:00] <mayankmadan_> ok[20:54:17] <Bloodust> that way you dont have to keep recreating the vao and vbo[20:54:19] <derhass_> the other funny thing is that this code eve _does_ work on my nvidia[20:54:46] <Bloodust> funny code[20:55:17] *** kuldeepdhaka has quit IRC[20:55:22] <derhass_> so the answer is: your implementation is broken, or you have a timing issue because you use single buffering[20:55:53] <zzuegg> fun thing is, i am currently at 11k lines of code and i also only have a colored triangle :P[20:56:07] <newguise1234> lol[20:56:08] *** RyanPridgeon has joined ##OpenGL[20:56:20] <derhass_> why do people need so many lines for colored triangles?[20:56:31] <mayankmadan_> i still cant make out what to do :)[20:56:33] <newguise1234> one line for every dot[20:56:37] <newguise1234> its very high resolution[20:56:44] <derhass_> mayankmadan_: what gl implmentation are you using? mesa?[20:56:50] <mayankmadan_> yes[20:57:04] <derhass_> you shouldn't do that stuff at all[20:57:25] <derhass_> use modern gl with shaders[20:57:35] <mayankmadan_> so there is something wrong with my set up?[20:57:43] <zzuegg> hehe, abstracting away from gl mostly. i could probably render any mesh, but i only have a triangle up to now[20:57:44] <derhass_> or use legacy GL with builtin attributes, if you _really_ want to[20:57:55] <newguise1234> I think the shaders will get you away from using glColor3f[20:58:20] <derhass_> mayankmadan_: not really. it _should_ work, and it does work for me[20:58:21] <newguise1234> it might be a bit of reading, but the arcsynthesis tutorial really helped me get my head on straght with regards to opengl[20:58:33] <derhass_> mayankmadan_: but it is still not adviceable to do it that way[20:59:07] *** cden has left ##OpenGL[21:00:31] <mayankmadan_> okay[21:02:34] *** Sos has quit IRC[21:03:13] *** Garner has quit IRC[21:05:07] *** ClarusCogitatio has joined ##OpenGL[21:06:15] *** ablephar` has quit IRC[21:06:53] *** ablephar` has joined ##OpenGL[21:08:30] <mayankmadan_> derhass_, but then how do i get the needed libraries?[21:08:48] <derhass_> which libraries?[21:09:15] <mayankmadan_> which the header files uses[21:09:31] *** PasNox has quit IRC[21:09:38] *** erhan_ has joined ##OpenGL[21:09:40] <derhass_> I've no idea what you are talking about[21:11:28] <newguise1234> mayankmadan_: it should use the same libraries you have to link your current code to[21:12:02] <mayankmadan_> but isnt there a problem with mesa[21:12:04] <newguise1234> mayankmadan_: derhass_ was saying you shouldn't use legacy GL at all, you should use modern GL because mesa has support for it[21:12:23] <derhass_> I'd say that independent of mesa[21:13:26] <Codex_> linux open source opengl drivers have improved alot recently[21:13:37] *** bjz has quit IRC[21:13:56] <Codex_> they're actually useful for development now[21:13:56] *** bjz has joined ##OpenGL[21:14:01] *** zzuegg2 has joined ##OpenGL[21:14:30] *** zzuegg has quit IRC[21:14:51] *** zzuegg2 is now known as zzuegg[21:16:52] <mayankmadan_> what do i do :)[21:17:42] <newguise1234> load a vertex and fragment shader would be my guess/recommendation[21:18:46] <foobaz> mayankmadan_: i use pkgconfig for header/library flags[21:19:27] <foobaz> e.g.: pkg-config --libs gl[21:21:40] <Waynes1> Codex_: http://i.imgur.com/4GlF8Ru.png[21:24:54] <Codex_> waynes1: my answer is this: http://sivut.koti.soon.fi/~terop/clouds.png[21:26:01] <Codex_> gl_points are pretty neat.[21:26:53] *** snakenerd has quit IRC[21:29:16] *** bkre has joined ##OpenGL[21:30:15] *** sedeki has quit IRC[21:30:33] *** telex has quit IRC[21:31:35] *** clauswit_ has joined ##OpenGL[21:32:12] *** bkre_ has quit IRC[21:32:40] *** telex has joined ##OpenGL[21:35:21] <mayankmadan_> im really sorry bother again but i cant seem to get the concept of shaders[21:35:53] <mayankmadan_> *sorry to[21:36:00] *** centrinia has joined ##OpenGL[21:37:29] <Codex_> mayankmadan_: they're not exactly very useful. You can change the colour of your triangles.[21:37:39] *** newguise1234 is now known as bettlejuice[21:37:54] <Stragus> Shaders are "not exactly very useful"?[21:37:54] *** bettlejuice is now known as newguise1234[21:37:56] <japro> for(vertices) vertex_shader(vertex); fragments = rasterize_primitives(vertices); for(fragments) fragment_shader(fragments)[21:38:10] <Stragus> japro nailed it[21:40:04] <mayankmadan_> thanks[21:40:15] <derhass_> Codex_: uhm.[21:43:06] *** MLM has quit IRC[21:46:14] <Bloodust> Stragus ignore codex, he doesnt understand shaders[21:47:27] <foobaz> i don't know why people get so hung up on shaders, they are the simplest part of opengl[21:47:44] <foobaz> way easier than vertex specification for example[21:48:11] <foobaz> it's just a domain-specific language like SQL or CSS, it's not rocket science[21:48:12] <xissburg> for the same reason people can't get what are pointers[21:50:10] <Codex_> shaders havent solved any of the problems.[21:51:12] <Codex_> I dont like that shaders always need to be modified when you add any new features[21:51:24] <xissburg> What are the problems?[21:51:25] <japro> glsl as such is fine. how exactly they are invoked requires some grokking i'd agree[21:51:31] <Codex_> since you cant combine independent shaders[21:51:40] <derhass_> you can[21:53:04] <foobaz> you don't like modifying your code while adding features to your program? lol[21:53:19] <foobaz> how do you do it then? :)[21:53:29] <Codex_> xissburg: generating enough complexity for games is the actual problem.[21:53:32] <derhass_> bitrot[21:53:38] <derhass_> just wait until it happens[21:53:44] <Codex_> foobaz: instead of modifying, you just add new code.[21:54:43] <Codex_> foobaz: I like to add new independent modules.[21:54:44] *** PasNox has joined ##OpenGL[21:55:35] <zzuegg> just build your shadercode out of module-snippets then[21:55:58] <Codex_> zzuegg: that doesnt work very well[21:55:59] <zzuegg> expecially subroutines might just be what you want[21:56:13] <zzuegg> why not, works for me pretty well[21:57:01] <Codex_> I dont want to write new shaders every time. It needs to be automatic[21:57:09] *** pauldachz has left ##OpenGL[21:57:44] <zzuegg> automatic from what? at some point you have to write some code i guess[21:58:04] <Bloodust> bahaha[21:58:24] <Bloodust> automatic shader generation :DD[21:59:08] *** clauswit_ has quit IRC[22:00:17] <Codex_> zzuegg: I have 3 useful shaders: empty shader, colour shader, and texture shader. Other than that, there isnt really anything I want to do inside shaders.[22:01:19] <Codex_> all the other shader attempts failed miserably[22:01:23] *** Ad1 has quit IRC[22:02:59] <zzuegg> mhmh, what should i say. if you dont want to do anything inside shaders its your thing. but fact is, modern opengl happens mostly inside shaders. thats where the fun is. making the whole cpu side stuff work is the hard work[22:03:43] <japro> zzuegg, but but... it needs to be automatic! (whatever that means?)[22:04:04] <Stragus> MakeAnAwesomeOpenGlKillerApp();[22:04:27] <japro> i mean i agree it's nuts i need to make new textures every time i want things to look different... even to change colors i need to change friggin numbers?[22:05:09] <japro> Stragus, what have shaders ever done for you? HUH???[22:05:51] <Stragus> Don't ask what shaders have done for you, ask what you can do for your shaders!!11[22:06:06] <japro> they want to be compiled... linked... used... they are essentially the attention whores of graphics programming[22:07:05] <derhass_> japro: the aqueduct[22:07:21] <Stragus> Sanitation, sanitation was nice[22:07:30] *** bjz has quit IRC[22:08:06] <derhass_> and the wine![22:08:17] <Codex_> count the number of shader lines of code compared to real code: http://codepad.org/LT4LHQgK Half the code is just to support shaders. (not very automatic when everyone needs to do it manually)[22:08:39] <nido> does anyone know if an opengl implementation exists that doesn't leak memory according to either valgrind or clang's memory sanitizer[22:08:42] <Bloodust> "real code"[22:09:02] <Bloodust> Codex_ why dont you use layouts?[22:09:26] * japro checks his code[22:09:33] <Codex_> bloodust: not supported[22:09:36] <derhass_> because his meaningless line counting metric would totally screw up[22:09:37] <japro> my shader compilation code is pretty much 50 lines[22:09:45] <Stragus> nido, is it "leaking" memory, or just buffering for later uses?[22:09:54] <foobaz> nido: what is it leaking? VBOs? textures?[22:09:57] <Bloodust> hah[22:10:07] <Bloodust> well thats your loss[22:10:11] <Bloodust> its an old feature[22:10:14] <japro> i usually have the inverse problem[22:10:15] <derhass_> nido: there is a very high chance that these are just false positives[22:10:22] <dahlia> I've not seen leaks in my apps[22:10:25] <japro> valgrind doesn't understand where mapped memory comes from[22:10:56] <japro> so it goes all "dude, that is totally uninitialized and not even malloced!"[22:12:02] <japro> also when using catalyst i have to suppress fglrx in valgrind since that singlehandedly produces thousands of "errors" per second in valgrind[22:12:18] <japro> i guess again because it doesn't understand where the driver gets it's memory from[22:12:27] <derhass_> it even does so without valgrind^^[22:12:48] *** razieliyo has quit IRC[22:13:07] <newguise1234> Codex_: I may not be doing it right, but I just have a renderer class which I derive and initialize it with different shader file names.[22:13:17] <mayankmadan_> had no idea a little question would start a shader war :)[22:13:22] *** Garner has joined ##OpenGL[22:13:29] <nido> Stragus: foobaz derhass_ these are all true, the problem is however that it does make it harder to check whether I missed something. Since it has been ages (pre-shaders) since i did something with gl, I was hoping perhaps an implementation was known that perhaps didn't perform well (or even visually correctly), but did have obvious memory implications[22:13:45] <japro> mayankmadan_, that escalated quickly[22:14:02] * japro is suddenly holding a longbow[22:14:04] <foobaz> nido: please be more specific about the problem you are having[22:14:04] <derhass_> nido: you could try the mesa software rasterizer[22:14:10] <derhass_> nido: llvmpipe, nowadays[22:14:39] <derhass_> this will not use any kernel modules[22:15:05] <Codex_> newguise1234: its worse than you think. Every time "sh" is mentioned in the example, it's a shader dependency.[22:15:27] <zzuegg> if you dont want to stick in the 90s you better get used to shaders[22:15:32] <Codex_> newguise1234: for example rendersprite() has a shader dependency[22:15:54] <nido> foobaz: the problem is that my usual avenues for checking memory usage do not work. What I am really looking for I think is a way to check whether everything has been properly managed opengl-wise[22:16:10] <japro> i always love that mindset.... "everyone is using this to great effect... i don't like it... it sux!"[22:16:14] <newguise1234> Codex_: thats because rendering the sprite depends on using the shader :p[22:16:41] <newguise1234> which is much more efficient than calling legacy functions[22:16:53] <newguise1234> I'm just spouting what I've read/heard now though[22:17:44] <foobaz> nido: i check for leaks by watching my heap size[22:18:07] <newguise1234> and I'm sure it could be done in legacy code, but I think its very easy to add, lets say lighting effects to even 2d images with shaders[22:18:10] <foobaz> it is a rudimentary technique that doesn't tell you anything about where the leak is coming from, but it works[22:18:28] * newguise1234 has been brainwashed by the order of the shaders[22:18:48] *** mathias_ has quit IRC[22:18:52] <japro> foobaz, hmm, maybe someone can make a special gcc version for you that replaces all the errors with "there is something wrong"[22:18:53] <japro> :D[22:18:54] <nido> newguise1234: do you happen to have a shader 2d image draw example handy?[22:19:06] <foobaz> i have a script that repeatedly writes my app's heap size to a csv file, then i graph the csv file in a spreadsheet[22:19:18] * dahlia thinks shaders are fun and enjoys those shadertoy sites[22:19:35] <nido> japro: if it includes a linenumber i'd prefer it over the gazillion lines a properly misplaced ) in c++ can generate[22:20:10] <newguise1234> nido: I don't I'm sorry, and I'm sure I'm trivializing it[22:20:11] <japro> nido, hrhr that is very much a gcc thing thoug[22:20:29] *** mathias_ has joined ##OpenGL[22:20:48] <japro> gcc should just have a switch to turn of all the "instantiated from:" outputs[22:20:50] *** snakenerd has joined ##OpenGL[22:20:51] <japro> off[22:20:55] *** Waynes1 has quit IRC[22:21:52] *** snakenerd has quit IRC[22:21:53] <TheLorax> is there a way to debug why no triangles are being drawn in opengl 3+? I've drawn triangles before with VAOs and shaders, but I have a bug somewhere and it's preventing triangles from showing up on the screen. It could be a multitude of problems, and I have no idea how to verify each one.[22:22:17] <paul424_> Heh, any of you have any use of barcyntric coordinates ?[22:22:21] <japro> well there is a way :D[22:22:27] <newguise1234> TheLorax: apitrace helped me track down that I was generating a vbo instead of a vao, then binding said vbo to a vao[22:22:29] <foobaz> TheLorax: check glGetError()[22:22:38] *** Waynes has joined ##OpenGL[22:22:55] <TheLorax> to be clear: I have a program with one working VAO, and one broken one. I have verified the BO data with beugle, and it looks good[22:23:18] <japro> my default approach is: check all errors, clear to nonblack, have the shader output a solid color instead of whatever it is doing, despair, stare the code into submission[22:23:21] <japro> ... etc.[22:23:35] <TheLorax> foobaz, I check glGetError frequently, but not after every call.[22:23:54] <japro> well once is usually enough to figure out if there is an error[22:23:55] <TheLorax> japro, yeah, that's what I'm doing now.[22:23:57] *** snakenerd has joined ##OpenGL[22:24:12] <dahlia> japro: hitting the monitor sometimes helps[22:24:20] <Waynes> Codex_: http://sivut.koti.soon.fi/~terop/clouds.png "problem loading page"[22:24:25] <foobaz> errors stick around until you check them so you don't need to check after every call[22:24:34] <TheLorax> foobaz, ah, good to know.[22:24:52] <Codex_> waynes: works fine for me[22:24:53] <japro> also enabling debug output if available[22:25:01] <TheLorax> what is debug output?[22:25:33] <Waynes> Codex_: weird[22:25:47] <japro> TheLorax, also... you are not alone: https://twitter.com/ID_AA_Carmack/status/370205518532329472[22:25:47] <Waynes> Codex_: ah, now it works here, too![22:25:47] <japro> :D[22:25:51] <foobaz> TheLorax: an opengl 4 feature[22:26:14] *** tehrain has quit IRC[22:26:18] *** faty has quit IRC[22:26:18] <Waynes> japro: carmack!!! \o/[22:26:21] *** stefkos has quit IRC[22:26:21] <TheLorax> I'm on opengl 3 :(, but I could temporarily switch to 4 for development.[22:26:50] <japro> ARB_debug_output is also commonly available as extension in gl3[22:29:10] *** rmelo has joined ##OpenGL[22:30:43] *** ClarusCogitatio has quit IRC[22:32:08] <mayankmadan_> what is ModelViewProjectionMatrix ?[22:32:45] *** ClarusCogitatio has joined ##OpenGL[22:32:55] <japro> the product of the Model- the View- and the projection matrix :)[22:33:56] <newguise1234> nido: when I said it would be simple, I wasn't thinking about the use of textures, I hadn't actually thought through the problem at all and really just want to put my foot in my mouth now lol[22:34:59] <japro> newguise1234, if you can do that i'm impressed[22:35:16] <newguise1234> lol[22:35:42] <japro> also: textures or didn't happen[22:36:06] <newguise1234> mayankmadan_: something to take note of, the Major-order of your matrices in glsl and your cpu code are most likely different[22:36:12] *** razieliyo has joined ##OpenGL[22:36:19] *** razieliyo has quit IRC[22:36:19] *** razieliyo has joined ##OpenGL[22:36:20] <foobaz> mayankmadan_: watch out, the opengl matrix stack was removed six years ago, it only exists in compatibility profile now[22:36:40] <japro> nido, https://github.com/progschj/OpenGL-Examples/blob/master/03texture.cpp#L87[22:36:53] <foobaz> but ModelViewProjectionMatrix lives on as a concept, even though it is not part of the opengl API[22:37:40] <newguise1234> mayankmadan_: means you will most likely have to transpose them when you pass them in. and if you perform multiplications outside glsl, the order of the matrices would be reversed.[22:38:04] <newguise1234> there is a transpose option in the gluniform functions though[22:38:33] <japro> that is only relevant if you use like C style 2d arrays[22:38:39] <japro> which cool kids don't do btw[22:39:18] <newguise1234> lol[22:39:29] <newguise1234> well, thats how glm::mat4 is ordered as well[22:39:43] <newguise1234> <-- has got too many excuses[22:39:52] <japro> no it isn't?[22:40:00] <japro> glm uses column major by default[22:40:07] <japro> you can change that though[22:40:37] *** jdolan has quit IRC[22:41:11] <newguise1234> hmm[22:41:34] <newguise1234> maybe pixies got to my glm config or something then lol[22:41:39] <mayankmadan_> so if i send a matrix to the shader, its transpose would be saved?[22:43:37] <newguise1234> if you're using a C 2d matrix, the position you would access with [0][1] in your code, would show up at [1][0] in the glsl code[22:43:54] <derhass_> or not[22:44:07] <derhass_> there are so many places you can swap that around[22:44:46] <newguise1234> I'm just trying to help avoid a problem i had darn it! lol[22:44:47] <mayankmadan_> so the order would get reversed right?[22:44:54] <newguise1234> the access order would[22:45:09] <newguise1234> because glsl accesses via "column-major"[22:45:56] <newguise1234> so the first index would refer to the column number, and the second would refer to the row number[22:46:04] <newguise1234> whereas in "row-major"[22:46:20] <newguise1234> the first index would refer to the row number, and the second would refer to the column number[22:46:24] <japro> that is the math convention that stays the same[22:46:35] <japro> column vs row major is a memory layout thing[22:47:05] <newguise1234> well bugger me, I didn't want to get that wrong, but I guess I had lol[22:47:10] *** TyrfingMjolnir has quit IRC[22:47:29] <derhass_> matrix storage odrer is one of those things that to the beginner often seems to be confusing, but once grapsed, it becomes totally trivial and unimprotant[22:47:52] <derhass_> one just needs to be consistent[22:49:06] <foobaz> i have never had a problem with matrix order, it has always worked the way i expected[22:52:20] <japro> http://ideone.com/P4cJIW[22:53:04] *** MLM has joined ##OpenGL[22:53:35] *** paul424_ has quit IRC[22:54:00] <derhass_> maybe we should store matrices along a z-order curve[22:54:56] <japro> actually...[22:54:59] <foobaz> there are two of those too[22:55:16] *** foreignFunction has quit IRC[22:55:18] <japro> derhass_, someone here presented a paper about exactly that[22:55:24] <foobaz> the counterpart is more like an N-order curve[22:55:33] <derhass_> japro: I just wondered if that might be good for anything[22:56:10] <japro> iirc it helped when multiplying very large dense matrices with vectors[22:56:22] <foobaz> GPUs seem to store pixels to get cache locality between vertically adjacent pixels[22:56:31] <derhass_> well, for every obscure idea, one probably can find a use case[22:56:34] <foobaz> maybe GPUs use z-order for textures/framebuffers[22:56:42] <derhass_> foobaz: I know[22:56:56] <derhass_> at least: something like that[22:57:23] <japro> you can view zorder as the result of recursive tiling[22:57:25] <chrisf> foobaz: is usually just tiling at various scales.[22:57:44] <foobaz> i wonder if a image file format storing pixels in z-order would have better compression due to the spatial locality[22:57:49] <japro> and iirc in most cases a bit more "sedated" tiling is probably better in practice[22:57:53] <japro> like 4x4 tiles or so[22:58:06] *** ClarusCogitatio has quit IRC[22:58:45] *** paul424 has joined ##OpenGL[23:00:02] *** erhan_ has quit IRC[23:00:29] *** ClarusCogitatio has joined ##OpenGL[23:01:39] <japro> foobaz, using rle on that is very similar to storing the image as a quadtree[23:02:07] <foobaz> interesting[23:02:38] <foobaz> hilbert curve has nice spatial locality too[23:04:55] <japro> well, bedtime[23:06:09] *** faty has joined ##OpenGL[23:06:19] *** faty has quit IRC[23:06:19] *** faty has joined ##OpenGL[23:07:44] *** hexagoxel has joined ##OpenGL[23:08:51] <Codex_> i'm thinking of this rendering algorithm: if (f(x,y,z)) { putpixel(x,y); }[23:08:53] *** Yaniel has quit IRC[23:09:52] *** japro has quit IRC[23:09:57] <Codex_> supposedly it works for any subset of R^3[23:10:11] *** erihel has quit IRC[23:10:58] <derhass_> Codex_: could be done with shaders without much hassle[23:11:12] *** erihel has joined ##OpenGL[23:11:15] *** Yaniel has joined ##OpenGL[23:11:38] <Codex_> big problem is that you need to specify triangles to get it working.[23:11:43] *** bkre has quit IRC[23:11:51] *** bkre has joined ##OpenGL[23:11:57] <derhass_> a gigantic problem, yes[23:12:07] <derhass_> two lines of code[23:12:28] <Codex_> you cant find surface from subset of r^3 easily[23:12:46] *** jdolan has joined ##OpenGL[23:12:49] <derhass_> i'm not speaking of triangulating that surface[23:12:57] <derhass_> i'm speaking of implementing that algorithm[23:15:05] <Codex_> its difficult to choose (x,y,z) points from r^3 without going through large number of points.[23:15:49] <derhass_> I didn't say that it is efficient[23:16:04] <derhass_> but you did come up with that algorithm, not me[23:16:36] *** paul424 has quit IRC[23:17:24] *** bkre has quit IRC[23:17:34] *** bkre has joined ##OpenGL[23:18:31] *** ShadowIce has quit IRC[23:19:57] <Codex_> choosing random point results in holes in the objects :([23:20:35] <Codex_> good for clouds, but not much for anything else.[23:21:01] <mayankmadan_> im currently using glsl version 1.20. is that old?[23:21:05] <mayankmadan_> too old?[23:21:46] <nido> jdolan: tnx[23:21:55] <nido> make that japro, who is now offline. apologies[23:22:12] *** slidercrank has quit IRC[23:25:10] *** Lucretia has quit IRC[23:25:55] *** Lucretia has joined ##OpenGL[23:26:12] *** Alina-malina has quit IRC[23:27:20] *** snakenerd has quit IRC[23:31:07] *** mayankmadan__ has joined ##OpenGL[23:34:01] *** paul424 has joined ##OpenGL[23:34:32] *** mayankmadan_ has quit IRC[23:37:51] *** Alina-malina has joined ##OpenGL[23:38:40] <mayankmadan__> can someone please have a look at http://pastebin.com/kQLYMbER[23:38:56] <mayankmadan__> i have used shaders but still only red background shows up[23:40:28] <derhass_> mayankmadan__: first of all, you shouldn't recomiple the shaders per frame[23:40:29] *** pizthewiz has quit IRC[23:40:40] <newguise1234> mayankmadan__: in your shader, try gl_Position.w = 1.0f;[23:41:01] <derhass_> mayankmadan__: youre fragment shader is wrong[23:41:11] <derhass_> mayankmadan__: vertex shader I mean[23:41:14] *** paul424 has quit IRC[23:41:33] <derhass_> mayankmadan__: you need to use an attribute for the position, not a uniform[23:41:45] <newguise1234> ^-- "in vec3 position"[23:42:01] <newguise1234> err "in vec3 pos;"[23:42:23] <derhass_> it is also not clear which gl version is used[23:42:50] <mayankmadan__> derhass_, 1.10[23:42:51] <newguise1234> add a #version 120 at the beginning of each of your shaders[23:42:57] <newguise1234> err, 110 sorry :/[23:43:10] <derhass_> newguise1234: that is the default anyway[23:43:12] <mayankmadan__> why doesnt it work with uniform[23:43:27] <newguise1234> you're passing in your value to an attribute[23:43:28] <derhass_> mayankmadan__: I specifically spoke of the gl version, not the glsl version[23:43:41] <newguise1234> oh sorry[23:43:44] <mayankmadan__> doesnt attribute type stays the same for all vertices[23:43:57] <newguise1234> uniform does not change across a draw call[23:44:03] <derhass_> the type. but not the values[23:44:17] <newguise1234> attributes will step through the buffers you assign them to over the course of a draw call[23:44:23] *** BitPuffin has quit IRC[23:45:10] <zzuegg> also at a first look your vertices seems to be in the wrong order..[23:45:46] <mayankmadan__> zzuegg, why?[23:46:00] *** qeed has joined ##OpenGL[23:46:06] <derhass_> zzuegg: face culling is off, so it doesn't really matter[23:46:31] *** TunnelCat has joined ##OpenGL[23:46:47] *** pizthewiz has joined ##OpenGL[23:47:12] *** pizthewiz has quit IRC[23:47:36] <zzuegg> ah ok. quickly tested and by default its off. my fault[23:47:45] *** damir__ has quit IRC[23:50:53] *** ClarusCogitatio has quit IRC[23:53:04] *** centrinia has quit IRC[23:53:26] *** Alina-malina has quit IRC[23:54:23] *** ClarusCogitatio has joined ##OpenGL[23:55:41] *** Alina-malina has joined ##OpenGL[23:57:12] *** konom has quit IRC[23:59:59] *** Zupo has joined ##OpenGL