January 20, 2009 
< | 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 | 31 | >
January 20, 2009 [00:00:56] *** amz has joined ##opengl[00:03:19] *** iammisc has joined ##OpenGL[00:05:20] *** calav3ra has quit IRC[00:06:18] *** phrosty has joined ##opengl[00:08:31] *** Eforen has joined ##opengl[00:17:31] *** Suprano has quit IRC[00:19:09] *** rnx has quit IRC[00:19:24] *** rnx has joined ##opengl[00:20:09] *** pfo has joined ##OpenGL[00:21:43] *** elite01 has quit IRC[00:22:49] *** kbotnen_ has quit IRC[00:22:55] *** jmd has quit IRC[00:26:58] *** LordMetroid has quit IRC[00:39:14] *** clayasaurus has joined ##OpenGL[00:41:30] *** mads- has quit IRC[00:41:46] *** aum_ has quit IRC[00:43:27] *** sparky_ has joined ##OpenGL[00:45:08] *** Amorphous has quit IRC[00:48:33] *** Amorphous has joined ##opengl[00:53:58] *** korff_home has quit IRC[01:00:47] *** sparky has quit IRC[01:07:44] *** [p]Zombie has joined ##OpenGL[01:08:27] <[p]Zombie> Anyone here who has worked with opengl in windows but without using VS to compile/link?[01:08:48] <[p]Zombie> opengl + glut i may add[01:11:29] *** b0000 has quit IRC[01:22:51] *** HuntsMan has joined ##opengl[01:30:27] *** Spkka has joined ##OpenGL[01:30:54] *** Baughn has quit IRC[01:31:05] *** [p]Zombie has left ##OpenGL[01:34:19] *** Baughn has joined ##OpenGL[01:35:43] *** rnx has quit IRC[01:37:32] *** rnx has joined ##opengl[01:39:15] *** bijoo_osdev has joined ##opengl[01:39:16] *** bijoo_appdev has joined ##OpenGL[01:52:15] *** johndoe has quit IRC[02:01:10] *** reprore_ has joined ##OpenGL[02:04:48] *** dvoid has quit IRC[02:06:59] *** reprore_ has quit IRC[02:10:50] *** x0rx0r has joined ##OpenGL[02:11:41] *** pietia has quit IRC[02:15:44] *** qeed has joined ##opengl[02:16:57] *** pwned has quit IRC[02:17:03] *** domino14 has joined ##OpenGL[02:20:53] *** Jernej has joined ##OpenGL[02:24:22] <domino14> can i put glLoadName inside a display list?[02:24:40] <domino14> i'd like to be able to select the polygons of a model individually[02:26:12] <domino14> oh great.. nevermind. the maximum depth of a name stack is way too small[02:27:06] <domino14> how else can i select an individual polygon in a display list?[02:32:53] *** GinoMan has quit IRC[02:33:43] *** JernejL has quit IRC[02:34:16] *** clayasaurus has left ##OpenGL[02:35:38] *** Walt has quit IRC[02:41:46] *** JernejL has joined ##OpenGL[02:42:37] *** GinoMan has joined ##OpenGL[02:47:08] *** Jernej has quit IRC[02:47:47] <MatthiasM> domino14: don't use select mode[02:50:56] <domino14> how should i do it?[02:51:08] <domino14> i want to be able to click on a model and select a polygon or point or something[02:51:25] *** Jernej has joined ##OpenGL[02:51:28] <yno> domino14: use color detection picking[02:52:08] <domino14> zat[02:53:41] <MatthiasM> use math to determine the hit object, use bounding boxes/spheres to speed up the test[02:53:42] <yno> write the scene with a own color for each object, then analyze the color of the pixel that your mouse pointed, and you give your object[02:54:26] <MatthiasM> GL select mode does the same - but without using bounding shapes[02:56:04] <domino14> but how do i use "math"[02:56:11] <domino14> like ray tracing?[02:56:31] <yno> notice that the advantage of the technique I explained is that it manages texture alpha, but rendering all the scene can be slower that using math[02:56:36] <ville> cast a ray and find with what it intersects with[02:56:43] <yno> than*[02:57:11] <domino14> cast ray should go from where to where[02:57:31] <MatthiasM> domino14: look at gluUnproject as a start[02:58:02] <domino14> whoa cool[02:58:11] <domino14> props[02:58:13] <MatthiasM> yno: not only may the rendering be an issue - but also the readback will wait until the rendering is done[02:58:29] <MatthiasM> and alpha blending might result in "wrong" colors[02:59:26] <yno> only alpha test, without blending[03:01:54] *** JernejL has quit IRC[03:07:14] *** iion has joined ##OpenGL[03:12:50] *** Tempoe has quit IRC[03:14:10] *** Tempoe has joined ##OpenGL[03:22:50] <domino14> how do i get a xyz window coordinate?[03:22:52] <domino14> windows are only xy[03:22:55] <domino14> for gluunproject[03:23:22] <mlucassmith> read it from the depth buffer after you've rendered the scene[03:23:53] *** iammisc has quit IRC[03:24:23] <MatthiasM> no - just use any value you like[03:24:32] <MatthiasM> domino14: don't read from the buffer[03:25:05] *** JernejL_ has joined ##OpenGL[03:25:10] <domino14> :([03:25:22] <domino14> i found a site that said[03:25:23] <domino14> You can obtain any window space Z value by reading the depth buffer with glReadPixels().[03:25:42] <MatthiasM> it's just a value used to transform - choose any value[03:26:02] <mlucassmith> he might misclick with a random z value, but he probably won't[03:26:05] <MatthiasM> the resulting vector will have the correct direction - normalize it to get unit length[03:26:24] <domino14> vector?[03:35:19] *** Spkka has quit IRC[03:36:47] *** MatthiasM has quit IRC[03:36:54] *** MatthiasM has joined ##opengl[03:38:13] *** Kasu has quit IRC[03:40:22] *** Jernej has quit IRC[03:57:19] *** domino14 has quit IRC[04:01:40] *** bijoo_osdev has quit IRC[04:01:40] *** bijoo_appdev has quit IRC[04:09:07] *** reprore_ has joined ##OpenGL[04:13:09] *** Aintaer has quit IRC[04:16:39] *** schwinn434 has joined ##OpenGL[04:17:55] *** e_roder has joined ##OpenGL[04:18:03] <e_roder> hey[04:18:34] <e_roder> does anybody have experience with shadow volumes using shaders?[04:19:13] <e_roder> i had them implemented with a ffp but when i switched to shaders i get strange effects[04:21:08] *** qeed has quit IRC[04:27:29] *** schwinn434 has quit IRC[04:34:00] <e_roder> the stenciled shadow is calculated when the scene is first rendered, but it won't move when the object or camera is moved[04:41:22] *** schwinn434 has joined ##OpenGL[04:58:01] *** schwinn434 has quit IRC[05:00:29] <sparky_> e_roder: what if you ask it nicely?[05:00:37] *** sparky_ is now known as sparky[05:00:46] <e_roder> Cg doesn't play nice[05:01:03] <e_roder> i've heard something about using a texture as a stencil buffer[05:01:13] <sparky> there is no difference[05:01:18] <sparky> whether you are using shaders or not[05:01:23] <e_roder> but first i guess i have to get textures to work with shaders[05:01:29] <e_roder> well the test works the same[05:01:54] <e_roder> but i think that the vertex shader transformations are not applied to the vertices before writing to the stencil buffer[05:02:20] <sparky> incorrect[05:02:32] <sparky> vertex shading occurs first[05:02:34] <e_roder> really?[05:02:42] <e_roder> well something is funky[05:02:53] <e_roder> because i'm drawing my shadow volume (with a wireframe)[05:03:12] <e_roder> even that is clearly behaving properly, but the stencil doesn't seem to be[05:03:30] <sparky> you just have some bug in your code, there is no difference between shadow volumes with and without custom shaders[05:03:39] *** jfroy|work has quit IRC[05:03:53] <e_roder> wanna take a look at it?[05:04:00] <sparky> not really :)[05:04:14] <e_roder> alright[05:04:23] <sparky> sorry, but this is my time off[05:04:29] <e_roder> fair enough[05:04:41] <e_roder> but thanks anyway for setting me straight[05:04:45] <sparky> np[05:05:08] <e_roder> ill say this though[05:05:14] <e_roder> i had shadow volumes working with a ffp[05:05:22] <e_roder> i switched to shaders[05:05:25] *** reprore_ has quit IRC[05:05:32] <e_roder> and got my geometry to move with the camera[05:05:38] <sparky> you just accidently messed something up when you switched to shaders[05:06:02] <e_roder> aren't shadow volumes just geometry?[05:06:15] <sparky> which is easy to do when dealing with something like opengl considering you can't really debug into the actual rendering pipeline[05:06:28] <e_roder> yeah[05:06:29] <e_roder> alright[05:06:45] <sparky> shadow volumes are geometry but you can still easily mess things up[05:07:03] <sparky> are you using Cg or CgFX?[05:07:11] <e_roder> Cg[05:07:48] <sparky> do you suspect the error is it doesn't update the stencil buffer or do you think the geometry itself gets messed up?[05:08:18] <tmccrary> how do you pronounce albedo?[05:08:38] <sparky> al-bee-do is how people usually say it[05:08:52] <e_roder> it's not updating the stencil buffer[05:09:01] <e_roder> what is it?[05:09:09] <sparky> e_roder: sounds like a setup bug to me exactly like I said[05:09:19] <e_roder> setup bug?[05:09:28] <sparky> yeah on your part[05:09:31] <e_roder> right[05:09:40] <e_roder> like in the pixel format descriptor?[05:09:46] <e_roder> i have stencil buffering enabled[05:10:02] <e_roder> hmmm[05:14:18] <e_roder> what about lighting with shaders?[05:14:28] <sparky> what about it[05:14:32] <e_roder> do they behave the same?[05:14:41] <e_roder> or do i have to implement them via the fragment shader/[05:14:42] <e_roder> ?[05:14:45] <sparky> I don't follow the question[05:14:53] <sparky> when you write shaders you write your own light[05:14:59] <e_roder> can i use opengl lighting with shaders[05:15:00] <e_roder> so no[05:15:01] <e_roder> ok[05:15:07] <sparky> the answer is no[05:15:09] <e_roder> i think that's causing part of the problem[05:16:14] <e_roder> wow i kinda got it to work[05:16:16] <e_roder> thanks![05:16:32] <sparky> first of all the built-in lighting takes place in the vertex shader[05:16:45] *** zacs7 has joined ##opengl[05:16:45] *** tmccrary has quit IRC[05:18:09] <sparky> that's great[05:23:11] *** attacke has left ##OpenGL[05:34:50] *** jfroy has joined ##OpenGL[05:39:28] *** msh07 has joined ##OpenGL[05:40:06] *** msh07 has quit IRC[06:01:40] *** x0rx0r has left ##OpenGL[06:19:01] *** amz has quit IRC[06:22:00] *** Rolenun has quit IRC[06:23:56] *** schwinn434 has joined ##OpenGL[06:28:47] *** schwinn434 has quit IRC[06:29:07] *** schwinn434 has joined ##OpenGL[06:31:23] *** WhatAHam has quit IRC[06:31:36] *** WhatAHam has joined ##OpenGL[06:35:39] *** schwinn434 has quit IRC[06:50:16] *** yno has quit IRC[06:59:17] *** ol1veira_ has joined ##OpenGL[07:03:57] *** sparky_ has joined ##OpenGL[07:14:32] *** Entelin has quit IRC[07:15:25] *** korff_home has joined ##OpenGL[07:17:03] *** sparky has quit IRC[07:37:10] *** scai has joined ##opengl[07:52:53] *** scai has left ##opengl[08:01:00] *** pietia has joined ##OpenGL[08:29:12] *** kbotnen has joined ##OpenGL[08:34:18] *** boghog has quit IRC[08:37:59] *** jmd has joined ##opengl[08:41:48] <jmd> I'm having problems with gdk_gl_config_new ; It often returns a config without a accumulation buffer, even though glxinfo says there is a FBConfig with an accumulatioin buffer.[08:41:56] *** zommi has joined ##OpenGL[08:42:05] *** e_roder has quit IRC[08:42:49] *** kbotnen_ has joined ##OpenGL[08:43:14] *** kbotnen has quit IRC[08:44:18] *** vade has quit IRC[08:46:26] *** realHans has joined ##OpenGL[08:46:48] *** kbotnen_ has quit IRC[08:52:54] *** realHans has left ##OpenGL[09:09:13] *** Bollinger has joined ##OpenGL[09:17:57] *** UUncia has joined ##OpenGL[09:20:29] *** [AD]Turbo has joined ##OpenGL[09:20:52] <[AD]Turbo> yo[09:21:08] <zacs7> yo[09:24:00] *** axleAx has joined ##OpenGL[09:26:25] <axleAx> If am making a game etc, opengl can produce the graphics of a game such as half-life 2?[09:27:29] <zacs7> yes[09:27:31] <Spark> and no[09:27:45] <Spark> if you're asking if it can do what d3d9 can do[09:27:49] <Spark> the answer is probably yes[09:27:55] <zacs7> a bit of both ;)[09:28:15] <zacs7> Spark: visually it can[09:28:25] <Spark> however to implement a graphics engine of that quality would take a lot of work beyond just learning and calling into opengl[09:28:39] <Spark> a lot of work that will be written by you and will execute on the cpu[09:30:00] <Spark> if you want to minimise the amount of work you have to do, you could consider using a more highlevel engine like ogre or ihrlicht[09:30:05] <zacs7> and if you have to ask that then you have a long way to go[09:30:21] <zacs7> or just work off the ioquake3 engine[09:30:27] *** axLe_REY has joined ##OpenGL[09:30:50] <Spark> yeah i mean engines like hl2 are developed by a large number of experts over a long period of time[09:31:03] <zacs7> very long[09:31:47] *** axleAx has quit IRC[09:31:57] <axLe_REY> So opengl is used for the basic graphics? (eg. Mario) and d3d9 for the complex? What factor would help decide[09:32:16] <zacs7> axLe_REY: not at all[09:32:53] <Spark> d3d9 and gl are mostly equivalent[09:32:53] <zacs7> The main differences are, dx has large commercial backing[09:33:15] <Spark> in my experience of implementations, dx is much less friendly and a bit faster[09:33:20] <Spark> gl implementations vary a lot in quality[09:33:31] <axLe_REY> More money, you mean?[09:33:58] <zacs7> I guess[09:34:03] <Spark> gl's design is a bit more sane[09:34:08] <Spark> and glsl is easier to use i'd argue[09:34:39] <Spark> gl is all about providing a nice interface, d3d9 is all about getting something out there ASAP that people can use to write 3d apps[09:35:15] <zacs7> gl ftw[09:35:47] <Spark> i'm currently aiming for gl on linux, d3d9 on win32[09:35:49] <axLe_REY> So if i coded from 9am to 6pm non stop how long could it take to get a hl2 game engine?[09:35:59] <axLe_REY> 2yrs?[09:36:00] <Spark> 5 years maybe[09:36:28] <Spark> oh game engine[09:36:33] <Spark> i was only talking about graphics[09:36:44] <Spark> the other 75% of the game would take another 10 years of your time[09:36:44] <zacs7> probably close to 10[09:36:47] <axLe_REY> And a decent one (like for vice city)?[09:36:54] <zacs7> 7 or 8 years[09:36:57] <Spark> heh i'm actually writing a gta clone[09:37:24] <zacs7> In C?[09:37:31] <axLe_REY> Yea[09:37:41] <Spark> c++[09:37:57] <Spark> http://spark.woaf.net/bullet/evo.avi[09:38:03] <zacs7> cool :P[09:38:14] <Spark> the world is taken from SA[09:39:16] <zacs7> Cool, nice textures[09:39:21] <zacs7> ;)[09:39:55] <Spark> if only they weren't all stolen[09:40:15] <zacs7> Spark: it looks awesome. I'll keep an eye on it ;)[09:40:28] <Spark> progress is slow because it's just a hobby[09:40:29] *** axleAx has joined ##OpenGL[09:40:33] <Spark> it's open source though[09:40:43] <axleAx> Btw, i got two books, c and c++, and want to code a game, which should i study on first[09:41:12] <zacs7> and/or[09:41:22] <axleAx> Gta clone, what are the changes youv introduced?[09:42:10] *** axleAx is now known as Axl3_R3y[09:42:12] <Spark> there's not much gameplay so far[09:42:18] <Spark> in fact there's no gameplay[09:42:22] <Spark> i've been doing this 2 years[09:42:30] <Spark> perhaps longer i can't remember[09:42:47] <Axl3_R3y> Your Project page?[09:43:02] <Spark> there isn't one[09:43:48] <Axl3_R3y> When you make one, ill try help[09:43:48] *** axLe_REY has quit IRC[09:43:55] <zacs7> lolz[09:43:59] <Spark> i'm hoping to get some community going[09:44:00] <Spark> the keystone of it is this massive scripting framework[09:44:09] <zacs7> Sigh lua :([09:44:11] <Spark> i figured a game like gta has a lot of small gameplay elements that are mostly independent[09:44:34] <Spark> so this is perfect for a large number of people to put a small amount of work in each[09:44:43] <zacs7> Spark: I'd be interested in some sort of community[09:45:14] <zacs7> At least move it to google code or sf.net[09:45:27] <Spark> it's on sf at the moment, but just as a convenient place to dump code[09:45:30] <zacs7> does it have a d3d renderer?[09:45:34] <Spark> it's using ogre[09:45:40] <zacs7> :o[09:45:53] <Spark> suprised?[09:46:12] <Spark> the d3d9 backend has some bug that i haven't teased out yet[09:46:14] <zacs7> nah[09:46:16] <Axl3_R3y> I noticed vicecity, is just a copy everywhere you go! The people all walk the same, look the same, buildings are the same, cars damage the same etc,[09:46:35] <zacs7> screw d3d support[09:46:37] <Spark> it just crashes with some exception to do with not having enough memory for a new index/vertex/texture buffer[09:46:44] <Spark> however there is enough memory, pix tells me so[09:46:59] <Spark> yeah well i'm usually on linux which is why it hasn't been a priority[09:47:08] <Spark> but it will be necessary for the success of the project so needs to be fixed some time[09:47:39] *** kenws has joined ##OpenGL[09:47:42] <zacs7> And not using stolen data[09:47:50] <zacs7> ;)[09:47:57] <Spark> i'm not sure of the legality to be honest[09:48:12] <Spark> the way i have it set up is as follows[09:48:17] <Spark> there is an engine, with its own formats for things[09:48:32] <Spark> and a convertor that looks in a gta sa directory and compiles all that game data into my own formats[09:48:49] <Spark> obviously the engine by itself is completely legal[09:48:55] <Spark> but i think the converter should be too[09:49:01] <Spark> it's just a reader for some proprietory formats[09:49:14] <Spark> obviously using the converter breaks the EULA of gta[09:49:40] <Spark> but i think there are not any serious implications to that[09:50:04] <Spark> obviously i won't distributed any files that are taken from or derived from copyright gta files[09:50:08] <Spark> *distribute[09:50:08] <zacs7> but distributing the data is bad[09:50:16] <Axl3_R3y> What ideas have you in mind 4 the game Spark? More violence, cars?[09:50:17] <Spark> yeah you won't be able to play on the gta map unless you own gta[09:50:19] <zacs7> good[09:50:46] <Spark> there is some gta-community stuff that i could use with permission from the authors[09:50:51] <Spark> something called myriad islands[09:50:57] <Spark> which is a new world[09:51:01] <zacs7> used that[09:51:03] <Spark> but i think it still reuses a lot of gta stuff[09:51:06] <zacs7> broken mostly ;)[09:51:08] <Spark> heh[09:51:35] <Spark> also it might be possible to get some people to make a city for it[09:51:39] <Spark> once the engine is proven[09:51:50] <Spark> but the gta map is nice and has character[09:51:58] <Spark> i don't want it ending up all surreal and stupid like second life[09:52:05] *** sohail has quit IRC[09:52:22] <zacs7> hehe[09:52:35] <Spark> Axl3_R3y: i'd like at least the basic gameplay elements - walking, running, climbing, driving, swimming, boating, flying, parachuting, blowing stuff up, killing people, etc[09:53:05] <Spark> at the moment i have almost finished driving[09:53:15] <Spark> after that i will work on walking/running and possibly climbing[09:53:27] <Spark> and then probably shooting and blowing up the cars[09:53:30] <Spark> since that seems like fun[09:53:50] <Spark> oh, and some sort of multiplayer mode is high up my list[09:54:05] <Spark> i think i should probably start doing that sooner rather htan later since it's hard to shoehorn it into an existing single player game[09:54:22] <Spark> i'd like to be able to do something like sa-mp[09:54:54] <Axl3_R3y> Hmm, multiplayer (where everyone would join in place of a citizen) that gta would be chaotic[09:55:14] <Spark> there would probably be no NPCs and only a handful of players[09:55:18] <zacs7> it's too hard[09:55:18] <zacs7> although gigabit lan...[09:55:20] *** iion has quit IRC[09:55:31] <Axl3_R3y> So what would you name it[09:55:37] <Spark> it's called grit[09:55:46] <Spark> i was going to call it "gnu theft auto" but chickened out[09:56:04] *** belou has joined ##OpenGL[09:56:30] <zacs7> hehe good[09:57:41] <Axl3_R3y> Nice[09:57:46] *** sparky has joined ##OpenGL[10:02:03] <Axl3_R3y> Still i like the 'gnu theft auto' name *opensource[10:02:05] <Axl3_R3y> Still i like the 'gnu theft auto' name *opensource[10:06:02] *** Axl3_R3y has left ##OpenGL[10:07:01] *** neoneye has joined ##OpenGL[10:07:20] *** sparky_ has quit IRC[10:12:45] *** sohail has joined ##OpenGL[10:18:02] *** Osirus has joined ##OpenGL[10:18:05] *** pietia has quit IRC[10:19:56] *** Osirus has quit IRC[10:20:24] *** Osirus has joined ##OpenGL[10:26:33] *** zwiep` has quit IRC[10:26:40] *** zwiep` has joined ##opengl[10:27:02] *** Osirus has quit IRC[10:28:18] *** Osirus has joined ##OpenGL[10:32:32] *** notsonerdysunny has joined ##OpenGL[10:32:56] <notsonerdysunny> Hello .. how would one catch double-click events in opengl?[10:33:28] <bobbens> opengl doesn't specify anything about input, it's only graphics[10:33:30] <rnx> opengl does graphics ... nothing else[10:33:35] <notsonerdysunny> or is it the job of the windowing system?[10:33:41] <notsonerdysunny> oh ic[10:33:45] <bobbens> this is the job of sdl, glut or whatever you're using[10:34:41] <notsonerdysunny> I am actually maintaining a legacy code written X/Motif lib[10:35:01] <notsonerdysunny> would any body know how to catch the double click event then?[10:35:33] <notsonerdysunny> I meant written with X/Motif Library .. so you think my X/Motif library should handle this?[10:36:05] <bobbens> check to see if it lets you catch double click event per se, otherwise you'll have to handle two single clicks and check time offset if it's within a threshold and then generate your double click event[10:36:14] <bobbens> i haven't done X/Motif programming so I have no idea[10:36:17] <bobbens> read their documentation[10:40:36] *** jmd has quit IRC[10:40:45] <notsonerdysunny> Thanks bobbens[10:42:16] *** Nescafe has joined ##OpenGL[10:58:32] *** Eforen has quit IRC[10:59:10] *** Eforen has joined ##opengl[11:00:14] *** Eforen has quit IRC[11:00:54] *** Ingenu has joined ##OpenGL[11:14:30] *** rabbit- has joined ##OpenGL[11:20:53] <quicksilver> patapon, locoroco, rolando and similar games have smoothly rendered 2D curves[11:20:58] <quicksilver> I wonder if that's MSAA[11:21:08] <quicksilver> or if it's some special purpose curve smoothing algorithm.[11:23:19] <acetoxy> Multiple Sclerosis Association of America?[11:24:30] <quicksilver> multisampling anti aliasing[11:24:32] *** dvoid has joined ##OpenGL[11:24:49] <acetoxy> ah[11:27:13] <zacs7> is not msaa a special purpose algorithm?[11:35:48] *** boghog has joined ##opengl[11:37:05] *** bubu` has joined ##OpenGL[11:38:31] <quicksilver> zacs7: it's a kind of adaptive supersampling where you only actually do the actual samples if you think you need to.[11:38:50] <quicksilver> I think it's triggered by the depth buffer - more samples if the depth buffer changes suddenly.[11:39:25] <zacs7> ahh I see[11:39:47] <Spark> one thing i don't get about these AA approaches (other than FSAA which is braindead)[11:39:53] <Spark> so you want to make the edges of triangles smooth[11:40:04] <Spark> how can you do that without having to use alpha and scene blending[11:40:09] <Spark> which means z sorting and all that crap[11:40:22] <zacs7> Spark: that's easy use a circle ;)[11:40:29] <Spark> hmm?[11:41:09] <zacs7> Triangle with smooth edges ;)[11:43:04] <quicksilver> we need RTFM_FTW or someone to wake up and tell us the answers.[11:43:22] <quicksilver> I was sure I understood the answer to Spark's question but now I think about it, I can't construct the reasoning ;)[11:51:32] *** zacs7 has quit IRC[11:52:26] *** JernejL_ has quit IRC[11:55:54] *** predaeus has joined ##opengl[12:20:53] *** Suprano has joined ##OpenGL[12:25:03] *** sparky_ has joined ##OpenGL[12:28:25] <Ingenu> what's the deal with AA ?[12:29:37] *** kaputt has quit IRC[12:30:45] <Ingenu> what's the question about AA ?[12:32:08] <Spark> Ingenu: what i said[12:36:12] <quicksilver> Ingenu: Spark's question was how you can make the edges of a triangle smooth over a distant background without depth sorting.[12:36:24] *** sparky has quit IRC[12:36:37] <quicksilver> Ingenu: My question was, what are good techniques for smooth (anti-aliased) 2D curve drawing.[12:38:35] *** scai has joined ##opengl[12:41:04] *** Spkka has joined ##OpenGL[12:41:16] *** Madsy has joined ##OpenGL[12:41:25] <Ingenu> MSAA does edge antialiasing[12:41:31] <Ingenu> that's how it works[12:42:05] <Madsy> MSAA? The lookup-table thing which sucks? :-)[12:42:16] <quicksilver> Ingenu: but if the foreground is drawn first[12:42:24] <quicksilver> then isn't it "too late" to blend it against the background[12:42:24] *** rabbit- has quit IRC[12:42:29] <quicksilver> just like any blending-based solution?[12:46:15] <Ingenu> Multi Sampling Anti Aliasing[12:46:31] <Ingenu> it's widely supported[12:46:51] <Ingenu> MSAA doesn't "blend"[12:47:08] <Ingenu> it detects polygon edge by having more than a single sample by pixel[12:47:08] <quicksilver> Ingenu: do you understand the question Spark and I are asking?[12:47:52] <quicksilver> its hardwired into the primitives? So primitives always generate more samples along their edges?[12:47:59] <quicksilver> or its based on something else like depth buffer changes?[12:48:08] <Ingenu> they generate more samples on every pixel[12:48:15] <Ingenu> but it doesn't have any effect beside the edges[12:48:25] <Ingenu> since all fragments have the same color everywhere but on edges[12:48:37] <Ingenu> depth buffer[12:48:42] <quicksilver> I thought the whole point of MSAA was to only bother with the extra samples at edges[12:48:49] <quicksilver> otherwise it's just FSAA isn't it?[12:48:56] <Ingenu> so to speak[12:49:08] <Ingenu> MSAA is FSAA[12:49:16] <Ingenu> it's just not Super Sampling[12:49:28] <Ingenu> SSAA & MSAA are FSAA[12:49:37] <Ingenu> (both)[12:49:55] <quicksilver> OK, I think I'm use the words wrongly, sorry.[12:50:03] <quicksilver> SSAA is blindly supersampling every single pixel, right?[12:50:14] <quicksilver> so you have a fixed ratio of (say) 4 fragments per pixel?[12:50:21] <Ingenu> yes[12:50:40] <quicksilver> Now MSAA is supposed to be smarter[12:50:42] <Ingenu> in SSAA you evaluate each pixel color then you average pixels together to get the final image[12:50:47] * quicksilver nods[12:51:02] <quicksilver> SSAA can be thought of as rendering ot a higher resolution[12:51:09] <quicksilver> and them subsampling that to get your final frame[12:51:10] <quicksilver> right?[12:51:23] <quicksilver> which is the classic antialiasing technique used by many offline techniques.[12:51:40] <Ingenu> yes[12:51:46] <Ingenu> that is exactly that[12:51:51] <Ingenu> it's not "thinking of" ^^[12:52:04] *** wisey has joined ##OpenGL[12:52:12] * quicksilver nods[12:52:14] <Ingenu> you do render to higher resolution then downsample to the screen resolution[12:52:21] <quicksilver> OK, so let's put SSAA to one side now.[12:52:35] <quicksilver> What is "clever" about MSAA? At what point does it 'decide' to generate more fragments?[12:52:55] <Ingenu> the difference with MSAA is that MSAA does only evaluate a fragment color if there's a reason to[12:53:12] <Ingenu> if all the fragments of a pixel are in the same polygon, only one color is computed[12:53:40] <Ingenu> if the all belong to different triangles, then up to n samples are computed (where n is the number of samples you asked for)[12:53:55] <Ingenu> the/they[12:54:11] <quicksilver> Hmm.[12:54:26] <quicksilver> does this make everythign two-pass in some sense?[12:54:39] <quicksilver> in the first pass, all the fragments are generated, but the fragment shaders are not run yet[12:54:52] <quicksilver> and in the second pass, fragment shaders are run for some subset of these fragments?[12:55:14] <Ingenu> no[12:55:49] <Ingenu> samples depths are compared, a mask is generated per primitive and a color is computed if the mask isn't null (ie at least one fragment passes the depth test)[12:56:18] <Ingenu> so it's like the usual deal, except if tests more than one sample per pixel[12:56:52] *** dvoid has quit IRC[12:57:16] <quicksilver> Ingenu: but depths are computed by the fragment shader aren't they?[12:57:21] <Ingenu> the thing is that, if you have 4x MSAA and an edge on a pixel, in which case one primitive takes 2 samples and the other 2 samples[12:57:25] <Ingenu> you only compute 2 colors[12:57:32] <quicksilver> Ingenu: so you have to run the fragment shader for each sample, before you know the depths?[12:57:48] <Ingenu> (ie run two fragment shaders )[12:57:57] <Ingenu> instead of 4 with SSAA[12:58:28] <Ingenu> no, you do like usual, depth test first, run fragment shader later (except in some cases)[12:58:55] <Ingenu> There's a nice paper about the order of the tests depending on the alpha and stencil tests written by Humus for ATi[12:58:55] <quicksilver> I thought the depth value was determined by what the fragment shader put into gl_FragDepth[12:59:01] <Ingenu> yep[12:59:10] <Ingenu> that's one case in which you can't depth test early[12:59:11] <quicksilver> so how do oyu know the depth value before you run the fragment shader?[12:59:15] <quicksilver> Ah.[12:59:27] <quicksilver> so this technique only works for fragment shaders which don't mess with the depth value?[12:59:27] <Ingenu> but usuallly you don't write that, you leave it auto filled[12:59:33] <Ingenu> so the hardware can do clever tricks[12:59:44] <Ingenu> no[12:59:44] <quicksilver> so the shader compiler has to "notice" that the shader doesn't change gl_FragDepth[12:59:48] <Ingenu> it works for them all[12:59:57] <Ingenu> it's just that you don't save fragment shader power[12:59:57] <quicksilver> btu it's faster if the shader doesn't write to fragDepth[13:00:04] * quicksilver nods[13:00:10] <quicksilver> OK, that is one of the things I didn't understand.[13:00:29] <quicksilver> so the driver can notice that a particular fragment shader doesn't touch fragDepth and be cleverer in this case?[13:02:52] <Ingenu> of course[13:02:56] <Ingenu> it does that all the time[13:03:00] * quicksilver nods[13:03:05] <quicksilver> Thanks.[13:03:05] <Ingenu> the compiler does also optimize shaders to some extent[13:03:09] <quicksilver> Next part I don't understand:[13:03:16] <quicksilver> suppose a draw a blue quad in the background.[13:03:34] <quicksilver> this has all been processed and rendered to pixels and is already in the color buffer.[13:03:44] <quicksilver> now I draw a red triangle using MSAA[13:03:59] <quicksilver> in one particular pixel, the primitve only covers part of the pixel[13:04:06] <quicksilver> by what mechanism does the red end up 'blended' with the blue?[13:04:08] *** scai has left ##opengl[13:05:39] *** johndoe has joined ##opengl[13:08:30] <Ingenu> can't find that ATi pdf[13:08:33] <Ingenu> that's annoying[13:10:00] <Ingenu> nop[13:10:09] <Ingenu> the buffer stores samples not pixels[13:10:22] <Ingenu> so 4x MSAA = 4 times bigger ^^[13:10:49] <Ingenu> it's the ROP that does merge fragments into pixels[13:14:53] <Ingenu> and it's just a weighted average[13:15:10] *** groton has joined ##OpenGL[13:15:43] <quicksilver> Ingenu: AH![13:15:49] <quicksilver> Ingenu: so you really do store 4x the data![13:16:01] <quicksilver> Ingenu: it's just sometimes you save time by storing the same bytes 4 times[13:16:08] <quicksilver> instead of calculating 4 different colours[13:16:09] <quicksilver> right?[13:19:49] *** f00bar80 has quit IRC[13:19:56] *** notsonerdysunny has quit IRC[13:20:34] <Ingenu> yep[13:20:47] <Ingenu> still a huge saving[13:20:50] <quicksilver> Ingenu: finally I understand.[13:20:52] <quicksilver> thank you so much.[13:20:56] <quicksilver> Obvious in retrospect.[13:21:01] *** rnx has left ##opengl[13:21:02] <quicksilver> but that's bugged me for ages :)[13:21:55] <Ingenu> ^^[13:22:22] <Ingenu> MSAA have a little drawback, that's why the "centroid" word was added to GLSL[13:22:39] <Ingenu> you may sample your color outside of your primitive[13:22:46] <Ingenu> since you sample at the center of the pixel[13:22:56] <Ingenu> and your primitive may very well not cover it[13:23:10] *** UUncia has quit IRC[13:23:14] <Ingenu> there's an article about that on OpenGL.org[13:24:25] <Ingenu> http://www.opengl.org/pipeline/article/vol003_6/[13:26:16] <quicksilver> Ingenu: good article. Bookmarked to read over lunch ;) thanks.[13:33:12] *** doub|work has joined ##opengl[13:34:41] *** yno has joined ##OpenGL[13:34:53] <yno> hi[13:35:34] <quicksilver> Ingenu: Well i will try my grand smooth 2D rendering ideas on MSAA to start with.[13:35:47] <quicksilver> Ingenu: and I will experiment with whether it makes more sense to do my own custom AA implementation.[13:38:35] <Madsy> Ingenu: Yep. Great article.[13:39:44] <yno> does glEnable(GL_TEXTURE_*) only acts on the activated texture unit?[13:40:16] <doub|work> yes[13:40:28] <yno> ok tanks :)[13:40:38] <yno> +h[13:41:09] <Ingenu> ah found back the ATi paper I was looking for : http://developer.amd.com/media/gpu_assets/Depth_in-depth.pdf[13:42:28] *** HuntsMan has quit IRC[13:44:29] <quicksilver> Ingenu: thanks. added to lunchtime reading list.[13:44:35] <quicksilver> going to be a long lunch![13:46:56] *** LtJax has joined ##opengl[13:48:56] *** doub has quit IRC[13:48:56] *** doub|work is now known as doub[13:49:43] <quicksilver> Hmm. One 2D AA technique : http://people.csail.mit.edu/ericchan/articles/prefilter/[13:49:57] <quicksilver> although I'm slightly wary of techniques which use 'blurring' instead of antialiasing.[13:50:08] <quicksilver> I guess it can work OK if you get the blur width right though.[13:51:08] <acetoxy> Oh, thanks for the link[13:51:19] <quicksilver> acetoxy: which one?[13:52:15] <acetoxy> This one: http://people.csail.mit.edu/ericchan/articles/prefilter/[13:52:36] <quicksilver> ah, you're interested in 2D AA too? ;)[13:53:46] <acetoxy> A little bit, maybe. I might need it someday :)[13:58:32] * Spark finishes reading the scrollback[13:58:39] <Spark> yeah that answered my question rather well :)[13:59:56] *** elite01 has joined ##opengl[14:00:05] <Spark> so how can you do that "manually"[14:00:10] <quicksilver> Spark: yeah, I even got it into my thick head in the end ;)[14:00:40] <Spark> is it possible to write a fragment shader that somehow knows whether or not it needs to calculate the colour for this fragment?[14:01:11] <quicksilver> fragment shaders are pretty restricted in what they are allowed to "read".[14:01:23] <Spark> yeah that's what i thought[14:01:23] <quicksilver> it would have to be somehow setup by the vertex shader[14:01:46] <Spark> could you render the mask to a texture[14:01:47] <quicksilver> perhaps if the vertex shader sets up texture coords over a B&W texture which has a straight edge in it[14:01:49] <Spark> in a prepass[14:01:57] <quicksilver> then the fragment shader can sample from that[14:01:57] <Spark> but i doubt that would be worth the extra cpu overhead[14:02:03] <quicksilver> if the value is < 0.5, then discard[14:02:09] <quicksilver> (because you're outside the line)[14:02:24] <quicksilver> I'm not sure how much time "discard" really saves though.[14:02:29] <Spark> hmm[14:02:37] <quicksilver> you've already paid the cost of setting up the fragment shader and setting up its inputs.[14:02:48] <quicksilver> presumably it depends how complex the part you're skipping is :)[14:03:25] <Spark> yeah but if it's not very complicated you may as well do basic FSAA[14:04:08] <Spark> SSAA, i should say[14:08:58] *** johndoe has quit IRC[14:12:11] *** Suprano has quit IRC[14:19:07] *** Suprano has joined ##OpenGL[14:23:04] *** eXtronuS_ has joined ##OpenGL[14:24:50] *** johndoe has joined ##opengl[14:26:45] *** Aintaer has joined ##OpenGL[14:27:04] *** doub has quit IRC[14:27:59] *** johndoe has quit IRC[14:34:23] *** eXtronuS_ has quit IRC[14:34:32] *** eXtronuS_ has joined ##OpenGL[14:37:56] *** ewn has joined ##OpenGL[14:41:49] *** vade has joined ##OpenGL[14:42:02] <Ingenu> discard saving depends on your coherency[14:42:26] <Ingenu> the GPU are executing the same instructions on a group of 4 (usually) fragments[14:42:54] <Ingenu> if branching leads to different execution, both branches are taken, and some results are discarded[14:43:07] <Ingenu> so you pay the price of both branches, and not one[14:43:29] <Ingenu> so I'd guess your discard is conditional, which means that it needs be coherent too[14:44:55] <Ingenu> http://sa08.idav.ucdavis.edu/[14:45:04] *** HuntsMan has joined ##opengl[14:45:08] <Ingenu> Course Note 2 might be of interest to get an idea of what's going on inside the GPU[14:57:26] *** eXtronuS_ has quit IRC[15:04:56] *** Suprano has quit IRC[15:21:42] *** phenom9600 has joined ##OpenGL[15:23:27] *** loonysalmon has joined ##OpenGL[15:23:54] *** loonysalmon has left ##OpenGL[15:26:24] *** kbotnen has joined ##OpenGL[15:28:00] *** BenPa85 has joined ##opengl[15:31:29] *** phenom9600 has quit IRC[15:41:50] *** pietia has joined ##OpenGL[15:45:30] *** vade has quit IRC[15:48:37] *** Suprano has joined ##OpenGL[15:49:27] *** dvoid has joined ##OpenGL[15:49:55] *** LordMetroid has joined ##OpenGL[15:57:12] *** nytejade has quit IRC[16:00:16] *** eXtronuS_ has joined ##OpenGL[16:09:26] *** m4ggus has joined ##opengl[16:13:07] *** nywles has joined ##OpenGL[16:13:23] *** kbotnen has quit IRC[16:33:39] *** Blaay has joined ##OpenGL[16:34:30] *** johndoe has joined ##opengl[16:35:23] *** scai has joined ##opengl[16:37:48] *** vade has joined ##OpenGL[16:51:42] *** eXtronuS_ has quit IRC[16:55:40] *** elite01 has quit IRC[17:01:16] *** LtJax has quit IRC[17:07:12] *** GX has joined ##OpenGL[17:08:40] *** LtJax has joined ##OpenGL[17:17:21] *** kbotnen has joined ##OpenGL[17:23:02] *** geocalc has quit IRC[17:23:37] *** geocalc has joined ##opengl[17:28:27] *** GuShH has quit IRC[17:30:53] *** ljungk has joined ##OpenGL[17:31:10] *** UUncia has joined ##OpenGL[17:32:49] *** paul424 has joined ##OpenGL[17:35:21] *** Blaay has quit IRC[17:50:40] <BenPa85> hi guys, I use the following texture coordinates: "1.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.0f, 0.0f, 0.0f" but the image is flipped vertically, what must I use to flipp it?[17:50:56] *** kenws has quit IRC[17:52:03] <dindinx> BenPa85: 1,0,0,0,1,1,0,1[17:52:30] *** [AD]Turbo has quit IRC[17:53:22] *** pwned has joined ##opengl[17:54:05] <quicksilver> Things That Really Piss Me Off About OpenGL Code Examples #42 : all those stupid ".0f" s[17:54:19] <Madsy> heheh[17:54:19] <mlucassmith> That's not OpenGL[17:54:34] <Madsy> That's more a C syntax issue, indeed[17:55:03] <Madsy> quicksilver: It's either that or a lot of implicit type conversion errors.[17:56:45] <quicksilver> "1" is a valid float literal in C.[17:56:51] <quicksilver> isn't it?[17:57:26] <dindinx> quicksilver: no, it is an interger literal, but the conversion is implicit.[17:58:02] *** paul424 has quit IRC[17:58:17] <quicksilver> int main() { float x = 1; return 0; }[17:58:23] <quicksilver> compiles with no warnings for me[17:58:30] <dindinx> yes.[17:58:31] <quicksilver> no implicit type conversions error or warning.[17:58:41] <quicksilver> (well there is a warning about unused 'x' actually ;)[17:58:51] <dindinx> because the conversion is implicite, why would it warn about it?[17:59:00] <quicksilver> so what is the point of the ".0f" shit, then?[17:59:09] <dindinx> none :)[17:59:12] <quicksilver> as I said.[17:59:14] <quicksilver> thanks.[17:59:59] <dindinx> well, tell the reader that the value is meant to be a float.[18:00:32] *** LordMetroid has quit IRC[18:00:36] <dindinx> it is necessary in float x = 1/5.f; though. (float = 1/5; would result in x being 0)[18:00:55] *** X-Scale2 has joined ##OpenGL[18:01:18] <quicksilver> dindinx: but it's not necessary in glTranslatef (1,1,1)[18:01:25] <quicksilver> dindinx: which is where I see it most/where it annoys me most :)[18:01:42] <quicksilver> although I suppose it could be annoying if you added /5 later and it didn't do what you expected.[18:02:57] *** BenPa85 has quit IRC[18:08:53] *** kbotnen has quit IRC[18:08:56] *** ewn has quit IRC[18:09:26] *** XT95_ has joined ##OpenGL[18:09:51] *** gusnan has joined ##OpenGL[18:12:38] *** a-stray-cat has joined ##OpenGL[18:12:43] <groton> quicksilver, nothing to think today?[18:13:43] <quicksilver> groton: eh?[18:14:27] <groton> quicksilver, all that hating for the .0f :P[18:16:13] <quicksilver> groton: I'm always full of hate.[18:16:20] <quicksilver> groton: the hate keeps me sharp.[18:16:25] <quicksilver> stop hating, and I fall asleep.[18:17:08] <groton> oh, i hate you :P[18:19:13] *** NorthStar has quit IRC[18:19:16] <quicksilver> thanks. That helps a bit.[18:23:36] *** JernejL has joined ##OpenGL[18:23:53] *** Osirus has quit IRC[18:24:33] *** belou has quit IRC[18:28:52] *** groton has quit IRC[18:28:58] *** zommi has quit IRC[18:30:54] *** jfroy has quit IRC[18:43:50] *** LordMetroid has joined ##OpenGL[18:44:02] *** AlastairLynn has joined ##opengl[18:45:57] *** UUncia has quit IRC[18:50:07] *** jfroy|work has joined ##OpenGL[18:57:25] *** predaeus has quit IRC[18:57:47] *** predaeus has joined ##opengl[19:15:26] *** Hypnosekroete has quit IRC[19:15:40] *** PsiOmegaDelta has joined ##OpenGL[19:16:50] *** PsiOmega has quit IRC[19:16:51] *** Spkka has quit IRC[19:17:25] *** UUncia has joined ##OpenGL[19:18:36] *** Spkka has joined ##OpenGL[19:22:59] *** itewsh has joined ##OpenGL[19:23:59] *** elite01 has joined ##opengl[19:26:49] *** elite01 has quit IRC[19:29:59] *** iion has joined ##OpenGL[19:30:13] *** a-stray-cat has quit IRC[19:34:04] *** a-stray-cat has joined ##OpenGL[19:35:28] *** elite01 has joined ##opengl[19:37:45] *** djork has joined ##opengl[19:40:33] *** PsiOmegaDelta has quit IRC[19:40:57] *** PsiOmega has joined ##OpenGL[19:45:23] *** UUncia has quit IRC[19:47:58] *** Blaay has joined ##OpenGL[19:54:22] *** UUncia has joined ##OpenGL[20:03:48] *** wisey has quit IRC[20:04:09] *** johndoe has quit IRC[20:04:32] *** johndoe has joined ##opengl[20:06:23] *** NevroPus has joined ##OpenGL[20:07:35] *** mm765^sleep is now known as mm765[20:09:37] *** predaeus has quit IRC[20:09:42] *** kbotnen has joined ##OpenGL[20:10:14] *** XT95__ has joined ##OpenGL[20:11:15] *** NevroPus has quit IRC[20:11:49] *** XT95_ has quit IRC[20:12:48] *** NinZine has quit IRC[20:24:43] *** Nescafe has quit IRC[20:27:42] *** dv_ has joined ##opengl[20:28:10] *** Walt has joined ##opengl[20:28:48] *** AlastairLynn has quit IRC[20:41:05] *** eXtronuS_ has joined ##OpenGL[20:43:48] *** rabbit- has joined ##OpenGL[20:44:18] *** elite01 has quit IRC[20:50:10] *** rabbit- has quit IRC[20:52:14] *** _3b_ has quit IRC[20:52:15] *** iion has quit IRC[20:52:15] *** LordMetroid has quit IRC[20:52:15] *** hackkitten has quit IRC[20:52:15] *** druggy_ has quit IRC[20:52:15] *** deXM96 has quit IRC[20:52:15] *** ext has quit IRC[20:52:16] *** autonomy has quit IRC[20:52:16] *** turbo24prg has quit IRC[20:52:16] *** rektide has quit IRC[20:59:46] *** X-Scale2 has left ##OpenGL[21:07:13] *** eXtronuS_ has quit IRC[21:09:44] *** _3b_ has joined ##OpenGL[21:10:05] *** iion has joined ##OpenGL[21:10:05] *** LordMetroid has joined ##OpenGL[21:10:05] *** hackkitten has joined ##OpenGL[21:10:05] *** druggy_ has joined ##OpenGL[21:10:05] *** deXM96 has joined ##OpenGL[21:10:05] *** turbo24prg has joined ##OpenGL[21:10:05] *** ext has joined ##OpenGL[21:10:05] *** rektide has joined ##OpenGL[21:10:05] *** autonomy has joined ##OpenGL[21:17:59] *** Kasu- has joined ##OpenGL[21:19:32] *** eXtronuS_ has joined ##OpenGL[21:21:12] *** NevroPus has joined ##OpenGL[21:21:25] *** UUncia has quit IRC[21:42:56] *** macrocat has joined ##opengl[21:43:43] *** elite01 has joined ##opengl[21:43:44] *** NevroPus has quit IRC[21:50:34] *** LtJax has quit IRC[21:51:17] *** NinZine has joined ##OpenGL[21:52:23] *** pfo has quit IRC[21:52:46] *** eXtronuS_ has quit IRC[21:52:51] *** pfo has joined ##OpenGL[21:53:11] *** LtJax has joined ##opengl[21:54:14] *** gusnan has quit IRC[22:05:31] *** Acry has joined ##OpenGL[22:13:52] *** NinZine has quit IRC[22:16:57] *** Ingenu has quit IRC[22:17:29] *** Blaay has quit IRC[22:29:06] *** XT95___ has joined ##OpenGL[22:31:21] *** Spkka has quit IRC[22:32:25] *** groton has joined ##OpenGL[22:33:54] *** GX has quit IRC[22:35:40] *** GuShH has joined ##OpenGL[22:37:14] *** XT95__ has quit IRC[22:53:50] *** davidc__ has quit IRC[22:55:44] *** NevroPus has joined ##OpenGL[23:05:32] *** barbar__conan has joined ##OpenGL[23:08:01] *** itewsh has quit IRC[23:11:45] *** Jernej has joined ##OpenGL[23:16:58] *** macrocat has quit IRC[23:19:29] *** JernejL_ has joined ##OpenGL[23:19:34] *** JernejL has quit IRC[23:22:34] *** XT95___ has quit IRC[23:24:28] *** NevroPus has quit IRC[23:28:21] *** JernejL has joined ##OpenGL[23:29:08] *** eXtronuS_ has joined ##OpenGL[23:29:59] *** Suprano has quit IRC[23:32:10] *** vampirefrog has joined ##OpenGL[23:32:30] *** vampirefrog has quit IRC[23:32:47] *** Jernej has quit IRC[23:33:08] *** vampirefrog has joined ##OpenGL[23:36:23] *** sparky_ has quit IRC[23:36:41] *** b0000 has joined ##opengl[23:41:16] *** scai has left ##opengl[23:41:34] *** JernejL_ has quit IRC[23:46:59] *** JernejL has quit IRC[23:50:42] *** dv_ has quit IRC[23:54:33] *** nytejade has joined ##OpenGL[23:57:12] *** qeed has joined ##opengl[23:58:13] *** a-stray-cat has quit IRC