November 2, 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 2, 2014 [00:00:26] *** yaakuro has joined ##OpenGL[00:04:05] *** kidnapped_robot has quit IRC[00:07:41] *** rawtass has quit IRC[00:15:55] *** anivemin has joined ##OpenGL[00:20:33] *** anivemin has quit IRC[00:21:22] *** groton has quit IRC[00:22:47] *** kidnapped_robot has joined ##OpenGL[00:25:27] *** pizthewiz has joined ##OpenGL[00:26:01] *** Waynes1 has quit IRC[00:28:47] *** kidnapped_robot has quit IRC[00:32:55] *** b4b has quit IRC[00:39:28] *** metredigm has quit IRC[00:39:43] *** Syzygy__ has quit IRC[00:41:15] *** stef has quit IRC[00:41:41] <Khlorghaal> how come when i stencilfunc(NEVER) with stenciltest enabled, my fragments are still passing?[00:43:14] *** stef has joined ##OpenGL[00:43:29] <shakesoda> is stencil enabled and do you actually have a stencil buffer?[00:43:36] <shakesoda> make sure of those things first[00:44:15] <Khlorghaal> yeah i know i have my fbo complete[00:44:53] *** shintah has quit IRC[00:45:18] *** kidnapped_robot has joined ##OpenGL[00:45:39] <Khlorghaal> i have it working just a bit ahead in my pipeline[00:46:22] <Khlorghaal> http://hastebin.com/yevopawexu.avrasm[00:46:47] <Khlorghaal> line 37 does nothing, but 7 works as expected[00:47:01] *** pazul has quit IRC[00:55:40] *** Chunk2 has quit IRC[00:58:50] *** pazul has joined ##OpenGL[01:00:44] *** Chunk2 has joined ##OpenGL[01:00:54] *** tkeemon has quit IRC[01:01:22] *** BitPuffin has joined ##OpenGL[01:06:59] *** yaakuro has quit IRC[01:11:23] *** Zopieux has left ##OpenGL[01:11:31] *** Lemml has quit IRC[01:22:50] *** Crehl has quit IRC[01:28:55] *** hexagoxel_ has joined ##OpenGL[01:29:33] *** hexagoxel has quit IRC[01:35:11] *** samrat has joined ##OpenGL[01:37:28] *** kidnapped_robot has quit IRC[01:43:29] *** TyrfingMjolnir has joined ##OpenGL[01:44:34] *** kuldeepdhaka has joined ##OpenGL[01:46:02] *** Ryp has joined ##OpenGL[01:50:21] *** hahuang65 has quit IRC[01:50:33] *** hahuang65 has joined ##OpenGL[01:50:47] *** samrat has quit IRC[01:52:36] *** kidnapped_robot has joined ##OpenGL[01:53:13] *** Suchorski has quit IRC[01:53:36] *** devbug has joined ##OpenGL[01:59:39] *** hahuang65 has quit IRC[02:01:10] *** hahuang65 has joined ##OpenGL[02:01:12] *** pazul has quit IRC[02:01:50] *** starless has joined ##OpenGL[02:01:59] *** hahuang65 has quit IRC[02:02:17] *** hahuang65 has joined ##OpenGL[02:02:37] *** hahuang65 has quit IRC[02:02:46] *** hahuang65 has joined ##OpenGL[02:04:37] *** anivemin has joined ##OpenGL[02:04:41] *** hahuang65 has quit IRC[02:04:51] *** hahuang65 has joined ##OpenGL[02:06:23] *** paperManu has joined ##OpenGL[02:06:46] *** hahuang65 has quit IRC[02:07:10] *** hahuang65 has joined ##OpenGL[02:07:41] <_Cid> can you use an std::vector for a VBO?[02:07:41] *** Ryp has quit IRC[02:07:42] *** warchild has quit IRC[02:08:34] *** hahuang65 has quit IRC[02:08:43] *** hahuang65 has joined ##OpenGL[02:08:57] <HuntsMan2> _Cid: sure[02:09:00] *** hahuang65 has quit IRC[02:09:33] *** anivemin has quit IRC[02:09:38] *** hahuang65 has joined ##OpenGL[02:10:21] *** hahuang65 has quit IRC[02:10:30] *** hahuang65 has joined ##OpenGL[02:11:04] *** hahuang65 has joined ##OpenGL[02:11:31] <_Cid> HuntsMan2: you pass bufferdata .data() right?[02:11:35] *** hahuang65 has quit IRC[02:11:44] *** hahuang65 has joined ##OpenGL[02:13:02] *** hahuang65 has quit IRC[02:13:20] *** hahuang65 has joined ##OpenGL[02:15:59] *** centrinia has joined ##OpenGL[02:16:01] *** hahuang65 has quit IRC[02:16:17] *** hahuang65 has joined ##OpenGL[02:16:44] <HuntsMan2> _Cid: yeah, or &vector[0][02:16:52] *** foreignFunction has quit IRC[02:17:28] *** hahuang65 has quit IRC[02:17:37] *** hahuang65 has joined ##OpenGL[02:18:06] *** linuxuz3r has quit IRC[02:18:27] *** pizthewiz has quit IRC[02:24:52] *** starless has quit IRC[02:26:27] <_Cid> HuntsMan2: should I do sizeof(float) * vector.length()?[02:26:41] <HuntsMan2> yeah[02:27:34] <_Cid> er .size I guess[02:28:47] <Khlorghaal> derp, i only had stencil attached to my first fbo[02:29:59] <Khlorghaal> i had the renderbuffer bound as only depth instead of depth_stencil :([02:37:02] *** charlie5 has quit IRC[02:39:15] <Khlorghaal> deferred lighting->with stencil 300fps->400fps http://i.imgur.com/Cc9dlOp.png[02:40:15] *** hexagoxel_ has quit IRC[02:40:23] <_Cid> so if my vbo is going to change often, that means I'm going to need to call glBindBuffer and glBufferData every frame[02:40:31] <_Cid> ?[02:40:53] <_Cid> since the size of the buffer is specified[02:40:59] <Khlorghaal> well you call them when you need to call them, important thing is use dynamic_draw hint[02:41:39] <_Cid> interesting thank you[02:41:56] <_Cid> I have to update the vbo with glBufferSubData right[02:42:09] <HuntsMan2> glBufferSubData only if the size of the VBO doesn't change[02:42:26] <_Cid> okay well it may[02:42:38] <_Cid> so I guess glBufferData[02:42:55] <_Cid> well glBufferSubData has a size parameter[02:42:58] <_Cid> why can't it change[02:43:16] <HuntsMan2> size of your data[02:43:18] <HuntsMan2> not of the VBO[02:43:31] <_Cid> well if I use a vector[02:43:31] <HuntsMan2> glBufferSubData can update only a part of a VBO[02:43:40] <_Cid> and pass .size * sizeof(float)[02:43:56] <_Cid> then my data changing does mean the size of my container is changing[02:44:26] <HuntsMan2> but it will error if the size is bigger and you use glBufferSubData[02:44:36] <_Cid> I trust you:)[02:44:40] <_Cid> so I'll use glBufferData[02:44:41] <HuntsMan2> lol[02:44:43] <_Cid> every frame[02:44:53] <_Cid> or perhaps check if the size changes[02:44:56] <HuntsMan2> you can later optimize[02:44:56] <_Cid> is that worth it?[02:45:23] <HuntsMan2> optimize?[02:45:37] <_Cid> check if the size changes and call glbuffersubdata[02:45:41] <_Cid> if it doesn't[02:46:04] <HuntsMan2> sure, because glBufferData is expensive[02:46:10] <HuntsMan2> it reallocates memory in the GPU size[02:46:12] <HuntsMan2> side[02:46:18] <_Cid> okay[02:46:26] <_Cid> would it be good to just[02:46:33] <_Cid> pass a huge vbo to start[02:46:37] <_Cid> and then use buffersubdata[02:46:43] <_Cid> to fill it up[02:47:06] <_Cid> ie glbufferdata with a huge size while passing a vector[02:47:14] <_Cid> then fill that vector and keep it below the size[02:47:22] <_Cid> and increase size if necessary[02:47:46] <_Cid> that would eliminate pretty much all calls to glbufferdata and allow for glbuffersubdata[02:47:53] <_Cid> to be used each frame[02:48:05] *** stefkos has quit IRC[02:49:49] *** charlie5 has joined ##OpenGL[02:49:58] <Khlorghaal> I make a class that essentially wraps an ArrayList into gpu memory[02:50:34] <Khlorghaal> I do a preWrite method which i pass the size, and it expands both the buffer (java :( ) and the vbo[02:51:28] <_Cid> hm[02:51:32] <Khlorghaal> and i always use subData to update the data, when just expanding if you pass null do bufferData it doesnt bother with memory transfer[02:52:01] <_Cid> okay[02:52:13] <_Cid> so you can use glbufferdata to expand it without the memory transfer, then subdata to transfer cuz its faster[02:54:04] <Khlorghaal> well if you were doing the two adjacently itd be slightly faster to use buffer data, but this is very nice for convenience[02:56:55] <_Cid> wait[02:57:16] <_Cid> okay[02:58:52] *** kidnapped_robot has quit IRC[03:03:43] *** hellome has joined ##OpenGL[03:14:02] *** kidnapped_robot has joined ##OpenGL[03:14:38] *** zajfy has quit IRC[03:18:52] *** shintahW2 has joined ##OpenGL[03:20:44] *** Vtec234 has quit IRC[03:21:53] *** shintahW has quit IRC[03:21:53] *** shintahW2 is now known as shintahW[03:23:10] *** Garner has quit IRC[03:32:06] *** centrinia has quit IRC[03:33:22] *** Lucretia has quit IRC[03:33:24] *** robot-beethoven has joined ##OpenGL[03:34:13] *** Lucretia has joined ##OpenGL[03:40:55] *** Suburst has joined ##OpenGL[03:42:31] *** mat^2 has quit IRC[03:47:42] *** centrinia has joined ##OpenGL[03:48:17] *** Hunts2 has joined ##OpenGL[03:52:18] *** HuntsMan2 has quit IRC[03:52:56] *** RyanPridgeon_ has joined ##OpenGL[03:53:25] *** anivemin has joined ##OpenGL[03:55:42] *** RyanPridgeon has quit IRC[03:56:32] *** pizthewiz has joined ##OpenGL[03:56:47] *** Syzygy_ has joined ##OpenGL[03:57:53] *** anivemin has quit IRC[04:01:37] *** Zupo2 has quit IRC[04:03:02] *** Keniyal has joined ##OpenGL[04:03:19] <doomedbunnies> I have an arbitrarily-sized texture (possibly NPOT) on the GPU, and I want to downsample it into a 128x128 texture (not preserving aspect ratio). I can just blit it in, but even with linear filtering, that loses a whole lot of image quality.[04:03:59] <doomedbunnies> Is the best option just to create a whole bunch of POT textures and blit down from one to the next, so I get the benefit of linear sampling? Or would I be better off to construct custom shaders to take multiple samples in a single pass? (I imagine the latter is probably the better approach)[04:04:07] <doomedbunnies> Or maybe there's some other way to do it.[04:04:14] <Textmode> offhand I'd say its going to get mangled no matter what.[04:04:41] <derhass> yeah[04:04:51] <Polarina> doomedbunnies, are you using mipmapping?[04:04:53] <doomedbunnies> Absolutely, yes. But if you just blit straight from a 1024x1024 to a 128x128, there will be pixels which don't contribute at all to the output image.[04:04:57] *** pizthewiz has quit IRC[04:05:25] <derhass> but instead of manually doing multiple passes, you could generate mipmaps[04:05:27] <doomedbunnies> Polarina: Erm.. at the moment, I'm not using mipmapping for the texture that's going to be downsized; I'd have to build them.[04:05:36] <derhass> or better: let the gpu generate the mipmap levels[04:05:40] <Polarina> doomedbunnies, you can use glGenerateMipmaps.[04:09:41] *** jdolan has quit IRC[04:10:14] *** jdolan has joined ##OpenGL[04:12:15] <Stragus> A high quality solution would be better suited to the CPU[04:13:27] *** seangrove has quit IRC[04:13:33] <derhass> you also can do this on the gpu, of course[04:13:45] <doomedbunnies> Mm. I need speed more than quality. But would rather avoid awful-quality. ;)[04:13:49] <doomedbunnies> Testing with mipmaps now.[04:14:03] <Stragus> Mipmaps will give you speed and acceptable quality[04:14:38] <doomedbunnies> I'm all about the "acceptable quality". It's practically my middle name.[04:14:48] <doomedbunnies> doomed "acceptable quality" bunnies, that's me.[04:14:59] <doomedbunnies> :)[04:15:13] <Stragus> Fancy downsampling algorithms map the pixels into some 2D curve and resolve the output pixels, while preserving contrasts and avoiding blur[04:15:18] <Stragus> Okay :)[04:15:31] *** pizthewiz has joined ##OpenGL[04:15:51] *** pizthewiz has quit IRC[04:17:06] <doomedbunnies> Still getting little blobby bits where particular source pixels are getting emphasised more than others, but within quality limits that I'm prepared to accept. Minimaps was a pretty easy solution. Thanks, guys! :)[04:25:40] *** urraka has quit IRC[04:27:02] <_Cid> what is the best way to handle lots of sprites?[04:27:11] <_Cid> in terms of textures[04:27:24] <_Cid> a texture array requires all the textures be the same dimensions correct[04:27:32] <_Cid> or no more than the max[04:28:16] <slime> array texture(s) and/or texture atlas(es)[04:28:24] <slime> maybe even a combination[04:28:26] <Stragus> A texture array requires identical dimensions, yes[04:28:38] <_Cid> how exactly does a texture atlas work[04:28:57] <_Cid> a single texture loaded with all textures?[04:29:12] <Stragus> You put many different images into one giant textures, to avoid switching textures all the time[04:29:19] <_Cid> hm[04:29:22] <_Cid> I'd like to do that[04:29:42] <Stragus> Probably not all textures, and it only works well for textures which never need to "wrap around"[04:29:53] <Stragus> So the sprites you mention would be a perfect candidate[04:30:06] <_Cid> yeah[04:30:10] <glYoda> doomedbunnies for NPOT GPU accelerated mipmapping I'd specifying NICEST for GENERATE_MIPMAP_HINT as well[04:30:23] <glYoda> (via the existing Hint command in the GL)[04:30:52] <glYoda> you'll find that certain vendors will use a far higher quality filter pass when that is specified[04:30:59] <glYoda> for the NPOT case[04:31:38] <doomedbunnies> Ah, cool. Thanks, glYoda![04:32:00] <glYoda> (i.e. something other than a naive box filter for instance)[04:32:17] <_Cid> so for a texture atlas would you just specify a massive texture in glTexImage2D[04:32:54] <Stragus> Interesting. glYoda is like Google, is there anything he doesn't know? :)[04:33:15] <Stragus> _Cid, that's the general idea. You may still need multiple textures, or a texture array[04:33:47] <Stragus> A texture array implies 3D texcoords but avoid the need to switch textures, the best option depends on the specific case[04:35:19] <doomedbunnies> Hm.. OpenGL is giving me an "invalid enumeration" error for glHint( GL_GENERATE_MIPMAP_HINT, GL_NICEST )[04:35:43] <glYoda> under what GL version and vendor[04:36:29] <doomedbunnies> OpenGL Context: Vendor: NVIDIA Corporation Renderer: NVIDIA GeForce GT 650M OpenGL Engine Version: 4.1 NVIDIA-10.0.43 310.41.05f01 Shading Language Version: 4.10[04:37:14] <derhass> well, that hint was removed long ago[04:37:41] <glYoda> because it's a fully supported hint[04:37:41] *** shingshang has joined ##OpenGL[04:38:53] *** Khlorghaal has quit IRC[04:39:33] <foobaz> i doubt that hint does anything anyway[04:39:57] <glYoda> umm want to bet?[04:40:04] <foobaz> what would it even mean? gamma correct averaging of pixels?[04:40:21] <foobaz> surely any mipmap generation is going to use a box filter to avoid artifacts at the edge[04:40:43] <glYoda> in any case you'll find the hint in question is relative to SGIS_generate_mipmap which is GL 2.x level[04:40:54] <Stragus> There are many very fancy filtering algorithms that would be quite expensive to run by default[04:40:58] <glYoda> for the core API profile you won't have this available[04:41:06] <foobaz> Stragus: but they don't work at an edge[04:41:10] <glYoda> foobaz LOL no[04:41:16] <Stragus> What? Sure they do[04:41:31] <glYoda> there are a number of higher quality approaches for NPOT mipmap filtering[04:41:50] <glYoda> and vendors DO in fact leverage that[04:41:57] <doomedbunnies> Net result: It's not in core profile. So whether or not it's 'fully supported' doesn't really matter for me. :)[04:41:58] <foobaz> for NPOT that makes sense, since box filter is no longer ideal[04:42:14] <foobaz> but for powers of two, box filter is perfect[04:42:22] <Stragus> No, box filter is not perfect, even for powers of two[04:42:25] <Stragus> It blurs too much[04:42:26] <glYoda> foobaz had you bothered to read what started it you'd realize that NPOT was the relevant case[04:42:41] <Stragus> I have seen a boost in mipmapping quality by switching to a more intelligent algorithm[04:42:50] <glYoda> yep[04:43:17] <foobaz> sorry i did not consider NPOT, you are right[04:43:33] <elveni> hmm, anyone of u guys had this issue with visual studio? my projects seem to be launching twice when pressing F5, same with CTRL+F5 o.O[04:43:37] <Stragus> Even for powers of two, screw the box filter :)[04:43:41] *** Orion] has quit IRC[04:44:15] <foobaz> choice of resampling algorithm is highly dependent on the contents of the image, it's not as simple as "nicer" or "faster"[04:44:44] <Stragus> Box filter often blurs too much, mipmaps become blurry with no details[04:44:45] <foobaz> your fancy filter might not look so great on line art, or it might have ringing artifacts for images with few colors[04:44:53] <Stragus> Ah sure, obviously[04:45:31] <foobaz> i've written a few resampling filters myself[04:46:37] <derhass> in the end, resampling is just guesswork[04:46:39] <glYoda> well you probably aren't shipping any in a driver[04:46:48] <derhass> there will never be an optimal approach[04:46:59] <foobaz> yes i am only shipping them in userspace :)[04:47:32] <doomedbunnies> I should be more clear about what I'm doing. I render my scene into a FBO with two color buffers. Color buffer #1 contains diffuse, buffer #2 contains glowing elements. I then copy buffer #2 into another set of textures where I do an axis-separated gaussian blur, then add them back over the diffuse image to make the final output screen image.[04:47:39] <glYoda> in any case my earlier point stands -- the GL exposes hints for varying the quality of GPU side mipmap generation and whenever those hints are available it's worth using them[04:49:45] <doomedbunnies> The specific issue I have is that I have a lot of very thin glowing elements, which tend not to survive the resolution drop between FBO color buffer #1 and the top-resolution blur buffer. So the 'glow' effect tends to strobe as these thin elements move on the screen, as they move in and out of highly sampled areas during that resolution-reduction step.[04:50:47] <doomedbunnies> (So in my particular case, I care a lot more about "every pixel gets sampled evenly during the resolution reduction" than about "not introducing extra blur into the image", seeing as I'm just going to gaussian blur it anyway)[04:50:52] <Stragus> Ouch, very thin glowing elements and heavy downsampling won't mix well[04:51:03] *** Cabanoss- has joined ##OpenGL[04:51:23] <derhass> maybe you want an max filter instead of a box averaging[04:51:41] <foobaz> how about drawing the thin glowing parts as separate geometry?[04:51:41] <Stragus> Probably something in between[04:52:20] <foobaz> you can't expect a bitmap to faithfully represent features smaller than a pixel[04:52:46] <foobaz> or maybe you could just make the line thicker[04:53:06] *** petervaro has joined ##OpenGL[04:53:22] <doomedbunnies> It's true. The max filter is a good idea. I really care more about keeping any glow data that's in the high-resolution image, much more than I care about equally maintaining the non-glow data.[04:53:45] <doomedbunnies> glYoda: Thanks for the link, reading now. :)[04:54:14] *** ragecryx has quit IRC[04:54:29] *** Cabanossi has quit IRC[04:54:30] *** Cabanoss- is now known as Cabanossi[04:55:23] <foobaz> you might consider drawing the different mip levels by hand[04:55:33] <foobaz> then you have full control over how your line appears[04:55:56] <doomedbunnies> Also, gah at that article. What reviewer approved their usage of 'l' as a loop variable? Especially with how often they use (l-1).[04:56:15] *** Dark_Confidant has joined ##OpenGL[04:56:16] <Stragus> Mathematicians do that stuff all the time[04:56:30] <doomedbunnies> max(1,width>>l)[04:56:35] <doomedbunnies> FIENDS[04:56:58] <doomedbunnies> Seriously hard to tell 1 and l apart in that PDF's font. :)[04:57:28] <derhass> doomedbunnies: why do you think such a technical report did go through any such review?[04:57:33] <glYoda> meh seems pretty obvious to me[04:57:41] <glYoda> given the algorithm hehe[04:57:51] <glYoda> (context++)[04:58:29] <derhass> hehe, l for level is quite obvious[04:58:57] <glYoda> meh just look at what the above step does[04:59:24] *** Dark_Confidant|m has quit IRC[04:59:30] <glYoda> the location of "1" and "l" should be obsivous… even when they appear to be identical characters :P[04:59:40] <glYoda> *obvious[04:59:47] <Textmode> https://www.opengl.org/wiki/VBO_-_just_examples ← This page says the article describes deprecated APIs, it does not say *which* APIs, or what to use instead. Would someone be kind enough to enlighten me?[05:01:18] *** glYoda has quit IRC[05:01:31] *** glYoda has joined ##OpenGL[05:01:49] <derhass> Textmode: glEnableClientState, glVertexPointer, glNormalPointer and so on[05:01:58] <derhass> Textmode: not using VAOs is another thing[05:03:43] <Textmode> what replaces them?[05:04:03] <derhass> generic vertex attributes[05:04:34] <Textmode> fair enough.[05:06:04] <foobaz> shaders, basically[05:06:47] <doomedbunnies> float x1=min(x0+1,max(1,width>>(l-1))-1);[05:06:56] <doomedbunnies> I'm pretty sure they're having a laugh. ;)[05:08:50] <glYoda> "shaders, basically" …umm shaders have absolutely nothing to do with this[05:09:31] <glYoda> and it's also worth noting that "generic vertex attributes" have been with us since the initial ARB_vertex_buffer_object specification[05:11:39] <glYoda> the only difference here (i.e. going from GL 1.x into GL >= 3.x for instance) is the fact that client side vertex attributes were deprecated (i.e. [Vertex, Normal, …]Pointer and the relevant enables mentioned earlier) and VAOs (i.e. ARB_vertex_array_object) are a requirement[05:12:55] <dahlia> why did they make them required instead of optional?[05:13:01] *** bb010g has joined ##OpenGL[05:13:04] *** zoraj has quit IRC[05:14:41] *** xissburg has quit IRC[05:16:12] <Textmode> presumably it simplifies something somewhere in the pipeline.[05:16:38] <glYoda> well the introduction into the core API along with the deprecation of the existing client side VA path made it a fairly sensible idea from an API standpoint[05:17:14] <glYoda> since it effectively mirrors the rest of the API WRT binding behavior[05:19:32] <dahlia> I like them but it just seemed strange that many of the calls dealing with vertex buffers remained the same so it made me wonder[05:20:30] <slime> well, now the new vertex attribute buffer/format functions are in, with ARB_vertex_attrib_binding[05:20:43] <glYoda> yep[05:21:01] <slime> (although you can't take advantage of that in Mac OS X yet...)[05:21:02] <glYoda> unification has been a somewhat slow process heheh[05:21:04] *** paperManu has quit IRC[05:21:12] <glYoda> (concerning the API)[05:21:34] <dahlia> must be designed my committee :P[05:21:38] <dahlia> *by[05:21:52] *** paperManu_ has quit IRC[05:22:03] <glYoda> pretty much :)[05:24:57] *** qeed has quit IRC[05:30:39] *** shintahW has quit IRC[05:30:59] *** shintahW has joined ##OpenGL[05:42:07] *** shintahW2 has joined ##OpenGL[05:42:12] *** anivemin has joined ##OpenGL[05:43:49] *** petervaro has quit IRC[05:44:30] *** meoblast001 has joined ##OpenGL[05:45:03] *** shintahW has quit IRC[05:45:03] *** shintahW2 is now known as shintahW[05:47:17] *** anivemin has quit IRC[05:50:14] *** gaganjyot has joined ##OpenGL[05:51:11] *** charlie5 has quit IRC[05:51:37] *** fatalhalt has joined ##OpenGL[05:59:54] *** japro has quit IRC[06:03:03] *** MLM has quit IRC[06:06:32] *** charlie5 has joined ##OpenGL[06:06:44] *** pauldachz has quit IRC[06:07:18] *** pauldachz has joined ##OpenGL[06:09:23] *** pauldachz has quit IRC[06:16:03] *** pauldachz has joined ##OpenGL[06:22:24] *** pauldachz has quit IRC[06:23:02] *** pauldachz has joined ##OpenGL[06:23:40] *** pauldachz has quit IRC[06:25:08] *** pauldachz has joined ##OpenGL[06:25:32] *** pauldachz has quit IRC[06:26:30] *** pauldachz has joined ##OpenGL[06:27:11] *** pauldachz has quit IRC[06:28:08] *** gaganjyot has quit IRC[06:44:19] *** Budd has joined ##OpenGL[06:45:08] *** fatalhalt has quit IRC[06:45:20] *** BitPuffin has quit IRC[06:51:41] <Budd> I'm trying to migrate from old-school glVertex calls to arrays. I have a simple test here that fails: http://hastebin.com/atapifasiy.coffee[06:52:56] <LeelooMinai> Budd: Why is there 0 in BindVertexArray?[06:52:57] <Budd> the glVertex() variant works properly. The glDrawArrays variant draws to apparently random coordinates (different on different runs of the program, theough the data does not change).[06:53:26] <Budd> LeelooMinai: other parts of my code use VAOs, and I want to be sure that was disabled.[06:54:16] *** fatalhalt has joined ##OpenGL[06:55:46] *** sam has quit IRC[06:57:03] *** akiress has quit IRC[07:00:11] *** RyanPridgeon_ has quit IRC[07:02:02] *** indefini has joined ##OpenGL[07:04:15] *** HaltingState has quit IRC[07:04:36] <LeelooMinai> Budd: Hmm... maybe try 0 for stride there?[07:05:17] *** jhuntley has quit IRC[07:05:26] <LeelooMinai> instead if sizeof(vdata_t)[07:06:32] <LeelooMinai> Since it want stride between individual points. Don't know - not sure how vdata_t is defined in your code[07:07:04] <LeelooMinai> But from first branch it seems like it holds more than one vertex.[07:07:17] *** HaltingState has joined ##OpenGL[07:07:54] <LeelooMinai> That would explain why you get seemingly random points[07:09:11] *** Zeioth has quit IRC[07:10:59] <Budd> LeelooMinai: vdata_t is just three floats.[07:12:06] <Budd> It seems the issue is that I needed to glBindBuffer (GL_ARRAY_BUFFER, 0) - otherwise it fights with the client-side buffer.[07:12:44] <LeelooMinai> SO it works now?[07:13:02] <Budd> I assumed that glBindVertexArray (0) would take care of that. Yes, it works now,.[07:13:13] <LeelooMinai> A, ok[07:13:25] <Budd> Now to write the third case with GPU-side buffers.[07:13:29] <Budd> Thanks for the help.[07:15:04] *** BreadProduct has quit IRC[07:15:26] *** gaganjyot has joined ##OpenGL[07:28:26] *** MLM has joined ##OpenGL[07:28:56] *** Zupo has joined ##OpenGL[07:30:56] *** anivemin has joined ##OpenGL[07:32:10] *** gaganjyot has quit IRC[07:32:23] *** meoblast001 has quit IRC[07:32:42] *** Bigpet_ has quit IRC[07:35:34] *** anivemin has quit IRC[07:37:26] *** Dark_Confidant has quit IRC[07:37:26] *** Dark_Confidant|m has joined ##OpenGL[07:37:35] *** wiky has joined ##OpenGL[07:37:36] *** konom has joined ##OpenGL[07:43:28] *** Suburst has quit IRC[07:45:54] *** fatalhalt has quit IRC[07:48:22] *** sam has joined ##OpenGL[07:48:43] *** phao has quit IRC[07:50:46] *** slime has quit IRC[07:52:06] *** slime has joined ##OpenGL[07:52:22] *** slime has joined ##OpenGL[07:57:03] *** bb010g has quit IRC[07:57:06] *** bjz has quit IRC[07:58:57] *** Twinklebear has quit IRC[08:17:05] *** tcsc has quit IRC[08:19:28] *** Gamecubic has quit IRC[08:20:45] *** shingshang has quit IRC[08:23:16] *** CainJacobi has quit IRC[08:31:10] *** stoopdapoop has quit IRC[08:31:44] *** anivemin has joined ##OpenGL[08:32:24] *** Syzygy__ has joined ##OpenGL[08:33:02] *** stoopdapoop has joined ##OpenGL[08:35:31] *** Syzygy_ has quit IRC[08:35:33] *** JoshSyn has joined ##OpenGL[08:36:30] *** anivemin has quit IRC[08:47:58] *** Lemml has joined ##OpenGL[08:57:22] *** Syzygy__ has quit IRC[08:57:50] <Textmode> Hmm, is there a way to do stipple-fills in pre-shader OGL versions?[08:59:27] *** Garner has joined ##OpenGL[09:04:48] *** Demon_Fox has quit IRC[09:05:45] *** groton has joined ##OpenGL[09:07:45] *** TheBix has joined ##OpenGL[09:11:29] *** mat^2 has joined ##OpenGL[09:11:32] *** devbug has quit IRC[09:12:57] *** wiky has quit IRC[09:25:53] *** rawtass has joined ##OpenGL[09:26:57] *** razieliyo has quit IRC[09:32:30] *** anivemin has joined ##OpenGL[09:33:17] *** shintah has joined ##OpenGL[09:35:07] *** groton has quit IRC[09:36:12] *** ManDay has joined ##OpenGL[09:37:02] *** anivemin has quit IRC[09:37:40] *** bjz has joined ##OpenGL[09:39:27] *** Suburst has joined ##OpenGL[09:40:08] *** Smilex1 has joined ##OpenGL[09:47:49] *** ikrima has joined ##OpenGL[09:55:33] *** james4k has quit IRC[10:09:13] <dahlia> Textmode: use a texture[10:09:35] <Textmode> dahlia: will that work with stencils?[10:09:53] <dahlia> should[10:14:43] *** Textmode has quit IRC[10:15:31] *** Match has joined ##OpenGL[10:16:37] *** stefkos has joined ##OpenGL[10:21:24] *** hexagoxel has joined ##OpenGL[10:28:04] *** robot-beethoven has quit IRC[10:30:03] *** charlie5 has quit IRC[10:30:16] *** newguise1234 has joined ##OpenGL[10:30:26] *** charlie5 has joined ##OpenGL[10:31:26] <newguise1234> I'm trying to get my head around VAOs. Is it that, anything bound while a VAO is bound, will be rebound when the VAO is bound again?[10:31:29] *** pazul has joined ##OpenGL[10:32:39] *** bjz has quit IRC[10:33:09] *** bjz has joined ##OpenGL[10:37:27] *** viggo has joined ##OpenGL[10:38:21] *** stefkos has quit IRC[10:38:45] *** pazul has quit IRC[10:40:22] *** viggo2 has quit IRC[10:40:38] <Yaniel> not exactly[10:41:25] <Yaniel> only 1) vertex attrib pointers (which includes the GL_ARRAY_BUFFER that was bound when setting them) and 2) the index buffer binding[10:41:56] <Yaniel> those are stored in the VAO[10:42:03] <newguise1234> okay, thats exactly what they're showing in the tutorial, but I was wondering if it generalized more, thank you[10:42:36] <Yaniel> note that the information about buffers in the attrib pointers does not mean that it would bind anything to GL_ARRAY_BUFFER[10:42:38] *** Smilex1 has quit IRC[10:42:54] <Yaniel> so if you want to update one you have to bind it again regardless of the bound VAO[10:43:40] <newguise1234> okay, but I can bind a vao and draw without binding the vbo because the information is stored in the pointers?[10:44:23] <newguise1234> I mean, given my vao has been set up properly[10:45:45] *** Alina-malina has quit IRC[10:46:24] <Yaniel> yep[10:46:49] <Yaniel> also binding VBOs while a VAO is bound does not affect the VAO until you set a vertex attrib pointer[10:46:59] <Yaniel> (except for the index buffer of course)[10:47:12] <newguise1234> That is a wonderful piece of information and pulls it all together, thank you.[10:48:24] <rawtass> is it possible to have two depth attachments to a framebuffer?[10:49:08] *** Alina-malina has joined ##OpenGL[10:50:01] <rawtass> I am testing shadow mapping with my deferrd shader and in this case my depth texture map is already used to reconstruct positions of the scene from camera perspective.[10:51:00] *** pazul has joined ##OpenGL[10:53:03] *** MLM has quit IRC[10:57:29] *** realz has quit IRC[10:59:23] *** foreignFunction has joined ##OpenGL[11:01:49] *** neure has joined ##OpenGL[11:07:38] <Yaniel> not as depth attachments[11:07:45] <Yaniel> but you can have the other as a colour attachment[11:10:18] <rawtass> I am storing my shadow map in a color attachment now[11:10:50] <rawtass> in the same framebuffer as all my normals, depths and diffuse colors[11:11:05] <rawtass> but in this case, can I use sampler2Dshadow ?[11:12:03] <Yaniel> I'm not sure[11:14:53] <rawtass> is there a "best pratice" for how to handle a shadow map with a deferred shader / g-buffer?[11:14:57] *** ManDay has quit IRC[11:15:51] *** Suburst has quit IRC[11:17:17] *** Crehl has joined ##OpenGL[11:18:59] *** letoram has quit IRC[11:21:12] *** anivemin has joined ##OpenGL[11:25:41] *** anivemin has quit IRC[11:29:55] *** xdrone has joined ##OpenGL[11:30:07] *** japro has joined ##OpenGL[11:32:40] *** Waynes has joined ##OpenGL[11:40:20] *** james4k has joined ##OpenGL[11:41:21] *** madsy has quit IRC[11:45:04] *** james4k has quit IRC[11:45:12] *** Madsy has joined ##OpenGL[11:45:12] *** Madsy has joined ##OpenGL[11:47:39] *** Djstey is now known as Djstey|away[11:51:54] *** HunterD has joined ##OpenGL[11:56:33] *** konom has quit IRC[11:57:05] *** JoshSyn has joined ##OpenGL[12:01:30] *** ville has quit IRC[12:04:57] *** Crehl has quit IRC[12:05:17] *** Nach0z has quit IRC[12:05:48] *** Bigpet_ has joined ##OpenGL[12:06:33] *** Nach0z has joined ##OpenGL[12:11:36] *** ville_ has joined ##OpenGL[12:12:57] <newguise1234> The way it makes sense to me is that glDrawRangeElements start/end indices rely on the size and stride that are set in glVertexAttribPointer. Is this wrong?[12:14:15] <Hunts2> what do you mean?[12:14:47] <Bloodust> well yes I guess[12:14:51] <newguise1234> I'm trying to store index offsets in my program for use in a "packed" vbo and ibo[12:15:13] <newguise1234> and I'm trying to figure out if I need byte offsets or "count" offsets[12:15:28] <Hunts2> you need indices[12:15:40] <Hunts2> maybe that is what you call "count" offsets[12:15:46] <newguise1234> yes sorry[12:16:43] <newguise1234> and so I was wondering how glDrawRangeElements treats the indices, if it utilizes the size and stride given in glVertexAttribPointer to determine how far to step with each index[12:17:02] <Bloodust> yes ofc[12:17:06] <Bloodust> same with glDrawElements[12:17:09] <Hunts2> yeah but you should not worry about that[12:17:11] <newguise1234> Cool thank you.[12:17:29] <Bloodust> beginptr + stride*index[12:17:45] <newguise1234> I'm not worried about it, just trying to connect where interrelated things are.[12:18:57] <newguise1234> Thank you for your help and making me clarify, it just cements what I'm reading about a little more.[12:22:10] *** letoram has joined ##OpenGL[12:25:07] *** zajfy has joined ##OpenGL[12:26:07] <Match> hi all, is possible in ES2 to visualize only some vertices of a mesh exluding some other only in vertex shader ?[12:26:29] *** letoram has quit IRC[12:26:34] <Match> the exclusion algorithm reside in vertex I mean[12:28:24] *** TheBix has quit IRC[12:28:32] *** thetourist has joined ##OpenGL[12:30:40] *** letoram has joined ##OpenGL[12:32:45] *** HunterD has quit IRC[12:33:57] <newguise1234> you could set the position coords to some offscreen value based on some conditionals?[12:34:10] <newguise1234> I don't know that thats the best idea[12:34:43] <Bloodust> you can[12:34:50] *** HunterD has joined ##OpenGL[12:34:58] <newguise1234> or set it to a non-visible color[12:35:18] <newguise1234> (passed to the fragment shader)[12:35:32] <Bloodust> yeah, tell fragment shader to discard the triangle or create zero size triangle[12:36:28] <neure> latter you need to do in vertex shader[12:37:16] <neure> and if you share vertices among different primitives, you may need to duplicate those[12:37:33] <neure> so that you can process per primitive vertices instead of shared vertices[12:38:21] *** thetourist has quit IRC[12:38:33] *** thetourist has joined ##OpenGL[12:38:39] *** thetourist has quit IRC[12:38:54] *** thetourist has joined ##OpenGL[12:39:01] <newguise1234> offtopic: Somone pointed me to this paper, and I think some people here might have an interest in it? I know I enjoyed it.[12:39:03] <newguise1234> http://gfx.cs.princeton.edu/pubs/Sander_2007_%3ETR/tipsy.pdf[12:39:16] *** PasNox has joined ##OpenGL[12:40:05] <neure> newguise1234, is there implementation in github?[12:41:30] <newguise1234> I've only read the paper sorry. The way they described it, it should not be difficult to put into a backend without changing too much stuff[12:41:57] <newguise1234> Its pretty much the first thing I've read along these lines, so that may be a reason I found it particularly eye opening[12:42:21] <neure> https://github.com/tfmoraes/Tipsify-Go[12:42:59] <newguise1234> Oh nice.[12:43:28] *** centrinia has quit IRC[12:45:54] *** RyanPridgeon has joined ##OpenGL[12:48:18] *** Portals has joined ##OpenGL[12:55:51] <newguise1234> in glDrawRangeElementsBaseVertex, start and end are indices, indices is a byte offset that start counts from? and basevertex is a byte value? or an index value. ?[12:56:12] *** jeaye has quit IRC[12:56:24] *** snakenerd has joined ##OpenGL[12:56:32] *** thetourist has quit IRC[12:57:21] <newguise1234> On further thinking I think basevertex is an index value.[12:57:34] <TheFlash> newguise1234: Indices are... it's a plural from index.[12:58:08] *** snakenerd has quit IRC[12:58:42] *** krnlyng has joined ##OpenGL[12:59:00] <newguise1234> TheFlash: indices is a function argument, sorry[13:00:24] <newguise1234> I probably should have surrounded it by quotes or some such.[13:00:37] <krnlyng> hi, i have an issue with glCreateProgram, it returns zero in this program: https://bpaste.net/show/bc2d5d01f9bb any ideas?[13:01:21] <Madsy> krnlyng: Why is that an issue? 0 is a program[13:01:22] <Hunts2> krnlyng: do you have a valid OpenGL context when you call that function?[13:01:54] <Madsy> Oh, my bad. Seems like 0 is an error[13:02:00] <krnlyng> Madsy: https://www.khronos.org/opengles/sdk/docs/man/xhtml/glCreateProgram.xml this says 0 is an error[13:02:01] <Bloodust> version 100 ? duuude[13:02:19] <krnlyng> Hunts2: yes i do have a valid context[13:02:47] <krnlyng> Hunts2: this is code from a plugin i want to create, the main program renders fine[13:02:55] <Hunts2> krnlyng: that's the only reason it could fail[13:03:16] *** Syzygy_ has joined ##OpenGL[13:03:49] <Hunts2> krnlyng: you can try printing the return value of glGetString(GL_VERSION) near your glCreateProgram call[13:03:50] <krnlyng> Hunts2: could it be that it happens because the opengl context is in another so file?[13:04:14] <Hunts2> krnlyng: contexts do not "belong" to library files[13:04:31] *** jeaye has joined ##OpenGL[13:05:05] <krnlyng> ah wait... maybe the my plugin gets initialized before the graphics plugin, need to check that[13:05:17] *** Beetny has quit IRC[13:06:31] <Hunts2> krnlyng: if glGetString returns null, then you have no context[13:07:01] *** anivemin has joined ##OpenGL[13:07:09] <krnlyng> Hunts2: yeah it returns null, my plugin gets initialized before the graphics plugin :|[13:07:17] <Hunts2> ;)[13:10:23] <krnlyng> thanks :)[13:12:02] *** anivemin has quit IRC[13:13:51] <Portals> I've two different meshes. Which consist of one vbo and one ibo.[13:14:04] <Portals> I use glBufferData to spectify the size of both[13:14:15] <Portals> then I use glBufferSubdata to buffer data[13:14:37] <Portals> Though when I use this. My two meshes interfer with each other[13:14:40] *** groton has joined ##OpenGL[13:14:57] <Portals> But when I use glBufferData to upload the data directly. I've no problem[13:15:41] <Portals> Why does glBufferSubData interfer with other vbos but not glBufferData?[13:16:20] <Portals> Here's my mesh code : http://pastebin.com/Racj6cJJ[13:17:42] <Bloodust> code looks good to me[13:18:02] <Bloodust> as long as the buffers are large enough to hold the subdata call data[13:18:57] <Portals> I'm not getting any OpenGL errors[13:20:04] *** Crehl has joined ##OpenGL[13:20:30] <Portals> Doesn't seem to be the size.[13:21:47] *** HunterD has quit IRC[13:21:56] *** groton has quit IRC[13:22:36] *** BitPuffin has joined ##OpenGL[13:24:38] *** Djstey|away is now known as Djstey[13:24:47] *** Madsy has quit IRC[13:28:02] <Portals> I really need glBufferSubData for my SpriteBatch.[13:28:11] <Portals> Or else the performance is going to take a big hit[13:28:18] *** karab44 has joined ##OpenGL[13:28:22] <Portals> I've only tested glMapBuffer stuff.[13:28:36] <Portals> Is it any better then glBufferSubData?[13:28:40] <Portals> Bloodust[13:28:54] <Bloodust> glBufferSubdata should work just fine, I really dont see why it would cause any problems with that code[13:29:15] <Bloodust> I dont know if mapping is any faster[13:29:22] <Bloodust> but persistent mapping is[13:29:52] <Portals> What's persistent mapping?å[13:30:33] <Bloodust> the mapping is .. persistant[13:30:37] <Bloodust> https://www.opengl.org/wiki/Buffer_Object#Persistent_mapping[13:31:04] <Portals> English isn't main language, sorry.[13:32:14] <neure> persistent mapping - you dont need to unmap[13:32:23] <neure> buffer can remain mapped while you issue draw calls[13:33:40] <Portals> Thanks neure![13:34:05] *** thetourist has joined ##OpenGL[13:34:35] <neure> not all GPUs support persistently mapped buffers though[13:35:03] <Portals> It's 4.4 right? Neure?[13:35:09] <neure> and you need to use new API functions to use it[13:35:23] <Match> thanks all for answer concerning vertices visualization[13:35:24] <neure> yes, I think some recent GL version includes persistently mapped buffers[13:35:43] <Match> I'm happy it seems an interesting topic also for others[13:36:37] <Portals> Thanks![13:41:11] *** Slion has joined ##OpenGL[13:44:53] *** xdrone has quit IRC[13:44:56] *** Kane has joined ##OpenGL[13:48:51] *** HunterD has joined ##OpenGL[13:50:46] <Match> Bloodust (but also to others), in your opinion if I send a Vertex buffer and an index buffer tailored to my needs (in order to stripe a subset of vertices), the triangles amount is related as described in index buffer ?[13:52:21] <Match> simple sample: I send a vertex buffer with thousands of vertices but une index buffer with 3 index only , the gpu refresh only 1 triangle , right ? with 1 triangle perrformance I mean...[13:52:53] <Bloodust> umm yes, index buffer dictates how many triangles you draw[13:53:08] <Bloodust> in short[13:53:23] *** paperManu_ has joined ##OpenGL[13:53:33] <Bloodust> obviously your draw call parameters define how many indices to use[13:56:45] *** gaganjyot has joined ##OpenGL[14:01:04] *** ShadowIce has joined ##OpenGL[14:04:39] *** konom has joined ##OpenGL[14:11:37] *** Ryp has joined ##OpenGL[14:14:02] *** shingshang has joined ##OpenGL[14:15:17] *** MiniCow has joined ##OpenGL[14:17:11] *** thetourist has quit IRC[14:21:04] *** thetourist has joined ##OpenGL[14:21:57] *** ville_ is now known as ville[14:22:39] *** gaganjyot has quit IRC[14:22:55] *** CapsAdmin has quit IRC[14:24:23] *** Madsy has joined ##OpenGL[14:24:32] *** Madsy has joined ##OpenGL[14:25:08] *** qeed has joined ##OpenGL[14:25:28] *** charlie5 has quit IRC[14:25:31] <rawtass> is there a "best pratice" for how to handle a shadow map with a deferred shader / g-buffer? I am already using my depth buffer for the camera geometry.[14:26:03] *** urraka has joined ##OpenGL[14:30:41] *** BreadProduct has joined ##OpenGL[14:33:03] *** realz has joined ##OpenGL[14:41:10] *** Khlorghaal has joined ##OpenGL[14:42:21] *** CapsAdmin has joined ##OpenGL[14:47:57] *** Djstey is now known as Djstey|away[14:49:58] *** kuldeepdhaka has quit IRC[14:52:28] *** damir__ has quit IRC[14:54:24] *** Zupo has quit IRC[14:55:47] *** anivemin has joined ##OpenGL[14:57:18] *** JoshSyn has quit IRC[15:00:17] *** anivemin has quit IRC[15:05:17] *** phao has joined ##OpenGL[15:06:47] *** telex has joined ##OpenGL[15:09:39] *** stefkos has joined ##OpenGL[15:12:24] *** phao has quit IRC[15:16:40] *** Gamecubic has joined ##OpenGL[15:21:21] <japro> rawtass, ? usually you have multiple fbos with different depth buffers in that case i gues?[15:22:39] *** Zeioth has joined ##OpenGL[15:24:42] *** thetourist has quit IRC[15:32:50] *** groton has joined ##OpenGL[15:36:44] *** ManDay has joined ##OpenGL[15:37:47] *** groton has quit IRC[15:39:51] *** PasNox has quit IRC[15:42:41] *** PasNox has joined ##OpenGL[15:45:15] *** thetourist has joined ##OpenGL[15:47:37] *** shintah has quit IRC[15:48:03] *** shintah has joined ##OpenGL[15:51:07] *** xdrone has joined ##OpenGL[15:56:35] *** anivemin has joined ##OpenGL[16:01:42] *** anivemin has quit IRC[16:02:31] <Portals> Bloodust, With framebuffer, you can create all kinds of cool effects using shaders right?å[16:02:47] <newguise1234> if you specify layout(location = 0) in vec3 Position, in the vertex shader file, does that make it so you don't have to call glBindAttribLocation from within your program?[16:02:54] *** HunterD has quit IRC[16:05:08] *** thetourist has quit IRC[16:06:13] <newguise1234> I've my answer, its due to versioning sorry.[16:06:25] *** RyanPridgeon has quit IRC[16:07:37] <derhass> newguise1234: versioning?[16:07:46] <derhass> newguise1234: what are you talking about?[16:08:22] <newguise1234> I mean, the layout(location = 0) wasn't added until 3.3[16:08:39] <newguise1234> I was looking through a project I had worked on and was wondering why it never called glBindAttribLocation[16:10:22] <derhass> yeah, GL_ARB_explicit_attrib_location[16:15:24] *** HunterD has joined ##OpenGL[16:16:42] <rawtass> japro: but say I have default fb, g-buffer, and shadow fb.. When I do the lighting I need to have access texture maps which was written from both the g-buffer fb and the shadow fb. I thought I could only access textures from one fb at the time?[16:18:03] <Portals> Whenever I render to my framebuffer, the first texture I render is being scaled up on the whole framebuffer and no other textures gets drawn. any ideas?[16:19:17] *** Misu has joined ##OpenGL[16:20:58] *** tcsc has joined ##OpenGL[16:26:52] *** thetourist has joined ##OpenGL[16:28:47] *** Zupoman has joined ##OpenGL[16:28:47] *** Zupoman has joined ##OpenGL[16:33:11] *** lenarhoy1 has joined ##OpenGL[16:37:47] *** razieliyo has joined ##OpenGL[16:37:47] *** razieliyo has joined ##OpenGL[16:39:58] <lenarhoy1> what is the correct way of converting texel coordinates [0,800)x[0,600)_N to uv-coordinates [0,1]x[0,1]_R?[16:40:41] *** petervaro has joined ##OpenGL[16:40:45] <lenarhoy1> i'm sure I'm missing a -1 or +vec2(0.5) somewhere because the result is slighly blurred[16:41:56] <lenarhoy1> right now i'm doing this: uv = vec2(1/800.0, 1/600.0) * ivec2(x, y);[16:42:10] *** thetourist has quit IRC[16:43:05] *** foreignFunction has quit IRC[16:44:22] <lenarhoy1> hmm, it's not vec2(1.0/799.0, 1/599.0) either[16:44:28] <urraka> maybe try that but with 0.5 pixel offset on the vertices[16:44:50] <lenarhoy1> fragments?[16:44:52] <urraka> i mean 1/800,1/600[16:44:55] <ClaudiusMaximus> lenarhoy1: you could probable use GL_NEAREST filter to get a sharp image at 1:1 pixel:texel scaling[16:44:55] *** xissburg has joined ##OpenGL[16:45:14] <lenarhoy1> ClaudiusMaximus: but I need the linear filter elsewhere[16:46:11] <lenarhoy1> texelFetch(tex, uv, mip) doesn't interpolate but the access is slower, correct?[16:47:23] <lenarhoy1> hm, maybe not[16:48:25] <Bloodust> umm vec2(1/800.0, 1/600.0) is correct[16:50:09] *** pazul has quit IRC[16:51:34] <derhass> lenarhoy1: why would fetching texels be slower?[16:53:33] <lenarhoy1> yeah, it's probabaly about the same[16:54:05] <lenarhoy1> works fine now, but I'm still wondering why it was blurred with 1/800.0, 1/600.0[16:56:31] <derhass> well. if your texture is 800x600, the tex coord (1/900, 1/600) is exactly at the corner between 4 texels, so with bilinear filter, you average all four of them[16:56:37] <derhass> *800[16:57:17] *** anivemin has joined ##OpenGL[16:57:18] *** tz has quit IRC[16:57:37] *** katlogic has quit IRC[16:58:57] *** Twinklebear has joined ##OpenGL[16:59:31] *** damir__ has joined ##OpenGL[17:00:32] *** zoraj has joined ##OpenGL[17:02:00] *** anivemin has quit IRC[17:02:47] *** katlogic has joined ##OpenGL[17:03:33] *** tz_ has joined ##OpenGL[17:04:03] *** tz_ is now known as tz[17:05:03] <newguise1234> are uniform locations a separate count than varying locations?[17:06:00] <newguise1234> ie. can I have a (layout location=0) in vec3 Position; (layout location=0) uniform mat4 Perspective;[17:06:21] <newguise1234> s/(layout /layout(/[17:07:37] *** Waynes has quit IRC[17:08:04] *** Waynes has joined ##OpenGL[17:09:34] *** hdon has quit IRC[17:11:13] *** gaganjyot has joined ##OpenGL[17:13:53] <newguise1234> Can you set a VAO to have glVertexAttribPointers that point to data in multiple GL_ARRAY_BUFFERS? just by binding different buffers between calls of glVertexAttribPointer?[17:14:46] <Madsy> newguise1234: Yes each vertex array has an associated buffer binding point[17:14:55] <Madsy> As a part of the VAO state[17:14:57] <elveni> what physics engines do you guys use on your opengl projects?[17:15:05] <elveni> i'm torn between physx and bullet myself.[17:15:09] <Madsy> newguise1234: look at the state tables in the OpenGL spec[17:21:20] <japro> rawtass, uh, you don't read from the framebuffer[17:21:26] <japro> you read from the textures attached to them[17:21:38] <japro> and the textures you can access however you want[17:22:00] <japro> well actually the problematic case is reading from the one that you are rendering to ;)[17:24:16] <Bloodust> elveni physx[17:24:52] <newguise1234> Thanks Madsy I've the spec downloaded now[17:30:15] *** tz has quit IRC[17:31:12] *** tz has joined ##OpenGL[17:31:44] *** seangrove has joined ##OpenGL[17:39:22] <newguise1234> does glEnableVertexAttribArray enable an attribute for a vao or for a program, or is it enabled in general and you have to make sure the proper attributes are enabled/disabled on every draw call[17:40:25] *** tcsc has quit IRC[17:40:55] <newguise1234> just read the errors box, it looks like it requries a vao to be bound, so I'll go with that[17:44:16] *** Alina-malina has quit IRC[17:45:17] *** Alina-malina has joined ##OpenGL[17:57:03] *** RyanPridgeon has joined ##OpenGL[17:57:52] *** Alina-malina has quit IRC[17:58:00] *** lenarhoy1 has quit IRC[17:58:06] *** samrat has joined ##OpenGL[18:02:44] *** Alina-malina has joined ##OpenGL[18:06:54] *** HaltingState has quit IRC[18:09:33] *** TunnelCat has quit IRC[18:13:21] *** nitroxis has quit IRC[18:13:30] *** nitroxis has joined ##OpenGL[18:15:37] *** Portals has quit IRC[18:16:06] *** DolpheenDream has joined ##OpenGL[18:16:16] *** Crehl_ has joined ##OpenGL[18:16:36] *** HarbingTarbl has quit IRC[18:16:38] *** ValicekB has quit IRC[18:19:28] *** Crehl has quit IRC[18:19:57] *** HarbingTarbl has joined ##OpenGL[18:26:18] *** HaltingState has joined ##OpenGL[18:32:32] *** ValicekB has joined ##OpenGL[18:36:32] *** kidnapped_robot has quit IRC[18:38:57] *** xdrone has quit IRC[18:39:41] *** voidstar has quit IRC[18:40:57] <Budd> Is it possible to have the GPU calculate per-triangle normals internally in OpenGL ES? I'm thinking no, from the docs I find...[18:43:57] *** zoraj_ has joined ##OpenGL[18:46:02] *** anivemin has joined ##OpenGL[18:46:04] *** zoraj has quit IRC[18:46:51] *** kidnapped_robot has joined ##OpenGL[18:50:02] *** ison has joined ##OpenGL[18:50:13] <ison> Hello. So I'm using a technique to render many low-poly models, where I batch all meshes into 1 big mesh. I have to generate 1 texture atlas with all textures, and change tex coords for all meshes to match new texture atlas. It works great, but I found 1 problem. What if a tex coord is not in range <0,1>? For example, if someone sets tex coord = 10,10 then my technique will fail, because texture can't be repeated 10 times this way, bec[18:50:18] <ison> ). Is it common for 3d models to have tex coords not in range <0,1>?[18:50:52] *** anivemin has quit IRC[18:53:33] <katlogic> you have to wrap inside the frag shader[18:53:49] <katlogic> which is source of major performance hit with atlases[18:54:29] *** Ryp has quit IRC[18:54:36] <katlogic> one workaround is to repeat each tile in the atlas few times, and making sure the mesh polys are never bigger than that[18:54:45] <katlogic> (fixes bleeding issues too)[18:54:46] <ison> hmm, damn[18:55:03] <ison> but then, I'd need extremely large atlas[18:55:07] <katlogic> yes[18:55:12] <ison> is it common for models to have tex coords not in range <0,1>?[18:55:25] *** thetourist has joined ##OpenGL[18:55:28] <katlogic> huh?[18:55:42] <katlogic> yes. when texture is repeated.[18:56:02] <ison> hmm, ok[18:56:15] *** Orion] has joined ##OpenGL[18:56:21] <katlogic> its unrelated to model though, uv is whatever vert shader outputs[18:56:40] *** thetourist has quit IRC[18:56:47] <ison> unrelated to model? UVs are specified for each vertex by someone who makes the model[18:56:54] *** tz has quit IRC[18:57:11] *** hexagoxel_ has joined ##OpenGL[18:57:33] *** Portals has joined ##OpenGL[18:57:46] <katlogic> commonly, along with normals[18:57:48] <katlogic> but not necessarily[18:58:02] <katlogic> in any case, yes, it can be more than 0-1[18:58:06] <ison> I've never seen any 3d model without UVs specified by someone who made the model[18:58:12] <katlogic> 0-8 simply means repeat texture 8 times[18:58:25] <katlogic> assuming top left is 0,0 and down bottom is 8,8[18:58:40] <ison> seems like the only way is to repeat tex coords in frag shader[18:58:55] <katlogic> yes, simply use a wrap[18:59:03] <katlogic> usually two fract() and few mults will do[18:59:08] <katlogic> no need for conditionals[18:59:09] <ison> or just make sure that tex coords are always 0-1[18:59:25] <katlogic> you can fragment the model too[18:59:31] <katlogic> depends what your models look like[18:59:58] <ison> after all I think it's not very common to repeat textures on models in games[18:59:58] <ison> or is it[19:00:06] <katlogic> once again[19:00:07] <katlogic> depends[19:00:17] <katlogic> dont go by whats common, go by what you need :)[19:00:57] <ison> I'm using texture atlas for distant objects, they are batched into 1 big model[19:01:05] *** hexagoxel has quit IRC[19:01:26] <katlogic> yes, for lod projection you dont generally need a repeat[19:01:43] <katlogic> depends how you actually the lod[19:02:12] <katlogic> or you mean mipmap?[19:02:34] <ison> I meant LOD[19:02:37] <ison> a different model[19:02:38] <ison> low poly[19:02:41] <katlogic> yes[19:03:04] <katlogic> in that case depnds how you generate the model[19:03:05] <ison> also I use it for low-poly static objects, such as rocks[19:03:08] <katlogic> assuming you just reduce the mesh[19:03:14] *** Plasmastar has quit IRC[19:03:16] <katlogic> just make sure to have no repeated textures[19:03:23] <ison> they aren't generated, they should be pre-made as 3d model[19:03:27] <katlogic> ugh[19:03:38] <ison> is it a bad idea?[19:03:41] <katlogic> well[19:03:49] <katlogic> its tricky[19:03:57] <katlogic> to make it not look ugly[19:04:09] <katlogic> generated lod meshes are seamless transition[19:04:16] <katlogic> manually done ... usually not[19:05:09] <ison> hmm, for high poly models probably yes, but in my game, most of the models are low-poly anyway[19:05:11] <katlogic> ison: but its being done both ways in any case[19:05:29] *** foreignFunction has joined ##OpenGL[19:05:43] <ison> I'm using a lot of low-poly models, like 100k models[19:05:56] <katlogic> 100k poly is low poly? :)))[19:06:02] <ison> 100k models, not poly[19:06:17] <katlogic> well, 100k is a lot[19:06:24] *** Plasmastar has joined ##OpenGL[19:06:46] <katlogic> depends if its simple brushes (ie source engine like), or complex models[19:07:32] *** Sos has joined ##OpenGL[19:07:45] <Khlorghaal> if a transparent surface is lit, is color= a*light*rgb + (1-a)*refracted*rgb ?[19:08:14] <ison> http://i58.tinypic.com/11j6k4p.png[19:08:34] *** anivemin has joined ##OpenGL[19:09:14] <katlogic> ison: i have no idea what that is[19:09:26] <ison> this is 100k low poly models[19:09:34] <ison> :P[19:09:44] <katlogic> well, if you're cloning minecraft, dont bother with lod[19:09:53] <katlogic> bottleneck is elsewhere[19:10:07] <ison> where is? I'm not using cubes for terrain[19:10:12] <katlogic> notably the enormous overdraw[19:10:21] <ison> I think my bottleneck will be having to render a lot of low-poly models placed by player[19:10:25] <katlogic> yes[19:10:58] <katlogic> whatever you do, you need to simplify whatever mesh you have[19:11:11] <katlogic> stupidly repeating it is just minecraft[19:11:21] <katlogic> ie immense resource usage for very simple/ugly thing[19:12:35] <ison> why repeating models is minecraft? I need to render a lot of trees and rocks, they are repeated, yet it's not a minecraft[19:13:14] <katlogic> well, with terrain its slightly easier than voxels[19:13:22] <katlogic> but still pretty tricky[19:13:28] <katlogic> terrain is all about dynamic lod :)[19:13:47] <ison> terrain is not a problem as I said before, I don't have a terrain made of voxels or cubes or whatever[19:13:53] <ison> I'm using 'normal' terrain with dynamic lod[19:14:04] <katlogic> not just heightmap[19:14:07] <katlogic> grass and forests too[19:14:10] <katlogic> (are lod)[19:14:23] <ison> hmm, for trees I just change them to billboards[19:14:30] <ison> if they are far away[19:14:42] <katlogic> yeah that works fairly[19:14:47] <ison> yet I still find low-poly models more efficient than using depth-sorted billboards[19:15:18] <katlogic> if you can live with the alpha-transition, then by all means[19:15:43] * katlogic thinks alphatrans is ugly, but its a cheap trick, so if the point is to keep it simple ...[19:15:53] <ison> what's alpha transition[19:16:00] <katlogic> transition of lod jump[19:16:14] <katlogic> you render both, near and far and alpha between em[19:16:16] <ison> not a big problem I guess[19:16:20] <ison> lod jumps[19:16:28] <katlogic> engines like oblivion its where its really ugly[19:16:52] *** cr`nge has joined ##OpenGL[19:16:56] *** paperManu has joined ##OpenGL[19:17:48] <katlogic> ison: in any case, you want everything as single mesh[19:17:55] <katlogic> 100k is way too much, even with instancing[19:18:14] <katlogic> instances are just for thing which must be kept separate (ie actual moving objects)[19:19:30] <ison> why too much?[19:19:34] <ison> it runs at 100 fps[19:19:51] <katlogic> here it would run 3fps[19:19:55] <katlogic> (mobile :)[19:20:09] <ison> on mobile ye, I guess[19:20:14] <katlogic> but by all means[19:20:28] <katlogic> if your intent is supporting nvidia, i guess its ok[19:20:32] <katlogic> to go minecraft style[19:20:52] <ison> why only nvidia?[19:20:59] <katlogic> any big iron vendor :)[19:21:04] <Bloodust> cant do minecraft with instancing :P[19:21:06] <katlogic> ison: try it on intel gma or tegra[19:21:13] <katlogic> those things can easily render 5 million tris[19:21:18] <katlogic> but only 50k instances[19:21:29] <katlogic> if youre lucky (tegra)[19:21:34] <katlogic> or 5k instances if not (intel)[19:21:55] <ison> these are for mobiles arent they?[19:22:22] <katlogic> Bloodust: in this case i meant having mad hardware requirements for simple things :)[19:22:41] <katlogic> ison: how many tris? :)[19:22:56] <ison> dunno yet[19:23:04] <japro> well, if requiring more than an intel gma counts as "mad requirements" something is wrong ;)[19:23:12] <ison> what is mad requirements[19:23:27] <japro> what would low requirements be then? voodoo3?[19:23:27] <katlogic> japro: for stuff like 500k tris, even intel can cope with it :)[19:23:50] <japro> i assume with gma he means the pre HD graphics stuff you find in netbooks etc.[19:24:03] *** zzuegg has joined ##OpenGL[19:24:05] <japro> he, you, whoever... :)[19:24:19] <katlogic> nah[19:24:28] <katlogic> intel hd is still pretty crappy[19:24:40] <katlogic> with lots of small meshes instanced[19:24:47] *** aethersis has joined ##OpenGL[19:25:13] <derhass> well, intel hp is a huge leap forward compared to gma[19:25:33] <derhass> gma is just unusable for almost everything by this decade's standards[19:25:41] <derhass> *HD[19:26:00] <katlogic> hd 5000 here, its horrible :)[19:26:15] <katlogic> but can do 5m tris at 30fps, so i guess its better than gma/voodoo3[19:26:19] <katlogic> which can only dream of that fill rate[19:26:43] <japro> anyway 100k objects are suspicious. i mean there is a big difference between "i have 100k objects in my world/scene" and "I need to render 100k objects"[19:27:02] <katlogic> yeah[19:27:03] <japro> 100k objects on the screen means they average like 20px? :D[19:27:06] <ison> japro for open-worlds its the same[19:27:12] <japro> so, 4x4 or so?[19:27:23] <ison> japro http://i58.tinypic.com/11j6k4p.png[19:27:27] *** tz has joined ##OpenGL[19:27:34] <ison> 100k is not a lot[19:27:42] <katlogic> ison: you can do hybrid approach for open world.[19:28:02] <katlogic> non-moving things all in few meshes merged, recompute mesh as neeeded[19:28:09] <japro> ison, that is a pathological case i'd claim. unless you are writing "endless storage space simulator 2015"[19:28:33] *** razieliyo has quit IRC[19:28:34] *** razieliyo_ has joined ##OpenGL[19:28:35] <ison> japro just replace the pistol models with tree objects[19:28:38] <japro> like each level of culling you add already cuts out like one order of magnitude[19:28:53] <ison> katlogic that's eaxctly how I do it currently[19:29:01] <katlogic> and you end up with 100k meshes?[19:29:03] <katlogic> ugh[19:29:03] <ison> I store static objects in several VBOs[19:29:28] <katlogic> ison: oh, in that case its not really 100k objects drawn, or is it?[19:29:30] <katlogic> or better said[19:29:35] <ison> they are not rendered as 100k drawindexedtriangle list calls[19:29:39] <katlogic> do you draw each individual tree, or a forest mesh?[19:29:51] <ison> katlogic a forest mesh, merged at runtime[19:30:14] <katlogic> well, in that case your uv problem is non-issue[19:30:20] <katlogic> simply make sure you have no repeating textures :)[19:30:33] <ison> indeed[19:31:11] <katlogic> or better yet[19:31:15] *** pauldachz has joined ##OpenGL[19:31:16] <katlogic> make those special case vbo[19:31:30] <katlogic> and special shader which knows how to wrap around[19:32:06] <katlogic> as those things are usually special anyway (ie water surface)[19:32:07] <ison> the problem is that I found almost all models to have UVs not in range 0,1[19:32:19] *** aethersis is now known as dreamminder[19:32:21] <ison> I mean, when I used to make 3d models I've never used UVs different than 0-1[19:32:31] <katlogic> ugh[19:32:36] <ison> but, for example, almost all battlefield models use it[19:32:36] <katlogic> well, lots of repeating going on then[19:32:39] <ison> like UV -0.5[19:32:45] <katlogic> oh[19:32:57] <katlogic> yeah, depends how its interpreted btw[19:33:11] <katlogic> whatever the model has on it is insignificant, the point is what you end up with in frag shader[19:33:22] <katlogic> vert/geom shaders might transform it from some special encoding[19:34:30] <ison> btw. does anyone nowadays implement lighting other than deferred lighting?[19:34:40] <ison> does any game use forward rendering?[19:36:49] <krnlyng> hi, i have a weird issue. the following code causes a segfault if WTH_EXTRA is set to 0: https://bpaste.net/show/f64bcdfe4c5b (but the segfault doesn't happen anywhere in the code it actually happens later so i assume some memory overwriting happens) yet if i set WTH_EXTRA to 4 it works, why could that be? also the code does not crash if i comment this line: glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, 0, colors); another thing, it also produces garbage o[19:36:50] <krnlyng> n screen if anyone can see why from this short pice of code i'd be very happy :)[19:37:33] *** shingshang has quit IRC[19:37:48] *** Dark_Confidant has joined ##OpenGL[19:37:54] <glYoda> "usually two fract() and few mults will do" …uh no: srcCoords - floor( srcCoords ) is all you'll need[19:38:10] *** anivemin has quit IRC[19:38:28] <glYoda> assuming one wants the standard REPEAT behavior available within the GL[19:38:37] <Portals> aaaaaaaaaaarghhhh å[19:38:49] <katlogic> glYoda: isn't that fract()? :)[19:39:03] <glYoda> katlogic note what I quoted[19:39:13] <glYoda> and note why I responded the way I did[19:39:14] <glYoda> heh[19:39:24] <katlogic> glYoda: i suck at trivia and mind reading[19:39:35] <glYoda> there is no "two" of anything here[19:39:48] <katlogic> glYoda: x and y[19:39:57] <glYoda> nor is there any use of multiply[19:40:04] <glYoda> explicitly that is[19:40:25] <glYoda> katlogic realize that we have a vector builtin for floor as well as fract[19:40:38] <glYoda> and in fact those might very well be implemented in a vector form[19:40:48] <glYoda> (at the ISA level)[19:40:54] *** Dark_Confidant|m has quit IRC[19:41:11] <glYoda> in any case my point stands you'll need a subtract as well as a call to floor[19:42:23] <glYoda> working around what the GLSL gives you (i.e. attempting to manually create the various builtins for instance) isn't a wise idea[19:42:33] <japro> glYoda, i always fract(fract(x)) to make really sure[19:42:46] <glYoda> :P[19:44:45] *** samrat has quit IRC[19:45:35] *** Match has quit IRC[19:52:17] *** DrBenway has quit IRC[19:54:39] *** BlackFox has quit IRC[19:54:47] *** ManDay has quit IRC[19:55:06] *** BlackFox has joined ##OpenGL[19:55:39] *** BlackFox has quit IRC[19:55:57] *** BlackFox has joined ##OpenGL[19:56:16] *** Misu2 has joined ##OpenGL[19:57:29] *** Misu has quit IRC[19:58:20] *** Portals has quit IRC[19:58:45] *** Jubb has quit IRC[19:59:46] *** Misu has joined ##OpenGL[20:00:50] *** Keniyal_ has joined ##OpenGL[20:01:04] *** erihel has quit IRC[20:01:19] *** gareppa has joined ##OpenGL[20:03:29] *** Misu2 has quit IRC[20:04:02] *** Keniyal has quit IRC[20:10:26] *** SleekoNiko has quit IRC[20:11:59] *** SleekoNiko has joined ##OpenGL[20:12:18] *** Gamecubic has quit IRC[20:12:47] *** Gamecubic has joined ##OpenGL[20:13:02] *** BlackFox has quit IRC[20:13:22] *** HarbingTarbl has quit IRC[20:13:40] *** gaganjyot has quit IRC[20:13:48] *** BlackFox has joined ##OpenGL[20:19:11] *** Twey has quit IRC[20:20:42] *** neure has quit IRC[20:21:55] *** Twey has joined ##OpenGL[20:23:20] *** fatalhalt has joined ##OpenGL[20:25:18] *** tz has quit IRC[20:26:01] *** tz has joined ##OpenGL[20:30:49] *** junaidnaseer2 has joined ##OpenGL[20:31:00] *** CainJacobi has joined ##OpenGL[20:32:52] *** Sos has quit IRC[20:33:10] *** Garner has quit IRC[20:35:20] *** Sos has joined ##OpenGL[20:35:31] *** DolpheenDream has quit IRC[20:37:09] *** Majiet has joined ##OpenGL[20:43:48] *** petervaro has quit IRC[20:44:31] *** james4k has joined ##OpenGL[20:45:36] *** Syzygy_ has quit IRC[20:46:56] *** zoraj__ has joined ##OpenGL[20:49:28] *** james4k has quit IRC[20:50:04] *** zoraj_ has quit IRC[20:58:36] *** paperManu has quit IRC[21:03:06] *** Madsy has quit IRC[21:06:22] <Khlorghaal> how much faster is glcopypixels than drawing a fullscreen quad with passthrough texelFetch?[21:06:47] *** Madsy has joined ##OpenGL[21:06:48] *** Madsy has joined ##OpenGL[21:06:55] <Khlorghaal> although im stencil testing, so i suppose i dont have a choice[21:09:30] <Yaniel> for just copying thee is also glBlitFramebuffer[21:10:39] *** dreamminder has quit IRC[21:12:59] *** petervaro has joined ##OpenGL[21:13:05] *** Ad1_RnR has joined ##OpenGL[21:13:57] *** james4k has joined ##OpenGL[21:14:49] *** bjz has quit IRC[21:15:10] *** Garner has joined ##OpenGL[21:15:19] *** groton has joined ##OpenGL[21:16:44] *** Ad1_RN has quit IRC[21:18:32] *** pazul has joined ##OpenGL[21:19:54] *** ragecryx has joined ##OpenGL[21:20:57] *** bjz has joined ##OpenGL[21:22:47] <glYoda> "how much faster is glcopypixels than drawing a fullscreen quad with passthrough texelFetch?" …in terms of the underlying "blit" operation you'll find the two pretty comparable… the same is true for BlitFramebuffer[21:23:18] <glYoda> the primary difference is in the realm of validation / state setting overhead[21:23:28] *** fatalhalt has quit IRC[21:23:48] *** ZeuPiark has joined ##OpenGL[21:24:12] <glYoda> at least for cases where one doesn't have a faster (i.e. dedicated) blit path to invoke on the driver side[21:24:41] *** MiniCow has quit IRC[21:24:45] <glYoda> i.e. something the client won't have access to when using a FS quad with texelFetch[21:25:27] <glYoda> (multisample blit would be a good example of that BTW)[21:25:50] *** groton has quit IRC[21:27:05] *** MiniCow has joined ##OpenGL[21:28:49] *** pazul has quit IRC[21:30:40] *** groton has joined ##OpenGL[21:33:18] *** cr`nge has quit IRC[21:35:33] *** bb010g has joined ##OpenGL[21:36:42] *** bjz has quit IRC[21:40:46] *** pazul has joined ##OpenGL[21:44:11] *** Djstey|away is now known as Djstey[21:45:05] *** redpill has joined ##OpenGL[21:47:16] *** cr`nge has joined ##OpenGL[21:47:19] *** piark has joined ##OpenGL[21:47:19] *** ZeuPiark has quit IRC[21:47:48] *** piark has quit IRC[21:51:34] *** ikrima has quit IRC[21:51:35] *** Keniyal has joined ##OpenGL[21:51:54] *** HaltingState has quit IRC[21:52:29] *** HaltingState has joined ##OpenGL[21:53:51] *** erihel has joined ##OpenGL[21:55:00] *** groton has quit IRC[21:55:05] *** Keniyal_ has quit IRC[21:55:58] *** agorecki has joined ##OpenGL[21:59:53] *** devbug has joined ##OpenGL[22:01:00] *** agorecki has quit IRC[22:01:22] *** agorecki has joined ##OpenGL[22:09:32] *** HunterD has quit IRC[22:10:38] *** petervaro has quit IRC[22:14:08] *** Keniyal_ has joined ##OpenGL[22:14:37] *** PasNox has quit IRC[22:17:28] *** Keniyal has quit IRC[22:24:06] *** yaakuro has joined ##OpenGL[22:29:58] *** aethersis has joined ##OpenGL[22:29:58] *** aethersis is now known as dreamminder[22:30:34] *** konom has quit IRC[22:31:51] *** gareppa has quit IRC[22:41:05] *** dreamminder has quit IRC[22:53:18] *** cr`nge has quit IRC[22:59:49] *** pazul has quit IRC[23:04:52] *** ison has quit IRC[23:06:39] *** MLM has joined ##OpenGL[23:07:16] *** Kane has quit IRC[23:08:36] *** rawtass has quit IRC[23:11:48] *** pazul has joined ##OpenGL[23:12:42] *** Bigpet_ has quit IRC[23:14:01] *** centrinia has joined ##OpenGL[23:16:15] *** Waynes has quit IRC[23:21:36] *** telex has quit IRC[23:22:46] *** telex has joined ##OpenGL[23:23:49] *** losh has joined ##OpenGL[23:26:53] *** pazul has quit IRC[23:33:43] *** kuldeepdhaka has joined ##OpenGL[23:38:39] *** pazul has joined ##OpenGL[23:42:54] *** foreignFunction has quit IRC[23:46:38] *** realz has quit IRC[23:47:07] *** stefkos has quit IRC[23:48:16] *** karab44 has quit IRC[23:57:03] *** Zupoman has quit IRC[23:57:30] *** Zupo2 has joined ##OpenGL