November 9, 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 9, 2014 [00:00:42] <Yaniel> what table?[00:01:03] <Yaniel> also, this only sets the multipliers for the blend operation[00:01:17] <void256> the table on page 3 of their paper :)[00:01:18] <Yaniel> glBlendEquation sets the actual operation[00:01:34] <void256> glBlendEquation(GL_FUNC_ADD);[00:02:07] <void256> there is a table with operations like "A over B" .. Fa = 1 and Fb = 1-source-alpha[00:02:22] <void256> and so on[00:02:47] <void256> and I wonder why there is no operation with Fa = source-alpha and Fb = 1-source-alpha[00:02:57] <Yaniel> hm[00:03:32] <void256> considering that it is somewhat the default blending operation for a lot of caes[00:03:37] <Yaniel> yeah[00:03:39] <void256> *cases[00:04:24] <void256> http://i.imgur.com/roz9wOZ.png <-- the table I refer to[00:06:29] <Yaniel> there is[00:06:33] <Yaniel> A atop B[00:07:08] <void256> yes, but it is using destination alpha[00:07:16] <Yaniel> oh right[00:07:23] <void256> maybe its a typo xD[00:07:35] <void256> and they mean source alpha ^^[00:07:55] <slime> http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx[00:08:22] *** srjil_ has quit IRC[00:08:25] <void256> I kinda assumed it has to do with pre-multiplied alpha =D[00:08:42] * void256 is reading that slime link ...[00:08:46] <void256> *now[00:13:44] <void256> ok[00:15:23] <void256> so actually duff & potter use pre-multiplied alpha (of course) and it's "A over B" with Fa = 1 and Fb = 1-source-alpha :) and Fa = source-alpha and Fb = 1-source-alpha is actually the NONE pre-multiplied alpha version of "A over B"[00:15:25] <void256> nice![00:15:28] <void256> thanks! :)[00:16:40] <Yaniel> ah[00:17:23] *** dmlloyd has quit IRC[00:17:40] *** dmlloyd has joined ##OpenGL[00:19:42] *** foreignFunction has quit IRC[00:21:04] *** charlie5 has quit IRC[00:21:37] *** Zupo has quit IRC[00:25:36] <Majiet> hi[00:25:53] *** Ryp has joined ##OpenGL[00:26:22] <Captain_Crow> is it possible to combine variance shadows with cascade shadow maps?[00:29:47] *** void256_ has joined ##OpenGL[00:31:23] *** fatalhalt has joined ##OpenGL[00:31:36] *** void256 has quit IRC[00:31:41] *** void256_ is now known as void256[00:34:12] *** jdolan has joined ##OpenGL[00:35:53] *** Pyuruku has joined ##OpenGL[00:36:38] *** Match has quit IRC[00:36:46] *** Match_it has quit IRC[00:36:58] <Pyuruku> Hi there, I'm currently implementing a software based renderer, emulating the basic OpenGL pipeline. I'm pretty much done with it, however I have two problems I cannot seem to figure out. The first problem has to do with back-face culling[00:37:08] <Pyuruku> http://i.imgur.com/KhUjOJ5.png This is the output (mine on the right) for a cube[00:37:23] <Pyuruku> however for a sphere, some back faces are still deemed as "visible" by my renderer[00:37:39] <Pyuruku> http://i.imgur.com/iiFVaNh.png[00:37:49] <Pyuruku> I'm wondering why this would happen....[00:37:57] <Pyuruku> my code is calculating the culling in view space[00:38:04] <Pyuruku> so I assume the camera is at 0,0,0[00:38:17] *** Ryp has quit IRC[00:38:19] <Pyuruku> and perform the cam dir dot surface normal[00:38:39] <Pyuruku> to me it almost seems like my code thinks the camera is at a different angle? :o[00:40:32] <derhass_> Pyuruku: well, doing the bf culling in view-space is definitively not emulating the gl pipeline[00:40:51] *** prophile has quit IRC[00:40:56] <derhass_> that will totally ignore thr projection[00:41:02] <Pyuruku> oh? I remember reading somewhere that it was done in the view space since the camera was at 0,0,0 making it "easier"[00:41:03] <Pyuruku> :S[00:41:17] <derhass_> Pyuruku: nope, the culling is done in 2d window space[00:41:32] <Pyuruku> not ndc I assume?[00:41:38] <derhass_> no[00:41:46] <derhass_> basically, it is done during triangle setup[00:42:05] <Pyuruku> so convert the verts into screen space, then do my calculations?[00:42:12] <derhass_> and the test is virtually free, as the calculations for it are needed for rasterization anyway[00:42:30] <Pyuruku> okay, so this should be done after perspective divide?[00:43:26] <derhass_> Pyuruku: well, "should" is relative. depends on how exact you try to emulate real gpu's behavior[00:43:36] <Pyuruku> I just wish to match the output[00:45:08] *** b4b has joined ##OpenGL[00:45:12] *** linuxuz3r has joined ##OpenGL[00:45:14] <linuxuz3r> hi[00:45:25] <linuxuz3r> is display list deprecated[00:45:29] *** stefkos has quit IRC[00:45:35] <derhass_> linuxuz3r: yes[00:46:02] <derhass_> Pyuruku: if you want to match GL, you have to do it after the projection, but not necessarily in window space[00:46:04] <linuxuz3r> what replaced it derhass_[00:46:04] *** centrinia has joined ##OpenGL[00:46:11] <derhass_> linuxuz3r: nothing[00:46:24] *** tcsc_ has joined ##OpenGL[00:46:24] <derhass_> at least not in general[00:46:32] <derhass_> for geomerty, there are VBos of course[00:46:44] *** tcsc has quit IRC[00:47:22] <Pyuruku> wow[00:47:26] <Pyuruku> that just instantly worked derhass_[00:47:28] <Pyuruku> thank you![00:47:42] <Pyuruku> http://i.imgur.com/E5rLYoa.png :-)[00:49:28] <derhass_> Pyuruku: it is probably still the easiest and most efficient way to do it in window space, right before rasterization[00:49:40] <Pyuruku> yep, thats exactly where it is in my code :D[00:49:45] <derhass_> Pyuruku: as this boils down to a simple cross product[00:49:52] <Pyuruku> just had to move it down a bit, line-wise haha[00:53:10] *** jdolan has quit IRC[00:53:12] *** b4b has quit IRC[00:54:14] *** Waynes1 has quit IRC[00:55:27] *** fatalhalt has quit IRC[00:55:52] *** nimtz has joined ##OpenGL[00:56:24] *** jdolan has joined ##OpenGL[00:58:28] *** robot-beethoven has joined ##OpenGL[00:58:50] *** puerum has quit IRC[00:59:10] *** puerum has joined ##OpenGL[00:59:15] *** nimitz has quit IRC[00:59:48] *** Taywee has quit IRC[01:00:14] *** telex has quit IRC[01:00:17] *** kidnapped_robot has quit IRC[01:00:24] *** jdolan has quit IRC[01:01:15] *** Keniyal_ has quit IRC[01:01:44] *** foobaz has quit IRC[01:02:10] *** cmr has quit IRC[01:02:10] *** shakesoda has quit IRC[01:02:40] *** Bigcheese has quit IRC[01:02:40] *** nepgear has joined ##OpenGL[01:02:42] *** antognolli has quit IRC[01:02:43] *** telex has joined ##OpenGL[01:03:00] *** antognolli has joined ##OpenGL[01:03:10] *** Taywee has joined ##OpenGL[01:03:11] *** Peixinho has quit IRC[01:03:24] *** Bigcheese has joined ##OpenGL[01:03:29] *** foobaz has joined ##OpenGL[01:03:33] *** cmr has joined ##OpenGL[01:03:33] *** cmr has joined ##OpenGL[01:03:49] *** kidnapped_robot has joined ##OpenGL[01:04:09] *** tz has quit IRC[01:04:18] *** tz has joined ##OpenGL[01:04:37] *** Peixinho has joined ##OpenGL[01:04:49] *** japro has quit IRC[01:06:21] *** SugarCube has quit IRC[01:07:27] *** Lemml has quit IRC[01:11:28] *** Ad1_RN has joined ##OpenGL[01:14:52] *** Ad1_RnR has quit IRC[01:19:26] *** SugarCube has joined ##OpenGL[01:19:29] *** b4b has joined ##OpenGL[01:21:28] *** Pyuruku has quit IRC[01:27:10] *** ivan\ has joined ##OpenGL[01:28:35] *** Ryp has joined ##OpenGL[01:31:28] *** BitPuffin has quit IRC[01:32:17] *** slidercrank has quit IRC[01:34:49] *** void256 has quit IRC[01:34:49] *** puckipedia has quit IRC[01:36:00] *** Biliogadafr has quit IRC[01:36:47] *** puckipedia has joined ##OpenGL[01:36:59] <linuxuz3r> hi i have a question what is x in Adata[][01:37:02] <linuxuz3r> http://pastie.org/9706156[01:39:46] <HuntsMan> its an array, so there are multiple values of x[01:41:09] *** carvite has quit IRC[01:41:35] *** carvite has joined ##OpenGL[01:41:37] <Textmode> linuxuz3r: they should be in order, so each sub-initialiser should be {x, y, type}[01:46:03] *** Viata has joined ##OpenGL[01:47:26] *** ShadowIce has quit IRC[01:52:37] *** mazde has quit IRC[01:52:41] *** hexagoxel has quit IRC[01:55:09] *** charlie5 has joined ##OpenGL[02:05:23] *** clincher has quit IRC[02:06:43] *** kuldeepdhaka has joined ##OpenGL[02:24:05] *** b4b has quit IRC[02:27:30] *** clincher has joined ##OpenGL[02:29:22] *** b4b has joined ##OpenGL[02:32:22] *** clincher has quit IRC[02:34:24] *** BreadProduct_ has joined ##OpenGL[02:37:33] *** BreadProduct has quit IRC[02:37:41] *** BreadProduct_ is now known as BreadProduct[02:52:17] *** linuxuz3r has quit IRC[02:53:13] *** clincher has joined ##OpenGL[03:10:01] *** TheBeerinator has joined ##OpenGL[03:13:18] *** hdon has joined ##OpenGL[03:17:35] <doomedbunnies> Bah. Making nice camera controls is difficult. (apart from the most boring of first-person cameras, of course)[03:18:56] *** roboman2444 has quit IRC[03:19:36] *** roboman2444 has joined ##OpenGL[03:19:56] *** timsche has quit IRC[03:20:59] *** Crehl has quit IRC[03:21:03] *** qeed has quit IRC[03:23:11] *** Garner has quit IRC[03:23:18] *** Misu has quit IRC[03:23:22] <b4b> does html5 allow for custom tags or just custom tag attributes?[03:24:18] *** DapperPixpy has joined ##OpenGL[03:24:57] *** Ryp has quit IRC[03:26:49] <HuntsMan> b4b: why do you keep asking such kinds of questions here?[03:28:30] *** shintah has quit IRC[03:28:37] <Textmode> HuntsMan: to be fair, iirc the actual web design channels are locked down tighter than fort knox.[03:28:56] <Textmode> b4b: still though, perhaps you might want to try in ##programming or #friendly-coders instead?[03:34:57] *** Vge has quit IRC[03:39:29] *** Madsy has quit IRC[03:47:16] *** Leates has quit IRC[03:48:37] *** Hunts has joined ##OpenGL[03:52:22] *** HuntsMan has quit IRC[03:53:53] *** hdon has quit IRC[03:59:56] *** pabb has joined ##OpenGL[04:00:29] <Stragus> Ahah. We can probably help with any programming language, sure... but HTML is stretching it a little. :)[04:00:56] *** jdolan has joined ##OpenGL[04:01:48] <Textmode> Stragus: is there an opengl binding for BF? :3[04:03:23] <derhass_> that's something someone should built, i think :)[04:05:53] *** jdolan has quit IRC[04:08:51] *** samrat has joined ##OpenGL[04:10:17] <Textmode> nah, but there needs to be a BFSL.[04:11:15] <derhass_> besides HLSL?[04:11:21] <derhass_> don't think so[04:11:23] *** Viata has quit IRC[04:12:03] <Textmode> you draw the line there, eh?[04:12:12] <derhass_> nope[04:12:21] <derhass_> I'm just trolling[04:14:52] *** urraka has quit IRC[04:14:58] <centrinia> I made a converter: https://gist.github.com/Centrinia/2836820aaf12e048e320[04:15:12] <centrinia> You could have a big one dimensional texture.[04:15:23] *** bkre_ has quit IRC[04:15:34] <Textmode> …[04:15:37] *** samrat has quit IRC[04:15:50] <Textmode> centrinia: it was a joke! You aren't supposed to actually do it![04:15:59] <centrinia> :([04:16:25] <Textmode> what have you done? WHAT HAVE YOU DONE‽[04:16:51] <centrinia> Hmm. Befunge Shader Language. :p[04:17:05] <centrinia> You can use two dimensional textures.[04:18:29] *** samrat has joined ##OpenGL[04:28:37] <centrinia> /* BFSL: +++++[>+++++++++<-],[[>--.++>+<<-]>+.->[<.>-]<<,] */ uniform uint ptr[30000]; void main() { int i=0; ptr[i] += 5; while(ptr[i]&255) { i++; ptr[i] += 9; i--; ptr[i]--;} /* ... */ }[04:43:51] *** pabb has quit IRC[04:46:06] *** Cabanossi has quit IRC[04:47:48] *** Cabanossi has joined ##OpenGL[04:50:35] <DMJC-M> how do you handle triangle/quad issues if OpenGL only draws in triangles now?[04:50:43] <DMJC-M> I mean from a modelling context[04:50:58] <DMJC-M> since a quad has 3 different ways it can be split into triangles[04:51:08] <DMJC-M> and a bunch of other ways it can be subdivided[04:52:05] <DMJC-M> e.g, if I'm writing a modeller and I want to put a quad in, that quad would be divided by default into two triangles, but the modeller may want to split it differently to the default way that opengl has chosen.[04:52:25] <Stragus> Normally, the modeller will output a final triangle mesh[04:52:42] <Stragus> Quads are just temporary, handy during the modelling process[04:53:11] <DMJC-M> so I should use quads + opengl for writing a 3d modeller?[04:53:32] <Stragus> Most modelling software handles arbitrary polygons too[04:53:33] <DMJC-M> and then render out the final mesh as triangles for game engines etc?[04:53:42] *** ClarusCogitatio has quit IRC[04:53:52] <DMJC-M> yeah, I understand that, but I'm trying to use OpenGL 3/4[04:54:04] <Textmode> iirc, quads were *always* broken down into triangles anyway.[04:54:23] <Textmode> so nothing has actually changed.[04:54:27] <Stragus> That's not relevant... Modelling can operate on arbitrary polygons even if it's always broken into triangles for rendering[04:54:32] <DMJC-M> ok, so it's more about hiding the triangles from modellers as they work on the model[04:54:46] <DMJC-M> and then once the model is complete turning it into triangles?[04:54:56] <Stragus> That's generally how it works, yes[04:55:42] <DMJC-M> ok, so the next question is, is that done by drawing objects as both solids, and as lines[04:55:53] <DMJC-M> but not drawing all lines, just the ones you want the modeller to see?[04:56:09] <DMJC-M> so if you want them to only see the quad they're editing, you draw the 4 outer lines[04:56:20] <DMJC-M> and let them define how the quad is split into triangles?[04:56:42] <Stragus> You could play a little in Blender to get an idea of the interface and rendering[04:57:04] *** mockillo has quit IRC[04:57:09] <Stragus> Generally, modellers want to be able to see lines and vertices[04:57:12] <DMJC-M> I've used 3d modellers for over a decade, I understand what it does as a modeller, but it's just getting my head around the quads to triangles bit[04:57:45] <DMJC-M> because with glbegin/glend you could actually create quads, but I can understand the downside there too (instability and badly defined quads)[04:58:01] <Stragus> Okay. That part is usually handled by the modelling software just fine, by splitting quads into two triangles that would cause the least distorsions of normals[04:58:02] *** w00tc0d3 has joined ##OpenGL[04:58:20] <DMJC-M> eg, 3 vertices of a quad are planar, but the 4th vert isn't... that used to make rendering look weird/broken[04:58:23] *** netchip has quit IRC[04:58:26] *** w00tc0d3 is now known as Guest589[05:02:47] *** Guest589 has quit IRC[05:04:14] *** Orion] has quit IRC[05:08:59] <dawik> DMJC-M: before I export to wavefront format I triangularize the mesh then just draw the indices[05:09:00] *** meoblast has joined ##OpenGL[05:09:42] <dawik> load the vertex to a vertex buffer object and the indices to an index buffer object[05:10:58] <dawik> using glDrawElements() with one of the arguments being number indices..[05:11:14] <dawik> still working on a texture loader =)[05:11:18] *** meoblast001 has quit IRC[05:11:19] <dawik> trying to find time for it[05:11:51] <dawik> anyway, dont overthink it[05:12:22] *** shingshang has joined ##OpenGL[05:12:42] *** pabb has joined ##OpenGL[05:13:19] *** devbug has joined ##OpenGL[05:21:59] *** DMJC-M has quit IRC[05:23:30] *** xissburg has quit IRC[05:24:15] *** mockillo has joined ##OpenGL[05:25:10] *** samrat has quit IRC[05:26:29] *** meoblast has quit IRC[05:31:51] *** samrat has joined ##OpenGL[05:35:36] *** jdolan has joined ##OpenGL[05:37:45] *** w00tc0d3_ has joined ##OpenGL[05:42:33] *** w00tc0d3_ has quit IRC[05:42:44] *** Bigpet_ has quit IRC[05:47:39] *** konom has quit IRC[05:52:24] *** slime has quit IRC[05:55:53] *** slime has joined ##OpenGL[05:57:02] *** samrat has quit IRC[05:57:33] *** b4b has quit IRC[05:59:37] *** samrat has joined ##OpenGL[06:02:37] *** b4b has joined ##OpenGL[06:02:58] *** clauswit_ has joined ##OpenGL[06:04:52] *** clauswitt has quit IRC[06:16:44] *** Pyuruku has joined ##OpenGL[06:17:18] <Pyuruku> Question, when you do min(vec2, vec2) in GLSL what exactly is this doing? Is this the minimum length?[06:19:38] <cmr> Pyuruku: it does it component wise, so the result will be vec2(min(v1.x, v2.x), min(v1.y, v2.y))[06:20:05] <Pyuruku> thank you cmr, is there a place where I can look up the implementation details of glsl functions?[06:20:09] <Pyuruku> is that even available?[06:21:13] <Stragus> Not the implementation details because it's all closed-source, but the specifications are quite clear on this[06:21:29] <Pyuruku> where would I find such specifications? D:[06:21:30] <cmr> Stragus: well, an always look at mesa...[06:21:35] <cmr> Pyuruku: https://www.opengl.org/documentation/glsl/[06:21:44] <cmr> https://www.opengl.org/registry/ in general[06:21:48] <Stragus> Yes well, digging into Mesa's source code would be a very poor learning experience :)[06:26:57] *** pabb has quit IRC[06:28:09] *** kidnapped_robot has quit IRC[06:54:51] *** bob_twinkles has joined ##OpenGL[06:58:45] *** jdolan has quit IRC[07:01:36] *** b4b has quit IRC[07:04:11] *** glYoda has quit IRC[07:04:20] *** Zeioth has quit IRC[07:04:24] *** glYoda has joined ##OpenGL[07:08:17] *** tcsc_ has quit IRC[07:09:49] *** RyanPridgeon has quit IRC[07:17:43] *** kuldeepdhaka_ has joined ##OpenGL[07:20:26] *** kuldeepdhaka has quit IRC[07:24:57] *** roboman2444 has quit IRC[07:26:07] *** jhuntley has quit IRC[07:31:22] *** roboman2444 has joined ##OpenGL[07:44:43] *** DapperPixpy has quit IRC[07:49:56] *** Pyuruku has quit IRC[07:56:59] *** dshwang has quit IRC[08:10:10] *** devbug has quit IRC[08:12:31] *** CainJacobi has quit IRC[08:12:50] *** jbud has quit IRC[08:27:11] *** JoshSyn has joined ##OpenGL[08:33:29] *** samrat has quit IRC[08:34:45] *** damir__ has quit IRC[08:35:53] *** jdolan has joined ##OpenGL[08:37:11] *** Gamecubic has quit IRC[08:39:05] *** damir__ has joined ##OpenGL[08:42:11] *** seangrove has joined ##OpenGL[08:42:21] *** kuldeepdhaka_ has quit IRC[08:45:11] *** jdolan has quit IRC[08:55:41] *** Twinklebear has quit IRC[08:56:55] *** karab44 has joined ##OpenGL[08:57:46] *** karab44 has joined ##OpenGL[08:58:00] *** dshwang has joined ##OpenGL[08:59:03] *** karab44 has joined ##OpenGL[09:00:10] *** karab44 has joined ##OpenGL[09:00:14] *** FrodoTheHobbit1 has joined ##OpenGL[09:00:17] *** karab44 has quit IRC[09:02:09] *** cr`nge has joined ##OpenGL[09:02:47] *** FrodoTheHobbit has quit IRC[09:06:45] *** Garner has joined ##OpenGL[09:09:23] *** karab44 has joined ##OpenGL[09:16:01] *** dshwang has quit IRC[09:17:23] *** slime has quit IRC[09:17:46] *** Sound has joined ##OpenGL[09:18:50] *** slime has joined ##OpenGL[09:23:17] *** TyrfingMjolnir has quit IRC[09:31:47] *** BreadProduct has quit IRC[09:37:01] *** kuldeepdhaka has joined ##OpenGL[09:37:04] *** bb010g has quit IRC[09:41:15] *** JoshSyn has quit IRC[09:44:39] *** cden has joined ##OpenGL[09:48:06] *** JoshSyn has joined ##OpenGL[09:49:48] *** hdon has joined ##OpenGL[09:50:08] *** rdgawdzi_ has joined ##OpenGL[09:50:28] *** rdgawdzi_ has quit IRC[09:50:37] *** Match has joined ##OpenGL[09:57:39] *** Lemml has joined ##OpenGL[10:13:00] *** JoshSyn has quit IRC[10:19:32] *** samrat has joined ##OpenGL[10:22:35] *** stefkos has joined ##OpenGL[10:24:35] *** Jack_ has joined ##OpenGL[10:35:51] *** ShadowIce has joined ##OpenGL[10:38:09] *** viggo has joined ##OpenGL[10:38:28] *** samrat has quit IRC[10:39:56] *** Waynes has joined ##OpenGL[10:40:05] *** viggo2 has quit IRC[10:42:03] *** Dark_Confidant|m has joined ##OpenGL[10:42:03] *** Dark_Confidant has quit IRC[10:42:48] *** Dark_Confidant has joined ##OpenGL[10:43:11] *** slidercrank has joined ##OpenGL[10:43:34] *** Bigpet_ has joined ##OpenGL[10:43:35] *** Cheery has left ##OpenGL[10:45:14] *** Khlorghaal has quit IRC[10:45:17] *** foreignFunction has joined ##OpenGL[10:46:22] *** petris has quit IRC[10:46:29] *** Dark_Confidant|m has quit IRC[10:48:33] *** Ad1 has joined ##OpenGL[10:49:24] *** petris has joined ##OpenGL[10:53:04] *** MLM has quit IRC[10:56:07] *** shintah has joined ##OpenGL[10:58:47] *** Lemml has quit IRC[11:00:03] *** tapout has quit IRC[11:01:26] *** tapout has joined ##OpenGL[11:01:59] *** Lemml has joined ##OpenGL[11:02:34] *** dshwang has joined ##OpenGL[11:04:26] *** PasNox has joined ##OpenGL[11:10:51] *** qwertz has joined ##OpenGL[11:10:52] *** nitroxis has quit IRC[11:11:01] *** nitroxis has joined ##OpenGL[11:13:41] *** samrat has joined ##OpenGL[11:14:17] <qwertz> Hello, I just tried to code open gl on my laptop and figured out that the window handle (using glfw) couldnt be created after setting the windowhint of major and minor version to 1 2 or 3, so I downloaded an extension viewer which said it supports open gl up to 3.1... my driver is the newest I can get and I even tried setting the version to 1 with no achievement. Any ideas?[11:15:40] <cmr> qwertz: does the simple example work for you? https://github.com/glfw/glfw/blob/master/examples/simple.c[11:17:00] <qwertz> Well I can't check right now since I'm on my phone, collecting ideas to try out later but I can tell you it worked without setting any windowhints[11:17:14] *** Demon_Fox has quit IRC[11:19:28] <cmr> if you were requesting the core profile, none of those versions have a core profile. you should rather ask around in #glfw, but you probably won't get much further without sharing your code[11:20:43] <qwertz> Okay ill check back there later, thanks[11:26:50] *** qwertz is now known as qwertz_mobile[11:32:36] *** Dudi has joined ##OpenGL[11:38:51] *** PasNox_ has joined ##OpenGL[11:39:03] *** PasNox has quit IRC[11:41:03] *** Keniyal has joined ##OpenGL[11:41:56] *** PasNox_ is now known as PasNox[11:44:03] *** robot-beethoven has quit IRC[11:44:51] <Captain_Crow> do variance shadows work with cascade shadow mapping?[11:45:28] <Yaniel> read up on both and take a guess[11:46:23] <Bloodust> :D[11:48:24] <Captain_Crow> i'd image that technically it would "work", but i dont know if the variance shadows would scale differently on each section of the cascade shadow map[11:52:12] *** groton has joined ##OpenGL[11:57:47] *** RyanPridgeon has joined ##OpenGL[11:58:43] *** timsche has joined ##OpenGL[12:06:10] *** Leates has joined ##OpenGL[12:07:32] *** samrat has quit IRC[12:09:00] *** ManDay has joined ##OpenGL[12:15:09] *** JoshSyn has joined ##OpenGL[12:16:10] *** pazul has joined ##OpenGL[12:17:47] *** asdf has joined ##OpenGL[12:18:50] *** jokoon has joined ##OpenGL[12:19:14] *** qwertz_mobile has quit IRC[12:19:51] *** cden has quit IRC[12:20:42] *** Misu has joined ##OpenGL[12:21:23] *** Textmode has quit IRC[12:21:55] *** jdolan has joined ##OpenGL[12:27:06] *** jdolan has quit IRC[12:33:35] <jokoon> I need to read/write to the same texture, so I use 2 clones.[12:33:49] <jokoon> in this link http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Chapter-2.2%3a-Shaders.html[12:33:59] <jokoon> what does this line do ?[12:34:00] <jokoon> gl_Position = vec4(position, 0.0, 1.0);[12:34:18] <jokoon> isn't gl_Position already defined ?[12:34:53] <cmr> jokoon: no, it's not. it is the purpose of the vertex shader to define it, given the input data.[12:35:26] <jokoon> so I can't just call it position2 instead ?[12:35:28] <timsche> and normally u want to multiply the vec4 expression with ur matrices[12:35:33] <jokoon> it has to be gl_Position[12:36:36] *** groton has quit IRC[12:36:41] <Yaniel> gl_Position goes to the rasterizer[12:36:51] <Yaniel> that is hardwired in the driver/hw[12:37:04] <Yaniel> the rest is generic stuff in the shader[12:38:56] <jokoon> so "position" as an attribute, will automatically take the value of the position of the pixel[12:39:08] <jokoon> and then it's assigned to gl_Position[12:39:45] <Yaniel> no[12:39:56] <Hunts> position is an attribute that will get positions of the vertices[12:39:58] <Hunts> but not automatically[12:40:02] <Hunts> you have to setup that[12:40:02] <Yaniel> "position" is a generic attribute that will get whatever value you give it[12:40:11] <Yaniel> from glVertexAttribPointer[12:40:26] <Yaniel> usually you'd set it up to be the vertex position of course[12:40:26] <jokoon> oh ok you do that with opengl[12:40:35] <jokoon> "attribute" means input[12:41:14] <Yaniel> gl_Position is the final position you want to place the vertex at, after modelviewprojection transformations or whatever you want to do[12:41:32] <Yaniel> it is then used to actually rasterize the triangle on screen[12:41:52] *** Dudi has quit IRC[12:46:23] *** devPunk has joined ##OpenGL[12:46:37] *** devPunk has left ##OpenGL[12:46:44] *** devPunk has joined ##OpenGL[12:49:24] *** paperManu_ has joined ##OpenGL[12:50:10] *** hexagoxel has joined ##OpenGL[12:50:37] *** Dudi has joined ##OpenGL[12:50:51] *** Jack has joined ##OpenGL[12:51:15] *** Jack is now known as Guest24462[12:53:37] *** Jack_ has quit IRC[12:54:24] *** Beetny has quit IRC[12:55:43] *** newguise1234 has quit IRC[12:55:44] *** newguise1234 has joined ##OpenGL[12:56:57] *** dshwang has quit IRC[12:59:50] <jokoon> so if I want to get the pixel position in my fragment shader, I have to set it as an output in my vertex shader[13:00:47] <Hunts> there's gl_FragCoord[13:00:51] <cmr> jokoon: https://www.opengl.org/sdk/docs/man/html/gl_FragCoord.xhtml[13:02:13] *** devPunk has left ##OpenGL[13:04:51] *** qeed has joined ##OpenGL[13:06:35] *** Dudi has quit IRC[13:07:50] *** telex has quit IRC[13:08:50] *** telex has joined ##OpenGL[13:09:12] *** xish has quit IRC[13:09:43] *** xissburg has joined ##OpenGL[13:15:52] *** damir__ has quit IRC[13:15:55] *** paperManu_ has quit IRC[13:18:20] *** Keniyal has quit IRC[13:18:36] *** Keniyal has joined ##OpenGL[13:21:23] *** clauswitt has joined ##OpenGL[13:21:36] *** Keniyal has quit IRC[13:22:29] *** Keniyal has joined ##OpenGL[13:23:12] *** clauswitt has quit IRC[13:23:49] *** clauswitt has joined ##OpenGL[13:23:57] *** pazul has quit IRC[13:24:33] *** clauswit_ has quit IRC[13:30:22] *** indefini has joined ##OpenGL[13:30:53] *** Keniyal_ has joined ##OpenGL[13:32:11] *** Keniyal has quit IRC[13:35:54] *** pazul has joined ##OpenGL[13:36:23] *** Crehl has joined ##OpenGL[13:40:24] *** BitPuffin has joined ##OpenGL[13:43:24] *** centrinia has quit IRC[13:54:30] *** kuldeepdhaka has quit IRC[13:54:41] *** dshwang has joined ##OpenGL[13:58:30] *** dshwang has quit IRC[14:00:17] *** Biliogadafr has joined ##OpenGL[14:01:49] *** groton has joined ##OpenGL[14:02:23] *** Guest24462 has quit IRC[14:04:23] *** cr`nge has quit IRC[14:09:23] *** srjil has joined ##OpenGL[14:10:18] *** samrat has joined ##OpenGL[14:10:38] *** Orion] has joined ##OpenGL[14:12:07] *** clauswitt has quit IRC[14:12:28] *** clauswitt has joined ##OpenGL[14:12:35] *** Sricharanized has joined ##OpenGL[14:14:03] *** Sricharanized has left ##OpenGL[14:15:11] *** zajfy has quit IRC[14:15:47] *** clauswitt has quit IRC[14:16:28] *** clauswitt has joined ##OpenGL[14:17:14] *** urraka has joined ##OpenGL[14:18:36] *** PasNox has quit IRC[14:19:15] *** Sricharanized has joined ##OpenGL[14:34:34] *** cr`nge has joined ##OpenGL[14:35:21] *** kuldeepdhaka has joined ##OpenGL[14:35:37] *** jdolan has joined ##OpenGL[14:37:36] *** Madsy has joined ##OpenGL[14:40:51] *** jdolan has quit IRC[14:42:43] *** damir__ has joined ##OpenGL[14:44:08] *** zoraj has joined ##OpenGL[14:44:56] *** jdolan has joined ##OpenGL[14:46:53] *** Sricharanized has left ##OpenGL[14:48:35] *** Sricharanized has joined ##OpenGL[14:49:32] *** Sricharanized has left ##OpenGL[15:04:53] *** zoraj has left ##OpenGL[15:06:48] *** Dark_Confidant has quit IRC[15:06:48] *** Dark_Confidant|m has joined ##OpenGL[15:13:01] *** dshwang has joined ##OpenGL[15:21:08] *** JoshSyn has quit IRC[15:26:54] *** Ryp has joined ##OpenGL[15:28:06] *** Ryp1 has joined ##OpenGL[15:30:09] *** TyrfingMjolnir has joined ##OpenGL[15:30:11] *** det- has joined ##OpenGL[15:31:41] *** Ryp has quit IRC[15:31:52] *** det has quit IRC[15:34:13] *** moser has joined ##OpenGL[15:38:32] *** samrat has quit IRC[15:38:34] *** wiky has joined ##OpenGL[15:41:50] *** Match has quit IRC[15:43:21] *** moser has quit IRC[15:46:37] *** TheLorax has joined ##OpenGL[15:47:50] <TheLorax> when doing indexed drawing, is there a way to say "I want the n'th vertex, and the m'th texture coord, and the p'th normal"?[15:48:40] *** Ryp1 has quit IRC[15:48:49] <Polarina> TheLorax, that is not possible.[15:48:50] <Hunts> nope[15:49:26] <TheLorax> so, if I have 3 vertex attributes, it always takes the n'th from all 3 BOs?[15:49:41] <TheLorax> (just to be perfectly clear :P)[15:49:43] <Hunts> yeah[15:49:45] <TheLorax> thanks[15:49:57] *** moser has joined ##OpenGL[15:51:35] *** det- has quit IRC[15:51:43] *** det has joined ##OpenGL[15:55:10] *** meoblast001 has joined ##OpenGL[15:56:23] *** moser has quit IRC[15:57:47] *** PasNox has joined ##OpenGL[15:58:12] *** kuldeepdhaka has quit IRC[16:10:00] *** Zeioth has joined ##OpenGL[16:10:36] *** ManDay has quit IRC[16:11:17] *** BitPuffin has quit IRC[16:11:53] *** hdon has quit IRC[16:11:56] *** BitPuffin has joined ##OpenGL[16:12:39] *** tcsc has joined ##OpenGL[16:14:28] *** lenarhoyt has joined ##OpenGL[16:14:29] *** bkre_ has joined ##OpenGL[16:15:27] *** lenarhoyt has quit IRC[16:20:40] *** samrat has joined ##OpenGL[16:22:44] *** Sound has quit IRC[16:27:49] *** jokoon has quit IRC[16:27:52] *** hdon has joined ##OpenGL[16:31:56] *** jbud has joined ##OpenGL[16:33:32] *** konom has joined ##OpenGL[16:38:16] *** stefkos has quit IRC[16:39:34] *** Twinklebear has joined ##OpenGL[16:41:00] *** jokoon has joined ##OpenGL[16:43:46] *** Dark_Confidant has joined ##OpenGL[16:45:48] *** Ryp1 has joined ##OpenGL[16:46:11] *** groton has quit IRC[16:47:02] *** wiky has quit IRC[16:47:13] *** Dark_Confidant|m has quit IRC[16:50:21] *** Ryp1 has quit IRC[16:51:31] *** Ryp has joined ##OpenGL[16:52:08] *** Waynes1 has joined ##OpenGL[16:53:40] *** Waynes has quit IRC[16:54:47] *** Ryp has quit IRC[16:55:39] *** katlogic has quit IRC[16:56:48] <jokoon> wtf is precise in glsl ? I'm reading the red book and can't understand one bit of that part[16:57:00] *** jdolan has quit IRC[16:57:27] <Stragus> Tell the compiler not to use approximate calculations, that you need the full numerical range[16:58:03] <Stragus> Divisions and such can be calculated with a lower precision to save precious cycles[16:58:49] <jokoon> yeah something about IEEE floating point[16:58:53] <jokoon> or optimizations[16:59:34] <Stragus> You shouldn't have to worry about that for additions and multiplications[17:00:01] <Stragus> Though one can save cycles with approximations for divisions, pow(), trigonometry, etc.[17:00:02] *** katlogic has joined ##OpenGL[17:00:12] *** wiky has joined ##OpenGL[17:00:20] <jokoon> geez that's a lot of low level details[17:00:34] <Yaniel> just the tip of the iceberg[17:00:34] <jokoon> are shader developers well paid ?[17:01:08] <Stragus> Are software programmers well paid? :) It all depends how skilled you are[17:01:39] <jokoon> I mean is there a high demand to make shaders in games[17:02:04] <Yaniel> not significant in comparison to other code[17:02:11] <jokoon> I don't like 3D engines and API, bit 'm fascinated by shaders[17:02:25] <jokoon> but*[17:02:25] <Stragus> Generally, the two of them go together[17:02:42] *** Sound has joined ##OpenGL[17:03:50] *** jdolan has joined ##OpenGL[17:05:01] <jokoon> isn't there a way to know how many pipelines there are on graphic card ?[17:05:11] <Yaniel> uhh what?[17:05:15] <jokoon> on my card[17:05:33] <jokoon> I mean it can vary by a lot[17:05:42] <jokoon> how many calculation units[17:05:55] <jokoon> all those things[17:05:55] <Yaniel> opencl can tell you that[17:06:05] <Stragus> Or CUDA[17:06:43] <Stragus> OpenGL is higher level than this, since the concept of cores/units/pipelines vary a lot depending on the hardware[17:07:01] <Stragus> varies*[17:07:38] <jokoon> writing opencl code seems quite hard[17:08:07] <Yaniel> not really, just tedious[17:08:39] <jokoon> any python or C++ wrapper ?[17:08:39] *** jdolan has quit IRC[17:08:42] <Stragus> I enjoy writing CUDA code, I haven't tried OpenCL[17:09:19] * Stragus shivers and recoils at the mention of OpenCL and python[17:09:35] <Yaniel> the opencl code itself is okay, the setup it requires is rather convoluted[17:10:15] <jokoon> isn't opencl some sort of a hack ?[17:10:32] <jokoon> I mean a GPU is not design for code[17:10:41] <Bloodust> what :D[17:10:52] <jokoon> for example a GPU is bad at branch prediction[17:11:19] <Yaniel> these days GPUs are not that different from CPUs with tons of SIMD units[17:11:31] <Yaniel> or what are they called[17:11:33] <Yaniel> SIMD lanes?[17:11:58] <Stragus> There's no "branch prediction" in GPUs, but there are branches[17:12:25] <Stragus> You don't need deep pipelines or clever branch prediction because it just switches to different threads whenever it stalls waiting for something[17:12:53] <jokoon> a GPU is massively parallel compared to a CPU, but by how much ? how can quantitize the parallelism of a gpu ?[17:13:14] <Stragus> CPUs are all about how to run a single thread fast. GPUs are about how to run 50000 threads in parallel for peak performance[17:13:19] <jokoon> for example how many "core" does a gpu have ?[17:13:39] <Stragus> Even if you have a GPU with 1536 "CUDA cores", you want more than 1536 threads[17:13:47] <Stragus> It switches to other threads whenever it waits for a memory load[17:13:58] <Bloodust> jokoon hundreds, thousands maybe[17:14:16] <jokoon> "maybe" ?[17:14:28] <Bloodust> I dont rember[17:14:29] <jokoon> you mean it depends on the quality of the chipset[17:14:32] <Bloodust> but its up there[17:14:39] <Bloodust> yeah, greatly[17:14:52] <Stragus> And these aren't independent cores, execution flow is consistent among bundles... Bundles of 32 on Nvidia hardware[17:15:39] <Bloodust> wikipedia says, NVIDIA GTX 980 has 2048 shader processors, 128 texture mapping units and 64 render output units[17:15:53] <Bloodust> gtx 970 on the other hand only has 1664 shader processors[17:16:00] *** PasNox has quit IRC[17:16:03] <jokoon> can't you build more software on opencl/cuda instead of the CPU ?[17:16:04] <Bloodust> hehe, the words aligned[17:16:16] <jokoon> I mean you would need to redesign an engine[17:16:21] *** PasNox_ has joined ##OpenGL[17:16:46] <Stragus> Not all code is friendly to massive GPU parallelization[17:17:15] *** groton has joined ##OpenGL[17:17:45] <jokoon> what if you make it friendly ?[17:18:01] <Yaniel> what if that is not possible[17:18:04] <jokoon> isn't what functional languages are good at ?[17:18:22] <Stragus> It depends on the algorithms, some stuff isn't possible, or the overhead is massive[17:18:29] <Yaniel> pointers for example[17:18:47] *** wiky has quit IRC[17:18:49] <Stragus> CUDA handles pointers just fine[17:19:13] <jokoon> I remember there was a paper on a kernel/os written in lisp or haskell[17:19:36] <Yaniel> neither of them runs on GPUs (yet)[17:19:37] <jokoon> I admit I didn't understand a lot of it[17:19:52] <Yaniel> Stragus: as in you can make, say a rb-tree in CUDA?[17:20:10] <Stragus> Sure. The memory access patterns won't be optimal to CUDA hardware though[17:20:13] <jokoon> well maybe just don't use a rb tree[17:20:14] <Yaniel> not that it would make much sense[17:20:25] <jokoon> use something else for that need[17:20:38] <Yaniel> yeah the memory access patterns will totally kill a lot of algorithms[17:20:59] <Yaniel> especially at the point where you have 10 compute units with completely different access patterns[17:21:00] <jokoon> maybe most algorithms we use are just good on a single thread[17:21:09] *** PasNox__ has joined ##OpenGL[17:21:10] <Yaniel> oh really[17:21:25] <jokoon> maybe the future will be entirely parallel[17:21:50] <Yaniel> maybe[17:21:54] *** PasNox_ has quit IRC[17:22:00] <Yaniel> but HW will still have to evolve[17:22:10] *** PasNox__ is now known as PasNox[17:22:15] <jokoon> in what way ?[17:22:40] <Stragus> Algorithms where each core can very easily take different paths and access totally different information don't perform that great on GPUs[17:22:46] <Bloodust> better, faster, stronger[17:23:01] <Yaniel> for example my GPU only has 9 cores as far as threading is concerned[17:23:10] <Yaniel> cores as in compute units[17:23:19] <jokoon> maybe CPUs will become obsolete, maybe future cpu will have as many core a gpu has[17:23:22] <Stragus> Still, I managed to make my raytracer some 10x faster on CUDA than on CPUs (using SSE/AVX), the gain is just lower[17:23:25] <jokoon> maybe soemthing between the two[17:23:27] <Yaniel> while that is advertised as "960 shader processors"[17:23:42] <Yaniel> the 960 is just SIMT[17:24:05] *** danicampa901 has joined ##OpenGL[17:24:14] <Yaniel> and that happens to be damn useful when doing raster graphics[17:24:31] <Yaniel> and.. some other things[17:24:37] <Yaniel> but nowhere near everything[17:24:45] <jokoon> I don't understand why they are not making high performance GPU on CPU chips[17:25:12] <jokoon> I know there are embedded graphic chips, but I don't see high performance[17:25:44] <jokoon> why not just put the cpu and the GPU on the same die[17:26:06] *** kidnapped_robot has joined ##OpenGL[17:26:06] <jokoon> just make on chip dedicated to games[17:26:20] <jokoon> one*[17:26:44] <jokoon> I'm not a chip engineer but I don't know why it's not doable[17:26:46] <Yaniel> ever heard of intel?[17:26:47] <Stragus> AMD/ATI already does that[17:26:50] <Stragus> And Intel[17:26:51] <jokoon> even for higher performance[17:27:17] <jokoon> then why high performance PC still have graphic cards ?[17:27:21] <jokoon> even consoles[17:27:34] <Yaniel> that merge is certainly a thing that will continue[17:28:01] <jokoon> didn't AMD cancel something hybrid like that?[17:28:19] <Bloodust> cpus and gpus are already in same die[17:28:36] <Stragus> Flexibility, distributed heat production, different chip manufacturers accessing differently designed memory?[17:28:43] <Bloodust> but obviously you cant fit enough transistors and fast ram inside a cpu[17:28:53] <Stragus> CPU RAM isn't designed for the same usage patterns as GPU RAM[17:29:09] <jokoon> ah yeah[17:29:46] *** gaganjyot has joined ##OpenGL[17:30:20] <jokoon> "can't fit enough transistor" well doesn't that amount double every six month ?[17:30:43] <Stragus> GPU RAM can be slow, but it needs massive bandwidth to retrieve big chunks of data at once. CPU RAM needs very fast fetch of small cache lines[17:30:44] <Bloodust> well no and the timespan is 18 months[17:30:50] <jokoon> I mean if you take hardware from 3 years ago you could make it hybrid[17:31:12] <Bloodust> jokoon you do realize GPUs are a lot bigger than CPUs[17:31:35] <jokoon> yeah so what ? isn't it better to have a bigger fan than two ?[17:31:51] <Yaniel> it's not just the fans[17:32:12] <Bloodust> you're right, cooling is one reason[17:32:15] <jokoon> well water cooling isn't mainstream yet too.[17:32:25] <jokoon> yet I'd pay for it[17:32:35] <Bloodust> compress GPU to a size of CPU and itll just melt[17:32:43] <jokoon> isn't it standard on the Dell xps ?[17:32:56] <Bloodust> what is?[17:33:00] <jokoon> water cooling ?[17:33:06] <Bloodust> dunno[17:33:10] <Bloodust> but water cooling wont solve this[17:33:29] <jokoon> put a heat pump then[17:33:59] *** PasNox has quit IRC[17:34:03] <Bloodust> :P[17:34:25] *** PasNox has joined ##OpenGL[17:34:35] <jokoon> GO INVENT SOMETHING !!! I WANT all that music on this phone ! go work on it ![17:34:44] <Bloodust> you can already have that[17:35:00] <jokoon> Just a joke from bill burr[17:35:11] <Bloodust> good man[17:35:25] <jokoon> if you get 100 steve jobs maybe engineers would invent more shit[17:35:31] *** derhass has joined ##OpenGL[17:35:36] <jokoon> maybe not[17:36:30] <Bloodust> science works slowly[17:37:10] <Bloodust> you know we've been studying fusion power since 1950s and the ETA for a proper fusion plant is 2030s[17:38:36] *** derhass_ has quit IRC[17:38:47] <jokoon> maybe a better education system and more incentive to pursue scientific careers would help too[17:39:21] <Bloodust> tell that to other countries, our education system is top of the line :D[17:39:39] *** Zupoman has joined ##OpenGL[17:39:43] <jokoon> not before highschool[17:40:05] <Bloodust> huh[17:40:22] *** jdolan has joined ##OpenGL[17:41:00] <jokoon> if you put the brightest in college, but they don't know enough basics, you won't have enough grey matter[17:41:06] *** clauswit_ has joined ##OpenGL[17:41:45] <jokoon> there is some evaluation of this[17:41:47] <Bloodust> sure I agree on that but our education system is still top of the line[17:42:07] <jokoon> for high levels academics it is[17:42:17] <jokoon> but for kids it sucks[17:42:29] *** clauswit_ has quit IRC[17:42:36] <Bloodust> Im not from the USA if thats what you're implying[17:42:46] <jokoon> that's why you could teach many more students and raise standards[17:42:49] <jokoon> oh[17:42:59] <jokoon> I thought you were talking of the US[17:43:06] <Bloodust> nope[17:43:16] *** clauswit_ has joined ##OpenGL[17:43:21] <Bloodust> talking about my home country, Finland[17:43:37] *** clauswitt has quit IRC[17:44:26] *** PasNox has quit IRC[17:44:40] <jokoon> don't know how to interepret university ratings[17:44:51] *** PasNox has joined ##OpenGL[17:45:27] *** clauswit_ has quit IRC[17:46:21] *** clauswitt has joined ##OpenGL[17:48:56] *** jdolan has joined ##OpenGL[17:49:32] *** Dudi has joined ##OpenGL[17:50:56] *** Dudi_ has joined ##OpenGL[17:54:12] *** Dudi has quit IRC[17:55:06] *** tcsc has quit IRC[17:57:44] *** Ad1 has quit IRC[17:58:31] *** anivemin has joined ##OpenGL[18:00:04] *** ragecryx has joined ##OpenGL[18:05:07] *** PasNox has quit IRC[18:05:59] *** PasNox has joined ##OpenGL[18:10:01] *** japro has joined ##OpenGL[18:10:01] *** tcsc has joined ##OpenGL[18:15:32] *** suppahsrv has quit IRC[18:15:36] *** anivemin has quit IRC[18:16:45] *** PasNox has quit IRC[18:17:44] *** PasNox has joined ##OpenGL[18:22:50] *** RyanPridgeon has quit IRC[18:23:42] *** meoblast001 has quit IRC[18:28:59] *** PasNox has quit IRC[18:30:30] *** tapout has quit IRC[18:30:36] *** PasNox has joined ##OpenGL[18:35:52] *** Dudi has joined ##OpenGL[18:36:32] *** samrat has quit IRC[18:36:55] *** ClarusCogitatio has joined ##OpenGL[18:38:11] *** samrat has joined ##OpenGL[18:39:16] *** Dudi_ has quit IRC[18:42:02] *** ClarusCogitatio has quit IRC[18:42:46] *** RyanPridgeon has joined ##OpenGL[18:42:47] *** stefkos has joined ##OpenGL[18:42:59] *** PasNox has quit IRC[18:43:33] *** suppahsrv has joined ##OpenGL[18:43:50] *** PasNox has joined ##OpenGL[18:45:22] *** clauswit_ has joined ##OpenGL[18:47:40] *** clauswit_ has quit IRC[18:48:27] *** clauswitt has quit IRC[18:48:38] *** clauswitt has joined ##OpenGL[18:51:09] *** devPunk has joined ##OpenGL[18:54:00] *** BitPuffin has quit IRC[18:55:14] *** ClarusCogitatio has joined ##OpenGL[18:56:17] *** hexagoxel has quit IRC[18:58:05] *** Nickeeh_ has quit IRC[19:02:27] *** shingshang has quit IRC[19:02:55] *** clauswitt has quit IRC[19:03:55] *** Nickeeh has joined ##OpenGL[19:04:29] *** clauswitt has joined ##OpenGL[19:04:41] *** neure has joined ##OpenGL[19:07:00] *** neure has quit IRC[19:07:05] *** clauswitt has quit IRC[19:07:55] *** clauswitt has joined ##OpenGL[19:09:42] *** clauswitt has quit IRC[19:10:53] *** clauswitt has joined ##OpenGL[19:12:18] *** devPunk has quit IRC[19:12:26] *** clauswitt has quit IRC[19:12:32] <jokoon> varying is the same thing than in or out ? what about attribute ?[19:12:42] <jokoon> can't grasp if there's a difference[19:13:52] <jokoon> (talking about shaders)[19:15:04] *** clauswitt has joined ##OpenGL[19:16:42] *** aethersis has joined ##OpenGL[19:17:18] *** clauswitt has quit IRC[19:17:22] *** tapout has joined ##OpenGL[19:18:23] *** glYoda has quit IRC[19:19:25] *** clauswitt has joined ##OpenGL[19:20:40] *** DapperPixpy has joined ##OpenGL[19:21:29] *** glYoda has joined ##OpenGL[19:21:37] *** Crehl has quit IRC[19:22:42] *** jhuntley has joined ##OpenGL[19:25:09] *** PasNox has quit IRC[19:25:13] *** PasNox_ has joined ##OpenGL[19:25:24] *** tapout has quit IRC[19:28:23] *** tapout has joined ##OpenGL[19:29:42] *** hdon has quit IRC[19:30:01] *** stefkos has quit IRC[19:30:44] <jokoon> you always need to write this in a vertex shader ? gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;[19:31:02] *** PasNox__ has joined ##OpenGL[19:31:11] <aethersis> no xD[19:31:20] *** PasNox_ has quit IRC[19:33:03] *** tapout has quit IRC[19:33:25] *** Mango_Man has joined ##OpenGL[19:34:19] *** hexagoxel has joined ##OpenGL[19:34:29] *** Nickeeh has quit IRC[19:36:08] *** Nickeeh has joined ##OpenGL[19:39:29] *** hexagoxel has quit IRC[19:40:03] <roboman2444> jokoon, if you arent using a projection matrix, you dont[19:40:17] <roboman2444> such as 2d stuff or FS quads.[19:40:27] <jokoon> okay[19:41:15] <roboman2444> or passing vert stuff not as ye olden gl_Vertex[19:42:02] <roboman2444> or maybe you do some extra junk to the vert position before that... such as skeletal animation or maybe ofsetting the vertex by a heightmap/wave[19:42:05] <Stragus> These days, you generally should use your own vertex attribs rather than the old predefined ones[19:46:01] *** centrinia has joined ##OpenGL[19:49:09] *** Shogun_ has quit IRC[19:49:54] *** Sound has quit IRC[19:50:42] *** glYoda has quit IRC[19:50:54] *** glYoda has joined ##OpenGL[19:52:43] *** Match has joined ##OpenGL[19:53:22] <jokoon> so attribute = in and varying = out ?[19:55:57] <Stragus> "varying" keyword is unnecessary starting from GLSL 1.3[19:56:10] <Stragus> Unless "flat", in is always varying[19:56:58] <jokoon> but in glsl 4.x is it replaced by out ?[19:57:21] <Yaniel> not exactly[19:57:31] <Yaniel> varyings move between shader stages[19:57:33] <Stragus> No. "out" is what you output from the vertex shader to the fragment shader, "in" is what comes into your fragment shader[19:57:58] <Yaniel> are called in and out by what they are from the perspective of each stage[19:58:11] <Yaniel> attribute is the old name for in in vertex shaders[19:58:34] *** harha_ has joined ##OpenGL[19:58:50] <jokoon> from http://nehe.gamedev.net/article/glsl_an_introduction/25007/ "Varyings are used for passing data from a vertex shader to a fragment shader."[19:59:52] <jokoon> oh so if you declare something in the vertex shader, it's also declared in the fragment shader then[19:59:57] <harha_> I need some advice regarding ray refractions. Is there anyone in here who would like to check if my calculations are correct? I'm getting black pixels on random places in my refractive objects, is this just some precision problem or what? Otherwise the refractions seem correct and rays go in and out from materials. It's a raytracer I'm making for fun.[20:01:47] <harha_> http://hastebin.com/lahevoyeje.avrasm <-- Well, there's my refraction function anyways, I'm quite clueless here since I'm not sure if the problem is caused by this method or my ray -> primitive intersection methods...[20:01:59] *** MLM has joined ##OpenGL[20:02:20] <Yaniel> jokoon: no[20:02:45] <jokoon> but you said it's always varying ![20:02:45] <Yaniel> if you have an out variable in the vertex shader[20:02:48] *** PasNox__ is now known as PasNox[20:03:04] <Yaniel> and a in with the same name in the fragment shader[20:03:16] <Yaniel> then the shader linker will wire those together[20:03:35] <roboman2444> jokoon, out and in were introduced in ogl 3, i think[20:03:41] <roboman2444> is varying deprecated?[20:03:44] <Yaniel> yes[20:03:49] <Yaniel> as is attribute[20:04:00] <harha_> varying is deprecated ? Wut, I've always used it...[20:04:05] <Yaniel> since glsl 1.30 I think[20:04:09] <harha_> :S[20:04:21] <Yaniel> or 1.40[20:04:39] <flan3002> Is there an alternative to varying in the version of GL ES SL that GL ES 2 uses?[20:05:03] <Yaniel> 1.40, the same time as profiles were introduced so gl3.1[20:05:04] <jokoon> so is this nehe tutorial still outdated?[20:05:12] <Yaniel> flan3002: no that is still varying[20:05:22] <flan3002> Oh, good. :)[20:05:37] <Yaniel> nehe has been outdated for over a decade[20:05:46] <jokoon> oh.[20:06:29] *** BitPuffin has joined ##OpenGL[20:08:34] <roboman2444> hm[20:08:44] <roboman2444> so, i want to learn how to think a little better about graphics[20:09:00] <Yaniel> there are a bunch of decent modern gl tutorials around[20:09:15] <Yaniel> open.gl for example[20:09:29] *** Leates has quit IRC[20:09:55] <harha_> TheBennyBox has a really good introductory modern opengl video tutorial series in youtube if you prefer watching videos. The guy also has plenty of some other more advanced awesome opengl tutorials.[20:10:25] <roboman2444> can someone explain to me how some of the demoscene effects are done.[20:10:37] <roboman2444> especially ones that involve lots of geometry doing weird movement[20:10:42] <roboman2444> https://www.youtube.com/watch?v=vVjY4_ToABA like the wavy stuff in here[20:11:04] <harha_> Raymarching perhaps?[20:11:35] <roboman2444> no, as these sorts of stuff have been done since 2000[20:12:18] <roboman2444> like, im pretty decent at other opengl stuff.[20:12:42] <roboman2444> but anything that requires mesh deformation or generation (especially not your standard vertex shader based stuff) i get confused[20:12:50] <harha_> Well nothing prevents you from doing those effects with like single fragment shader nowadays. I don't know then, no idea how they did complex stuff like that back in the days..[20:14:18] <harha_> you should check out https://www.shadertoy.com/ if you haven't already[20:14:35] <harha_> the site has some really amazing effects done only in the fragment shader... and everything is open source obviously[20:14:36] *** PasNox has quit IRC[20:14:37] <roboman2444> http://youtu.be/s7kRwQGyKJI?t=1m54s or like this[20:14:43] <roboman2444> im not a fan of fragment shader stuff[20:14:57] <roboman2444> especially since it isnt a good thing to incorperate with a game[20:15:08] <roboman2444> and usually is slower for simpler effects[20:15:32] <harha_> I'd imagine it being quite useful for example pixel perfect ligthing?[20:15:45] <harha_> slower than vertices though, yes..[20:15:45] <Bloodust> a big chunk of game effects are all done in fragment shader[20:16:21] <harha_> myep[20:16:33] <roboman2444> Well fragment shader for normal stuff is good[20:16:38] <harha_> https://www.shadertoy.com/view/Mss3WN <-- There's an oldschool'ish metaballs effect made in the fragment shader, as example.[20:16:43] <roboman2444> im not a fan of raymarching stuff in fragment shader[20:17:38] *** unreal has quit IRC[20:17:47] <harha_> why not? D:[20:20:16] *** Dudi_ has joined ##OpenGL[20:21:12] *** Dudi_ has quit IRC[20:21:28] <roboman2444> i have my reasons[20:21:39] <roboman2444> im more interested ATM how to do complex vertex stuff[20:21:49] <Bloodust> such as?[20:21:56] <roboman2444> or other weird effects that arent just raymarching a SDF in fragment shader[20:21:58] <harha_> Whatever floats your boat.[20:22:18] <roboman2444> Bloodust, look at any demo pre- 2010, and after 2000[20:22:29] <roboman2444> most of them have some weird vertex manipulation going on[20:22:38] <Bloodust> you have to be wayy more specific than that[20:22:47] <roboman2444> https://www.youtube.com/watch?v=u1n8uYmi9W8 this is a good one[20:22:50] *** Dudi has quit IRC[20:23:09] <roboman2444> like, how does one keep track of all of those cubes?[20:23:22] *** devPunk has joined ##OpenGL[20:23:32] *** devPunk has left ##OpenGL[20:23:42] <Bloodust> pretty easily on cpu side[20:24:01] <roboman2444> Bloodust, how would you do it?[20:24:18] <Bloodust> how would I store a bunch of cubes on cpu side?[20:24:20] <Bloodust> in an array[20:24:26] <Bloodust> I really dont understand what the issue here is[20:24:41] <roboman2444> and how would you do all the effects in that video?[20:25:07] <Bloodust> well in the beginning theres a branching tree[20:25:11] <Bloodust> or tree like structure[20:25:28] <Bloodust> thats pretty trivial to code[20:25:37] <roboman2444> i dunno if it is actually based on a tree[20:25:46] <japro> yeah, i use std::pretty_tree for that[20:25:46] <Bloodust> well its branching[20:26:04] <roboman2444> doesnt mean its a tree to STORE the cubes[20:26:06] <roboman2444> maybe to spawn them[20:26:27] <roboman2444> i suspect there is a float per cube that stores its "distance" along the tree as well[20:26:53] <Bloodust> okey..[20:27:33] <Bloodust> I have a function that takes a line (bunch of points) and outputs a tube that follows the line (bunch of triangles)[20:27:50] <Bloodust> it'd trivial to change that code to create the tube out of cubes[20:28:02] <Bloodust> and then all thats left to do, is the branching algorithm for the line[20:28:05] <japro> tubes of cubes[20:28:40] *** aethersis has quit IRC[20:30:10] <roboman2444> ok, any other ones that you think are out of the ordinary?[20:30:35] <bob_twinkles> the other thing they could be doing is just rending points and building the cubes in a geometry shader[20:30:40] <bob_twinkles> dunno if that's faster though[20:30:45] <Bloodust> it depends[20:30:52] <Majiet> is they any good tutorial on, cameras?[20:30:54] <Bloodust> I did that with my minecraft renderer for a while[20:31:07] <roboman2444> https://www.youtube.com/watch?v=XH3mu80MpWE[20:31:20] <roboman2444> this one has a scene where it voxelizes stuff[20:31:23] <roboman2444> really weirdl[20:31:33] <japro> Majiet, I like the classics: http://www.amazon.com/Ansel-Adams-Camera-Photography-Series/dp/0821221841[20:31:36] <bob_twinkles> I remember reading somewhere that geometry shaders get slower as the ratio of points in to points out gets higher[20:31:43] <Bloodust> bob_twinkles yep[20:31:51] <harha_> I have no idea what a geometry shader is... is it used as the rasterization part of the rendering pipeline perhaps?[20:31:55] <Bloodust> but cube is only 3 faces = 6 triangles[20:32:08] <roboman2444> Bloodust, you can usually use less as well if done right[20:32:11] <japro> harha_, somwhat like a vertex shader except it sees the whole primitive[20:32:17] <roboman2444> you only see at max 3 faces at a time[20:32:19] <Majiet> where thinking about to, opengl :P[20:32:22] <harha_> Oh, neat. D:[20:32:25] <japro> + it can ouput other/more/less primitives[20:32:28] <Bloodust> roboman2444 thats what I said[20:32:53] <Bloodust> full cube has 6 faces[20:33:08] <roboman2444> https://www.youtube.com/watch?v=8MMwO8Mvqfs this one is another wacky one[20:33:26] <Bloodust> yes yes[20:33:42] *** groton has quit IRC[20:36:43] *** gaganjyot has quit IRC[20:37:34] <harha_> Fuck it's sometimes difficult to see where I should use EPSILON for precision in a raytracer and where not. D: Black pixels, black pixels everywhere.[20:38:19] <japro> if(black){average_four_neighbors(); } // hack fix me (12 years ago)[20:38:34] <harha_> lol[20:39:12] <bob_twinkles> does someone feel like staring at an opengl call stream and telling me how I'm getting the nvidia driver to sigsegv?[20:40:55] <bob_twinkles> usually this means that I'm trying glDrawElements() too many things without setting up the right buffers[20:41:16] <bob_twinkles> but I can't for the life of me figure out what the driver wants that I'm not giving it[20:43:10] <Stragus> Some old attrib array left enabled?[20:44:14] <bob_twinkles> don't think so, unless there's one enabled by default I don't know about[20:44:44] *** SleekoNiko has quit IRC[20:45:17] <Bloodust> pastebin ![20:47:13] <bob_twinkles> http://pastebin.com/u7bv0jBZ[20:47:36] <bob_twinkles> the frame starts with a glClear() and ends with glXSwapBuffers[20:48:57] <Bloodust> wtf[20:49:07] <bob_twinkles> ?[20:49:23] <Bloodust> yeah I meant code[20:49:53] <bob_twinkles> uh... it's sort of spread across 3 or 4 C++ files and headers[20:50:16] <bob_twinkles> some of which are like 150+ lines[20:51:00] *** devbug has joined ##OpenGL[20:51:37] <bob_twinkles> I mean, I can throw the whole thing on github if you feel like trawling through it but I figured that the raw opengl call stream was easier[20:51:39] *** Match has quit IRC[20:52:06] <Bloodust> yeah no thanks[20:52:22] <bob_twinkles> heh[20:52:22] *** Mango_Man has quit IRC[20:52:45] *** Ad1 has joined ##OpenGL[20:53:13] *** FrodoTheHobbit has joined ##OpenGL[20:55:26] <urraka> bob_twinkles i see glBindVertexArray right after a glBindBuffer(GL_ELEMENT_ARRAY_BUFFER)[20:55:32] <urraka> which could be a problem[20:56:01] <urraka> the VAO will bind its own element array buffer[20:56:37] *** FrodoTheHobbit1 has quit IRC[20:58:17] <bob_twinkles> yep, that was it[20:58:35] <bob_twinkles> I knew that too =([20:58:37] <bob_twinkles> urraka++[20:58:40] <urraka> heh[20:58:53] *** ClarusCogitatio has quit IRC[21:01:02] *** jokoon has quit IRC[21:01:27] *** ClarusCogitatio has joined ##OpenGL[21:01:44] *** asdf has quit IRC[21:01:58] *** asdf has joined ##OpenGL[21:04:26] *** asdf has quit IRC[21:04:34] *** asdf has joined ##OpenGL[21:04:52] *** Jack has joined ##OpenGL[21:05:15] *** Jack is now known as Guest23051[21:06:34] *** ClarusCogitatio has quit IRC[21:09:50] *** soulz has quit IRC[21:10:27] *** ClarusCogitatio has joined ##OpenGL[21:11:57] *** Mango_Man has joined ##OpenGL[21:12:15] *** Ad1 has quit IRC[21:12:50] *** Mango_Man has quit IRC[21:13:25] *** AndChat|643025 has joined ##OpenGL[21:13:34] *** BreadProduct has joined ##OpenGL[21:14:44] *** soulz has joined ##OpenGL[21:15:42] *** AndChat|643025 has quit IRC[21:15:44] *** AndChat-643025 has joined ##OpenGL[21:15:44] *** soulz has quit IRC[21:16:46] *** telex has quit IRC[21:16:58] *** razieliyo has joined ##OpenGL[21:17:18] *** Ad1 has joined ##OpenGL[21:17:19] *** ClarusCogitatio has quit IRC[21:17:26] *** asdf has quit IRC[21:17:42] *** Ryp has joined ##OpenGL[21:17:57] *** ClarusCogitatio has joined ##OpenGL[21:18:21] *** unreal has joined ##OpenGL[21:18:47] *** telex has joined ##OpenGL[21:20:46] *** soulz has joined ##OpenGL[21:23:04] *** cr`nge has quit IRC[21:23:48] *** ClarusCogitatio has quit IRC[21:24:48] *** AndChat-643025 has quit IRC[21:24:53] *** ClarusCogitatio has joined ##OpenGL[21:24:55] *** t4nk618 has joined ##OpenGL[21:26:30] *** samrat has quit IRC[21:30:00] *** Shogun has joined ##OpenGL[21:30:36] *** Waynes1 has quit IRC[21:31:15] <t4nk618> hello, im currently implementing cascaded shadow mapping which works fine[21:31:34] <t4nk618> now i have one last cascade which covers a big area behind and in front of the camera to get large shadow casters into the scene[21:32:06] <t4nk618> now i want to blend in those shadows with the shadows of a closer cascade[21:32:23] <t4nk618> to get detailed close shadows, with the ones from large objects[21:32:31] <t4nk618> well it works, but not with pcf filtering[21:33:07] <t4nk618> as it smoothens the edges, i get lines between the part of the close cascade and the large cascade[21:33:17] <t4nk618> i can fix it with disabling pcf[21:33:24] *** ClarusCogitatio has quit IRC[21:34:05] <t4nk618> http://postimg.org/image/6q0k85443/[21:34:10] <t4nk618> here is an image displaying the problem[21:34:12] *** ClarusCogitatio has joined ##OpenGL[21:34:34] <bob_twinkles> texture borders?[21:34:50] <bob_twinkles> like it's pulling samples from outside of your maps when it filters[21:35:22] <t4nk618> no thats not the case, its just when the first texture map from the closer cascade stops, i load in the large shadow map from the last cascade which covers a large area[21:35:39] <t4nk618> and as i use percentage closer filtering, its smoothing ofc the shadow from the closer cascade[21:35:49] <t4nk618> resulting in smoothed out shadows to the larger cascade[21:36:14] <t4nk618> its like a canyon between the current cascade and the last cascade :)[21:36:30] <bob_twinkles> do you have a screenshot of what it's supposed to look like?[21:36:33] *** centrinia has quit IRC[21:36:40] <t4nk618> as i said , it works fine if i disable pcf[21:36:49] <t4nk618> the problem is, pcf is smoothing inwards[21:36:50] <t4nk618> somehow[21:36:56] <t4nk618> and not smoothing outwards[21:36:58] <t4nk618> thats what i need[21:37:38] <bob_twinkles> um...[21:37:46] <bob_twinkles> throw in a 1-factor?[21:38:02] *** cr`nge has joined ##OpenGL[21:38:14] <bob_twinkles> like instead of pcf(factor, a, b) do pcf(1-factor, a, b)[21:38:43] <bob_twinkles> or pcf(factor, b, a) if you like[21:38:59] *** b4b has joined ##OpenGL[21:40:39] *** ClarusCogitatio has quit IRC[21:41:30] *** ClarusCogitatio has joined ##OpenGL[21:42:44] <t4nk618> well if i use something like float depthValue = texture( shadowTexture2, sCoord.st + ( 1.0 - poissonDisk[i] /900.0) ).r; i get horrible aliasing[21:43:12] *** Garner has quit IRC[21:43:38] <bob_twinkles> is poissonDisk[i] / 900.0 normalized?[21:44:07] *** Guest23051 has quit IRC[21:44:20] <t4nk618> yes its filled with values like -0.94201624, -0.39906216[21:44:38] <t4nk618> it works with the 1.0 - part[21:44:44] <t4nk618> but its just offsetting too much[21:44:50] <bob_twinkles> what's the code you're using right now?[21:44:54] <bob_twinkles> that creates the canyons[21:45:07] <t4nk618> depthValue = texture( shadowTexture4, sCoord.st + poissonDisk[i]/700.0 ).r;[21:45:23] <t4nk618> without the pcf offset of the texture, it works fine[21:45:32] *** CainJacobi has joined ##OpenGL[21:46:06] *** Gamecubic has joined ##OpenGL[21:46:19] *** asdf has joined ##OpenGL[21:46:36] <t4nk618> the higher the divide, the smaller the smoothing[21:46:46] *** clauswit_ has joined ##OpenGL[21:46:50] <t4nk618> so poissonDisk[i] / 2000 only results in a small canyon[21:46:58] <bob_twinkles> what would happen if you subtracted the poissonDisk[i]/700?[21:47:14] <bob_twinkles> so "sCoord.st - poissonDisk[i]/700.0"[21:47:35] <t4nk618> the same[21:47:53] *** clauswit_ has quit IRC[21:48:14] <t4nk618> it maybe just offsets the shadow a little bit to the outside, but still smooths inwards[21:48:31] *** clauswit_ has joined ##OpenGL[21:49:07] <t4nk618> hmm i dont think it works like i want it to[21:49:15] <t4nk618> i need to overlap the large cascade to the smaller one[21:49:27] <t4nk618> because if i want smoothing, it always smoothes the edges of the small shadow map[21:49:30] *** clauswitt has quit IRC[21:49:36] <bob_twinkles> I feel like the problem is that the texture() call is getting something out of the [0,1] domain for u or v[21:50:22] <bob_twinkles> can you run your app under something like apitrace?[21:51:02] <t4nk618> and check what?[21:51:09] <t4nk618> i have a deferred pipeline, i can check all my textures[21:52:06] <t4nk618> here is the shadow map of the closer cascade : http://s1.postimg.org/stce9klu7/small.png[21:52:12] <t4nk618> you can see, its not getting the whole mesh[21:52:21] <t4nk618> and here is the "area" cascade: http://s27.postimg.org/doce892v7/large.png[21:52:49] <bob_twinkles> apitrace would tell you if the shader needed to be recompiled to normalize values[21:53:11] <bob_twinkles> which could confirm/deny my suspicion[21:54:07] <t4nk618> ah well i fixed it[21:54:29] *** Ryp has quit IRC[21:54:31] <bob_twinkles> what was the problem?[21:54:34] <t4nk618> i used a simple check like if( visibility < 1.0) to check if the small cascade has shadows[21:54:52] <t4nk618> if the fragment is in shadow, if not, i multiply it with the visibility of the "area" shadow factor[21:55:08] <t4nk618> now i check it like if(visibility < 0.7) to get the smooth part into it[21:55:23] <t4nk618> so it overrides the smoothed part with the area shadow[21:55:39] *** petervaro has joined ##OpenGL[21:55:54] <harha_> Guys, do these refractive spheres look correct to you? http://i.gyazo.com/409dbeef5cfe9e0c017d79ca2ca5fba7.png <-- The refraction index is below the usual 1.52 of glass in all spheres btw..[21:55:56] <bob_twinkles> ah, the good ole fiddle with the magic number fix[21:57:06] *** bb010g has joined ##OpenGL[21:57:17] <t4nk618> bob_twinkles yeah kinda[21:57:23] <t4nk618> till i find a better solution[21:57:40] <bob_twinkles> harha_: in my completely unprofessional opinion it looks like the IOR is too high, but I'm not sure exactly how that scene should look[21:58:09] <bob_twinkles> at least on the sphere on the right[21:59:11] <harha_> Myeah... it's hard to tell.. I think my calculations are correct and I've debugged the rays and they indeed refract at the each side of the sphere and the refraction index is calculated correctly at the each side of the sphere so... I guess it's working.. D:[21:59:35] <harha_> I took the refraction and reflection functions from GLSL doc...[22:00:14] <bob_twinkles> got an easy way to get the scene into another raytracer to check it?[22:00:23] <bob_twinkles> like blender's cycles or povray or something[22:02:42] <harha_> Oh, yeah... Why didn't I think of that? :S[22:02:45] <harha_> wtf[22:02:46] <harha_> brain[22:02:54] *** ClarusCogitatio has quit IRC[22:03:51] <bob_twinkles> dude I spent like 3 hours yesterday figuring out that I was binding the same buffer to both the array and element_array bindpoints[22:03:58] <bob_twinkles> and roflstomping all my data[22:04:10] <bob_twinkles> 1 mother f'in character =P[22:04:32] *** ClarusCogitatio has joined ##OpenGL[22:04:38] <harha_> xD[22:10:39] *** ClarusCogitatio has quit IRC[22:12:05] *** ClarusCogitatio has joined ##OpenGL[22:12:33] *** Garner has joined ##OpenGL[22:16:08] *** RyanPridgeon_ has joined ##OpenGL[22:17:11] *** ClarusCogitatio has quit IRC[22:18:53] *** RyanPridgeon has quit IRC[22:24:47] *** t4nk618 has quit IRC[22:32:18] *** harha_ has quit IRC[22:32:26] *** SleekoNiko has joined ##OpenGL[22:34:36] *** Alina-malina has quit IRC[22:38:02] *** stefkos has joined ##OpenGL[22:48:53] *** Alina-malina has joined ##OpenGL[22:48:54] *** Alina-malina has joined ##OpenGL[22:56:25] *** slime has quit IRC[22:59:52] *** Alina-malina has quit IRC[23:00:08] *** asdf has quit IRC[23:00:30] *** Alina-malina has joined ##OpenGL[23:00:30] *** Alina-malina has joined ##OpenGL[23:03:04] *** ragundo has joined ##OpenGL[23:03:55] *** dmlloyd has quit IRC[23:06:45] *** maw_ has quit IRC[23:06:48] *** Alina-malina has quit IRC[23:06:53] *** MrDen has quit IRC[23:07:48] *** MrDen has joined ##OpenGL[23:08:14] *** ragundo has quit IRC[23:08:49] *** Crehl has joined ##OpenGL[23:11:36] *** Ad1_RnR has joined ##OpenGL[23:12:13] *** maw has joined ##OpenGL[23:12:24] *** Crehl has quit IRC[23:15:11] *** Ad1_RN has quit IRC[23:19:46] *** b4b has quit IRC[23:24:19] *** asdf has joined ##OpenGL[23:25:42] *** DapperPixpy has quit IRC[23:30:19] *** Demon_Fox has joined ##OpenGL[23:33:33] *** hexagoxel has joined ##OpenGL[23:36:35] *** pazul has quit IRC[23:41:31] *** ragecryx has quit IRC[23:42:48] *** Khlorghaal has joined ##OpenGL[23:49:58] *** asdf has quit IRC[23:51:58] *** Shogun_ has joined ##OpenGL[23:52:27] *** Shogun has quit IRC[23:53:04] *** Lemml has quit IRC[23:56:32] *** TheTeapot has joined ##OpenGL[23:56:43] *** Gamecubic has quit IRC[23:57:07] *** FrodoTheHobbit1 has joined ##OpenGL[23:57:09] *** Gamecubic has joined ##OpenGL[23:57:23] *** foreignFunction has quit IRC[23:58:21] *** ShadowIce has quit IRC[23:58:45] *** razieliyo has quit IRC[23:58:55] *** FrodoTheHobbit has quit IRC[23:59:59] *** danicampa901 has quit IRC