November 13, 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 13, 2014 [00:00:02] *** Mejid has joined ##OpenGL[00:14:08] *** bookmark has joined ##OpenGL[00:19:31] <paul424> Light coming from a narrow angle may be "trapped" and reflected between the surfaces of the lens elements. Narrow in the sense ... we measure between lens surface and ray incoming , right ?[00:21:18] *** centrinia has joined ##OpenGL[00:21:27] *** Shogun has joined ##OpenGL[00:22:35] <paul424> I am not native speaker so ..[00:23:35] <bob_twinkles> ideally lenses would be perfectly transmissive i.e. they don't reflect or absorb any light[00:23:50] <bob_twinkles> this is not physically possible (at least with glass as far as we know)[00:24:30] <bookmark> i found this the other day does this help?: https://www.youtube.com/watch?v=-n97pw480bo[00:24:30] <paul424> we measure between lens surface and ray incoming , right ? ?[00:24:40] <bob_twinkles> so what it's talking about are basically specular reflections off of the lense[00:25:31] <bob_twinkles> paul424: correct, it's the same thing that causes specular highlights[00:25:45] *** shintah has quit IRC[00:26:07] <paul424> the narrow angle ... naah ok[00:26:10] <bob_twinkles> (the bright spots you get on shiny plastic and the bright strip you see on the ocean are examples of specular highlights)[00:26:27] <paul424> the other way is to measure between camera Z axis ... ehm[00:27:49] <bob_twinkles> you need to do some tranformation to... I guess "curve" the viewport is the best way to put it if you want your affect to be physically based[00:27:51] <bob_twinkles> but yeah[00:28:40] <bookmark> i think the camera has to be near the angle of incidence in order to see a bright spot from a camera[00:28:51] <bookmark> from a certain cermera i mean[00:29:01] <bookmark> with specular highlights[00:29:14] <newguise1234> on wiki it says if the lightsource is not in the "viewport" it will still cause a haze[00:29:40] <bob_twinkles> right[00:30:12] <bookmark> i just fake specular with reflection maps hehe[00:30:46] <bookmark> they are only static though :([00:30:46] <bob_twinkles> well, specular reflection is just the general case of a 100% reflective surface[00:30:56] <bob_twinkles> and realtime lighting is Really Hard (TM)[00:31:02] <bob_twinkles> so.. faking it's good too[00:31:58] <bookmark> i got openmp working if anyone want to know how it works. you can use more cores of your cpu[00:31:59] *** AbiBuccaneer has joined ##OpenGL[00:32:03] <newguise1234> you could go all math and compute it straight up like they did for blackholes in that new movie[00:32:21] <newguise1234> a couple petabytes of data is what I think they computed[00:32:44] <bob_twinkles> yeah something tells me that computing lighting from first principles isn't really practical[00:33:35] <newguise1234> I'm sorry, "the movie brushed up against 800 terabytes of data"[00:33:57] <newguise1234> I'll let you all talk about opengl now again[00:34:01] <bob_twinkles> well 4k uncompressed video will do that to you[00:34:11] <bazkie_bumpercar> newguise1234, marketing talk! ;)[00:34:53] *** ragecryx has quit IRC[00:35:02] *** AbigailBuccaneer has quit IRC[00:35:13] <newguise1234> lol[00:35:34] <bookmark> i suppose you could prerender a highlight and then just alter its UVs based off some reflection math to create a specular[00:35:48] *** leb has quit IRC[00:36:05] <bookmark> because you'd need the highlight as a texture in order to do that[00:36:40] *** paperManu has quit IRC[00:36:43] <bob_twinkles> it's probably easier/cheaper just to do screen space lighting[00:36:57] <bob_twinkles> the math on that would be pretty nasty to work out[00:36:59] <bookmark> eww[00:37:21] <bookmark> well maybe if you had a screen space normal map[00:37:35] <bookmark> i guess thats workable[00:37:50] <bob_twinkles> http://en.wikipedia.org/wiki/Quantum_vacuum_plasma_thruster[00:37:53] <bob_twinkles> ...[00:37:58] <bob_twinkles> wrong wiki link XD[00:38:00] <bob_twinkles> http://en.wikipedia.org/wiki/Deferred_shading[00:38:12] *** konom has quit IRC[00:38:25] *** slidercrank has joined ##OpenGL[00:40:52] <derhass> bob_twinkles: but close[00:41:32] <bob_twinkles> yeah I mean theoretical thruster technology is basically the same thing as deferred shading[00:42:46] *** zerokool has quit IRC[00:43:44] *** Sos has quit IRC[00:44:56] <bookmark> i just figured out how to go from using 13% of an i7 to using 100%[00:45:05] <bookmark> using openmp[00:45:58] <bookmark> open multi processing[00:46:34] <bob_twinkles> using 100% doesn't make 100% of it useful =P[00:46:46] <bookmark> not if its programmed poorly now[00:46:50] <bookmark> er.. no[00:47:05] <bookmark> i'm seeing a roughly 8 times speed increase though[00:49:23] <bookmark> i don't mean frame rate though[00:49:43] <bookmark> i just mean in calculating stuff that takes a long time to calculate[00:50:01] <bookmark> it can be done many times faster :D[00:50:12] <bob_twinkles> yeah multithreaded opengl seems like it's a pain to manage[00:50:15] <bob_twinkles> never tried it though[00:50:27] <bob_twinkles> (I assume you aren't issuing draw calls from more than one thread)[00:50:44] <bookmark> im not really using it on my opengl side of things just to calculate the routes for my AI[00:50:54] <bookmark> used to take like 2 hours now it takes like 20 minutes[00:51:04] <bob_twinkles> nice[00:51:38] *** razieliyo has quit IRC[00:52:09] *** LifeBlood has joined ##OpenGL[00:52:22] *** pauldachz has quit IRC[00:58:41] *** derhass has quit IRC[01:13:14] *** Ad1 has quit IRC[01:18:23] *** bkre_ has quit IRC[01:24:22] *** indefini has quit IRC[01:37:27] *** TheBunnyZOS has quit IRC[01:41:42] *** BreadProduct has quit IRC[01:42:29] *** hexagoxel has quit IRC[01:48:43] *** b4b has joined ##OpenGL[01:51:30] *** SnakeTrailSteve has quit IRC[01:52:55] *** marchelzo_ has joined ##OpenGL[01:55:16] *** staylor has quit IRC[01:55:17] *** DolphinDream has joined ##OpenGL[01:58:35] *** konom has joined ##OpenGL[01:59:01] *** zajfy has joined ##OpenGL[02:01:03] *** indefini has joined ##OpenGL[02:02:02] *** wutata- has joined ##OpenGL[02:02:45] *** paul424 has quit IRC[02:04:08] *** SnakeTrailSteve has joined ##OpenGL[02:14:32] *** SleekoNiko has joined ##OpenGL[02:21:56] *** dusted has quit IRC[02:24:12] *** roboman2444 has quit IRC[02:24:26] *** bazkie_bumpercar has quit IRC[02:26:14] *** roboman2444 has joined ##OpenGL[02:26:53] *** wutata- has quit IRC[02:31:26] *** meoblast001 has joined ##OpenGL[02:37:19] *** BitPuffin has quit IRC[02:49:28] *** sreich has quit IRC[02:51:53] *** roboman2444 has quit IRC[02:52:29] *** roboman2444 has joined ##OpenGL[02:53:11] *** fatalhalt has joined ##OpenGL[02:54:31] *** Twinklebear has joined ##OpenGL[02:55:10] *** leb has joined ##OpenGL[03:03:12] *** Garner has quit IRC[03:11:57] *** lenarhoyt has quit IRC[03:12:30] *** JoshSyn has joined ##OpenGL[03:17:53] *** puerum has joined ##OpenGL[03:18:00] *** zzuegg has quit IRC[03:20:12] *** Orion] has quit IRC[03:23:05] *** Crehl has quit IRC[03:26:32] *** Mejid has quit IRC[03:32:47] *** fatalhalt has quit IRC[03:37:14] *** hahuang65 has quit IRC[03:45:29] *** robot-beethoven has joined ##OpenGL[03:48:57] *** pizthewiz has quit IRC[03:49:16] *** Hunts has joined ##OpenGL[03:49:37] *** pizthewiz has joined ##OpenGL[03:52:43] *** HuntsMan has quit IRC[04:03:42] *** meoblast001 has quit IRC[04:08:56] *** lenarhoyt has joined ##OpenGL[04:09:07] *** pizthewiz has quit IRC[04:11:56] *** bb010g has joined ##OpenGL[04:13:37] *** lenarhoyt has quit IRC[04:19:24] *** Khlorghaal has joined ##OpenGL[04:25:54] *** Twinklebear has quit IRC[04:28:23] *** TunnelCat has quit IRC[04:29:30] *** glYoda has quit IRC[04:29:42] *** glYoda has joined ##OpenGL[04:30:12] *** narcan has joined ##OpenGL[04:32:07] *** kidnapped_robot has joined ##OpenGL[04:34:28] *** urraka has quit IRC[04:41:56] *** Cabanossi has quit IRC[04:44:25] *** lenarhoyt has joined ##OpenGL[04:44:34] *** wiky has joined ##OpenGL[04:46:50] *** Twinklebear has joined ##OpenGL[04:48:42] *** Cabanossi has joined ##OpenGL[04:53:16] *** pauldachz has joined ##OpenGL[05:01:17] *** wiky has quit IRC[05:04:44] *** damir__ has quit IRC[05:05:44] *** Madsy has quit IRC[05:06:04] *** l3dx has quit IRC[05:06:12] *** leb has quit IRC[05:06:13] *** Madsy has joined ##OpenGL[05:06:24] *** linuxuz3r_ has joined ##OpenGL[05:06:35] *** l3dx has joined ##OpenGL[05:07:24] *** samrat has joined ##OpenGL[05:08:49] *** edwardk_ has joined ##OpenGL[05:09:13] *** aaa801_ has joined ##OpenGL[05:09:21] *** phil has joined ##OpenGL[05:09:24] *** damir__ has joined ##OpenGL[05:09:26] *** leb has joined ##OpenGL[05:09:38] *** phil is now known as Guest74884[05:09:56] *** b4b has quit IRC[05:10:12] *** kriskrop1 has joined ##OpenGL[05:10:16] *** Nach0z_ has joined ##OpenGL[05:11:46] *** dav2d has joined ##OpenGL[05:12:01] *** danharibo has joined ##OpenGL[05:12:01] *** danharibo has joined ##OpenGL[05:12:07] *** loesh_ has joined ##OpenGL[05:12:07] *** dreda_ has joined ##OpenGL[05:12:10] *** icedev_ has joined ##OpenGL[05:12:16] *** Miklas_ has joined ##OpenGL[05:12:17] *** telex has quit IRC[05:12:24] *** jone- has joined ##OpenGL[05:12:28] *** jonet has quit IRC[05:12:29] *** langkid1 has quit IRC[05:12:30] *** Miklas has quit IRC[05:12:31] *** lahwran has quit IRC[05:12:32] *** Nickeeh has quit IRC[05:12:38] *** oberstein has quit IRC[05:12:40] *** Riking has quit IRC[05:12:41] *** MLM has quit IRC[05:12:42] *** icedev has quit IRC[05:12:43] *** edwardk has quit IRC[05:12:43] *** Nach0z has quit IRC[05:12:45] *** phillip_w has quit IRC[05:12:46] *** aaa801 has quit IRC[05:12:46] *** linuxuz3r has quit IRC[05:12:47] *** kriskropd has quit IRC[05:12:49] *** Motig has quit IRC[05:12:54] *** markstar has quit IRC[05:13:00] *** pa has quit IRC[05:13:03] *** pigeon_ has quit IRC[05:13:04] *** mm765 has quit IRC[05:13:06] *** groton___ has quit IRC[05:13:07] *** chrisf has quit IRC[05:13:09] *** dav1d has quit IRC[05:13:09] *** boblehest has quit IRC[05:13:14] *** loesh has quit IRC[05:13:14] *** dreda has quit IRC[05:13:15] *** danhedron has quit IRC[05:13:16] *** pigeon has joined ##OpenGL[05:13:19] *** groton___1 has joined ##OpenGL[05:13:22] *** chrisf_ has joined ##OpenGL[05:13:22] *** jone- is now known as jonet[05:13:25] *** lahwran_ has joined ##OpenGL[05:13:29] *** Nickeeh has joined ##OpenGL[05:13:48] *** boblehest has joined ##OpenGL[05:13:59] *** edwardk_ is now known as edwardk[05:14:20] *** langkid1 has joined ##OpenGL[05:14:40] *** markstar has joined ##OpenGL[05:14:49] *** telex has joined ##OpenGL[05:15:05] *** riking_ has joined ##OpenGL[05:15:18] *** oberstein has joined ##OpenGL[05:17:48] *** RyanPridgeon has quit IRC[05:22:44] *** b4b has joined ##OpenGL[05:22:52] *** riking_ has quit IRC[05:22:52] *** riking_ has joined ##OpenGL[05:23:08] *** riking_ is now known as Riking[05:23:48] *** Nach0z_ has quit IRC[05:23:53] *** MLM has joined ##OpenGL[05:23:53] *** pa has joined ##OpenGL[05:24:07] *** Nach0z has joined ##OpenGL[05:24:07] *** Nach0z has joined ##OpenGL[05:25:47] *** hdon has quit IRC[05:27:13] *** wiky has joined ##OpenGL[05:27:53] *** qeed has quit IRC[05:38:20] *** marchelzo_ has quit IRC[05:39:03] *** slidercrank has quit IRC[05:43:55] *** wiky has quit IRC[05:45:28] *** kidnapped_robot has quit IRC[05:51:57] <Domx> fucking people on the internet annoy me[05:52:15] *** samrat has quit IRC[05:54:05] *** samrat has joined ##OpenGL[05:56:32] *** b4b has quit IRC[06:00:16] *** samrat has quit IRC[06:04:32] *** snakenerd has joined ##OpenGL[06:05:25] *** DolphinDream has quit IRC[06:11:15] *** lahwran_ is now known as lahwran[06:14:12] *** Demon_Fox has quit IRC[06:14:51] *** Demon_Fox has joined ##OpenGL[06:15:43] *** fatalhalt has joined ##OpenGL[06:18:26] *** pizthewiz has joined ##OpenGL[06:23:02] *** centrinia has quit IRC[06:24:52] *** hahuang65 has joined ##OpenGL[06:26:22] *** DMJC-M has joined ##OpenGL[06:29:09] *** SleekoNiko has quit IRC[06:30:57] *** Zupo has joined ##OpenGL[06:34:39] *** luxigo_ has joined ##OpenGL[06:34:55] *** Zupo2 has quit IRC[06:36:46] *** luxigo_ is now known as luxigo[06:37:22] *** BreadProduct has joined ##OpenGL[06:44:37] *** samrat has joined ##OpenGL[06:55:53] *** f0ster has quit IRC[06:58:01] *** kuldeepdhaka_ has joined ##OpenGL[07:06:25] *** shintah has joined ##OpenGL[07:08:51] *** lenarhoyt has quit IRC[07:09:28] *** bookmark has quit IRC[07:11:58] *** foreignFunction has joined ##OpenGL[07:16:44] *** mat^2 has quit IRC[07:21:54] *** linuxuz3r_ is now known as linuxuz3r[07:30:41] *** leb has quit IRC[07:31:04] *** luxigo has quit IRC[07:33:28] *** staylor has joined ##OpenGL[07:38:53] *** dmlloyd has quit IRC[07:39:39] *** Twinklebear has quit IRC[07:45:11] *** dmlloyd has joined ##OpenGL[07:48:46] *** damir__ has quit IRC[07:49:48] *** narcan has quit IRC[07:49:50] *** HunterD has joined ##OpenGL[07:51:13] *** snakenerd has quit IRC[07:55:39] *** Twinklebear has joined ##OpenGL[07:55:54] *** bjz has quit IRC[07:55:58] *** bjz_ has joined ##OpenGL[07:56:57] *** zzuegg has joined ##OpenGL[07:58:38] *** fatalhalt has quit IRC[07:59:30] *** LifeBlood has quit IRC[07:59:31] *** HunterD has quit IRC[08:00:11] *** Syzygy_ has quit IRC[08:00:14] <pragma-> /ignore Domx[08:00:29] *** bjz_ has quit IRC[08:00:45] *** Twinklebear has quit IRC[08:05:03] *** Syzygy_ has joined ##OpenGL[08:10:58] *** Alina-malina has quit IRC[08:11:03] *** davidhelp has joined ##OpenGL[08:11:06] <davidhelp> hi[08:11:32] *** Alina-malina has joined ##OpenGL[08:11:35] *** Madsy has quit IRC[08:11:54] <davidhelp> anyone here?[08:13:45] <neure> yup[08:16:06] *** kuldeepdhaka_ has quit IRC[08:16:11] *** JoshSyn has quit IRC[08:17:07] *** pizthewiz has quit IRC[08:21:37] *** HunterD has joined ##OpenGL[08:27:51] *** clauswitt has joined ##OpenGL[08:29:02] *** damir__ has joined ##OpenGL[08:31:11] *** centrinia has joined ##OpenGL[08:31:23] *** Gamecubic has quit IRC[08:31:30] *** lenarhoyt has joined ##OpenGL[08:32:35] *** Bloodust has quit IRC[08:32:35] *** Bloodust- has joined ##OpenGL[08:33:01] *** Bloodust has joined ##OpenGL[08:35:14] *** CainJacobi has quit IRC[08:35:59] *** Bloodust- has left ##OpenGL[08:38:59] *** Garner has joined ##OpenGL[08:42:51] *** Mimnim has joined ##OpenGL[08:47:32] *** DrSkyLizard has joined ##OpenGL[08:49:16] *** Hunts has quit IRC[08:49:19] *** shingshang has joined ##OpenGL[08:52:04] *** Beetny has joined ##OpenGL[08:52:20] *** puerum has quit IRC[09:08:00] *** lenarhoyt has quit IRC[09:09:57] *** Burga has joined ##OpenGL[09:11:47] *** Beetny has quit IRC[09:12:55] *** erhan_ has joined ##OpenGL[09:14:31] *** ManDay has joined ##OpenGL[09:16:45] *** karswell has quit IRC[09:19:14] *** karswell has joined ##OpenGL[09:21:31] *** linuxuz3r has quit IRC[09:21:45] *** karswell has joined ##OpenGL[09:23:55] *** Alina-malina has quit IRC[09:24:11] *** lenarhoyt has joined ##OpenGL[09:25:33] *** DMJC-M has quit IRC[09:26:37] *** Zupo has quit IRC[09:28:12] *** rendar has joined ##OpenGL[09:28:53] *** lenarhoyt has quit IRC[09:29:34] <rendar> for rendering some text that will describe my opengl scene, i have to draw before the 3d stuff, then set the camera as orthonormal and draw the text...it works, but are there other methods? maybe faster?[09:31:28] <Bloodust> thats not slow[09:31:43] <Bloodust> and the order doesnt matter[09:31:47] <Bloodust> you can draw text first or last[09:42:22] *** DMJC-M has joined ##OpenGL[09:42:40] <neure> switching matrices is not expensive at all[09:42:53] <neure> you often have matrix per draw call anyway[09:43:51] *** kuldeepdhaka has joined ##OpenGL[09:51:22] *** Syzygy__ has joined ##OpenGL[09:52:06] *** forests has quit IRC[09:53:53] *** dmlloyd has quit IRC[09:54:28] *** Syzygy_ has quit IRC[09:54:34] *** forests has joined ##OpenGL[09:54:45] *** dmlloyd has joined ##OpenGL[10:00:43] *** PasNox has joined ##OpenGL[10:02:08] *** TyrfingMjolnir has joined ##OpenGL[10:03:06] *** redeemed has joined ##OpenGL[10:04:59] *** Beetny has joined ##OpenGL[10:06:04] *** luxigo has joined ##OpenGL[10:06:20] *** hahuang65 has quit IRC[10:07:39] *** HunterD has quit IRC[10:13:29] *** davidhelp has quit IRC[10:17:42] *** foreignFunction has quit IRC[10:18:57] *** PasNox has quit IRC[10:20:04] *** PasNox has joined ##OpenGL[10:25:03] *** Alina-malina has joined ##OpenGL[10:25:04] *** Alina-malina has quit IRC[10:25:05] *** Alina-malina has joined ##OpenGL[10:25:05] *** lenarhoyt has joined ##OpenGL[10:27:34] *** DMJC-M has quit IRC[10:30:09] *** lenarhoyt has quit IRC[10:33:05] *** MLM has quit IRC[10:33:49] *** agorecki has quit IRC[10:33:53] *** clincher has quit IRC[10:35:31] *** clincher has joined ##OpenGL[10:36:18] *** PasNox has quit IRC[10:36:37] *** PasNox has joined ##OpenGL[10:38:38] *** Lemml has joined ##OpenGL[10:41:27] *** Demon_Fox has quit IRC[10:45:54] *** pazul has joined ##OpenGL[10:51:26] *** DMJC-M has joined ##OpenGL[10:58:28] *** HunterD has joined ##OpenGL[10:58:53] *** Sos has joined ##OpenGL[10:59:30] *** hexagoxel has joined ##OpenGL[11:06:32] *** shintahW2 has joined ##OpenGL[11:08:54] *** akaWolf has quit IRC[11:10:09] *** shintahW has quit IRC[11:10:09] *** shintahW2 is now known as shintahW[11:11:58] *** BreadProduct has quit IRC[11:12:55] *** indefini has quit IRC[11:13:57] *** TyrfingMjolnir has quit IRC[11:19:13] *** PasNox has quit IRC[11:20:14] *** PasNox has joined ##OpenGL[11:23:43] *** slime has quit IRC[11:24:13] *** jokoon has joined ##OpenGL[11:24:17] <jokoon> hello[11:25:22] *** slime has joined ##OpenGL[11:25:37] <jokoon> so if I have a pixel in a texture, can I use gl_TexCoord to know what is the index of the current pixel I'm calculating ?[11:25:48] *** lenarhoyt has joined ##OpenGL[11:30:13] *** PasNox has quit IRC[11:30:14] *** erhan_ has quit IRC[11:30:39] *** lenarhoyt has quit IRC[11:31:03] *** PasNox has joined ##OpenGL[11:31:15] *** erhan_ has joined ##OpenGL[11:31:32] *** wutata has joined ##OpenGL[11:31:32] *** luxigo has quit IRC[11:33:16] *** Lucretia has quit IRC[11:33:23] *** adsc has joined ##OpenGL[11:34:05] *** hexagoxel has quit IRC[11:36:20] *** Lucretia has joined ##OpenGL[11:39:16] *** aethersis has joined ##OpenGL[11:39:25] <aethersis> hi, what's pixel and texel fillrate?[11:45:19] *** robot-beethoven has quit IRC[11:48:04] <Bloodust> http://en.wikipedia.org/wiki/Fillrate[11:48:35] <AbiBuccaneer> http://linustechtips.com/main/topic/145402-what-are-pixel-fillrate-texture-fillrate/[11:50:08] *** paul424 has joined ##OpenGL[11:50:29] <paul424> Unreal engine 1 == Fog volume[11:51:06] <paul424> well how it was implemented then ?[11:51:27] <Bloodust> wat[11:51:34] <Adrinael> wat[11:52:37] <AbiBuccaneer> paul424, i vaguely remember unreal tournament 99's fog, and i think that being in a fog volume or not just toggles fullscreen fog[11:52:58] <paul424> AbiBuccaneer: hmm ok[11:53:12] <Bloodust> fyi, fog in post process is really easy[11:53:13] <AbiBuccaneer> GL_FOG has been around for a while, so i suspect it used that (or the D3D equivalent, or whatever)[11:53:41] <AbiBuccaneer> Bloodust, UT99-era games wouldn't have had access to the depth buffer, so i don't know how you'd do your own fog[11:53:58] <Bloodust> yeah Im talking about modern approach[11:54:10] *** indefini has joined ##OpenGL[11:54:54] <Bloodust> I did sun in post processing once, it looked pretty good[11:55:13] <AbiBuccaneer> god rays?[11:55:17] <Bloodust> without god rays[11:55:38] <AbiBuccaneer> what else is there to sun rendering - a circle?[11:56:27] <Bloodust> like dat http://upload.wikimedia.org/wikipedia/commons/c/cc/Cs1.jpg[11:56:40] <Bloodust> like it shone(?) through cirrostratus cloud[11:56:55] <aethersis> nniiiice[11:57:04] <aethersis> if it really looks like dat :D[11:57:11] <Bloodust> but without the rays[11:58:52] *** ManDay has quit IRC[12:00:43] *** PasNox has quit IRC[12:01:52] *** PasNox_ has joined ##OpenGL[12:02:41] *** PasNox_ is now known as PasNox[12:04:07] *** hahuang65 has joined ##OpenGL[12:04:16] <paul424> Volumetric fog is something like an extended corona. It behaves like distance fog, but takes the shape of a sphere around a light source. I do not know if it is availible in UT2003, but I would suspect that it is. In Unreal Tournament, the radius of the spherical "fog" can be specified in the light's properties by setting the VolumeBrightness, VolumeFog, and VolumeRadius properties in the...[12:04:17] <paul424> ...Lighting group. The fog will only be visible if the camera is within a zone that has bFogZone=true.[12:06:36] *** shintahW2 has joined ##OpenGL[12:06:44] *** jokoon has quit IRC[12:06:55] *** urraka has joined ##OpenGL[12:07:02] *** snakenerd has joined ##OpenGL[12:08:01] *** snakenerd has quit IRC[12:09:02] *** hahuang65 has quit IRC[12:10:26] *** shintahW has quit IRC[12:10:26] *** shintahW2 is now known as shintahW[12:11:08] <aethersis> what happens when I assign value greater than 1 to texture? Clamps?[12:11:21] <AbiBuccaneer> aethersis, depends on the texture wrap mode - by default, it wraps[12:11:31] <aethersis> I mean color[12:11:39] <AbiBuccaneer> oh right, not UV coordinates[12:11:47] <AbiBuccaneer> that depends on the texture format[12:12:11] <AbiBuccaneer> there are texture formats like GL_RGBA32F, which can store values >1[12:12:30] <aethersis> very heavy?[12:12:44] <AbiBuccaneer> yeah, that'd be 128 bits per pixel[12:12:52] *** HunterD has quit IRC[12:13:06] <Bloodust> also 16F[12:13:14] <AbiBuccaneer> even GL_RED8UI can hold values > 1[12:13:18] <Bloodust> they are heavy but still very much usable[12:13:24] <AbiBuccaneer> https://www.opengl.org/wiki/Image_Format#Required_formats[12:13:30] *** doev has joined ##OpenGL[12:13:43] <AbiBuccaneer> "unsigned normalized" is what *most* commonly used texture formats are, but not all[12:14:00] <AbiBuccaneer> there's also signed normalized textures, which range from -1 to 1[12:14:04] *** hexagoxel has joined ##OpenGL[12:14:28] <AbiBuccaneer> and float textures and (signed/unsigned) integer textures[12:15:55] *** adsc has quit IRC[12:19:10] *** dementorr has joined ##OpenGL[12:21:11] <dementorr> Hello, How can I move the eye and center of my screen? I mean my screen is showing the points only if I draw them in [-1, 1] x [-1, 1]. If I draw them (2, -1) (3, 4) It just show a blank window. I tried to set the lookAt to (0, 0, -10) (0, 0, 10) (0, 1, 0) but I still got black. Anyone knows what to do?[12:22:05] <Bloodust> 2d or 3d?[12:22:21] <dementorr> 2D but I am writing in 3D with component z = 0[12:22:42] <Bloodust> then just a simple scaling matrix works[12:23:03] <Bloodust> orthographic projection[12:23:42] <dementorr> so I should set glOrtho to some 6 parameters?[12:23:59] <Bloodust> glOrtho is no longer part of core opengl ,dont use that[12:24:13] <Bloodust> what tutorial are you following?[12:24:38] *** charlie5 has joined ##OpenGL[12:24:49] <dementorr> I (think) I am using freeglut. My laptop doesn't support more than OpenGL 2.1[12:25:08] <Bloodust> thats enough to start using shaders[12:26:04] <dementorr> No tutorial, I'm making a project for school where I just need to get some points, then do a triangulation and if I give some points with (3, 5) I will scale them someting like (3/5, 5/5) to make it show corectly[12:26:55] *** lenarhoyt has joined ##OpenGL[12:27:07] *** ragecryx has joined ##OpenGL[12:27:53] *** Negative_Se7en has joined ##OpenGL[12:31:03] *** Folkol has joined ##OpenGL[12:31:35] *** lenarhoyt has quit IRC[12:32:01] *** Negative_Se7en has quit IRC[12:32:48] *** Jack has joined ##OpenGL[12:33:12] *** Jack is now known as Guest96709[12:33:30] <dementorr> So, lets say that I got the points (1, 7) (2, 3) (10, 5) (-1 -5) (3, 9) (-4, 2). The eye is at 0 0 -1 looking to 0 0 1 up is 0 1 0. If I try to change that to 0 0 -10 and 0 0 10, It wont show up anything. Only thing that is working is to take all pairs and devide them by max so eventualy I would get: (0.1, 0.7) (0.2, 0.3) (0.10, 0.5) (-0.1 -0.5) (0.3, 0.9) (-0.4, 0.2). How else can I scale (or change the view to be further away to s[12:33:57] <dementorr> 0.10 is actually 1[12:34:27] <Bloodust> create a orthographic projection matrix[12:35:38] <dementorr> so what parameters (or values) should I put in the matrix to get it correctly?[12:36:19] <Bloodust> http://www.songho.ca/opengl/gl_projectionmatrix.html#ortho[12:36:36] <dementorr> Thx :) I got it working[12:37:43] *** xissburg has joined ##OpenGL[12:40:23] <dementorr> Bloodust: Can you tell me something more? If my screen is a wide screen (16 : 9) do you know a way to preserve the image if I maximize the window? As for now, it just screches the image and it shows up disproportionate.[12:40:42] <Bloodust> you have to update glViewport[12:42:01] *** HunterD has joined ##OpenGL[12:44:50] *** adsc has joined ##OpenGL[12:46:57] *** doomlord_1 has joined ##OpenGL[12:47:56] *** razieliyo has joined ##OpenGL[12:49:21] <aethersis> does anyone know a way how to disable vsync under linux on freeGLUT?[12:50:05] *** mat^2 has joined ##OpenGL[12:54:51] <Adrinael> vblank_mode=0 in environment[12:55:25] <aethersis> how to set it[12:55:49] <Adrinael> export vblank_mode=0[12:55:53] <Adrinael> ./run_your_program[13:00:26] <aethersis> it doesn[13:00:28] <aethersis> doesn't work[13:01:11] *** DrSkyLizard has quit IRC[13:02:19] <Adrinael> Oh, yes, that's only for Mesa drivers[13:02:30] <Adrinael> What are you running? nvidia blob? fglrx?[13:02:34] <aethersis> nvidia[13:02:47] <aethersis> LIBS += -L /usr/lib/nvidia-331/libGL.so[13:03:06] <aethersis> no matter what I do, glut limits framerate to 60[13:03:15] <aethersis> apparently I measure it correctly now[13:03:41] <aethersis> but I want to be able to run the program as fast as possible[13:03:56] <aethersis> I could run the drawing procedure in a loop though[13:05:43] <Adrinael> Run nvidia-settings to disable vsync[13:06:44] *** shintahW2 has joined ##OpenGL[13:06:58] *** zajfy has quit IRC[13:07:38] <aethersis> eep 3000fps[13:07:46] <aethersis> coils wheezing![13:07:54] <Adrinael> Now get a 3000Hz monitor[13:07:58] <aethersis> XD[13:08:22] *** t4nk586 has joined ##OpenGL[13:08:36] <t4nk586> hello, is there a good way to get large shadow casters into the scene?[13:08:45] <t4nk586> im currently using cascaded shadow mapping, splitting the frustum into 3 parts[13:08:48] <aethersis> for 36MPix I get 80 fps[13:08:57] <aethersis> decent![13:09:01] <Bloodust> t4nk586 more frustum parts?[13:09:10] *** DrSkyLizard has joined ##OpenGL[13:09:12] <t4nk586> but what if the shadow caster is behind the frustum?[13:09:22] <t4nk586> i currenlty use my 3rd split as a kind of area split[13:09:29] <t4nk586> who gets large casters, but the quality is abysmal, ofc[13:09:40] <aethersis> 2,8GT/s[13:10:03] *** pazul has quit IRC[13:10:19] *** shintahW has quit IRC[13:10:19] *** shintahW2 is now known as shintahW[13:10:40] <t4nk586> i then check if my current split has a shadow fragment and the area split has a shadow fragment, if third split has, and the current split does not, i use the area (third) splits fragment[13:10:41] <aethersis> sorry, Gpix/s[13:10:58] *** Beetny has quit IRC[13:12:36] <t4nk586> im searching for an elegant way to get shadow casters who cast large shadows into the first split, but are not in the first splits cascade[13:14:24] <t4nk586> well maybe i should sample all 3 shadow textures at the same time, and check which one is shadowing the fragment[13:14:34] <t4nk586> if split 1 isnt and split 2 is, use split 2[13:14:42] <t4nk586> instead of getting splits by depth[13:14:53] *** Burga has quit IRC[13:17:56] *** samrat has quit IRC[13:18:54] *** dementorr has quit IRC[13:25:10] *** paperManu has joined ##OpenGL[13:27:41] *** lenarhoyt has joined ##OpenGL[13:32:20] *** paul424 has quit IRC[13:33:00] *** zzuegg has quit IRC[13:33:13] *** lenarhoyt has quit IRC[13:33:34] *** sam has quit IRC[13:34:36] *** sam has joined ##OpenGL[13:35:41] *** Shogun_ has joined ##OpenGL[13:36:14] *** snakenerd has joined ##OpenGL[13:37:53] *** gaganjyot has joined ##OpenGL[13:37:57] *** Shogun has quit IRC[13:39:12] *** gaganjyot has quit IRC[13:39:49] *** Shogun has joined ##OpenGL[13:40:48] *** gaganjyot has joined ##OpenGL[13:41:28] *** gaganjyot has quit IRC[13:42:28] *** Shogun__ has joined ##OpenGL[13:42:45] *** gaganjyot has joined ##OpenGL[13:43:00] <aethersis> I know it's kinda dumb, but if I have 2 texture inputs in fragment shader and add the same texture to both inputs, will it produce error?[13:43:19] *** Shogun_ has quit IRC[13:43:23] *** gaganjyot has quit IRC[13:43:27] <aethersis> I need to do that for more flexibility[13:43:36] <aethersis> or I could write separate shader for this case[13:44:39] <AbiBuccaneer> aethersis, a texture can be simultaneously bound to multiple texture units just fine. and two sampler uniforms can point to the same texture unit just fine[13:44:47] <AbiBuccaneer> you won't need to write a separate shader[13:44:52] <aethersis> thank god[13:45:10] <aethersis> I'm drawing a detailed schematic of my solver on paper so that I can figure out what shaders I will need and what data types[13:45:42] *** paul424 has joined ##OpenGL[13:45:50] *** Shogun has quit IRC[13:46:53] *** hdon has joined ##OpenGL[13:49:02] *** wutata- has joined ##OpenGL[13:50:25] *** t4nk586 has quit IRC[13:51:07] *** DMJC-M has quit IRC[13:52:11] *** wutata has quit IRC[13:54:25] *** telex has quit IRC[13:56:45] *** telex has joined ##OpenGL[13:57:43] *** Angelo has quit IRC[13:59:27] *** Angelo has joined ##OpenGL[14:05:12] *** zzuegg has joined ##OpenGL[14:06:52] *** shintahW2 has joined ##OpenGL[14:07:22] <aethersis> lol I'm ending up with a flowchart that will take a whole wall in front of me xD[14:07:55] <neure> i've worked with a state machine that spanned 14 x A4[14:08:13] <neure> it had nothing to do with graphics[14:08:38] *** paul424 has quit IRC[14:10:40] *** shintahW has quit IRC[14:10:40] *** shintahW2 is now known as shintahW[14:12:00] <Bloodust> hah[14:13:02] *** paperManu has quit IRC[14:13:12] *** lenarhoyt has joined ##OpenGL[14:21:56] *** akaWolf has joined ##OpenGL[14:22:01] *** gaganjyot has joined ##OpenGL[14:23:24] *** gaganjyot has quit IRC[14:24:22] *** gaganjyot has joined ##OpenGL[14:24:53] *** doomlord_1 has quit IRC[14:27:42] *** doomlord_1 has joined ##OpenGL[14:33:32] *** luxigo has joined ##OpenGL[14:34:52] *** tehrain has joined ##OpenGL[14:35:04] *** tehrain has joined ##OpenGL[14:35:16] *** konom has quit IRC[14:41:21] *** centrinia has quit IRC[14:42:48] *** TyrfingMjolnir has joined ##OpenGL[14:47:13] *** paperManu has joined ##OpenGL[14:51:11] *** samrat has joined ##OpenGL[14:52:06] *** paperManu has quit IRC[14:55:14] *** BitPuffin has joined ##OpenGL[15:05:37] *** Sos has quit IRC[15:06:04] *** AbiBuccaneer has quit IRC[15:06:55] *** shintahW2 has joined ##OpenGL[15:07:00] *** paperManu has joined ##OpenGL[15:07:28] *** DrSkyLizard has quit IRC[15:10:24] *** shintahW has quit IRC[15:10:25] *** shintahW2 is now known as shintahW[15:11:41] *** Ad1_RnR has joined ##OpenGL[15:15:28] *** Ad1_RN has quit IRC[15:21:53] *** gaganjyot has quit IRC[15:33:08] *** HunterD has quit IRC[15:39:23] *** Khlorghaal has quit IRC[15:41:37] *** HunterD has joined ##OpenGL[15:48:48] *** DiffuseStorm has joined ##OpenGL[15:58:53] *** doomlord_1 has quit IRC[16:00:51] <DiffuseStorm> Hey I'm building a small 2d gui for myself using opengl. The text rendering needs a quad per character and a text segment has x characters. This text segment will be stored on the gpu (vertices, text coordinates), but I probably don't want a buffer per text segment. It feels wrong. So this means I need something like malloc (for managing the memory) for the opengl vertex buffer. Is this a common requirement, and is there any op[16:00:51] <DiffuseStorm> en source code? So I can have a decent sized buffer and simply ask for memory within it?[16:01:16] *** Sricharanized has joined ##OpenGL[16:03:12] *** Sricharanized has left ##OpenGL[16:04:05] *** Sricharanized has joined ##OpenGL[16:05:42] *** damir__ has quit IRC[16:07:05] *** shintahW2 has joined ##OpenGL[16:07:11] *** cden has joined ##OpenGL[16:08:57] *** b4b has joined ##OpenGL[16:10:37] *** shintahW has quit IRC[16:10:37] *** shintahW2 is now known as shintahW[16:10:38] *** Sricharanized has left ##OpenGL[16:12:34] *** slidercrank has joined ##OpenGL[16:12:48] *** wutata- has quit IRC[16:23:07] *** Madsy has joined ##OpenGL[16:25:07] <newguise1234> DiffuseStorm: you can allocate a large "pool" with glBufferData, and then set parts of it with glBufferSubData[16:25:37] <newguise1234> you would then keep track of the offsets you used for different objects and use those offsets to display the data in your buffer[16:25:44] *** Zupo2 has joined ##OpenGL[16:25:58] <DiffuseStorm> newguise1234: Yes but I'm wondering how to manage that pool because I'll be both allocating data to that pool and deallocating. So it requires an algorithm such as those used in malloc.[16:26:23] <DiffuseStorm> So I'm wondering if there is an open source implementation of something like that.[16:26:24] *** asido has joined ##OpenGL[16:27:00] <newguise1234> I don't know of any, but I'm pretty new to this, you could implement a basic/non-efficient version pretty easily though[16:27:12] <DiffuseStorm> sure I'll probably do that[16:27:16] *** jokoon has joined ##OpenGL[16:27:24] <newguise1234> just keep track of object offsets and sizes, and when you want to add another object find the smallest place it will fit[16:27:36] <newguise1234> (if you have open space in the middle)[16:27:42] <jokoon> how do I use two textures with shaders when I want to read and write ?[16:27:42] <newguise1234> otherwise stick it on the back[16:28:11] <jokoon> with sfml[16:29:50] <newguise1234> what do you mean by read and write?[16:29:54] <newguise1234> to the textures?[16:30:10] <newguise1234> http://sfml-dev.org/documentation/2.0/classsf_1_1RenderTarget.php[16:30:40] <newguise1234> I don't know how to use shaders with sfml though sorry[16:31:29] *** PasNox has quit IRC[16:36:04] *** AbigailBuccaneer has joined ##OpenGL[16:37:07] *** Zupo3 has joined ##OpenGL[16:39:21] *** Zupo3 has quit IRC[16:39:39] *** Zupo3 has joined ##OpenGL[16:40:15] *** Zupo2 has quit IRC[16:42:06] *** Rutix has joined ##OpenGL[16:42:06] *** Rutix has joined ##OpenGL[16:47:55] <newguise1234> just reading about glMapBuffer, is it better to use than glBufferSubData?[16:48:25] <Yaniel> likely[16:50:31] *** clauswit_ has joined ##OpenGL[16:50:37] <DiffuseStorm> I don't understand how it works, is it actually possible to map the client's address space to memory that sits on the gpu?[16:50:45] <DiffuseStorm> (How glMapBuffer works)[16:51:22] *** danharibo is now known as danhedron[16:51:27] <Yaniel> it is possible to map gpu memory to the client's address space[16:52:04] <DiffuseStorm> Hmm wow, that sounds powerful, and will probably be much more powerful in the future as well.[16:53:03] <Bloodust> yeah map buffer + persistent mapping pretty much the fastest thing you can get[16:53:08] <newguise1234> thanks for the search item http://stackoverflow.com/questions/6543848/does-glmapbuffer-copy-data[16:53:12] <Bloodust> pbos might win, dunno[16:53:18] *** luxigo has quit IRC[16:53:20] <Bloodust> depends on usage[16:53:34] *** clauswitt has quit IRC[16:55:06] *** clauswit_ has quit IRC[16:55:49] *** Orion] has joined ##OpenGL[16:57:16] <jokoon> is glmapbuffer related to my question newguise1234 ?[16:57:27] <jokoon> sorry did not read your other answers[16:57:44] <jokoon> actually I've been told to use rendertexture[16:58:13] <newguise1234> jokoon: it was not, I would look into rendertexture and sf::shader for what you're trying to do[16:58:25] <Bloodust> if you want to render to texture, you need fbo[16:58:28] <newguise1234> I've not used sf::shader but I have used rendertexture and its not that convoluted[16:58:40] <newguise1234> Bloodust: he's using sfml[16:58:53] <Bloodust> okey..[16:59:06] <jokoon> yeah I want to keep it simple enough[16:59:39] <jokoon> I want to do some kind of game of life, but with my proper rules, so I use shader to speed it up[16:59:52] <jokoon> so I need to read/write at each frame[16:59:55] <jokoon> and swap[16:59:57] <jokoon> I guess[17:01:35] <DiffuseStorm> no you don't? I'm not sure what you mean by read and write. But I think a standard logic + render each frame will do fine. No need to manipulate what you rendered if that's what you mean.[17:01:53] <jokoon> yes that's what I mean[17:02:00] <jokoon> in a shader I heard you can't read and write[17:02:07] <jokoon> since it's parallel[17:03:32] <DiffuseStorm> Okay so you simply have the game of life logic in normal cpu code and each frame you generate the geometry to be rendered on the gpu?[17:04:02] <DiffuseStorm> err not generate, but create the geometry[17:04:19] <DiffuseStorm> err nevermind, that's the same thing[17:04:26] <newguise1234> I could be misinterpreting, but I think he wants something along the lines of a compute shader? storing the state of the game in a texture[17:04:48] <DiffuseStorm> ohh lol, I don't know enough about game of life to have figured that out, I think you may be right[17:04:57] <AbigailBuccaneer> you could run game of life in a fragment shader with ping-pong rendering fairly easily[17:05:28] <AbigailBuccaneer> ie. you have two textures, each time you read the previous state from one while writing the present state into the other, and swap each frame[17:05:38] <newguise1234> sorry for cutting you off Bloodust was just passing the little bit of information I had about his situation along[17:05:48] <newguise1234> I don't know much about rendering to textures and fbos[17:05:49] <Bloodust> np[17:06:05] <jokoon> DiffuseStorm, no I want to compute the states inside the shader[17:06:11] <jokoon> because shader are good at it[17:06:21] <jokoon> game of life is highly parallelizable[17:07:13] *** shintahW2 has joined ##OpenGL[17:08:39] *** jokoon has quit IRC[17:08:55] *** slidercrank has quit IRC[17:08:56] <newguise1234> jokoon: coming from AbigailBuccaneer's recommendation. It might be something along the lines of, set rendertarget to texture2, bind shader, render texture1 to rendertarget. set rendertarget to texture1, bind shader, render texture2 to rendertarget[17:09:00] <newguise1234> rinse wash repeat[17:09:16] <AbigailBuccaneer> precisely[17:09:47] <DiffuseStorm> jokoon: there seems to be a lot of material on the internet for gpu game of life: http://nullprogram.com/blog/2014/06/10/[17:09:49] <newguise1234> texture1 and texture2 must be created as rendertextures, just as a follow up[17:10:22] *** Ad1 has joined ##OpenGL[17:10:31] <AbigailBuccaneer> what do you mean "must be created as rendertextures"? most common textures are color-renderable (ie. can be used as framebuffer color attachments)[17:10:52] <newguise1234> AbigailBuccaneer: he is using sfml, which has a class heirarchy[17:10:56] <AbigailBuccaneer> ah[17:10:59] *** metredigm has joined ##OpenGL[17:11:13] *** Jack_ has joined ##OpenGL[17:11:17] *** shintahW has quit IRC[17:11:18] *** shintahW2 is now known as shintahW[17:11:46] *** metredigm has left ##OpenGL[17:12:54] *** kuldeepdhaka has quit IRC[17:13:06] *** sreich has joined ##OpenGL[17:13:53] *** Guest96709 has quit IRC[17:14:31] <DiffuseStorm> jokoon: This guy has got it down to science, but he does use CUDA: http://www.marekfiser.com/Projects/Conways-Game-of-Life-on-GPU-using-CUDA - Includes a chart on cpu vs gpu speed and more. Make sure to check out all the pages. It might be interesting even if you're going to use OpenGL.[17:15:09] <newguise1234> if you don't want to use cuda, you can look into opencl as well[17:15:16] *** kuldeepdhaka has joined ##OpenGL[17:15:27] <newguise1234> you can share opengl buffers as well[17:15:57] <newguise1234> I mean, I guess cuda has opengl interop[17:16:08] <newguise1234> but openCL is the open standard thats similar to cuda[17:16:11] *** cden has quit IRC[17:16:21] <DiffuseStorm> Stupid NVIDIA not updating their OpenCL drivers :([17:16:32] <DiffuseStorm> My fault, I bought nvidia :P[17:16:49] <newguise1234> aye, I read a post that said they would be updating in q1 of 2015[17:17:14] <newguise1234> same here, I thought I was missing some functionality, but I could do what I wanted, I just had to find a different function name[17:25:09] *** Portals has joined ##OpenGL[17:30:25] *** MLM has joined ##OpenGL[17:35:05] *** gaganjyot has joined ##OpenGL[17:36:46] *** gaganjyot has quit IRC[17:37:49] *** gaganjyot has joined ##OpenGL[17:37:55] *** redeemed has quit IRC[17:38:37] *** jyot has joined ##OpenGL[17:38:44] *** gaganjyot has quit IRC[17:39:25] *** pizthewiz has joined ##OpenGL[17:40:18] *** gaganjyot has joined ##OpenGL[17:41:20] *** jyot has quit IRC[17:41:23] *** gaganjyot has quit IRC[17:41:55] *** razieliyo has quit IRC[17:42:00] *** pizthewiz has quit IRC[17:42:02] *** DiffuseStorm has quit IRC[17:42:07] *** gaganjyot has joined ##OpenGL[17:42:22] *** jyot has joined ##OpenGL[17:43:03] *** razieliyo has joined ##OpenGL[17:43:03] *** razieliyo has joined ##OpenGL[17:43:40] *** gaganjyot has quit IRC[17:44:34] *** LeelooMinai has left ##OpenGL[17:44:51] *** gaganjyot has joined ##OpenGL[17:45:47] *** gaganjyot has quit IRC[17:46:17] *** HunterD has quit IRC[17:46:51] *** gaganjyot has joined ##OpenGL[17:47:57] *** gaganjyot has quit IRC[17:56:41] *** Zupo3 has quit IRC[17:57:15] *** Zupo has joined ##OpenGL[18:00:53] *** pizthewiz has joined ##OpenGL[18:04:25] *** erhan_ has quit IRC[18:09:25] *** HunterD has joined ##OpenGL[18:13:32] *** Misu has joined ##OpenGL[18:14:38] *** Zupo2 has joined ##OpenGL[18:16:30] *** TheBunnyZOS has joined ##OpenGL[18:16:55] *** Zupo has quit IRC[18:22:05] *** DrBenway has quit IRC[18:22:41] *** lenarhoyt has quit IRC[18:27:13] *** b4b has quit IRC[18:29:16] *** b4b has joined ##OpenGL[18:31:13] *** hahuang65 has joined ##OpenGL[18:33:16] *** Portals has quit IRC[18:33:19] *** PasNox has joined ##OpenGL[18:35:54] *** hahuang65 has quit IRC[18:41:30] *** CainJacobi has joined ##OpenGL[18:42:08] *** Motig has joined ##OpenGL[18:46:28] *** ripper93 has joined ##OpenGL[18:46:40] *** ripper93 has quit IRC[18:55:32] *** Shogun__ has quit IRC[18:58:09] *** ripper93 has joined ##OpenGL[19:03:41] *** adsc has quit IRC[19:11:21] *** stefkos has joined ##OpenGL[19:20:02] *** Zupoman has joined ##OpenGL[19:20:04] *** Zupoman has joined ##OpenGL[19:21:45] *** hahuang65 has joined ##OpenGL[19:21:54] *** Ryp has joined ##OpenGL[19:28:26] *** cden has joined ##OpenGL[19:29:54] *** shingshang has quit IRC[19:30:34] *** sedeki has joined ##OpenGL[19:33:23] *** pauldachz has quit IRC[19:38:49] *** PasNox has quit IRC[19:38:54] *** BitPuffin has quit IRC[19:40:05] *** hexagoxel has quit IRC[19:41:09] *** PasNox has joined ##OpenGL[19:42:51] *** jubei has joined ##OpenGL[19:45:08] *** Kane has joined ##OpenGL[19:46:20] *** AbleBacon has joined ##OpenGL[19:46:27] *** ShadowIce has joined ##OpenGL[19:47:26] <AbleBacon> i have a whole bunch of different objects of various classes, each one of which gets rendered in a different way (different texture, different shader, etc). what's the best way to set this up? should i store each object's model and texture within the object?[19:47:47] <Bloodust> no[19:48:21] <Bloodust> I have one place for models, one for shaders and one for textures[19:48:35] <AbleBacon> because i'm iterating through my list of objects (all of which share the same base class), but handling the rendering differently depending on what type of object it is is becoming a pain[19:48:39] *** ripper93 has quit IRC[19:48:48] <Bloodust> each object/class knows what model(+textures) it uses[19:49:03] <AbleBacon> they carry a pointer, then?[19:49:10] <Bloodust> no[19:49:15] <Bloodust> they dont need to access the data[19:49:18] <Bloodust> they carry an id[19:49:25] <Bloodust> and in my case that id is a string[19:49:42] <AbleBacon> ah--okay and you have some kind of dictionary structure set up to look up what it needs?[19:49:47] <Bloodust> bingo[19:49:58] <Bloodust> basically my model manager has map<string, Model> models;[19:50:05] *** metredigm has joined ##OpenGL[19:50:34] <Bloodust> so I gather all the object transformations and their models in an array, sort that, and render it[19:50:45] <Bloodust> and by models I mean model IDs[19:51:20] <AbleBacon> sort it how? so all of the "object A" objects are at the front, followed by "object B", etc?[19:51:34] <Bloodust> by shader, then by VAO id, then by texture[19:51:35] <AbleBacon> to avoid switching textures and shaders as much as possible?[19:51:41] <AbleBacon> ah okay[19:51:43] <Bloodust> to minimize state chances[19:52:00] <AbleBacon> hmmm that's actually a really good way of doing it[19:52:10] <Bloodust> http://codepad.org/0UAti8Qq[19:52:20] <Bloodust> I think I use this[19:52:28] <Bloodust> something along those lines anyway[19:52:30] <AbleBacon> i was originally going to try to sort my list of objects by what type of object each one is, but since rendering doesn't have to be coupled to my object model, that would work well...[19:54:23] <Bloodust> so I have a rendering queue[19:56:24] <metredigm> you sort on a per-frame basis?[19:56:31] *** sedeki has quit IRC[19:56:43] <AbleBacon> i have some models that are procedurally generated... like my asteroids are born with a random shape. how should i handle that?[19:57:32] <metredigm> if it's 2D triangulation should be pretty easy[19:57:40] <Bloodust> dunno lol[19:57:45] *** foreignFunction has joined ##OpenGL[19:57:48] <Bloodust> do you generate them on the gpu?[19:57:52] <AbleBacon> CPU[19:57:52] <metredigm> well, only if they are convex asteroids[19:57:53] <Bloodust> aah doesnt matter[19:57:59] <metredigm> triangle fan would be simple[19:58:11] <Bloodust> just push them to the render queue[19:58:14] <Bloodust> I see no problem with this[19:58:22] <AbleBacon> yeah, but i have to store their models somewhere[19:58:31] <Bloodust> well yeah obviously :D[19:58:35] <Bloodust> you have to have the data somewhere[19:58:38] <newguise1234> just have a model manager[19:58:48] <AbleBacon> how would that work?[19:58:50] <newguise1234> and your objects will hold an id to where they are there[19:58:57] <newguise1234> and your model manager holds the vbo vao information[19:59:12] <AbleBacon> hmmmm[19:59:32] <AbleBacon> it's just that i have other objects that all use the same model... not sure how to integrate those into the same system with the asteroids[19:59:44] <metredigm> yeah, implement caching in the manager[20:00:09] <newguise1234> just have those objects point to their model in the model manager[20:00:10] <AbleBacon> and what about objects that i render as particles? i'd have to store a pointer to a different rendering function in the model manager for that, right?[20:00:13] <metredigm> when the manager is queried for a model which has already been created, just pass the previously generated model[20:00:13] *** sedeki has joined ##OpenGL[20:00:24] <AbleBacon> ah--okay[20:00:36] <newguise1234> your renderer and model manager should be seperate[20:00:49] <newguise1234> so you can pass the same objects to multiple renderers[20:01:06] <AbleBacon> how would i query for, say, "asteroid10"? just have an entry in the model manager called "asteroid10"?[20:01:10] <newguise1234> afaik[20:01:20] <newguise1234> using a map as Bloodust suggested[20:01:28] <Bloodust> right, all my models are rendered with glDrawElements[20:01:50] <Bloodust> I used to support instancing but that didnt really work out well performance wise[20:02:23] <metredigm> yeah, during game init, dry query the manager with "asteroid10" and the model data[20:02:44] <AbleBacon> so... when i create an asteroid... i assign it a unique ID number... and then create an entry in the std::map for that unique ID along with the procedurally-generated model?[20:02:53] *** Folkol has quit IRC[20:02:54] <newguise1234> yes[20:03:04] <newguise1234> my model manager just has a load function[20:03:13] <newguise1234> which will take in a vertex array or a filename[20:03:15] <AbleBacon> see, but hten i'd get tempted to store all the rest of the info about the asteroid in that map entry as well...[20:03:26] <newguise1234> what type of information[20:03:34] <AbleBacon> like its location, how fast it's spinning, etc[20:03:41] <Bloodust> thats not part of model manager[20:03:42] <newguise1234> you should only be storing your gl related keys in the map entry[20:03:46] <newguise1234> like vbo ids vao ids[20:03:52] <newguise1234> ibo ids[20:03:58] <AbleBacon> yeah--it's just hard to me to separate all the properties conceptually[20:04:04] <metredigm> keeping rendering segregated from the ECS is generally a really good idea[20:04:07] <AbleBacon> okay--well i'm gonna try that! thanks for the help[20:04:15] <metredigm> also, use an ECS[20:04:25] <Bloodust> whats that[20:04:32] <metredigm> entity-component system[20:04:47] <Bloodust> yeah[20:04:53] <newguise1234> AbleBacon: https://github.com/jgleesawn/sdlgl/blob/master/game/src/glmanager/glmanager.h[20:04:53] <Bloodust> composition > inheritance[20:05:01] <newguise1234> that is my very poor implementation of a model manager[20:05:10] <AbleBacon> ew ew ew i don't want to use composition :([20:05:23] *** Dudi has joined ##OpenGL[20:05:25] <Bloodust> newguise1234 very raw[20:05:37] <AbleBacon> thanks, newguise1234--i'll look at that if i feel the need to "cheat"[20:05:41] <Bloodust> and not very safe[20:06:02] <Bloodust> also, it leaks memory?[20:06:08] <newguise1234> it doesn't leak memory[20:06:33] <Bloodust> who fills the gfxObjs vector[20:06:42] <newguise1234> new gfxObjs[20:06:46] <AbleBacon> how can you tell it leaks memory from the header alone?[20:06:58] <AbleBacon> oh--i see the other code files[20:06:59] <newguise1234> because it takes a pointer in a vector[20:07:00] <Bloodust> AbleBacon vector with pointers in it and empty destructor[20:07:10] <newguise1234> destructor is in the cpp[20:07:14] <newguise1234> its not a very good model manager[20:07:21] <Bloodust> oh right I missread that[20:07:38] <Bloodust> lets see if I can show you mine[20:07:48] <newguise1234> I just wanted something to pack multiple models into a single vbo[20:08:26] <newguise1234> AbleBacon: basicrenderer.cpp has the code that will actually render the objects[20:08:33] <newguise1234> its pretty coupled though[20:08:43] <newguise1234> I'm more excited about seeing Bloodust 's implementation if he can find it[20:09:00] <Bloodust> http://codepad.org/GmE0RB6N[20:09:12] <Bloodust> its not great[20:09:20] <Bloodust> but its something[20:09:38] <Bloodust> the rendering functions are old, ignore those[20:10:19] <Bloodust> also, my code is fully pointerless :P[20:10:29] <Bloodust> thanks to move semantics[20:10:30] <metredigm> a possible interesting way to render would be to have a large global VBO, seperate IBOs for each object[20:10:38] <metredigm> greatly reduce buffer binding state changes[20:10:44] <metredigm> however increase VBO generation time[20:11:00] <metredigm> and also puts a lower limit on the game vertex count[20:11:19] <Bloodust> metredigm smaller VBOs are usually recommened[20:11:48] <Bloodust> also, this option forces unsigned integer indices[20:13:38] *** jyot has quit IRC[20:13:54] *** Waynes has joined ##OpenGL[20:14:56] <Bloodust> oh yeah, my model class is huuge[20:15:30] <Bloodust> even after I moved model loading to separate files[20:16:16] *** metredigm has quit IRC[20:17:23] *** metredigm has joined ##OpenGL[20:20:04] <AbleBacon> so the model manager should store things that don't change for the object throughout its lifetime, right? like the model that it uses and the shader that it uses[20:20:24] <AbleBacon> it's just that the transformation for it changes every time...[20:20:38] <metredigm> shader should be kept seperate, unless you are using seperate shaders for each model[20:20:49] *** Beetny has joined ##OpenGL[20:20:50] <metredigm> yeah transformation matrix should be kept seperate[20:21:00] <AbleBacon> but then how do i sort all my objects?[20:21:12] <metredigm> sorting by position?[20:21:48] <AbleBacon> i have the object as represented for my simulation (speed, direction, positon, mass, etc), and then my object as represented for my rendering (shader, model, texture, etc)[20:21:56] <AbleBacon> they have to be able to "talk" back and forth[20:22:18] <metredigm> well, they will probably need a definite binding[20:22:22] <metredigm> really they should be the same thing[20:22:41] <metredigm> or they should be united in some sort of monolithic container[20:23:09] <metredigm> where you'd have a structure for entities, having two pointer members to a "logical" part and a "visible" part[20:23:20] *** bkre_ has joined ##OpenGL[20:23:20] <metredigm> you could have virtual event functions in both parts[20:23:55] <AbleBacon> hmmmm[20:24:05] <AbleBacon> i'm gonna start generalizing some of my stuff and then see how best to organize it i guess[20:26:57] <AbleBacon> each object will store what model it uses by ID... and... by name so that it can be loaded... but then i'd need a flag to say whether it's been loaded yet or not *sigh*[20:27:27] <AbleBacon> i mean texture[20:27:48] <Bloodust> if the model manager has the model name stored, its loaded[20:27:50] <Bloodust> otherwise nope[20:29:15] <AbleBacon> instead of storing shader ID, should i store the uniform ID instead?[20:30:07] <Bloodust> wat[20:30:17] <Bloodust> for what[20:30:20] <AbleBacon> i create a uniform for each texture with the shader that it uses[20:30:32] <Bloodust> oh, cant you use layouts?[20:31:24] <newguise1234> to get around not being able to use layouts, I essentially have a base renderer class, and then I have a derived class for each shader group that I load[20:32:00] <newguise1234> I pretty much just change the constructor and add a GLint array that holds uniform variable pointers[20:32:05] <newguise1234> or ids[20:32:06] <newguise1234> w/e[20:32:15] <AbleBacon> what's a layout? :-/[20:32:43] <newguise1234> layout(location = 0) in vec4 vertexCoord;[20:32:55] <newguise1234> would give you an attribute with id of 0[20:33:09] <newguise1234> layout(location = 0) uniform vec4 viewOffset;[20:33:17] <newguise1234> would give you a uniform variable with id of 0[20:33:18] <Bloodust> same thing for textures[20:33:34] *** asido has quit IRC[20:33:39] <Bloodust> layout(binding=0) sampler2D diffusetexture; something like this[20:33:43] <Bloodust> I dont remember the correct syntax[20:33:56] <newguise1234> makes it so you dont have to bind to attributes or uniforms in your program code[20:34:06] *** zzuegg2 has joined ##OpenGL[20:34:07] <newguise1234> you can just use the ids you specify in your shader[20:34:42] <Bloodust> which means texture binding becomes just glActiveTexture and glBindTexture[20:35:09] <Bloodust> no more uniform hell[20:37:08] <AbleBacon> oh--that's what i'm using[20:37:14] *** zzuegg has quit IRC[20:37:30] <AbleBacon> i think[20:40:12] *** Binero has joined ##OpenGL[20:40:15] <Binero> Hello[20:40:30] <Binero> Are all functions in the OpenGL XML specification context specific? https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml[20:41:08] <Binero> Well not necessarily context-specific, but do all of these require an active context?[20:41:12] *** BreadProduct has joined ##OpenGL[20:41:32] *** Syzygy__ has quit IRC[20:42:04] *** Syzygy__ has joined ##OpenGL[20:42:30] <Bloodust> umm 99% of them yes[20:42:39] <Binero> eh 99%[20:42:54] <Binero> So there actually is a 1% which works without an active context?[20:42:58] <Binero> Are they marked as such?[20:42:58] <Bloodust> maybe[20:43:12] <Binero> Need to know because I want to generate some bindings[20:45:09] <metredigm> can't think of any GL functions at all that don't require a context[20:45:19] <metredigm> since all of them would go through the GPU's implementation[20:45:23] <metredigm> pretty much regardless[20:45:49] <Bloodust> yeah, the wgl and glx kind of functions that are needed to create context dont require context, but everything else does[20:46:04] *** derhass has joined ##OpenGL[20:46:09] <Bloodust> but tbh I dont think those are part of the gl api[20:48:26] <Binero> alright[20:48:52] *** realz has quit IRC[20:51:18] *** Dudi has quit IRC[20:53:11] *** Dudi has joined ##OpenGL[20:54:13] *** Dudi has quit IRC[20:56:12] <metredigm> yeah glX and wgl are completely seperate[20:56:18] *** DMJC-M has joined ##OpenGL[20:56:23] <metredigm> from the GL api[20:56:46] <Bloodust> figured[20:57:02] <Bloodust> I never never created a context myself so Ive only heard about them[20:59:05] <metredigm> anyone here running linux with gl 3.3+[20:59:47] <Yaniel> 4.4[21:00:33] <metredigm> nice. if you're interested I made a TBO particle system as a 12-hour challenge, looks really cool on strong GPUs[21:00:39] <metredigm> http://github.com/metredigm/mini-particles[21:00:50] <metredigm> i can only get 150,000 particles as my GPU's kind of weak[21:02:33] <Binero> Yaniel: Are you using proprietary drivers?[21:03:06] <Bloodust> metredigm pics?vids?[21:03:20] <Yaniel> yeah[21:03:49] *** telex has quit IRC[21:04:44] *** telex has joined ##OpenGL[21:05:17] *** metredigm has quit IRC[21:06:08] *** rendar has quit IRC[21:06:38] *** metredigm has joined ##OpenGL[21:08:13] <Binero> is there a reason the openGL specification is not language independent?[21:08:31] <Binero> From my understanding it was made to make creating bindings easier, so why didn't they simply remove all C out of it?[21:09:38] *** chrisf_ is now known as chrisf[21:10:10] <metredigm> most languages are kind of based off of C[21:10:24] <Binero> yeah but none of those actually use the whole header bit the specification provides[21:10:33] <Binero> they only seem to make parsing harder[21:11:19] <Binero> The only way to automate generating bindings is by making a C parser, even from the XMLs[21:11:48] <Binero> you could still generate 90% of it automatically, but it'd require manually defining the types[21:12:01] *** rendar has joined ##OpenGL[21:12:11] <newguise1234> this is conjecture: most drivers and kernel related things are written in c, have restrictions with respect to recursion and such[21:12:28] <newguise1234> having the opengl interface be in c would allow direct "binding" to the drivers[21:12:46] <Binero> yeah[21:12:52] <Binero> But[21:13:16] <Binero> Why embed C code in the XML specification[21:13:31] <Binero> if they didn't creating C bindings would still be possible and as easy if not easier too[21:13:32] <roboman2444> you guys excited for glnext?[21:13:47] <Binero> Don't really get why they would do something like <types> C DEFINITIONS </types>[21:13:50] *** realz has joined ##OpenGL[21:13:59] <Yaniel> hopes high - for now[21:15:43] <roboman2444> i just want a more streamlined way of doin things[21:17:25] <XMPPwocky> Binero: actually, gl-rs (rust bindings) can be generated from those XML files[21:17:44] <Binero> I know but they are unsafe[21:18:27] <Binero> makes working with multiple contexts a pain[21:18:47] <XMPPwocky> well that's an opengl thing[21:18:53] *** Crehl has joined ##OpenGL[21:19:24] *** pizthewiz has quit IRC[21:19:26] <Binero> Well just moving the functions into a structure, and throwing the context with it would solve the issue[21:19:39] *** cden has quit IRC[21:19:45] *** tehrain has quit IRC[21:24:49] *** DMJC-M has quit IRC[21:26:56] <XMPPwocky> Binero: now you have to check on EVERY SINGLE OPENGL call[21:27:36] *** ragecryx has quit IRC[21:28:43] *** stefkos has quit IRC[21:29:13] <Binero> How do you mean?[21:30:06] <XMPPwocky> you'd have to check the context the structure represents[21:30:09] <XMPPwocky> and the current context[21:30:12] <Binero> No[21:30:13] <XMPPwocky> and see if they differ[21:30:17] <Binero> I just make an ActiveContext structure[21:30:28] <Binero> only the ActiveContext structure exposes the API[21:30:35] <XMPPwocky> Binero: you can write that on top of gl-rs, then, pretty easily[21:30:47] <Binero> I considered that[21:31:00] <Binero> But the thing is that I'd be wrapping around a wrapper around a wrapper[21:31:05] *** jubei has quit IRC[21:32:17] <XMPPwocky> well gl-rs isn't really a wrapper[21:32:19] <XMPPwocky> it's bindings[21:32:26] <Binero> the structure it generates[21:32:30] <Binero> I'd need to wrap around that[21:32:35] <Binero> to merge it with a context[21:32:39] <Binero> and then I'd need to wrap around that[21:32:44] <Binero> to generate an active context[21:32:57] <Binero> and every function call would go gl.active.context.binding[21:33:42] <Binero> I could create 'links' to the inner structure but that'd require another parser anyway[21:34:01] <Binero> also gl-rs won't work in rust 1.0 anymore[21:39:28] *** nido has joined ##OpenGL[21:39:52] *** Clinteger has quit IRC[21:41:57] <AbleBacon> is there any way to switch textures without doing multiple draw calls?[21:42:21] *** hexagoxel has joined ##OpenGL[21:43:40] <Yaniel> not exactly switch[21:44:06] <Yaniel> but you could use sampler objects and uniform buffers[21:44:11] <Yaniel> I guess[21:44:18] <Yaniel> or texture arrays[21:45:08] *** DrBoneStrong has joined ##OpenGL[21:46:04] <derhass> or bindless textures[21:46:34] <AbleBacon> hmmmmm[21:47:15] <AbleBacon> so i could have an array of texture IDs and have one texture ID for every 3 vertices?[21:47:27] <Yaniel> no[21:47:44] <Yaniel> texture arrays would be like a 3d texture[21:47:56] <AbleBacon> but i can pass the shader which texture to use, right?[21:48:06] <Yaniel> just without interpolation between layers[21:48:22] <AbleBacon> those words confuse me :([21:48:29] <AbleBacon> (new to 3D)[21:48:34] <Yaniel> so essentially a set of textures that you can index in your shader[21:49:55] <AbleBacon> https://www.opengl.org/sdk/docs/man/docbook4/xhtml/glActiveTexture.xml[21:49:59] <AbleBacon> are they "texture units"?[21:50:28] <Yaniel> what are?[21:50:47] <Yaniel> the things you canindex with array textures? no[21:51:15] <derhass> AbleBacon: you are confusing a few concepts here[21:52:34] <AbleBacon> so... uniforms you give names, right? so could i make an array of uniform names and pass one for each set of 3 vertices? and that would be the one that the shader would use?[21:53:10] <Yaniel> no[21:53:12] *** Garner has quit IRC[21:53:28] *** snakenerd has quit IRC[21:53:55] *** metredigm has quit IRC[21:55:53] <Bloodust> arrau texture is just an array of textures lol[22:03:50] *** snakenerd has joined ##OpenGL[22:04:26] *** b4b has quit IRC[22:06:55] *** gaganjyot has joined ##OpenGL[22:07:35] *** snakenerd has quit IRC[22:07:43] *** gaganjyot has quit IRC[22:08:11] *** gaganjyot has joined ##OpenGL[22:08:13] *** Waynes has quit IRC[22:09:26] *** Kane has quit IRC[22:10:32] *** gaganjyot has quit IRC[22:16:55] *** LifeBlood has joined ##OpenGL[22:17:53] *** DrBoneStrong1 has joined ##OpenGL[22:19:55] *** DrBoneStrong has quit IRC[22:21:16] *** foreignFunction has quit IRC[22:21:29] *** Garner has joined ##OpenGL[22:27:07] *** doev has quit IRC[22:31:39] <AbleBacon> so is it reasonable or even possible to design everything to use one draw call?[22:31:49] <AbleBacon> just load everything up and then draw it?[22:34:42] *** samrat has quit IRC[22:34:46] *** jubei has joined ##OpenGL[22:36:38] *** PasNox has quit IRC[22:38:33] <roboman2444> AbleBacon, kinda[22:38:38] *** HuntsMan has joined ##OpenGL[22:38:47] <roboman2444> if you dont need to change shader, texture, or blend modes[22:39:04] <roboman2444> so... likely need to use texture arrays for that, as well as instancing or similar[22:39:48] <roboman2444> you cant change depth tests either... but you can manually do the depth tests in shader if needed[22:39:59] <AbleBacon> and using texture arrays and instancing requires multiple draw calls?[22:40:12] <roboman2444> no[22:40:25] <roboman2444> they would allow you to use one draw calls with multiple textures[22:40:37] <AbleBacon> ah okay[22:40:39] <AbleBacon> thanks[22:40:56] <roboman2444> for example, someone might make a particle system that uses texture arrays/ texture atlases, and instances the particles[22:41:05] <roboman2444> which would only use one draw call[22:41:25] <roboman2444> but the particles are only using one shader, all doing the same blend and depth test operations[22:44:44] *** slidercrank has joined ##OpenGL[22:49:59] *** kuldeepdhaka has quit IRC[22:50:55] *** pauldachz has joined ##OpenGL[22:55:45] *** Mimnim has quit IRC[23:00:28] *** qeed has joined ##OpenGL[23:02:36] *** centrinia has joined ##OpenGL[23:07:20] *** Binero has quit IRC[23:07:32] *** Syzygy_ has joined ##OpenGL[23:09:40] *** Syzygy__ has quit IRC[23:12:19] *** mukunda_ has quit IRC[23:12:37] *** mukunda_ has joined ##OpenGL[23:13:18] *** DrBoneStrong1 has quit IRC[23:13:31] *** DrBoneStrong has joined ##OpenGL[23:20:32] *** bkre_ has quit IRC[23:20:44] *** bkre_ has joined ##OpenGL[23:21:57] *** pauldachs has joined ##OpenGL[23:22:58] *** pauldachz has quit IRC[23:27:53] *** sedeki has quit IRC[23:31:50] *** Clinteger has joined ##OpenGL[23:32:23] *** doev has joined ##OpenGL[23:34:09] *** doev has quit IRC[23:34:44] *** TunnelCat has joined ##OpenGL[23:38:00] *** ville has quit IRC[23:38:26] *** ville has joined ##OpenGL[23:39:39] *** tcsc has joined ##OpenGL[23:46:31] *** pizthewiz has joined ##OpenGL[23:50:48] *** pauldachs is now known as pauldachz[23:51:11] *** aretecode has joined ##OpenGL[23:53:35] *** DrBoneStrong has quit IRC[23:57:32] *** jubei has quit IRC[23:59:17] *** Misu has quit IRC[23:59:27] *** pa has quit IRC