November 11, 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 11, 2014 [00:00:26] *** metredigm has joined ##OpenGL[00:01:12] <aethersis> yeah sure and what else and what for[00:01:41] <aethersis> my favourite approach is fake it till you make it[00:01:51] <aethersis> if you can't tell a difference, then why overdo something?[00:02:20] <aethersis> you could do all the CFD, raytracing and shit for no reason because it can be easily faked with 100x lower GPU load[00:02:47] <bob_twinkles> yeah[00:02:57] <bob_twinkles> I think it's a weird for of NIH syndrome or something[00:03:10] <bob_twinkles> like "I could do it the easy way, or I could play with all these cool big words"[00:03:26] <aethersis> I'm writing my own fluid solver[00:04:43] *** ShadowIce has quit IRC[00:06:28] *** TunnelCat has joined ##OpenGL[00:07:44] <bob_twinkles> there's just so many fun toys you can implement (CFD, raytracing, entity component systems, what have you) that it's really easy to have a project get bogged down in infrastructure stuff[00:08:14] <aethersis> meh[00:09:12] *** DaReelMVP has joined ##OpenGL[00:13:17] *** narcan has joined ##OpenGL[00:17:04] *** vdgtech has joined ##OpenGL[00:17:10] <vdgtech> hellp[00:17:15] <vdgtech> hello+[00:18:35] <metredigm> hello++[00:19:15] *** staylor has quit IRC[00:19:34] <aethersis> hi--[00:20:26] *** clauswitt has quit IRC[00:22:40] *** sasoo7_ has joined ##OpenGL[00:24:01] *** sasoo7_ has left ##OpenGL[00:25:05] *** sasoo7_ has joined ##OpenGL[00:25:34] *** sasoo7_ is now known as yomamy[00:25:48] *** vdgtech has quit IRC[00:28:27] *** paperManu_ has joined ##OpenGL[00:29:33] *** paperManu_ has quit IRC[00:34:01] *** shintah has quit IRC[00:36:13] *** paperManu has joined ##OpenGL[00:36:45] *** yomamy is now known as AHugePinkDildo[00:37:43] *** AHugePinkDildo has quit IRC[00:37:47] *** DaReelMVP has quit IRC[00:38:00] *** DaReelMVP has joined ##OpenGL[00:39:52] *** DaReelMVP is now known as NateNeedsMoreSWA[00:45:25] *** timsche has quit IRC[00:49:30] <aethersis> mew[00:49:33] *** HaltingState has quit IRC[00:49:49] <bob_twinkles> woof[00:50:38] <aethersis> xD[00:50:39] <aethersis> yiff[00:51:24] *** HaltingState has joined ##OpenGL[00:55:33] <aethersis> xD[01:00:40] *** petervaro has quit IRC[01:00:59] *** prophile has joined ##OpenGL[01:01:21] *** derhass has quit IRC[01:08:28] *** MiniCow has joined ##OpenGL[01:11:02] *** Orion] has quit IRC[01:12:53] *** BreadProduct has joined ##OpenGL[01:13:13] <aethersis> jesus christ, I'm watching such a dumb film it's unbelievable[01:13:17] *** Sirolf has joined ##OpenGL[01:13:38] <aethersis> "Into the storm" Anyone seen it?[01:13:55] <bob_twinkles> nope[01:14:08] <bob_twinkles> is it worth it to implement valve's signed distance fields for text rendering[01:14:19] <bob_twinkles> or just splat some stuff from freetype and call it a day[01:15:10] *** tcsc has joined ##OpenGL[01:15:30] <bob_twinkles> hmm[01:15:40] <bob_twinkles> it looks like I'll need to pull in freetype either way[01:15:47] <bob_twinkles> texture splatting it is[01:16:13] *** BreadProduct_ has joined ##OpenGL[01:17:28] *** Sirolf has quit IRC[01:18:02] *** BreadProduct has quit IRC[01:18:17] *** BreadProduct_ is now known as BreadProduct[01:24:50] *** damir__ has quit IRC[01:25:24] *** shintahW2 has joined ##OpenGL[01:26:34] *** indefini has quit IRC[01:27:10] <XMPPwocky> font rendering[01:27:11] <XMPPwocky> args[01:27:13] <XMPPwocky> argh[01:27:45] *** bkc_ has quit IRC[01:27:53] *** shintahW has quit IRC[01:27:53] *** shintahW2 is now known as shintahW[01:28:18] *** bkc_ has joined ##OpenGL[01:29:37] *** CapsAdmin has quit IRC[01:30:02] *** CapsAdmin has joined ##OpenGL[01:30:58] <bob_twinkles> it doesn't look like it's gonna be _too_ bad[01:31:19] <bob_twinkles> just gotta wire freetype up to my textured rectangle machinery[01:32:12] *** konom has quit IRC[01:34:08] *** hexagoxel has quit IRC[01:34:38] *** aethersis has quit IRC[01:34:45] *** hexagoxel has joined ##OpenGL[01:35:18] *** bkre_ has quit IRC[01:35:52] *** Ryp has joined ##OpenGL[01:39:07] *** jdolan has quit IRC[01:45:22] *** petervaro has joined ##OpenGL[01:46:35] *** staylor has joined ##OpenGL[01:47:02] *** Twinklebear has joined ##OpenGL[01:53:28] *** dahlia is now known as dahlia_[01:57:06] *** konom has joined ##OpenGL[01:57:43] *** indefini has joined ##OpenGL[01:59:17] *** Ryp has quit IRC[02:00:52] *** jdolan has joined ##OpenGL[02:02:12] *** metredigm has quit IRC[02:02:37] *** SleekoNiko has joined ##OpenGL[02:03:30] *** robot-beethoven has joined ##OpenGL[02:06:25] *** hahuang61 has quit IRC[02:06:29] <foobaz> freetype works great as long as you only display the text at the exact size you render it at, with GL_NEAREST filtering[02:06:53] <foobaz> the strength of the valve approach is it lets you draw arbitrary font sizes with only one texture[02:09:24] *** pizthewiz has joined ##OpenGL[02:11:50] <bob_twinkles> I'm more or less going to be using this solely for debug/informational output[02:11:59] <bob_twinkles> so it doesn't matter if it looks like crap[02:12:12] *** centrinia has joined ##OpenGL[02:13:00] <bob_twinkles> at least until I get annoyed and bored and implement the valve approach =P[02:13:40] *** carvite has quit IRC[02:14:08] *** cr`nge has quit IRC[02:14:09] *** TyrfingMjolnir has joined ##OpenGL[02:14:53] *** slidercrank has quit IRC[02:16:05] *** hexagoxel has quit IRC[02:27:29] *** Misu has quit IRC[02:28:11] *** cr`nge has joined ##OpenGL[02:29:40] *** prophile has quit IRC[02:29:52] *** HuntsMan has quit IRC[02:30:44] *** carvite has joined ##OpenGL[02:36:48] *** Crehl has quit IRC[02:38:06] *** SleekoNiko has quit IRC[02:38:13] *** carvite has quit IRC[02:39:02] *** tz has left ##OpenGL[02:44:45] *** carvite has joined ##OpenGL[02:46:18] *** NateNeedsMoreSWA has quit IRC[02:49:24] *** carvite has quit IRC[02:51:11] *** SleekoNiko has joined ##OpenGL[02:51:19] *** carvite has joined ##OpenGL[02:52:20] *** paperManu has quit IRC[02:53:47] *** Ivorius_ has joined ##OpenGL[02:56:16] *** carvite has quit IRC[02:56:52] *** Ivorius has quit IRC[02:57:24] *** nemesit|znc has quit IRC[02:57:35] *** BtbN has quit IRC[02:57:37] *** hellome has quit IRC[02:58:03] *** jophish__ has quit IRC[02:58:08] *** jonet has quit IRC[02:58:37] *** jophish has joined ##OpenGL[02:59:24] *** YarnFive8 has quit IRC[02:59:29] *** roboman2444 has quit IRC[02:59:53] *** Keniyal has quit IRC[03:00:01] *** jophish is now known as Guest13969[03:02:35] *** BtbN has joined ##OpenGL[03:02:37] *** nemesit|znc has joined ##OpenGL[03:03:16] *** carvite has joined ##OpenGL[03:03:42] *** luxigo has joined ##OpenGL[03:05:13] *** konom_ has joined ##OpenGL[03:05:19] *** konom has quit IRC[03:05:23] *** konom_ is now known as konom[03:05:58] *** xissburg_ has quit IRC[03:06:18] *** jonet has joined ##OpenGL[03:06:23] *** MissionCritical has quit IRC[03:08:07] *** Demon_Fox has quit IRC[03:08:25] *** Demon_Fox_ has joined ##OpenGL[03:08:45] *** kraft has quit IRC[03:09:15] *** kraft has joined ##OpenGL[03:09:32] *** sreich_ has joined ##OpenGL[03:10:07] *** kestasjk has joined ##OpenGL[03:10:35] *** sreich has quit IRC[03:10:51] *** martyj-o has left ##OpenGL[03:12:42] <kestasjk> hi, trying to optimize our sea drawing and Im sending the same set of 128x128 vertex data over and over to several "tiles" of waves, is there any way to send the vertex data just ones and render it 16 times instead (and will that cause a speed benefit?)[03:14:14] <bob_twinkles> Buffer objects, and most likely[03:15:11] *** cr`nge has quit IRC[03:15:32] *** cr`nge has joined ##OpenGL[03:15:47] *** MissionCritical has joined ##OpenGL[03:15:53] <bob_twinkles> kestasjk: http://en.wikipedia.org/wiki/Vertex_Buffer_Object <- should have enough information to at least get you started[03:16:11] *** sreich_ is now known as sreich[03:16:20] <kestasjk> thanks, Ill give it a go[03:16:24] *** Zeioth2 has joined ##OpenGL[03:16:53] *** oogaw has joined ##OpenGL[03:18:09] *** Wagoo has quit IRC[03:19:52] *** kidnapped_robot has quit IRC[03:20:05] *** Zeioth has quit IRC[03:20:32] *** kidnapped_robot has joined ##OpenGL[03:22:44] *** Bigpet_ has quit IRC[03:26:14] *** Demon_Fox_ has quit IRC[03:26:34] *** Demon_Fox has joined ##OpenGL[03:27:06] <kestasjk> so I guess the idea is that I would write the wave heights to a sort of bitmap, and then somehow read from that bitmap and apply it to the vertex Z values and normals[03:27:34] <bob_twinkles> yep, you'd have a vertex shader that reads the height from a texture probably[03:29:59] *** charlie5 has quit IRC[03:43:11] *** Garner has quit IRC[03:45:30] *** SorajSM has joined ##OpenGL[03:47:16] <SorajSM> Hello all, I have a couple questions about uniform / attribute variables and how to use glUniform* and glVertexAttrib*[03:48:10] <SorajSM> How would you set a mat4 attribute?[03:48:27] <SorajSM> Currently I am using glVertexAttribPointer() like this:[03:48:59] <SorajSM> glVertexAttribPointer(handle + 0, 4, GL_FLOAT, GL_FALSE, 0, &v[0]);[03:49:08] <SorajSM> glVertexAttribPointer(handle + 1, 4, GL_FLOAT, GL_FALSE, 0, &v[1]);[03:49:16] <SorajSM> glVertexAttribPointer(handle + 2, 4, GL_FLOAT, GL_FALSE, 0, &v[2]);[03:49:24] <SorajSM> glVertexAttribPointer(handle + 3, 4, GL_FLOAT, GL_FALSE, 0, &v[3]);[03:49:37] <SorajSM> Is this correct? Could I replace 4 with 2 for a 4x2 matrix?[03:50:26] *** Lucretia has quit IRC[03:54:17] *** Lucretia has joined ##OpenGL[03:55:19] *** hahuang61 has joined ##OpenGL[03:58:09] *** urraka has quit IRC[04:00:21] *** b4b has joined ##OpenGL[04:02:31] *** hahuang61 has quit IRC[04:03:21] *** telex has quit IRC[04:03:57] *** hahuang65 has joined ##OpenGL[04:04:03] *** petervaro_ has joined ##OpenGL[04:04:44] *** telex has joined ##OpenGL[04:06:33] *** petervaro has quit IRC[04:10:03] <glYoda> (a) yes, (b) if you want a 4x2 I'd recommend packing your matrix into 2 4 component vertex attributes (assuming you need to pass this as a series of vertex attributes)[04:13:23] *** glYoda has quit IRC[04:13:34] *** glYoda has joined ##OpenGL[04:14:45] *** ragecryx has quit IRC[04:15:21] *** lenarhoyt has joined ##OpenGL[04:15:27] *** staylor has quit IRC[04:15:45] *** narcan has quit IRC[04:16:30] *** samrat has joined ##OpenGL[04:19:31] *** pizthewiz has quit IRC[04:19:48] *** SleekoNiko has quit IRC[04:20:40] *** puerum has joined ##OpenGL[04:23:29] *** kuldeepdhaka has joined ##OpenGL[04:31:53] *** SleekoNiko has joined ##OpenGL[04:33:28] *** narcan has joined ##OpenGL[04:36:27] *** luxigo has quit IRC[04:38:07] *** dexter0 has quit IRC[04:39:46] *** roboman2444 has joined ##OpenGL[04:39:47] <b4b> glYoda: r u transgender?[04:40:03] <b4b> I just learned alot of video game people become transgender[04:40:21] <b4b> check out the megazeux community[04:40:26] <glYoda> something tells me it's time for a kick ban[04:40:44] <glYoda> that and /ignore[04:41:08] *** meoblast001 has quit IRC[04:41:13] *** b4b has quit IRC[04:41:28] <roboman2444> what did i walk into?[04:42:04] <SorajSM> Hi glYoda, thank you for your help! I really appreciate it.[04:42:20] <glYoda> SorajSM no problem :)[04:42:42] <glYoda> roboman2444 b4b being a douche as I've come to expect[04:43:11] <glYoda> he's utterly WTF worthy[04:43:58] <roboman2444> weird[04:44:02] <roboman2444> hes usually a cool guy[04:44:02] *** Cabanossi has quit IRC[04:44:27] *** BreadProduct has quit IRC[04:45:17] <glYoda> really? ...I haven't seen him mention anything remotely on topic in this channel for nearly a year now[04:45:31] <glYoda> altho I might have missed it :P[04:50:16] *** jbud has joined ##OpenGL[04:50:33] *** Cabanossi has joined ##OpenGL[04:51:03] *** kidnapped_robot has quit IRC[04:51:14] *** RoBut1311 has joined ##OpenGL[04:52:41] *** dexter0 has joined ##OpenGL[04:53:47] *** pizthewiz has joined ##OpenGL[04:54:57] *** shingshang has joined ##OpenGL[04:57:24] *** RoBut1311 has quit IRC[05:02:02] *** Zupo has quit IRC[05:03:17] *** pizthewiz has quit IRC[05:03:27] *** charlie5 has joined ##OpenGL[05:09:05] *** Nickeeh has quit IRC[05:20:45] *** manny- has quit IRC[05:25:32] *** manny- has joined ##OpenGL[05:29:33] *** carvite has quit IRC[05:29:37] *** charlie5 has quit IRC[05:30:28] *** carvite has joined ##OpenGL[05:31:41] *** jdolan has quit IRC[05:32:10] *** jdolan has joined ##OpenGL[05:37:02] <ra4king> hmm when is it best to use glBufferSubData vs mapping it?[05:37:41] *** wreed has joined ##OpenGL[05:37:46] <roboman2444> ra4king, experiment[05:37:52] *** wreed has quit IRC[05:37:57] <ra4king> roboman2444: ok[05:37:59] <roboman2444> but what i have seen, its best to not use it[05:38:16] <roboman2444> only very weird cases does it do better[05:38:18] <ra4king> I remember reading that if the total data is smaller than a few kb, then I shouldn't map it[05:38:29] <roboman2444> yeah thats prolly true[05:38:35] <ra4king> I have a very very tiny amount of data that I need to stream every frame[05:38:42] <ra4king> I'll use bufferSubData[05:39:30] <roboman2444> try both[05:39:33] <roboman2444> never know[05:40:02] <chrisf> ra4king: how much?[05:40:32] <ra4king> 832 bytes[05:40:44] <ra4king> 800 of them will be constantly changing[05:41:11] <ra4king> this is for a simple performance graph, I'm doing a graph with 100 steps @ (x,y) each[05:41:48] <chrisf> subdata is for you[05:42:04] <ra4king> yup[05:42:48] <roboman2444> what is the general "cutoff"[05:42:54] <roboman2444> im sure it changes between platform, though[05:43:01] <chrisf> roboman2444: it's very driver-dependent.[05:43:39] <ra4king> is BufferStorage best used for a minimum amount of data or can I replace all usage of mapped VBOs to it?[05:43:43] <roboman2444> would you expect... say 10KB to be faster ?[05:45:33] <chrisf> ra4king: when #writes ~= #reads, persistent BufferStorage is likely your best option, regardless of the size[05:45:33] <kestasjk> bob_twinkles: this heightmap stuff is great, vastly faster[05:46:12] <ra4king> chrisf: thanks[05:46:14] <chrisf> ra4king: if the gpu will read it many times for each time you update, then you may want to do something else.[05:46:53] <chrisf> (the driver's placement of the buffer may not be ideal for gpu access)[05:47:26] *** luxigo has joined ##OpenGL[05:47:32] <chrisf> roboman2444: i dont recall where the cutoffs are, but the threaded drivers change behavior at some "a few KB" threshold[05:47:47] <bob_twinkles> kestasjk: you should look into updating your entire codebase to GL3.0 code, it's almost guaranteed to be much faster =P[05:47:52] <bob_twinkles> immediate mode is _really_ slow[05:47:57] <roboman2444> ok[05:48:23] <roboman2444> i buffer a lot of data into one large UBO and one large VBO[05:48:59] <chrisf> roboman2444: my understanding is that very small uploads get inlined into the client->server command buffer; large uploads cause a stall[05:49:16] <roboman2444> ah, ok[05:49:32] <chrisf> (you're allowed to trash the memory you passed to glBufferSubData after it returns)[05:49:51] <glYoda> "my understanding is that very small uploads get inlined into the client->server command buffer; large uploads cause a stall" …umm no[05:50:06] <glYoda> at least not in any cross platform / vendor manner[05:50:33] <glYoda> since it's quite possible that the HW itself doesn't even have a path to "inline" data directly into the command buffer[05:50:36] *** samrat has quit IRC[05:50:42] <chrisf> glYoda: not the hw's command buffer.[05:50:47] <glYoda> (i.e. data might need to be sourced from another external resource)[05:50:56] <glYoda> chrisf see what I just said[05:51:29] <chrisf> i never claimed there was any consistency to this across drivers or platforms[05:51:34] <glYoda> and use of the term "command buffer" is quite meaningless in any other realm[05:51:55] <glYoda> chrisf I never said you did… but I did say this is worth noting[05:52:24] *** luxigo has quit IRC[05:52:29] <glYoda> in any case these situations are typically dependent upon buffering within the driver[05:52:31] <chrisf> glYoda: the buffer im talking about is the buffer/queue between your thread and the driver's consumer thread in nv/amd's threaded drivers[05:52:47] <chrisf> glYoda: you may want to call it something else :)[05:53:12] <glYoda> it's possible that the driver can buffer (and therefore defer) updates internally on the driver side[05:53:38] <glYoda> i.e. queuing data into another internal ring buffer for instance[05:53:54] *** PhyloGenesis has joined ##OpenGL[05:53:56] <glYoda> OR the driver might never do that (due to storage overhead)[05:54:10] <glYoda> chrisf I'm aware[05:54:14] <glYoda> see what I just said[05:54:27] <glYoda> the point here is that you cannot ever assume that occurs[05:55:38] <glYoda> there are a number of platforms which won't save you from Buffer[Sub]Data and friends since the resource overhead imposed by buffering within the driver isn't worth the possible performance benefit[05:56:19] <glYoda> (assuming somewhat contrived cases like back to back updates for instance)[05:57:26] <bob_twinkles> on those platforms would the driver be forced to reupload the full buffer every time you changed something?[05:57:42] <glYoda> in terms of buffer updates I'd strongly recommend MapBuffer[Range] with MAP_UNSYNCHRONIZED_BIT (i.e. ARB_map_buffer_range) OR ARB_buffer_storage with MAP_PERSISTENT_BIT specified[05:58:06] *** luxigo has joined ##OpenGL[05:58:17] <glYoda> since those are going to be the typical "fast paths" from a reasonably cross vendor / platform standpoint[05:58:38] <glYoda> bob_twinkles that depends[06:00:07] <bob_twinkles> and we don't care because no matter what it's probably slow so don't do it?[06:00:44] <glYoda> the driver might attempt to eliminate redundant updates whenever it can but any sort of state validation on this front has a non zero cost[06:01:10] <glYoda> and the same goes for internal (driver side) buffering[06:01:30] <glYoda> after all that will likely cost virtual and physical memory[06:01:57] <glYoda> along with a fairly large amount of validation overhead and complexity within the driver itself[06:02:24] <glYoda> it's more sensible to solve those sorts of problems directly on the client side[06:02:27] <glYoda> within the app[06:02:54] <glYoda> versus forcing the driver to work around client side stupidity[06:03:18] <chrisf> MAP_PERSISTENT_BIT is great if you can :)[06:04:29] <bob_twinkles> so glBufferStorage is basically just glBufferData but with flags that actually mean something?[06:04:30] <glYoda> having the driver construct another N element ring buffer, spawn another thread (internally even) for somewhat deferred buffer updates is little more than a hack AFAIC[06:05:06] <glYoda> the client can handle those sorts of situations far more effectively[06:05:25] <glYoda> bob_twinkles effectively yes[06:05:45] <chrisf> MAP_UNSYNCHRONIZED_BIT does cause some sadness in those two threaded drivers im not supposed to assume the behavior of ;)[06:06:15] <glYoda> imagine that… and it kicks ass on drivers which don't bother with such hacks[06:06:25] <chrisf> indeed[06:07:17] <glYoda> solve the most general case ++[06:08:11] <glYoda> and let foolish app developers pay for their mistakes :)[06:08:16] <glYoda> heheh[06:11:05] *** bjz has joined ##OpenGL[06:12:57] *** luxigo has quit IRC[06:13:34] *** qeed has quit IRC[06:13:37] *** lenarhoyt has quit IRC[06:16:53] *** Dark_Confidant|m has quit IRC[06:20:37] *** Syzygy_ has joined ##OpenGL[06:24:02] *** TyrfingMjolnir has quit IRC[06:31:39] *** pizthewiz has joined ##OpenGL[06:33:00] *** MiniCow has quit IRC[06:37:48] *** samrat has joined ##OpenGL[06:40:44] *** Syzygy_ is now known as Syzygy[06:46:08] *** LifeBlood has joined ##OpenGL[06:49:03] *** james4k has quit IRC[06:49:31] *** james4k has joined ##OpenGL[06:49:47] *** Burga has joined ##OpenGL[06:51:45] *** wiky has joined ##OpenGL[06:57:14] *** Ivorius_ is now known as Ivorius[07:03:06] *** RyanPridgeon has quit IRC[07:04:42] *** Zeioth2 has quit IRC[07:05:34] *** narcan has quit IRC[07:07:02] <tapout> anyone know how to get opengl 3.3 on ubuntu?[07:09:34] *** lenarhoyt has joined ##OpenGL[07:13:44] *** luxigo has joined ##OpenGL[07:14:53] *** lenarhoyt has quit IRC[07:17:25] *** Garner has joined ##OpenGL[07:19:35] <SorajSM> echo "main(i){for(i=0;;i++)putchar(((i*(i>>8|i>>9)&46&i>>8))^(i&i>>13|i>>6));}" | gcc -x c - && ./a.out | aplay[07:19:43] <SorajSM> woops[07:22:07] *** SorajSM has quit IRC[07:22:31] <XMPPwocky> tapout: very carefully.[07:23:47] *** foreignFunction has joined ##OpenGL[07:24:51] *** foreignFunction has quit IRC[07:26:26] *** SorajSM has joined ##OpenGL[07:26:50] *** Pyuruku has joined ##OpenGL[07:27:31] *** SorajSM has quit IRC[07:28:03] <Pyuruku> Really dumb question, but I'm reading various shader sources and I see gl_ModelViewMatrix, which seems to have been deprecated. Is this equivalent to V * M where V is the view transform and M is the model transform?[07:30:38] <dawik> Pyuruku: its not a dumb question, I believe you are correct.[07:30:47] <centrinia> https://open.gl/transformations[07:30:59] <dahlia_> that one liner SOrajSM pasted is a pretty catchy tune :)[07:31:05] * dahlia_ dances....[07:31:09] <Pyuruku> Ok... I'm just trying to replicate simple shaders and it seems to be wrong on my end :o[07:32:30] *** damir__ has joined ##OpenGL[07:32:35] <dahlia_> Pyuruku: depending on your math library you may need to switch the order[07:35:05] *** PhyloGenesis has quit IRC[07:36:19] <Pyuruku> so I'm reading http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/point-lights/ and it says "It is assumed that the light's position is in camera space" Is this common? wouldn't it be more natural to define it in world space?[07:38:07] <dahlia_> mine are in world space[07:38:29] <dawik> light has a position? x)[07:38:38] <XMPPwocky> Pyuruku: you transform it first.[07:38:41] <dahlia_> can do position or direction[07:38:51] <XMPPwocky> better to do on the CPU once than on the GPU for every fucking fragment[07:39:36] <Pyuruku> So if I have my light position in world space, then to get the light direction it would be lightPos - (M * vertex), right?[07:39:59] *** CainJacobi has quit IRC[07:40:29] <centrinia> Again, dahlia_'s comment about the order is very important.[07:41:08] <Pyuruku> centrinia: that is the order whatever math library I'm using uses[07:42:37] *** dahlia_ is now known as dahlia[07:43:01] *** TyrfingMjolnir has joined ##OpenGL[07:43:34] * dahlia starts with drawing a triangle in NDC and then adding math expresions one at a time and testing each time[07:45:01] *** SleekoNiko has quit IRC[07:46:06] *** pizthewiz has quit IRC[07:49:10] *** LifeBlood has quit IRC[07:52:37] *** damir__ has quit IRC[07:54:18] <dawik> the order is important because matrices are non-commutative[07:56:19] *** damir__ has joined ##OpenGL[08:01:30] *** damir__ has quit IRC[08:05:11] *** TyrfingMjolnir has quit IRC[08:05:52] <centrinia> Also remember that the mat constructor in GLSL fills by columns.[08:07:51] *** TyrfingMjolnir has joined ##OpenGL[08:08:44] *** Twinklebear has quit IRC[08:10:21] *** lenarhoyt has joined ##OpenGL[08:11:49] *** DapperPixpy has quit IRC[08:13:46] *** jbud has quit IRC[08:14:14] <Pyuruku> yay I think its finally right now :o http://i.imgur.com/KNSDf1U.png[08:15:06] *** BtbN has quit IRC[08:15:07] *** jonet has quit IRC[08:15:15] <ra4king> Pyuruku: very nice![08:15:22] <ra4king> did you make that mesh yourself?[08:15:25] *** lenarhoyt has quit IRC[08:15:28] <Pyuruku> haha no I wish[08:15:37] *** noizex has quit IRC[08:15:38] <ra4king> cool, you got a link to it?[08:15:46] *** noizex has joined ##OpenGL[08:15:54] <Bloodust> whats with the floating triangle in the midle :D[08:16:01] *** icedev has quit IRC[08:16:01] <Pyuruku> http://tf3dm.com/3d-model/lamborghini-aventador-42591.html[08:16:10] <Pyuruku> the model is weird, some parts of the car are missing[08:16:17] <Pyuruku> like the rear right tail light and half of the underside[08:16:18] <ra4king> huh, alright. thanks[08:16:28] <Pyuruku> Bloodust: not sure :o[08:16:51] *** icedev has joined ##OpenGL[08:18:46] <Pyuruku> am I wrong to assume that you have a shader per model?[08:18:58] <Pyuruku> shader instance*[08:19:08] <Bloodust> that would not be smart[08:19:20] *** luxigo has quit IRC[08:19:42] <Pyuruku> so then would you have to assume each shader has the same position / normal input attributes?[08:20:07] *** nemesit|znc has quit IRC[08:20:28] <Bloodust> you can still have a few shaders[08:20:41] <Bloodust> just dont make a shader per model if all models use the same shader[08:22:36] <ra4king> Pyuruku: the model seems complete in Blender[08:22:46] <ra4king> I imported it into Blender and all was fine, check your loader[08:23:05] <Pyuruku> guess my obj loader sucks[08:23:06] *** MLM has quit IRC[08:23:20] <Pyuruku> or cant handle that many tris[08:23:27] *** Polarina has quit IRC[08:23:47] *** h3r3tic has quit IRC[08:23:48] <dahlia> ooooou pretty red car for me? o.0[08:23:53] *** Guest13969 has quit IRC[08:24:30] *** Syzygy has quit IRC[08:26:01] <Pyuruku> Bloodust: I'm looking over my code for instantiating vaos, http://pastebin.com/WUTjBHuM it doesnt even make sense to bind the shader at this point, does it?[08:26:13] <Pyuruku> im not even sure how this is rendering correctly now...[08:26:36] <Bloodust> you bind shader when you want to draw something[08:26:44] *** clauswitt has joined ##OpenGL[08:26:57] <Bloodust> not when you create VAOs[08:27:03] <Pyuruku> yeah, but i dont set the position / normal attributes when drawing[08:27:13] <Pyuruku> and now im wondering how anything is being drawn properly :S[08:27:30] <Bloodust> vao encapsulates vertex attribute bindings[08:27:34] *** kestasjk has quit IRC[08:28:27] *** petervaro_ has quit IRC[08:28:59] *** TyrfingMjolnir has quit IRC[08:29:03] *** Adrinael_ has joined ##OpenGL[08:29:47] <Pyuruku> ? what do you mean[08:30:15] <Pyuruku> dont I need to do shader->setAttributeBuffer for each object's positions?[08:30:45] <Bloodust> it stores the glEnableVertexAttribArray() and glVertexAttribPointer calls[08:31:06] <Bloodust> Pyuruku sure you do you[08:31:24] <Bloodust> all your models have own VAOs[08:31:29] *** razieliyo has joined ##OpenGL[08:31:38] *** clauswit_ has joined ##OpenGL[08:31:49] <Pyuruku> Right, each of my models has a VAO, however they should all share the same shader (for my purposes)[08:32:00] <Bloodust> they can[08:32:07] <Bloodust> and they shold[08:32:11] <Pyuruku> so when it comes time to draw, dont I need to specify where in the vao the positions / normals are?[08:33:03] *** luxigo has joined ##OpenGL[08:33:09] <dahlia> do that when you set up the vao[08:33:24] *** luxigo_ has joined ##OpenGL[08:33:35] *** linuxuz3r has quit IRC[08:33:45] *** clauswitt has quit IRC[08:33:57] <Pyuruku> so shader->setAttributeBuffer(---) should be within the vao creation?...[08:35:12] <dahlia> glVertexAttribPointer[08:37:11] <Pyuruku> I'm confused[08:37:41] *** luxigo has quit IRC[08:38:04] <Pyuruku> the vao holds a vbo and an ibo, so it has the vertex,normal and index information[08:38:19] <Pyuruku> when it comes time to draw, i bind my shader and vao[08:38:36] <Pyuruku> at this point I need to tell the shader where the position and indices are in the vao, right?[08:38:43] <Khlorghaal> vao doesnt really hold a vbo, it holds pointers, which may be to different vbos[08:38:46] <dahlia> I haven't done vaos for a while but I think you create a vao, bind the vbo and the ibo, set up pointers to the vertex attributes, then it remembers all that stuf so you only need to bind the vao when you draw[08:38:48] *** Adrinael has quit IRC[08:38:48] *** Adrinael_ is now known as Adrinael[08:39:34] <Khlorghaal> and the point of the vao is so that you only have to specify the attribs once[08:39:57] <Pyuruku> by attribs you mean the shader attributes?[08:39:58] <dahlia> which saves a lot of time[08:40:19] <tapout> on ubuntu, when i install opengl 3.3, it works, but complains : libGL error: failed to open drm device: Permission denied... after googling, it says to add myself to the user 'video' and reboot. i do so, and then opengl 2.1 is back. If i remove myself from the group 'video', 3.3 is back. What is going on[08:40:25] <dahlia> vertex attributes, like where position, normal, uv are in it[08:40:36] <dahlia> or whatever attributes you have[08:40:50] <Khlorghaal> attribs i mean attribute pointers[08:41:06] <Pyuruku> maybe its more clear if I ask this, http://pastebin.com/WUTjBHuM this is how im setting my vaos up, what is unnecessary in this? to me it seems like the shader binding doesnt do anything[08:41:51] *** Polarina has joined ##OpenGL[08:42:02] *** Polarina has quit IRC[08:42:02] *** Polarina has joined ##OpenGL[08:42:13] <Khlorghaal> that looks right[08:42:28] <Khlorghaal> so when you draw just bind the shaderprogram and vao then draw[08:42:32] <dahlia> you enable attributes in the shader when you bind the shader[08:42:40] <dahlia> not when you build the vao[08:42:58] <Pyuruku> but binding the shader for building the vao is correct[08:43:08] *** razieliyo has quit IRC[08:43:19] <dahlia> dont think it cares what shader you may have bound when you build the vao[08:43:24] <Khlorghaal> waitwhat i thought vertexattrib enable status was stored in the vao[08:43:39] <Pyuruku> then with this, I need to know what shader im using for each model before instantiating it[08:43:46] <Pyuruku> what if I want to change it after instantiating the vao?[08:44:26] <Khlorghaal> if you MUST have a different shader per model then make a wrapper class[08:44:59] <dahlia> usually its a shader for a material type, not for a specific model[08:45:00] <Khlorghaal> the shader and vao arent related[08:45:16] <Khlorghaal> except in how the shader recieves its vsh in data[08:45:32] <Khlorghaal> so the only thing linking them is vsh in binding points[08:45:40] <Pyuruku> if I have two shaders with the exact same input attributes, then would it be safe to swap them mid execution?[08:45:58] <Khlorghaal> without swapping vaos, yes[08:46:58] <dahlia> may want to look at a simple vao tutorial, hopefully one from the tutorials in the channel topic[08:47:07] <Khlorghaal> the vertexattribpointer specifies where in memory that binding starts, and its stride[08:47:39] <Pyuruku> im pretty sure i confused myself for no apparent reason...[08:47:46] <Khlorghaal> i can see how its confusing, vertex attribs were one of the steepest learning curves in gl for me[08:47:57] <dahlia> it is kinda confusing at first :)[08:48:09] <dahlia> (and subsequently)[08:48:34] <Khlorghaal> after that you expect new things to be hard but then youre just like 'oh you just bind it then do stuff'[08:49:14] <Khlorghaal> i was almost upset over how easy it was to learn RTT lol[08:49:34] *** jeaye has quit IRC[08:50:58] *** LifeBlood has joined ##OpenGL[08:51:43] *** LifeBlood has quit IRC[08:53:09] *** damir__ has joined ##OpenGL[08:53:12] *** jonet has joined ##OpenGL[08:55:40] *** BtbN has joined ##OpenGL[08:55:57] *** nemesit|znc has joined ##OpenGL[08:59:53] *** bjz has quit IRC[09:00:39] *** DMJC-M has joined ##OpenGL[09:02:11] *** puerum has quit IRC[09:02:44] *** DrSkyLizard has joined ##OpenGL[09:05:19] *** Beetny has joined ##OpenGL[09:09:03] *** TyrfingMjolnir has joined ##OpenGL[09:10:58] *** HunterD has joined ##OpenGL[09:11:05] *** lenarhoyt has joined ##OpenGL[09:12:12] *** jeaye has joined ##OpenGL[09:12:31] *** horlicks_ has quit IRC[09:12:35] *** h3r3tic has joined ##OpenGL[09:13:37] *** horlicks_ has joined ##OpenGL[09:14:55] *** cr`nge has quit IRC[09:15:27] *** losh has joined ##OpenGL[09:16:01] *** lenarhoyt has quit IRC[09:16:39] *** jophish has joined ##OpenGL[09:21:24] *** jophish is now known as Guest77188[09:22:04] <tapout> looking at this: https://www.opengl.org/sdk/docs/man/html/glEnableVertexAttribArray.xhtml ... it says it's available in 3.3. However, when I go to call it.. glEnableVertextAttribArray(0);, the function is undefined...[09:22:15] *** BreadProduct has joined ##OpenGL[09:24:17] <slime> Vertext or Vertex?[09:26:01] <tapout> ya, i typed it wrong here.. my Qt Creator won't auto complete anything other than glEnable ... if I cut/paste the function from the tutorial, it's undefined as well[09:26:26] *** prophile has joined ##OpenGL[09:27:25] *** bjz has joined ##OpenGL[09:28:28] *** DrSkyLizard has quit IRC[09:29:12] *** cr`nge has joined ##OpenGL[09:30:43] <Bloodust> lol, why u qt creator[09:32:20] <tapout> why not?[09:32:39] <Bloodust> because clearly it doesnt autocomplete anything other than glEnable :D[09:33:29] <slime> are you including a header with that function defined?[09:34:26] <tapout> this tutorial has... GL/glew.h and GL/freeflut.h[09:34:30] <tapout> freeglut.h[09:35:00] <Bloodust> glew defines it[09:35:03] <Bloodust> one way or anothr[09:36:54] *** Stragus has quit IRC[09:37:53] <tapout> weird, -lglew failed, -lGLEW worked, whereas -lglut worked, my bad :)[09:40:54] *** Gamecubic has quit IRC[09:43:12] *** Garner has quit IRC[09:45:36] *** erhan_ has joined ##OpenGL[09:50:06] *** Lemml has joined ##OpenGL[09:50:30] *** CrizMobius has joined ##OpenGL[09:53:35] *** Ranis has left ##OpenGL[10:03:48] *** james4k has quit IRC[10:04:45] *** Burga has quit IRC[10:07:19] *** Burga has joined ##OpenGL[10:09:14] *** TheBix has joined ##OpenGL[10:11:53] *** lenarhoyt has joined ##OpenGL[10:14:28] *** Guest77188 is now known as jophish[10:15:20] *** Sirolf has joined ##OpenGL[10:16:45] *** lenarhoyt has quit IRC[10:17:05] *** Garner has joined ##OpenGL[10:19:33] *** Sirolf has quit IRC[10:21:06] *** Ryp has joined ##OpenGL[10:30:39] *** Zupo has joined ##OpenGL[10:32:30] *** Ad1 has joined ##OpenGL[10:32:37] *** agorecki has quit IRC[10:34:44] *** DrSkyLizard has joined ##OpenGL[10:37:47] *** Demon_Fox has quit IRC[10:38:15] *** viggo has joined ##OpenGL[10:39:26] *** centrinia has quit IRC[10:39:53] *** tcsc has quit IRC[10:40:41] *** Ryp has quit IRC[10:41:14] *** viggo2 has quit IRC[10:42:05] *** cr`nge has quit IRC[10:42:41] *** samrat has quit IRC[10:43:10] *** samrat has joined ##OpenGL[10:50:45] *** Zupoman has joined ##OpenGL[10:50:45] *** Zupoman has joined ##OpenGL[10:52:07] *** snakenerd has joined ##OpenGL[10:52:56] *** luxigo_ has quit IRC[10:53:50] *** snakenerd has quit IRC[10:54:57] *** robot-beethoven has quit IRC[10:55:58] *** Pyuruku has quit IRC[10:57:39] *** wiky has quit IRC[11:00:44] *** Match has joined ##OpenGL[11:08:31] *** indefini has quit IRC[11:08:45] *** pazul has joined ##OpenGL[11:09:11] *** centrinia has joined ##OpenGL[11:10:11] *** narcan has joined ##OpenGL[11:12:39] *** lenarhoyt has joined ##OpenGL[11:14:37] *** redeemed has joined ##OpenGL[11:17:56] *** pazul has quit IRC[11:18:30] *** lenarhoyt has quit IRC[11:18:54] *** Ryp has joined ##OpenGL[11:19:50] *** Ryp1 has joined ##OpenGL[11:21:08] *** samrat has quit IRC[11:23:53] *** samrat has joined ##OpenGL[11:23:54] *** Ryp has quit IRC[11:30:31] *** pazul has joined ##OpenGL[11:35:05] *** luxigo_ has joined ##OpenGL[11:35:39] *** Stragus has joined ##OpenGL[11:39:51] *** HunterD has quit IRC[11:40:48] *** Nickeeh has joined ##OpenGL[11:45:27] <japro> hmm, so why is there a value for FRONT_AND_BACK for cull face but not something like "NONE"?[11:46:00] <japro> i know that is equivalent to disabling culling :) but it seems odd since culling both faces is about equally "useless"[11:47:50] *** luxigo_ has quit IRC[11:49:34] *** konom has quit IRC[11:52:14] *** maw has quit IRC[11:52:14] *** maw has joined ##OpenGL[11:52:15] *** Burga has quit IRC[11:52:53] *** luxigo_ has joined ##OpenGL[11:54:41] <Dave13h> japro: http://goo.gl/HbWH6L[11:54:46] <Adrinael> Culling front and back will still let lines draw[11:57:34] <japro> i guess as usual one shouldn't interpret too much into "old GL" logic[11:59:38] *** luxigo_ has quit IRC[12:00:22] <japro> so it seems i don't understand how stencilOpSeparate works:[12:00:23] <japro> http://ideone.com/8YroIK[12:00:31] <japro> i would expect those to give the same result[12:00:49] <japro> oh wait did i invert the front/back thing?[12:01:21] <japro> well i guess i did but it doesn't matter[12:01:45] <Adrinael> What's the result then?[12:01:46] *** mat^2 has quit IRC[12:01:56] *** Shogun has quit IRC[12:02:36] <japro> the "works" part gives correct stencil shadows (the drawn geometry is the shadow volumes)[12:02:49] <japro> the other one just stecils out all the shadow volumes[12:06:07] <japro> http://imgur.com/a/mKcJ2[12:06:17] <japro> the top one is the non working one[12:07:24] *** Polarina has quit IRC[12:07:59] *** Beetny has quit IRC[12:08:55] *** ozette has joined ##OpenGL[12:08:57] *** MiniCow has joined ##OpenGL[12:09:16] *** indefini has joined ##OpenGL[12:10:08] <japro> i have this suspicion that i don't understand what StencilOpSeparate really does[12:13:12] *** DMJC-M has quit IRC[12:13:23] <Adrinael> Do you have depth writes on?[12:13:35] <Adrinael> That would explain differences when you do it in two passes[12:13:47] <japro> nope[12:14:03] <japro> says glDepthMask(GL_FALSE); right in front of what is in the paste[12:14:04] <AbigailBuccaneer> japro, GL_INCR and GL_DECR clamp[12:14:13] <AbigailBuccaneer> which would explain it[12:14:26] <japro> i thought about that but don't see why?[12:14:41] *** Bigpet_ has joined ##OpenGL[12:14:44] <japro> oh to the range 0-X[12:14:45] <japro> right[12:14:48] <Adrinael> Start from 0, decr to ... 0[12:14:52] *** SnakeTrailSteve has quit IRC[12:15:02] <AbigailBuccaneer> japro, try GL_INCR_WRAP and GL_DECR_WRAP, it may help :)[12:15:13] *** lenarhoyt has joined ##OpenGL[12:16:00] *** hexagoxel has joined ##OpenGL[12:16:15] <japro> ah, that works. thanks[12:16:29] <AbigailBuccaneer> groovy[12:18:48] *** kuldeepdhaka has quit IRC[12:19:58] *** pazul has quit IRC[12:20:14] *** lenarhoyt has quit IRC[12:27:51] <japro> hmm, still wondering though if the stencil thing is really the best approach? i could get the same result by rendering into integer texture[12:28:07] <japro> and it would drop the requirement to render everything twice with different stencil mask :/[12:28:32] <japro> or i could do lighting purely in post processing which means i only have to run that with the stencils[12:29:18] *** TyrfingMjolnir has quit IRC[12:30:43] *** Beetny has joined ##OpenGL[12:31:47] *** pazul has joined ##OpenGL[12:32:08] *** DMJC-M has joined ##OpenGL[12:34:10] *** ozette has quit IRC[12:34:32] *** ozette has joined ##OpenGL[12:35:59] *** timsche has joined ##OpenGL[12:36:30] *** Polarina has joined ##OpenGL[12:37:11] *** jophish_ has joined ##OpenGL[12:41:41] *** telex has quit IRC[12:42:28] *** jophish has quit IRC[12:42:46] *** telex has joined ##OpenGL[12:43:16] *** narcan has quit IRC[12:44:31] *** Keniyal has joined ##OpenGL[12:44:50] *** Keniyal_ has joined ##OpenGL[12:46:28] *** centrinia has quit IRC[12:47:08] *** jophish_ is now known as jophish[12:47:26] *** Jack_ has joined ##OpenGL[12:47:36] *** Jack_ has quit IRC[12:48:58] *** Keniyal has quit IRC[12:51:39] *** DrSkyLizard has quit IRC[12:54:25] *** samrat has quit IRC[12:55:30] *** kuldeepdhaka has joined ##OpenGL[12:57:00] *** Khlorghaal has quit IRC[13:00:25] *** ozette has quit IRC[13:01:13] *** doomlord_1 has joined ##OpenGL[13:02:08] *** doomlord_1 has joined ##OpenGL[13:03:43] *** charlie5 has joined ##OpenGL[13:06:19] *** doomlord_1 has quit IRC[13:06:45] *** BtbN has quit IRC[13:07:25] *** Sirolf has joined ##OpenGL[13:08:58] *** erhan_ has quit IRC[13:09:09] *** snakenerd has joined ##OpenGL[13:09:47] *** Beetny has quit IRC[13:10:00] *** BtbN has joined ##OpenGL[13:12:10] *** xissburg has joined ##OpenGL[13:15:57] *** lenarhoyt has joined ##OpenGL[13:17:03] *** Misu has joined ##OpenGL[13:18:27] *** DMJC-M has quit IRC[13:20:42] *** lenarhoyt has quit IRC[13:22:41] *** Sos has quit IRC[13:26:15] *** pazul has quit IRC[13:26:40] <Captain_Crow> why cant stencil shadows have blurring?[13:28:59] *** Shogun has joined ##OpenGL[13:30:06] <AbigailBuccaneer> Captain_Crow, shadow volumes are inherently sharp - they're well-defined geometric volumes[13:30:26] <AbigailBuccaneer> stencil shadowing uses the stencil buffer to get exactly the fragments which are inside a shadow volume[13:30:56] <AbigailBuccaneer> from there you could apply some image-based morphological blurring technique[13:32:03] <AbigailBuccaneer> you could also attempt to definne a fuzzy shadow volume, eg. by progressively growing it[13:32:14] <Bloodust> post process everything![13:32:22] <Bloodust> thats my solution[13:32:26] <Bloodust> it solves all problems[13:32:38] <Bloodust> but it raises a philosophical question[13:33:03] <Bloodust> if everything is done in post process, does post process become just a process?[13:33:17] <japro> just add postpostprocesing[13:33:34] <AbigailBuccaneer> i can imagine a morphological blur could do a fairly good job of given blurred shadows, but i can also imagine that it could give awful results[13:33:43] <AbigailBuccaneer> (i guess i'm really just bragging about how good my imagination is now)[13:34:10] <japro> i could imagine solving the traveling salesman problem in polynomial time![13:34:21] <AbigailBuccaneer> dang japro, your imagination wins! i concede[13:34:23] <Bloodust> I could not[13:34:47] <japro> adds "Imagineer" to his cv[13:36:15] <japro> the ugly thing about pos processing is that it sucks if you get "close" :)[13:36:41] <japro> like if you want a building to cast a blurry shadow but have your face on the floor the post process blur would have to work over half the screen :)[13:36:50] <japro> which tends to suck... both quality and performance wise[13:37:51] <Bloodust> tis fine[13:37:53] *** DMJC-M has joined ##OpenGL[13:38:19] *** pazul has joined ##OpenGL[13:39:18] <AbigailBuccaneer> is it possible to do some sort of 3d distance field computation in real-time based on a depth buffer and a one-bit texture? that'd be rad for a whole bunch of things, but would also give you great quality blurred stencil shadows[13:42:28] <Captain_Crow> would it be a bad idea to have several stencil shadows overlapping?[13:42:57] <japro> not inherently i guess :)[13:43:12] <Adrinael> With stencil shadows, the results you have will be from the range of "yes, in shadow" to "no, not in shadow"[13:43:17] <japro> but stencil shadows can be really hard on fillrate so it's usually cost prohibitive i guess[13:43:26] <Adrinael> Several stencil shadows will just put you in the "yes, in shadow" bin[13:43:54] <japro> well you can essentially have and area light that way where you say calculate 4x4 shadow volumes or so and then count how many you are in[13:44:13] <Adrinael> Game Programming Gems 4 had some nifty shadowing techniques using shadow id's and perspective-corrected shadow textures, and whatnot[13:44:13] <japro> with 4x4 i mean 16 :)[13:44:17] <Adrinael> And that was back in the day[13:45:00] <japro> shadow volumes are odd in that they were possible in doom3 era but at the same time given some unlucky geometry or so can also murder modern hw[13:45:06] *** wiky has joined ##OpenGL[13:45:19] <AbigailBuccaneer> Adrinael, given that the stencil buffer is typically more than 1-bit large, is it not possible to get any info about how many shadows a fragment is in?[13:45:52] <japro> you could just repeat the process multiple times and additively blend the lighting into the result[13:46:19] <AbigailBuccaneer> as if they weren't hard enough on fillrate...[13:46:26] <japro> well yeah :D[13:46:27] <Adrinael> AbigailBuccaneer, you could read the stencil yourself with ARB_stencil_texturing[13:46:40] <japro> but any approach of using multiple shadow volumes will have hat effect[13:47:01] <japro> if you draw multiples in one pass you are equally brutal on fillrate i'd guess[13:47:56] <japro> that version from the picture up there just about runs on my crapbook.[13:48:10] <japro> gets somewhat stuttery when enabling msaa though[13:50:12] <japro> i guess they don't see much use anyway these days?[13:50:22] <japro> i was under the impression rage still used them for characters[13:53:49] *** DMJC-M has quit IRC[13:54:01] <Captain_Crow> so the best thing to do would be use stencil shadows to mark where the shadows should be then use post processing?[13:55:09] <AbigailBuccaneer> Captain_Crow, yes, or use a different approach to shadows :P[13:55:25] *** Ryp1 has quit IRC[13:56:20] <japro> all the cool kids use shadowmaps these days[13:56:26] <Bloodust> <3[13:56:43] <japro> the only reason i might use stencil shadows here is because the specific geometry allows a lot of shortcuts[13:56:55] *** BitPuffin has joined ##OpenGL[13:57:21] <Captain_Crow> aren't shadow maps slower for large scenes?[13:58:36] <AbigailBuccaneer> shadow maps and stencil shadows both require redrawing your opaque geometry to an intermediate buffer (a texture or the stencil buffer respectively)[13:59:35] <AbigailBuccaneer> stencil shadows then let you only draw the shadowed areas or only the lit areas, whereas shadow maps require you to draw the entire area that was potentially shadowed[14:00:30] <AbigailBuccaneer> when doing shadow mapping, unless it's a global light (eg. sunlight) the stencil buffer will usually be used to draw only the area which the light can reach[14:02:55] *** oogaw has quit IRC[14:04:36] <krnlyng> AbigailBuccaneer: yesterday you mentioned vogl, are there any minimalistic alternatives?[14:06:09] <Adrinael> apitrace[14:06:13] <Captain_Crow> so in a large scene with a lot of polygons would cascade shadow mapping still be fast? would if be faster to use lower samples with more maps or to use higher samples with less maps?[14:07:28] <krnlyng> Adrinael: unfortunately apitrace does not work on my platform https://github.com/apitrace/apitrace/issues/291 probably due to a libhybris conflict[14:10:18] *** lenarhoyt has joined ##OpenGL[14:14:23] *** urraka has joined ##OpenGL[14:14:42] *** BreadProduct has quit IRC[14:14:45] *** mat^2 has joined ##OpenGL[14:17:08] *** wiky has quit IRC[14:27:47] *** Wagoo has joined ##OpenGL[14:28:04] *** TyrfingMjolnir has joined ##OpenGL[14:32:51] <Adrinael> =([14:33:28] *** jdolan has quit IRC[14:35:52] *** matpow2 has joined ##OpenGL[14:39:43] *** mat^2 has quit IRC[14:39:44] *** paperManu has joined ##OpenGL[14:41:15] *** razieliyo has joined ##OpenGL[14:46:58] *** paperManu has quit IRC[14:50:31] *** HuntsMan has joined ##OpenGL[14:52:29] *** ragecryx has joined ##OpenGL[14:54:09] *** kuldeepdhaka has quit IRC[14:56:34] *** jokoon has joined ##OpenGL[14:56:43] *** kuldeepdhaka has joined ##OpenGL[14:56:46] *** tehrain has joined ##OpenGL[15:02:56] *** echelog has joined ##OpenGL[15:03:35] *** carvite has joined ##OpenGL[15:04:09] *** nemesit|znc has joined ##OpenGL[15:06:41] *** SnakeTrailSteve has joined ##OpenGL[15:10:41] *** Dom__ has quit IRC[15:10:59] *** erhan_ has joined ##OpenGL[15:17:21] *** Ryp has joined ##OpenGL[15:17:30] *** b4b has quit IRC[15:26:07] *** pazul has quit IRC[15:34:14] *** jdolan has joined ##OpenGL[15:37:05] *** Ryp has quit IRC[15:38:07] *** pazul has joined ##OpenGL[15:39:15] *** samrat has joined ##OpenGL[15:50:13] *** Gamecubic has joined ##OpenGL[15:56:46] *** HunterD has joined ##OpenGL[15:59:38] *** SleekoNiko has joined ##OpenGL[16:07:44] *** Sirolf has quit IRC[16:08:07] *** DrSkyLizard has joined ##OpenGL[16:11:58] *** HunterD has quit IRC[16:12:39] *** damir__ has quit IRC[16:14:27] *** SleekoNiko has quit IRC[16:16:07] *** clauswitt has joined ##OpenGL[16:19:05] *** DrSkyLizard has quit IRC[16:19:13] *** clauswit_ has quit IRC[16:20:27] *** clauswitt has quit IRC[16:23:16] <Captain_Crow> is cascade shadow mapping faster for large scenes than stencil shadows?[16:25:10] *** HunterD has joined ##OpenGL[16:26:18] <roboman2444> quite[16:26:43] <roboman2444> stencil shadows are very very slow, unless your geometry count is rather low[16:27:31] <roboman2444> not only because of the extra CPU side calculating the stencil geometry, but also because the more memory bandwidth and passes you have to do when actually rendering with them[16:27:47] <roboman2444> its also very hard to do any sort of instancing/grouping with em[16:28:34] *** jbud has joined ##OpenGL[16:29:22] *** jokoon has quit IRC[16:29:39] *** tcsc has joined ##OpenGL[16:30:50] *** TheBix has quit IRC[16:32:10] *** MLM has joined ##OpenGL[16:36:46] <AbigailBuccaneer> can stencil geometry be computed from regular geometry in a geometry shader? i've never used them so i'm not fully aware of their capabilities[16:38:13] *** Kane has joined ##OpenGL[16:39:31] *** pazul has quit IRC[16:41:02] *** matpow2 has quit IRC[16:42:36] <Adrinael> Yes[16:43:56] <Adrinael> http://http.developer.nvidia.com/GPUGems3/gpugems3_ch11.html[16:44:01] <Adrinael> 11.3.2[16:44:21] <hdon> stencil geometry = the geometry rendered to the stencil buffer?[16:44:24] * hdon is ignorant[16:44:45] * hdon clicks link[16:45:12] <Adrinael> The shadow volume geometry[16:45:36] <AbigailBuccaneer> hdon, yes, the geometry (of the shadow volumes) that is rendered to set the stencil buffer to the appropriate values for shadow rendering[16:46:43] <hdon> neat[16:51:37] *** pazul has joined ##OpenGL[16:57:36] *** gaganjyot has joined ##OpenGL[16:57:36] *** TyrfingMjolnir has quit IRC[16:59:18] *** Keniyal_ has quit IRC[17:03:30] *** JoshSyn has joined ##OpenGL[17:08:14] *** Folkol has quit IRC[17:16:22] *** mat^2 has joined ##OpenGL[17:26:15] *** gaganjyot has quit IRC[17:26:46] *** radr has quit IRC[17:28:07] *** pizthewiz has joined ##OpenGL[17:29:13] *** redeemed has quit IRC[17:30:12] *** stefkos has joined ##OpenGL[17:49:21] *** zajfy has quit IRC[17:51:26] *** radr has joined ##OpenGL[17:53:14] <ClaudiusMaximus> is glVertexAttribDivisor per vertex or per primitive? I'll be using GL_LINES, so two vertices per primitive, want to transform each line by 60 matrices.. bit confused by the man page https://www.opengl.org/sdk/docs/man3/xhtml/glVertexAttribDivisor.xml specifically "set(s) of vertices"[18:00:22] *** DapperPixpy has joined ##OpenGL[18:00:24] <AbigailBuccaneer> glVertexAttribDivisor(_, 0) = one attribute per vertex. glVertexAttribDivisor(_, 1) = one attribute per instance[18:01:17] <AbigailBuccaneer> "If divisor is non-zero, the attribute advances once per divisor instances of the set(s) of vertices being rendered."[18:01:58] <AbigailBuccaneer> so it only has an effect with glDrawElementsInstanced / glDrawArraysInstanced[18:02:19] <ClaudiusMaximus> AbigailBuccaneer: thanks for the clear explanation. so i guess i set glDrawArraysInstanced(GL_LINES, 0, n, 60) with glVertexAttribDivisor(_, 1) for my matrix attribute set[18:03:46] <ClaudiusMaximus> not got any code to test yet, still in the "thinking about how best to do it" stage[18:04:08] <AbigailBuccaneer> given that GL_LINES already splits the elements up pairwise, and so you can already draw arbitrarily many lines with one call to glDrawArrays, you may find that it's easier just to duplicate the per-line data you have to be per-vertex[18:04:53] <ClaudiusMaximus> AbigailBuccaneer: i want to transform each line by each matrix, so i'll have n/2 * 60 lines[18:06:27] <AbigailBuccaneer> if each line has its own matrix and its own unique vertex data, glDrawArraysInstanced isn't appropriate, i don't think[18:06:56] <urraka> looks like you already have the 60 lines in a buffer. i think you would take only 1 line in the buffer and do instancing with that[18:07:28] *** jbud has quit IRC[18:07:29] <ClaudiusMaximus> AbigailBuccaneer: i mean, foreach(line) { foreach(matrix) { draw matrix * line } }[18:07:40] <AbigailBuccaneer> ah, right, i see[18:08:22] <AbigailBuccaneer> yeah, that makes sense now, glDrawArraysInstanced is your friend here[18:09:19] <ClaudiusMaximus> i'm starting to port this to gl, extending it to 3d (maybe even occulus rift) instead of flattened stereographic projection and cairo http://mathr.co.uk/blog/2013-07-09_haystack_situations_trailer.html[18:10:01] *** realz_ has joined ##OpenGL[18:10:29] <ClaudiusMaximus> another question - billboarding GL_LINES to a 4-vertex GL_TRIANGLE_STRIP with a geometry shader is a sensible approach?[18:10:32] <AbigailBuccaneer> ClaudiusMaximus, i was wondering what use you had for repeatedly drawing lines, but this makes a lot of sense. pretty![18:10:45] <ClaudiusMaximus> AbigailBuccaneer: thanks :)[18:11:27] <AbigailBuccaneer> ClaudiusMaximus, as in, all n lines into a single textured quad?[18:11:47] <AbigailBuccaneer> or each line into a quad (for whatever reason)[18:12:23] <ClaudiusMaximus> AbigailBuccaneer: each line into a quad[18:13:05] <AbigailBuccaneer> and you want to do that for... getting a line whose width is in worldspace rather than screenspace?[18:13:24] <ClaudiusMaximus> yes, and also aren't wide lines deprecated/gone?[18:13:26] *** jbud has joined ##OpenGL[18:13:49] <AbigailBuccaneer> https://www.opengl.org/sdk/docs/man3/xhtml/glLineWidth.xml doesn't look like it[18:15:02] <ClaudiusMaximus> interesting[18:15:08] *** Majiet has joined ##OpenGL[18:15:25] <ClaudiusMaximus> is there an equivalent variable I could set in a shader?[18:15:34] <ClaudiusMaximus> per line rather than per draw call[18:15:36] <AbigailBuccaneer> if you're going to be using geometry shaders, i'd naively say that you may as well render GL_POINTS with a per-vertex transformation matrix and line length[18:15:43] <AbigailBuccaneer> ClaudiusMaximus, i don't think so[18:16:16] <AbigailBuccaneer> so i suspect turning them into quads (and i should probably clarify, when i say "quad" i mean "4-vertex tri-strip") is the way forwards[18:18:10] <ClaudiusMaximus> mm, i guess that's one thing to benchmark - might be easier to just have a vbo containing 4-vertex tri-strip for each line as they don't change most of the time[18:19:53] <ClaudiusMaximus> it's like a rolling buffer where the first few are growing and the last few are shrinking (replaced by new line when length becomes 0), the bulk in the middle is unmodified[18:20:31] *** CrizMobius has quit IRC[18:21:09] <ClaudiusMaximus> so i only need to reupload the part of the buffer that changed (maybe two parts, depending how the buffer changes wrap around)[18:21:46] <AbigailBuccaneer> ClaudiusMaximus, could get away with not changing the vertex data to change the line length[18:22:15] <AbigailBuccaneer> with clever usage of gl_VertexID / gl_InstanceID plus a timer uniform[18:22:55] <ClaudiusMaximus> true! thanks for the reminder, i think i thought of that earlier and promptly forgot[18:22:56] *** stefkos has quit IRC[18:24:03] *** stefkosPB has joined ##OpenGL[18:24:03] *** stefkosPB is now known as stefkos[18:24:06] *** ablepharus has joined ##OpenGL[18:25:08] *** ablepharus has quit IRC[18:25:36] *** james4k has joined ##OpenGL[18:26:12] <ClaudiusMaximus> AbigailBuccaneer: which gets me thinking GL_POINTS (one per line with both endpoints and a width) and a billboarding geometry shader that adjusts length according to gl_VertexID and timer uniform[18:29:31] <AbigailBuccaneer> hmm. thinking it through you're gonna be doing quite a bit more work than is strictly necessary - because the properties of the line (width etc) are unaffected by the current matrix[18:29:59] <AbigailBuccaneer> so maybe it makes sense to do that preprocessing on the CPU...[18:30:35] <AbigailBuccaneer> ooh! if you're just doing this as a cool GL thing, why not use transform feedback to process the geometry of one instance and then render that processed geometry for each matrix?[18:32:18] *** hexagoxel has quit IRC[18:32:28] *** Waynes has joined ##OpenGL[18:33:53] <ClaudiusMaximus> AbigailBuccaneer: good point, quite a lot of 60x repeated work, transform feedback might be worth it if i do the view/camera transformation there too[18:34:40] *** prophile has quit IRC[18:38:05] *** hahuang65 has quit IRC[18:38:26] <AbigailBuccaneer> if you can specify all the matrices as things to be applied to the viewspace coords, then yes[18:38:27] <ClaudiusMaximus> actually i need to do the view/camera after the 60x matrices because they change positions, so forget that last thing[18:38:31] <AbigailBuccaneer> ah[18:39:51] <AbleBacon> that's a pretty cool... simulation?... ClaudiusMaximus[18:40:00] <AbigailBuccaneer> but even so, if you combine each matrix with your view and projection matrices, then your vertex shader for the processed geometry would be incredibly simple[18:40:49] <AbleBacon> bookmarking your site >_>[18:42:13] <AbleBacon> when you finish converting that to GL, are you gonna post the source?[18:43:00] <ClaudiusMaximus> AbigailBuccaneer: view matrix changes over time (each frame, twice if i go stereo), so it'd be a bit more complicated[18:43:17] <ClaudiusMaximus> AbleBacon: yeah, probably[18:43:57] <ClaudiusMaximus> AbleBacon: code for the cairo version is here http://mathr.co.uk/blog/2014-03-01_haystack_situations_podcast.html[18:44:07] *** erhan_ has quit IRC[18:44:08] <ClaudiusMaximus> AbleBacon: thanks btw :)[18:44:16] <AbleBacon> you doing C++ for the GL stuff?[18:45:04] <ClaudiusMaximus> AbleBacon: probably, if only for glm (so mainly C-style but with the math operator overloading)[18:45:16] <AbleBacon> ah! i use GLM[18:46:34] <ClaudiusMaximus> not sure what the current state of the occulus sdk is, i seem to recall it being C++ last time i checked[18:57:08] *** Lemml has quit IRC[18:58:14] *** LifeBlood has joined ##OpenGL[19:00:32] *** gaganjyot has joined ##OpenGL[19:07:20] *** hexagoxel has joined ##OpenGL[19:09:47] *** ShadowIce has joined ##OpenGL[19:10:15] *** hahuang65 has joined ##OpenGL[19:11:39] *** Ad1_RnR has joined ##OpenGL[19:14:12] *** pizthewiz has quit IRC[19:15:10] *** Ad1_RN has quit IRC[19:16:19] *** jophish_ is now known as jophish[19:17:29] *** karab44 has joined ##OpenGL[19:18:54] *** pizthewiz has joined ##OpenGL[19:21:03] *** MiniCow has quit IRC[19:24:03] *** shingshang has quit IRC[19:26:09] *** doomlord_1 has joined ##OpenGL[19:31:10] *** pazul has quit IRC[19:36:21] *** Match has quit IRC[19:39:03] *** meoblast001 has joined ##OpenGL[19:39:50] *** Jeanne-Kamikaze has joined ##OpenGL[19:41:48] *** kaleid0 has joined ##OpenGL[19:43:09] *** pazul has joined ##OpenGL[19:43:56] *** Biliogadafr has joined ##OpenGL[19:46:20] *** foreignFunction has joined ##OpenGL[19:46:40] *** BlackFox has quit IRC[19:47:32] *** BlackFox has joined ##OpenGL[19:53:04] *** kaleid0 has quit IRC[19:56:32] *** TheBunnyZOS has quit IRC[19:56:56] *** TheBunnyZOS has joined ##OpenGL[20:00:03] *** doomlord_1 has quit IRC[20:02:23] *** kuldeepdhaka has quit IRC[20:02:35] *** timsche has quit IRC[20:09:20] *** Orion] has joined ##OpenGL[20:10:15] *** Jeanne-Kamikaze has quit IRC[20:16:11] *** telex has quit IRC[20:16:38] *** razieliyo has quit IRC[20:17:53] *** Crehl has joined ##OpenGL[20:18:05] *** damir__ has joined ##OpenGL[20:18:36] *** razieliyo has joined ##OpenGL[20:18:36] *** razieliyo has joined ##OpenGL[20:18:46] *** telex has joined ##OpenGL[20:19:31] *** sedeki has joined ##OpenGL[20:25:23] *** LifeBlood has quit IRC[20:31:31] *** pazul has quit IRC[20:33:16] *** sedeki has quit IRC[20:35:29] *** ManDay has joined ##OpenGL[20:37:25] *** sedeki has joined ##OpenGL[20:42:30] *** hahuang65 has quit IRC[20:42:32] *** mukunda_ has quit IRC[20:43:52] *** derhass has joined ##OpenGL[20:49:15] *** HunterD has quit IRC[20:56:26] *** BitPuffin has quit IRC[21:05:03] *** sedeki has quit IRC[21:05:48] *** samrat has quit IRC[21:07:49] *** PasNox has joined ##OpenGL[21:11:46] *** gaganjyot has quit IRC[21:16:58] *** CainJacobi has joined ##OpenGL[21:23:10] *** Roze has joined ##OpenGL[21:23:12] *** Garner has quit IRC[21:24:24] *** Sos has joined ##OpenGL[21:28:17] *** sedeki has joined ##OpenGL[21:35:53] *** charlie5 has quit IRC[21:37:47] *** Demon_Fox has joined ##OpenGL[21:38:20] *** hahuang65 has joined ##OpenGL[21:39:44] *** kafor7 has joined ##OpenGL[21:40:02] *** Jack_ has joined ##OpenGL[21:40:38] *** edenist has quit IRC[21:40:41] <kafor7> Hello[21:41:09] <kafor7> I'd like to know what's the best way to render image from an external raycaster using OpenGL ?[21:41:28] <kafor7> render to texture and display this frame ?[21:41:45] <HuntsMan> yeah[21:42:35] <kafor7> for me it seems like the least problematic solution since size of OpenGL window is not always equal to the size of the image that raycaster produces[21:42:47] *** edenist has joined ##OpenGL[21:43:08] <kafor7> at the beginning I though about PBO but because of that size problem I think that rendering to texture is better, am I right ?[21:43:23] *** hahuang65 has quit IRC[21:43:31] <HuntsMan> size problem?[21:43:38] <kafor7> yes[21:43:45] <HuntsMan> and PBO cannot really be used just to draw[21:44:00] <kafor7> why ?[21:44:02] *** Demon_Fox has quit IRC[21:44:08] <HuntsMan> its just a way to upload data to the GPU[21:44:11] <HuntsMan> asynchronously[21:44:12] <japro> "external raycaster" and "render to texture" doesn't really fit in my head?[21:44:14] <HuntsMan> and to download as well[21:44:20] <japro> external meaning "someone elses code but still in opengl"?[21:44:34] <kafor7> japro not necessary[21:44:48] <kafor7> it's raycaster that works complety on CPU[21:45:22] <kafor7> so HuntsMan render to texture seems reasonably ?[21:45:47] <japro> render to texture only really makes sense from inside opengl[21:45:55] <HuntsMan> kafor7: actually it is just render A texture[21:45:58] <HuntsMan> not "to" texture[21:46:06] <HuntsMan> it's just a texture mapped quad[21:46:06] <kafor7> ok ;)[21:46:16] <japro> yeah and if you use glTexImage or a pbo doesn't matter that much[21:47:41] <kafor7> so drawing a quad that fits the whole screen and put a texture on it and change that texture frequently it's ok, isn't it ?[21:48:06] <kafor7> using glTexSubImage[21:48:52] <derhass> why wouldn't it?[21:49:06] <derhass> although I still recommend PBOs[21:51:26] *** konom has joined ##OpenGL[21:54:05] <kafor7> I'm not very familiar with PBO, so it has nothing with current size of OpenGL window, am I right ? and it only manages data on GPU ?[21:54:17] <kafor7> pixel data[21:56:17] *** linuxuz3r has joined ##OpenGL[21:56:35] *** ivan\ has quit IRC[21:57:10] *** ivan\ has joined ##OpenGL[21:58:07] *** tehrain has quit IRC[21:59:33] *** snakenerd has quit IRC[22:00:45] *** ManDay has quit IRC[22:02:02] *** sedeki has quit IRC[22:02:22] *** Khlorghaal has joined ##OpenGL[22:03:13] *** agorecki has joined ##OpenGL[22:05:06] *** karab44 has quit IRC[22:08:26] *** Keniyal has joined ##OpenGL[22:09:00] *** Biliogadafr has quit IRC[22:15:06] *** glYoda has quit IRC[22:15:43] *** Crehl has quit IRC[22:22:46] *** hackkitten has quit IRC[22:28:25] *** stefkos has quit IRC[22:30:16] *** _leb has joined ##OpenGL[22:32:27] *** BitPuffin has joined ##OpenGL[22:37:43] *** jubei has joined ##OpenGL[22:38:52] *** hahuang65 has joined ##OpenGL[22:39:16] *** Alina-malina has quit IRC[22:43:59] *** hahuang65 has quit IRC[22:44:37] *** Jack_ has quit IRC[22:45:04] *** Jack_ has joined ##OpenGL[22:45:51] *** glYoda has joined ##OpenGL[22:47:39] *** Garner has joined ##OpenGL[22:49:31] *** horlicks_ has quit IRC[22:52:07] *** staylor has joined ##OpenGL[22:52:33] *** hahuang65 has joined ##OpenGL[22:52:51] *** sedeki has joined ##OpenGL[22:53:12] *** BitPuffin has quit IRC[22:56:36] *** realz_ has quit IRC[22:56:36] *** realz_ has joined ##OpenGL[22:56:36] *** Stragus has quit IRC[22:56:38] *** kafor7 has quit IRC[22:56:40] *** realz has quit IRC[22:56:45] *** realz_ is now known as realz[22:57:05] *** realz_ has joined ##OpenGL[22:58:26] *** Sos has quit IRC[22:58:31] *** realz has quit IRC[22:58:37] *** realz_ is now known as realz[22:58:42] *** realz has joined ##OpenGL[22:59:39] *** TunnelCat has quit IRC[22:59:51] *** centrinia has joined ##OpenGL[23:04:30] *** dusted has quit IRC[23:04:46] *** CainJacobi has quit IRC[23:05:35] *** Lemml has joined ##OpenGL[23:08:50] *** meoblast001 has quit IRC[23:09:18] *** losh has quit IRC[23:09:31] *** bkre_ has joined ##OpenGL[23:09:53] *** foreignFunction has quit IRC[23:11:37] *** prophile has joined ##OpenGL[23:11:38] *** staylor has quit IRC[23:11:53] *** horlicks_ has joined ##OpenGL[23:11:57] *** PasNox has quit IRC[23:15:39] *** Lemml has quit IRC[23:15:54] *** PasNox has joined ##OpenGL[23:18:21] <tapout> I've installed opengl 3.3 on ubuntu 14.04. As a regular user, glxinfo | grep "OpenGL version" will report 3.3. When I sudo to root, it reports 2.1. The /usr/bin/glxinfo is being executed in both cases, I can't figure out *why* this is?? The reason I need to figure out, i keep getting "libGL error: failed to open drm device: Permission denied" and "libGL error: failed to load driver:[23:18:22] <tapout> vmwgfx", .. googling these, they say to add my current user to "video", and reboot. I do, and then the current user now has opengl 2.1. As soon as I remove the group "video", i'm back to 3.3 opengl[23:18:22] *** jdolan has quit IRC[23:22:54] *** Waynes has quit IRC[23:23:13] *** qeed has joined ##OpenGL[23:23:16] *** BreadProduct has joined ##OpenGL[23:24:26] *** xaxxon has joined ##OpenGL[23:24:27] *** BreadProduct_ has joined ##OpenGL[23:26:58] *** Jack_ has quit IRC[23:27:22] *** Jack_ has joined ##OpenGL[23:27:47] *** BreadProduct has quit IRC[23:27:53] *** xaxxon has left ##OpenGL[23:28:02] *** BreadProduct_ is now known as BreadProduct[23:29:13] *** konom has quit IRC[23:29:51] *** sedeki has quit IRC[23:30:38] <HuntsMan> tapout: is GL_RENDERER different for both cases?[23:31:04] *** YarnFive8 has joined ##OpenGL[23:31:34] *** AbiBuccaneer has joined ##OpenGL[23:34:02] *** antonp has joined ##OpenGL[23:34:49] *** AbigailBuccaneer has quit IRC[23:35:19] *** PasNox has quit IRC[23:36:44] *** Stragus has joined ##OpenGL[23:37:08] <tapout> checkign[23:37:16] *** Dudi has joined ##OpenGL[23:38:08] *** konom has joined ##OpenGL[23:38:15] <tapout> HuntsMan, when I am a regular user: libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007ff478a55000), when I'm root or in the group 'video', libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007fb1d46a4000)[23:38:37] <tapout> there are no GL_ environment vars[23:38:37] <HuntsMan> tapout: that's not what I asked[23:39:03] <HuntsMan> try with[23:39:05] <HuntsMan> glxinfo | grep "OpenGL renderer"[23:39:32] <tapout> ah yes, different[23:39:58] <tapout> regular user: OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits) ... root: OpenGL renderer string: Gallium 0.4 on SVGA3D; build: RELEASE;[23:40:31] <HuntsMan> llvmpipe is the software rasterizer[23:40:37] <HuntsMan> which GPU do you have?[23:41:00] <tapout> I have an ATI 6990 card, this is running in vmware[23:41:31] <HuntsMan> well that's why[23:41:37] <HuntsMan> you only have up to GL 2.x[23:42:09] <tapout> my video card will only do 2.x ? wth[23:42:20] *** _leb has quit IRC[23:42:22] <HuntsMan> 3.3 was provided by the software renderer[23:42:25] <HuntsMan> not by your GPU[23:42:33] *** antonp has quit IRC[23:43:03] <tapout> it says on wikipedia, it supports up to 4.3[23:43:15] <tapout> All models support DirectX 11.0, OpenGL 4.3, OpenCL 1.2[23:43:19] <cmr> tapout: this is entirely about the vmware drivers, not the hardware.[23:43:21] <HuntsMan> sure but that not inside the VM[23:43:27] <HuntsMan> the VM is what is limiting your GL version[23:43:29] <slime> the proprietary AMD drivers support GL4.4 for your GPU[23:43:35] <HuntsMan> since inside the VM, you use the VM's implementation[23:44:07] <tapout> ah darn... I wonder if it would work in virtualbox then[23:44:25] <tapout> makes sense as to why it's being limited now.[23:44:38] <HuntsMan> no, Virtualbox has the same issue :D[23:44:50] <tapout> I either, go get a new ssd and install ubuntu straight, or program inside windows.[23:45:22] <tapout> I guess I can use qt creator and do it inside windows[23:46:05] <tapout> but I've had better luck on ubuntu programming with Qt... things just, work...[23:47:17] <tapout> isn't that something, thank you guys... I found the google link now: http://askubuntu.com/questions/449842/opengl-version-problem-on-mesa[23:49:15] *** konom has quit IRC[23:50:02] <foobaz> there is another option, get rid of windows entirely :)[23:50:35] <Stragus> No need for a new ssd, can't you resize your partition? Unless it's full because it's a SSD[23:50:53] * Stragus pets 4TB disk drives[23:56:19] *** hackkitten has joined ##OpenGL[23:56:43] <tapout> 256GB ssd, once you go SSD, you can't go back[23:58:18] *** Crehl has joined ##OpenGL[23:58:30] *** JoshSyn has quit IRC[23:59:01] *** Syzygy__ has joined ##OpenGL[23:59:30] *** Syzygy__ is now known as Syzygy[23:59:36] *** leb has joined ##OpenGL