February 16, 2018 
< | 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 | >
February 16, 2018 [00:03:49] <Fr0stBit> chrisf, Stragus: Does this seem ok? http://lpaste.net/3469071164020621312[00:05:09] <Fr0stBit> Cause if it does, we are down on 2ms![00:05:21] <Stragus> No, you want the nearby threads of a same warp to load consecutive memory locations, like you had before[00:05:34] <Stragus> Now they always have a 2 pixels gap[00:06:02] <Stragus> And you need to replace ImageLoad() by texelFetch()[00:06:17] <Stragus> And you should put the texelFetch() in the same loop that does the shared memory atomic adds[00:06:24] <Fr0stBit> Stragus: can you give me an example on how should i sample them?[00:06:27] *** raynold <raynold!uid201163@gateway/web/irccloud.com/x-ztesgjmqzhqgnjij> has quit IRC (Quit: Connection closed for inactivity)[00:06:34] <Stragus> Always avoid any kind of indexing in local memory, you want everything in registers[00:08:13] <Stragus> For example, a block of 16x16 threads can load a tile of 16x16 pixels on first iteration, then the next 16x16 "right" or "below" on the second iteration, etc.[00:11:05] <Fr0stBit> Stragus: so essentially each thread should do as many fetches as the group size?[00:12:36] <Stragus> No... something like 8 or 16 fetches, for a total thread count in the 5 digits[00:15:23] *** ignatiz- <ignatiz-!~scott@82.138.221.18> has quit IRC (Ping timeout: 256 seconds)[00:16:10] <chrisf> sparse sampling of luminance is also typically /fine/[00:16:19] <Stragus> The most important part is probably texelFetch(), I suspect imageLoad() does a direct memory load[00:18:05] <Fr0stBit> Stragus: should i change image2D to sampler2D too?[00:18:24] <chrisf> yes, and imageSize -> textureSize (or to a uniform)[00:19:35] <chrisf> Stragus: got a number this should be able to hit?[00:19:51] <Fr0stBit> I suppose instead of glBindImageTexture i should do the traditional glActiveTexture and glBindTexture too?[00:20:34] <Stragus> chrisf: I don't have much experience with low-end chips... and Nvidia says the GT640 has either 144 or 384 CUDA cores (eh?!)[00:20:44] <Stragus> Yes, old good traditional texture[00:20:53] <chrisf> Stragus: there's a bunch of things called a GT640[00:21:05] <Stragus> So it seems[00:21:11] <chrisf> Stragus: low end parts are a mess for rebadges[00:21:30] <chrisf> but im going to say 500us.[00:24:09] *** BearishMushroom <BearishMushroom!~BearishMu@82-209-154-59.cust.bredband2.com> has quit IRC (Read error: Connection reset by peer)[00:25:48] <chrisf> we used to do exposure adaptation on barely programmable potatoes, this doesnt have to be slow[00:26:46] <Stragus> I would rather pick 256 random samples (each blending 4 pixels) each frame, if it's just to get an idea of the exposure[00:27:44] <Fr0stBit> What about this: http://lpaste.net/3469071164020621312[00:27:44] <chrisf> still not fond of that barrier(); groupMemoryBarrier(); order[00:29:00] <Stragus> Your loads still have gaps, now 4 pixel gaps instead of 2[00:29:49] <chrisf> Fr0stBit: consider that texelFetch is actually 64 fetches together. you'd like them to be a coherent block[00:30:07] <chrisf> Fr0stBit: and then the next fetch should be another 16x16 coherent block[00:30:23] <chrisf> how's the perf, though?[00:31:13] <Fr0stBit> Stragus: do you mean that instead of blocks, i should try and load the subsequenced texels?[00:31:27] <Fr0stBit> chrisf: Gotten bad actually. 6ms[00:31:30] <Stragus> For that histogram of yours, would it be reasonable to get samples each blending 4 pixels? Instead of every single pixel individually[00:31:35] <Stragus> Yes, that's worse[00:31:43] <Stragus> You don't seem to understand the coherent memory access part[00:31:52] <Fr0stBit> Nop i don't[00:32:36] <Stragus> The threads of your block need to load consecutive memory locations as they execute concurrently/simultaneously[00:32:45] <Stragus> Thread 0 loads value 0, thread 1 loads value 1, etc.[00:32:56] <Stragus> Now, your thread 1 loads the value 4[00:34:05] <chrisf> Fr0stBit: you might instead load gl_GlobalInvocationID.xy + ivec2(16 * i, 0)[00:35:00] <chrisf> hang on, no, that's not right :)[00:35:57] <chrisf> more coffee :)[00:36:05] <Stragus> That c[] needs to go away, texelFetch() in same loop as atomicAdd()[00:37:11] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[00:37:16] <Fr0stBit> So something like this? http://lpaste.net/3469071164020621312[00:37:48] <chrisf> 16 is the wrong stride, im insufficiently caffeinated :)[00:38:14] *** Quetzal2 <Quetzal2!~Quetzal2@unaffiliated/quetzal2> has quit IRC (Remote host closed the connection)[00:38:55] *** qeed <qeed!~qeed@pool-98-118-249-109.clppva.fios.verizon.net> has quit IRC (Quit: Leaving)[00:39:07] <Stragus> That's better[00:39:17] *** qeed <qeed!~qeed@pool-98-118-249-109.clppva.fios.verizon.net> has joined ##OpenGL[00:39:37] <Stragus> You need to precompute 1.0/(lum_max - lum_min), don't perform a division by a constant in a shader[00:40:49] <chrisf> fetch stride should be src_width/(16*16) by the looks of it[00:40:59] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Remote host closed the connection)[00:41:22] <Fr0stBit> chrisf: So gl_WorkGroupID.x?[00:42:05] <Fr0stBit> I meant gl_WorkGroupSize.x[00:42:08] <chrisf> scratch that, ceil(src_width/16).[00:43:07] <Fr0stBit> chrisf: Could you explain?[00:43:58] <Fr0stBit> Stragus: Cause divisions are costly?[00:45:38] <chrisf> Fr0stBit: work out the pattern you want. the problem with the stride of 16 is the (1,0) group's i=0 fetch hits the same texels as the (0,0) group's i=1 fetch[00:46:36] <Fr0stBit> By the way, we are at 2.5ms![00:53:00] <chrisf> Fr0stBit: what's your budget for this pass?[00:55:24] <Fr0stBit> chrisf: Well, i'm just learning, and trying to make everything as fast as possible[01:05:26] *** LurchMan <LurchMan!~LurchMan@8.28.55.10> has joined ##OpenGL[01:06:24] <Fr0stBit> Also image load <-> texelFetch do not seem to have any difference[01:06:34] <Fr0stBit> With current context[01:07:02] <chrisf> did you get rid of the imageSize/textureSize ?[01:07:24] <chrisf> im curious as to its actual cost on that hw[01:08:31] *** acksys_ <acksys_!~fritz@mail12.shutterfly.com> has quit IRC (Ping timeout: 248 seconds)[01:13:29] <Stragus> Fr0stBit: Yes, divisions are slower and/or inaccurate compared to multiplications[01:14:35] <Fr0stBit> chrisf: yes i dit[01:14:36] <Stragus> So the drivers were clever enough to do the imageLoad() through the texture cache, that's good[01:15:40] <Stragus> If you were to use texture() to blend 4 pixels together, instead of retrieving each one, would that be too inaccurate for your histogram?[01:15:50] <Stragus> (with GL_LINEAR sampling)[01:17:25] <Fr0stBit> Stragus: nah, i think that would be ok[01:17:31] <Fr0stBit> I'll try it tomorrow and report back[01:17:40] <Stragus> That should provide quite a boost[01:18:28] *** Gama11 <Gama11!~quassel@p5DCDB9A1.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)[01:21:28] <chrisf> there's LOTS of perf to be gained if you're willing to trade off accuracy[01:22:08] *** Thaelim <Thaelim!~Thaelim@2601:281:c502:25d9:2de0:420e:4516:74e0> has joined ##OpenGL[01:22:29] *** thoys <thoys!~thoys@D47FB007.cm-9-1a.dynamic.ziggo.nl> has quit IRC (Ping timeout: 255 seconds)[01:23:55] <chrisf> (and you should be; user cant tell how precise you're being)[01:24:33] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has joined ##OpenGL[01:25:05] <Stragus> It's good to begin with an accurate slow version, at least to compare how accurate any quick approximation will be[01:30:51] *** xerpi <xerpi!~xerpi@98.red-83-45-194.dynamicip.rima-tde.net> has quit IRC (Quit: Leaving)[01:31:33] *** Thaelimm <Thaelimm!~Thaelim@2601:281:c502:25d9:2de0:420e:4516:74e0> has joined ##OpenGL[01:32:25] *** Thaelimm <Thaelimm!~Thaelim@2601:281:c502:25d9:2de0:420e:4516:74e0> has quit IRC (Remote host closed the connection)[01:32:25] *** Thaelim <Thaelim!~Thaelim@2601:281:c502:25d9:2de0:420e:4516:74e0> has quit IRC (Read error: Connection reset by peer)[01:32:48] *** Thaelimm <Thaelimm!~Thaelim@2601:281:c502:25d9:2de0:420e:4516:74e0> has joined ##OpenGL[01:34:18] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Ping timeout: 265 seconds)[01:34:50] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[01:34:53] <Fr0stBit> Stragus, chrisf: What other tricks can i do, to reduce accuracy and gain performance?[01:35:10] <chrisf> do less[01:35:14] <chrisf> do it less often[01:35:24] <chrisf> roll it in with something else you're doing to the same data anyway[01:35:37] *** thoys <thoys!~thoys@D47FB007.cm-9-1a.dynamic.ziggo.nl> has joined ##OpenGL[01:36:40] *** Neomex <Neomex!~quassel@net-37-117-5-106.cust.vodafonedsl.it> has quit IRC (Remote host closed the connection)[01:36:49] <chrisf> your eyes are slow at this, you dont need to do this every frame[01:38:52] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has quit IRC (Quit: Leaving)[01:39:55] <ClaudiusMaximus> i sped up some histogram equalisation code by realizing i didn't need 15bit or whatever it was accuracy, as my display is only 8bit, so my binary search could stop a few iterations earlier (would have been more sensible to downscale the histogram as well, didn't get around to that yet)[01:42:35] <chrisf> not even getting to the point of processing the histogram yet -- this is just a CS pass to build it :)[01:44:49] *** derhass <derhass!~derhass@dslb-094-222-155-209.094.222.pools.vodafone-ip.de> has quit IRC (Quit: leaving)[01:57:20] *** Tobbi <Tobbi!~Tobbi@supertux/tobbi> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)[01:58:38] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7n8nco8egy36si.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 255 seconds)[01:59:27] *** kasumi-owari <kasumi-owari!~kasumi-ow@ftth-213-233-237-007.solcon.nl> has quit IRC (Ping timeout: 240 seconds)[02:02:03] *** kasumi-owari <kasumi-owari!~kasumi-ow@ftth-213-233-237-007.solcon.nl> has joined ##OpenGL[02:04:54] *** ipe <ipe!~ipe@91-156-244-112.elisa-laajakaista.fi> has quit IRC (Read error: Connection reset by peer)[02:16:05] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[02:16:27] <pushrax> I love how easy it is to generate a histogram now though[02:17:17] *** Kingsquee <Kingsquee!~kingsquee@d108-180-237-219.bchsia.telus.net> has quit IRC (Quit: Just Monica.)[02:17:52] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Remote host closed the connection)[02:18:07] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[02:18:08] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Remote host closed the connection)[02:18:48] <pushrax> I feel so lucky that I'm only working on projects targeting really recent GL[02:20:00] <chrisf> for actual things im inclined to kill automatic adaptation and make it designer controlled[02:21:24] <chrisf> and if anyone is looking at a histogram it's a designer pretending they know how to do color grading[02:22:30] <pushrax> designer-controlled clamps and bias on the histogram can work really well though[02:23:27] <pushrax> I have also used histograms to check correctness of lighting changes[02:24:11] <chrisf> pushrax: what kind of things are you working on?[02:25:04] <pushrax> right now a VR engine for a game in development[02:25:21] <pushrax> well it actually ended up being VR as an afterthought but now we're rolling with it[02:25:42] <chrisf> hmmn, hope that works out.[02:25:48] <pushrax> just a side thing[02:25:52] <chrisf> VR as an afterthought often doesnt :([02:26:09] <pushrax> an afterthought early in development[02:26:44] <pushrax> at the point where we didn't even have an audio system yet[02:27:56] <chrisf> heh[02:28:12] *** Elysion <Elysion!~Elysion@118.211.15.153> has quit IRC (Read error: Connection reset by peer)[02:28:20] <pushrax> what've you been up to chrisf?[02:31:30] *** Thaelimm <Thaelimm!~Thaelim@2601:281:c502:25d9:2de0:420e:4516:74e0> has quit IRC (Remote host closed the connection)[02:33:42] *** toblorone <toblorone!~toblorone@162.246.216.28> has quit IRC (Remote host closed the connection)[02:36:25] <chrisf> pushrax: recently, making the GL & Vulkan conformance tests better[02:36:36] <chrisf> so more of the things we'd like to do are actually reliable across devices[02:43:16] *** acksys_ <acksys_!~fritz@ip72-208-121-9.ph.ph.cox.net> has joined ##OpenGL[02:45:55] <Fr0stBit> Ok, i've been thinking about it and i have the question now: When fetching multiple texels for each thread, should the texels for each thread be adjacent, or should be interleaved by iterations? For example, if each thread was about to use 4 texels, should thread 0 use 0,1,2,3 and thread 1 4,5,6,7, or should thread 0 use 0,2,4,6 and thread 1 1,3,5,7 (so when each thread fetches its nth texel, the next'[02:45:57] <Fr0stBit> thread's texel is right next to it)[02:46:34] *** Foritus <Foritus!~buggery@cpc91390-watf11-2-0-cust41.15-2.cable.virginm.net> has quit IRC (Ping timeout: 256 seconds)[02:48:15] *** acksys_ <acksys_!~fritz@ip72-208-121-9.ph.ph.cox.net> has quit IRC (Ping timeout: 268 seconds)[02:48:56] *** Foritus <Foritus!~buggery@cpc91390-watf11-2-0-cust41.15-2.cable.virginm.net> has joined ##OpenGL[02:49:21] <Stragus> Fr0stBit: Thread 0 should fetch 0,32,64,96 Thread 1 should fetch 1,33,65,97 Thread 2 should fetch 2,34,66,98[02:50:07] <Stragus> I picked 32 as an example, that could be 16 if you work in tiles of 16x16 for a workgroup[02:52:24] <Stragus> The important thing to remember is that, for example, a chunk of 32 threads should fetch 32 nearby memory locations without holes[02:53:06] <Stragus> In the case of texture memory, "nearby" means nearby in 2D (don't assume a linear memory layout)[02:53:29] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has joined ##OpenGL[02:54:32] *** KAHR-Alpha <KAHR-Alpha!~Alpha@LFbn-1-15527-64.w86-225.abo.wanadoo.fr> has quit IRC (Ping timeout: 265 seconds)[02:56:53] *** Orion] <Orion]!~H0i@unaffiliated/orion/x-3970838> has quit IRC (Ping timeout: 256 seconds)[02:57:09] <pushrax> not all hardware has an effective SIMD width of 32[02:57:12] <pushrax> though most does[02:58:08] <Fr0stBit> Stragus: So, essentially, if we do a for (uint i = 0; i < num_texels; ++i) load_ith_texel, we want for each thread the next thread's ith texel to be adjucent[02:59:03] <Stragus> Fr0stBit: Correct, whenever possible[02:59:09] <Fr0stBit> So when all threads execute each time the loop body concurrently, fetch nearby texels[02:59:39] <Stragus> Yes, you understood correctly[03:00:17] <Fr0stBit> Does each line in a kernel run at about the same timepoint in each thread as the others? Thats why?[03:01:05] <pushrax> each instruction in a SIMD unit gets executed in lock step on all the data in that unit[03:01:44] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has quit IRC (Ping timeout: 276 seconds)[03:01:51] <pushrax> your total number of threads in your workgroup are divided between SIMD units (nvidia calls this a warp)[03:02:00] <Stragus> Fr0stBit: It's a bit complicated, a workgroup is sliced into multiple warps (CUDA terminology) of 32 (Nvidia) or 64 (AMD) threads[03:02:08] <Stragus> And a warp executes in lock step[03:02:21] <Fr0stBit> i see[03:02:42] *** charlie5 <charlie5!~rod@124-170-214-48.dyn.iinet.net.au> has joined ##OpenGL[03:02:50] <pushrax> GPUs and modern SIMD-capable CPUs are not really all that different[03:03:16] <pushrax> GPUs basically make the tradeoff of "simpler but more"[03:03:20] <Stragus> Eh... Well, the "SIMD" found in GPU is a lot more flexible[03:04:42] <pushrax> less than one might expect though[03:05:47] <Stragus> I think the balance is just right for peak performance and flexibility[03:06:27] <chrisf> pushrax: a 16x16 tile fits everyone pretty well[03:09:58] <Fr0stBit> Gotta sleep guys! See ya tomorrow, really thanks for your help, learnt a ton of stuff today :)[03:10:30] <Stragus> Cool, good night[03:12:26] *** Fr0stBit <Fr0stBit!5150@2a02:2149:8167:1b00:922b:34ff:fe36:b288> has quit IRC (Quit: WeeChat 2.0.1)[03:13:10] *** charlie5 <charlie5!~rod@124-170-214-48.dyn.iinet.net.au> has quit IRC (Ping timeout: 240 seconds)[03:14:45] <chrisf> Stragus: your team is 64-wide now too[03:14:58] <chrisf> as of pascal?[03:15:24] *** spear2 <spear2!~spear2@71-95-117-135.dhcp.mdfd.or.charter.com> has joined ##OpenGL[03:15:53] <chrisf> oh, perhaps not. just some other rearrangement[03:16:10] <Stragus> The warp width has always been 32[03:16:21] <chrisf> i know it was on previous generations[03:16:25] <Stragus> Well, except some very early CUDA compute devices that had 8[03:17:33] <Stragus> Maybe you read the part about 64 float cores per SM, but they still run warps of 32 (multiple warps simultaneously)[03:17:34] <chrisf> Stragus: bad old days of NV4x ?[03:18:52] <Stragus> The 9xxx or something just before the GTX 2xx, I fortunately didn't have to suffer these too much :)[03:19:37] <Stragus> Ah, that was 8800, not 9xxx[03:19:55] <chrisf> imagine the 9xxx is the same[03:26:43] *** xaxxon <xaxxon!~xaxxon@73.109.62.214> has joined ##OpenGL[03:29:52] *** charlie5 <charlie5!~rod@124-170-207-183.dyn.iinet.net.au> has joined ##OpenGL[03:47:27] *** salamanderrake <salamanderrake!~quassel@cpe-65-189-208-111.neo.res.rr.com> has quit IRC (Ping timeout: 268 seconds)[03:48:16] *** salamanderrake <salamanderrake!~quassel@cpe-24-165-198-229.neo.res.rr.com> has joined ##OpenGL[03:49:43] *** bookmark <bookmark!~IceChat77@47.196.110.8> has joined ##OpenGL[03:49:45] <bookmark> hi[03:50:00] <bookmark> does anyone know how to write a scale matrix transformation[03:50:01] <bookmark> ?[03:50:31] <bookmark> i've got rotate and translate working in modern opengl but scale is hard[03:51:05] <bookmark> i guess i could look at the glm so nevermind[03:57:14] <pushrax> your matrix * vecN(your scale)[03:58:01] <pushrax> if you're just looking for scale, your matrix is the identity matrix[03:58:41] *** DarkUranium <DarkUranium!~DarkUrani@77.38.34.248> has quit IRC (Read error: Connection reset by peer)[03:58:48] <pushrax> sorry where vecN is actually matNxN[03:59:49] *** hgoel <hgoel!uid175521@gateway/web/irccloud.com/x-mcwxsdyumdeivuet> has joined ##OpenGL[03:59:52] <bookmark> i'm trying to do it server side though[04:00:03] <bookmark> not in glsl[04:00:16] <pushrax> oh and you're not using glm[04:00:27] <pushrax> well it's just a diagonal matrix[04:00:42] <bookmark> well i ported to glm but my world was rendering in the wrong place cuz glm sucks[04:00:43] <pushrax> of the scale in each dimension[04:00:45] <bookmark> basically[04:00:50] <bookmark> so now i'm rolling my own[04:00:50] <pushrax> pff glm is great[04:00:56] <bookmark> pfft no its not[04:01:52] <bookmark> i was using the gl depricated functions and they rendered my world in the correct location[04:02:03] <pushrax> anyway tldr index 0,0 is your scale in X, 1,1 is your scale in y, etc[04:02:35] <bookmark> ok[04:03:43] <pushrax> and I was cheating a bit earlier and ignoring the w dimension but you get the point[04:05:19] <pushrax> just think about what happens when you multiply a unit vector and you'll see why this makes sense[04:09:10] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[04:10:48] *** toblorone <toblorone!~toblorone@172.58.91.131> has joined ##OpenGL[04:12:16] *** glYoda <glYoda!~MTLYoda@c-73-25-27-206.hsd1.or.comcast.net> has joined ##OpenGL[04:26:55] *** fundies <fundies!~fundies@5.2.76.71> has quit IRC (Changing host)[04:26:55] *** fundies <fundies!~fundies@unaffiliated/cheeseboy> has joined ##OpenGL[04:27:37] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has joined ##OpenGL[04:41:15] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[04:53:43] <bookmark> wtf now i reloaded my glm version and the world is drawing in the right place now[05:17:07] *** Fig1024 <Fig1024!~Fig@175.117.3.23> has quit IRC (Ping timeout: 265 seconds)[05:20:04] *** bnka <bnka!~niklas@c-176be555.08-890-6e6b701.cust.bredbandsbolaget.se> has joined ##OpenGL[05:33:02] *** Xophosaurus <Xophosaurus!~yay@dhcp-108-168-68-218.cable.user.start.ca> has joined ##OpenGL[05:37:27] *** qeed <qeed!~qeed@pool-98-118-249-109.clppva.fios.verizon.net> has quit IRC (Ping timeout: 240 seconds)[05:39:57] *** rizzo <rizzo!~RizzoTheR@p54B6BDA4.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 264 seconds)[05:52:43] *** tambre <tambre!~tambre@e0b8-5873-0797-1dfa-ab80-8a0a-07d0-2001.dyn.estpak.ee> has joined ##OpenGL[06:07:38] *** kriskropd <kriskropd!~kris@unaffiliated/kriskropd> has quit IRC (Ping timeout: 276 seconds)[06:09:48] *** kriskropd <kriskropd!~kris@unaffiliated/kriskropd> has joined ##OpenGL[06:13:34] *** Fig1024 <Fig1024!~Fig@175.117.3.23> has joined ##OpenGL[06:15:29] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[06:17:02] *** raynold <raynold!uid201163@gateway/web/irccloud.com/x-rmryuwavgxxyguzg> has joined ##OpenGL[06:17:22] *** bnka <bnka!~niklas@c-176be555.08-890-6e6b701.cust.bredbandsbolaget.se> has quit IRC (Quit: Lost terminal)[06:25:12] *** yosafbridge <yosafbridge!~yosafbrid@68.ip-149-56-14.net> has quit IRC (Ping timeout: 260 seconds)[06:29:38] *** immibis <immibis!~chatzilla@122-59-200-50.jetstream.xtra.co.nz> has joined ##OpenGL[06:32:16] *** krystcich_ <krystcich_!~krystcich@178235146015.dynamic-zab-01.vectranet.pl> has joined ##OpenGL[06:32:26] *** yosafbridge <yosafbridge!~yosafbrid@68.ip-149-56-14.net> has joined ##OpenGL[06:38:26] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##OpenGL[06:39:23] *** cfoch_ <cfoch_!uid270777@gateway/web/irccloud.com/x-riiptfcdpxzelsrq> has joined ##OpenGL[06:41:29] *** kasper_ <kasper_!~safaf@82.137.10.92> has quit IRC ()[06:41:47] *** kasper^ <kasper^!~safaf@82.137.10.92> has joined ##OpenGL[06:45:56] *** bnka <bnka!~niklas@c-176be555.08-890-6e6b701.cust.bredbandsbolaget.se> has joined ##OpenGL[06:46:59] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[06:48:46] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##OpenGL[06:51:51] *** allisonzephyr <allisonzephyr!~allisonze@pool-72-77-42-97.pitbpa.fios.verizon.net> has joined ##OpenGL[06:53:54] *** asecretcat <asecretcat!~allisonze@pool-72-77-42-97.pitbpa.fios.verizon.net> has quit IRC (Remote host closed the connection)[06:56:40] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has quit IRC (Ping timeout: 240 seconds)[07:01:10] *** Lunatrius` <Lunatrius`!~Lunatrius@77.38.21.155> has joined ##OpenGL[07:03:48] *** Lunatrius <Lunatrius!~Lunatrius@77.38.21.155> has quit IRC (Ping timeout: 240 seconds)[07:03:48] *** Lunatrius` is now known as Lunatrius[07:05:13] *** zeduckmaster <zeduckmaster!~zeduckmas@85.106.1.181> has joined ##OpenGL[07:07:40] *** __asecretcat__ <__asecretcat__!~allisonze@pool-72-77-42-97.pitbpa.fios.verizon.net> has joined ##OpenGL[07:08:34] *** __asecretcat__ <__asecretcat__!~allisonze@pool-72-77-42-97.pitbpa.fios.verizon.net> has quit IRC (Client Quit)[07:09:54] *** asecretcat <asecretcat!~allisonze@pool-72-77-42-97.pitbpa.fios.verizon.net> has joined ##OpenGL[07:11:13] *** allisonzephyr <allisonzephyr!~allisonze@pool-72-77-42-97.pitbpa.fios.verizon.net> has quit IRC (Ping timeout: 248 seconds)[07:11:34] *** bnka <bnka!~niklas@c-176be555.08-890-6e6b701.cust.bredbandsbolaget.se> has quit IRC (Quit: leaving)[07:13:17] *** toblorone <toblorone!~toblorone@172.58.91.131> has quit IRC (Remote host closed the connection)[07:13:39] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: ZZZzzz…)[07:15:02] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has joined ##OpenGL[07:16:13] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[07:16:47] *** krystcich_ <krystcich_!~krystcich@178235146015.dynamic-zab-01.vectranet.pl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))[07:17:38] *** toblorone <toblorone!~toblorone@172.58.91.131> has joined ##OpenGL[07:17:58] *** toblorone <toblorone!~toblorone@172.58.91.131> has quit IRC (Read error: Connection reset by peer)[07:18:27] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##OpenGL[07:42:58] *** xaxxon_ <xaxxon_!~xaxxon@73.109.60.182> has joined ##OpenGL[07:43:11] *** xaxxon <xaxxon!~xaxxon@73.109.62.214> has quit IRC (Ping timeout: 248 seconds)[07:46:47] *** acksys0 <acksys0!~acksys@ip72-208-121-9.ph.ph.cox.net> has quit IRC (Ping timeout: 255 seconds)[07:48:35] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[07:48:46] *** toblorone <toblorone!~toblorone@172.58.91.131> has joined ##OpenGL[07:50:59] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##OpenGL[07:52:53] <dav1d> Xeek: some builds require symbols which are defined in khrplatform[07:53:24] <dav1d> Glad2 has logic to only include it when necessary[07:53:48] <dav1d> Glad just includes it to be safe[08:03:06] *** xaxxon_ is now known as xaxxon[08:07:32] *** Cooler <Cooler!~coolerext@27.97.175.106> has joined ##OpenGL[08:10:22] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[08:11:43] *** stefkos <stefkos!~Pawel@82.177.144.226> has joined ##OpenGL[08:15:59] *** bnka <bnka!~niklas@c-89-47.eduroam.liu.se> has joined ##OpenGL[08:17:43] *** nidefawl <nidefawl!~nidefawl@p2E58DD99.dip0.t-ipconnect.de> has joined ##OpenGL[08:21:08] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[08:24:48] *** ngm <ngm!~nishanth@183.82.187.154> has joined ##OpenGL[08:26:33] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[08:27:56] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##OpenGL[08:32:03] *** iderik <iderik!~idk@h-0-97.A147.priv.bahnhof.se> has joined ##OpenGL[08:33:09] <bookmark> is it possible to make a uniform that is a pointer ?[08:33:15] <bookmark> that can be switched out[08:33:34] <bookmark> without reexporting it[08:35:23] <Stragus> There are no pointers in GLSL[08:35:32] <bookmark> fudge[08:35:42] <bookmark> why the heck not[08:36:22] <bookmark> what about in like vulcan or something like that?[08:36:46] <Yaniel> this is sounding more and more like an XY problem[08:37:03] <bookmark> XY problem?[08:37:52] <Yaniel> "I wanna do X but my actual goal is Y, which is better achieved with completely different means"[08:37:56] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has joined ##OpenGL[08:37:59] <bookmark> ah[08:38:09] <bookmark> yeah i think i know what to do[08:38:22] <bookmark> i need just or two uniforms to do everything[08:38:30] <bookmark> one or two i mean[08:38:40] <bookmark> i have like 10 uniforms[08:39:05] <bookmark> which seems to make the fps slower[08:39:13] <Yaniel> and what are you actually trying to do?[08:39:19] <bookmark> make it faster[08:39:33] <Stragus> More uniforms aren't slower, it's what you do with them[08:39:50] <Stragus> Although updating them all one at a time will be slower, better use an UBO if you do a lot of that[08:39:57] <bookmark> actually in my code its the thing that is holding back a fast fps[08:40:03] <bookmark> i've already tested that[08:40:15] <bookmark> but its how to get rid of them that is annoying[08:40:38] <bookmark> uniform buffer object?[08:40:59] <Stragus> To update a bunch of uniforms in a single GL call. If that's your problem anyway[08:41:54] <bookmark> im not exactly sure the problem but i have two versions of my game one with just a few uniforms and one with like 10 to 15[08:42:07] <bookmark> and there is a 45 fps difference[08:42:17] <Yaniel> I wonder what the difference in the shaders loc is[08:42:18] <bookmark> goes from like 105 to like 60[08:42:32] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has joined ##OpenGL[08:42:48] <Stragus> Then benchmark with/without updating the uniforms[08:43:02] <Stragus> Updating too many uniforms usually implies performing too many draw calls anyway[08:43:15] <bookmark> no[08:43:28] *** zid <zid!~zid@cpc112319-pete13-2-0-cust670.4-4.cable.virginm.net> has joined ##OpenGL[08:43:29] <bookmark> i have consolidated my materials into single draw calls[08:43:39] <bookmark> so like all tile is in one call[08:43:42] <zid> I jsut did the opposite of that, split my materials into seperate draw calls :P[08:43:44] <bookmark> all metal in another[08:44:02] <zid> or maybe the same thing and i Just caught an odd sounding line first[08:44:18] <bookmark> actually Stragus you might be right[08:44:26] <zid> Anyway, came to bug you guys about transparent textures, I can discard; to make them 100% transparent but I can do some kind of blending?[08:44:26] <bookmark> if could update and use 3d textures[08:44:35] <bookmark> but i haven't got time for all of that tonight[08:44:38] <zid> or would I have to implement a compositor somehow[08:44:49] <bookmark> if i could use 3d textures i could just specify UVRs[08:44:53] <Stragus> zid: https://www.khronos.org/opengl/wiki/Blending[08:44:57] <zid> cheers[08:44:59] <bookmark> and render the whole map in one call[08:45:32] <Stragus> bookmark: It sounds like you have few GL draws and uniform updates, therefore it's your shader code that's slow[08:45:35] *** YungMoon <YungMoon!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[08:46:10] <bookmark> i thought fewer draw calls are better no?[08:46:34] <zid> Stragus: Cheers, perfect[08:46:36] <Stragus> Correct, unless you draw too much stuff that isn't visible[08:47:16] <bookmark> i'm not about to get into bsp trees[08:48:01] <bookmark> I mean i could decrease my frustum[08:48:31] <bookmark> at any rate what you told me was helpful thank you[08:48:45] <bookmark> it got me thinking that i should just upgrade to 3d textures soon[08:49:05] <bookmark> I have them working in another TU[08:49:06] <zid> https://i.imgur.com/sHgu0om.png I added binary transparency (fixed the fences) and fixed my lighting too, I wasn't rotating my normals :)[08:49:29] <zid> the fence in the center of the screen is an issue though[08:49:37] <Stragus> bookmark: Consider array textures instead, if I understood what you were doing correctly[08:49:48] <bookmark> is that lava? or rock?[08:49:50] <zid> at this angle is mostly disappears entirely because there's always a pixel that hit a discard[08:50:01] <zid> it's dirt[08:51:22] <zid> It's hard to tell because my lighting is a vector field, I figured out the math for point lights last night though thanks to a handy diagram I drew[08:57:23] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[09:00:32] <bookmark> Stragus, is there any reason to use array textures over 3d textures? i kind of liked the 3d textures because you can blend between them in glsl[09:00:35] <bookmark> ?[09:00:53] <bookmark> thought that was cool[09:00:56] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##OpenGL[09:01:02] <zid> bookmark: If you don't want it to blend :P[09:01:20] <bookmark> well it doesn't morph or anything[09:01:43] <bookmark> but one can switch between one texture and another slowly[09:02:21] <Stragus> If you do need that, then use a 3D texture. If you don't, then don't make the hardware work harder for nothing[09:03:03] <bookmark> hmm[09:03:15] <bookmark> ill have to bench mark them but i think they are fairly fast[09:03:42] <bookmark> just because hardware has more memory available to it doesn't mean its slower[09:03:43] <Stragus> Twice as much memory bandwidth as an array texture[09:03:43] <zid> Stragus: Is the fact I draw this using 16 draw calls because I have 16 textures ridiculous or about right?[09:04:11] <Stragus> zid: Anything below 200-500 draw calls is very fine[09:04:12] <bookmark> latency is only known anthropically with a bench mark[09:04:45] <bookmark> zid, thats what i'm doing too[09:04:51] <zid> Stragus: At that point I would consider using more memory by tagging my verts and using texture arrays?[09:04:53] <bookmark> for now[09:05:03] <zid> or a ghetto as fuck texture atlas[09:05:11] *** hellozee <hellozee!~hellozee@45.118.157.211> has joined ##OpenGL[09:05:11] <bookmark> haha[09:05:26] <bookmark> photoshop[09:05:35] <zid> I didn't realize how much texture repetition this thing used, a texture atlas for it is horrific[09:05:44] *** ertes <ertes!~ertes@haskell/developer/ertes> has quit IRC (Ping timeout: 260 seconds)[09:05:48] <Stragus> zid: More batching and fewer draw calls is always good, but you won't notice the overhead with < 200 draw calls[09:05:53] <zid> The n64 had a lot less ram than it had processing power[09:06:00] <zid> so it has tiny textures that repeat everywhere[09:06:16] <zid> The dirt ends up in a texture atlas like 40 times[09:06:58] <bookmark> i'm just happy i'll be able to fix it next week[09:07:09] <bookmark> seems everything i slot for a week takes two[09:07:20] <zid> I could uniqify the texture for 'free' though, but I'd lose the original look[09:07:57] <bookmark> damn wrinkles[09:08:06] <bookmark> in my plan[09:08:25] <zid> okay so I have avenues, which is nice, to make it faster/slower for less/more memory use etc[09:10:16] <bookmark> so....[09:10:49] <bookmark> would it be better to make one big 3d texture or one for each entity in the game[09:11:12] <zid> Only if you're using multiple blended materials on every entity would that be best[09:11:17] <bookmark> one big stack seems crazy undertaking[09:11:29] <bookmark> unless i just destroy it when map switch[09:11:34] <bookmark> and reload everything[09:11:45] <zid> most engines do[09:12:01] <bookmark> yeah but i mean character textures too[09:12:10] <Stragus> Many engines use one or several array textures for a lot of stuff[09:12:17] <zid> You could implement a texture cache deal[09:12:18] <Stragus> Forget 3D textures unless you really need a 3D texture[09:12:29] <bookmark> why they work?[09:12:47] <bookmark> i have it working and i currently don't have texture arrays working[09:13:06] <zid> so tex_load(BLACK_HERMIT_FOREARM); or whatever just gives you the old-gluint back if it's already loaded, then you just unload all the ones that are no longer used or whatever.. sounds like a lot of work[09:13:07] <bookmark> array textures rather[09:13:38] <zid> you'll eat a lot of runtime just doing the intersection test of what was loaded and needs to be loaded[09:13:45] <zid> you'd need to parse over all your map files twice too[09:13:53] <zid> to build the resource list, then actually load things[09:14:00] <zid> especially if it's hierarchical[09:14:08] <bookmark> its not[09:14:24] <bookmark> its just an wavefront .obj[09:14:29] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[09:14:33] <zid> The more you think about this the more you'll realize it's really technically hard and slow to properly do a 'diff' so you don't reload anything again[09:14:45] <bookmark> that's what i'm saying[09:14:55] <bookmark> i'm just going to throw all my textures in one 3d texture[09:15:01] <bookmark> and then access it with UVRs[09:15:08] <bookmark> on the frag[09:15:08] <zid> all 400GB of textures?[09:15:13] <bookmark> er.. vert shader[09:15:28] <Stragus> Your 3D texture will be twice as slow as an array texture, but whatever[09:15:43] <bookmark> well i can' always replace it later[09:15:48] <bookmark> with the array texture too[09:15:55] <bookmark> thats another perk[09:16:13] <zid> Stragus: Working on anything interesting?[09:16:29] <zid> My main issue atm is exposure to techniques and practices[09:16:51] <bookmark> zid check out my game: https://www.youtube.com/watch?v=raKF2GOmrfo[09:17:26] <bookmark> works with two controllers like an nes ;)[09:17:44] <zid> why does it have a badly cropped video running at 1fps[09:17:49] <zid> captured from a window[09:18:14] <zid> and crappy music[09:18:14] <bookmark> ehehe cuz i'm an ametuer[09:18:16] <zid> I regret clicking this[09:18:33] <zid> https://obsproject.com/[09:18:45] <bookmark> zid well it beats your game[09:18:47] <zid> It can capture dx/gl straight to x264 or stream it to twitch[09:18:50] <zid> I don't have a game[09:18:52] *** Neomex <Neomex!~quassel@net-37-117-5-106.cust.vodafonedsl.it> has joined ##OpenGL[09:18:52] <bookmark> i can tell by your map[09:18:55] <zid> so I am not sure it does[09:18:56] <bookmark> ;p[09:19:14] <bookmark> lol[09:19:20] <bookmark> whatever dude[09:20:20] <bookmark> and the video isn't badly cropped i was demonstrating the networked capability[09:20:38] <bookmark> there is a server and a client there if you open your eyes instead of being closed minded[09:21:18] <zid> It is infact badly cropped[09:21:27] <bookmark> lol[09:21:35] <bookmark> its how i wanted it[09:21:44] *** Portugol9 <Portugol9!~Portugol9@unaffiliated/portugol9> has joined ##OpenGL[09:21:52] <bookmark> i wanted it to look like a windows screen capture[09:21:57] <bookmark> too bad[09:22:03] <bookmark> lump it if you don't like it[09:22:39] <bookmark> of course once the game is done the advertisement won't look that way[09:22:50] <bookmark> but this is for funziez[09:23:17] *** xaxxon <xaxxon!~xaxxon@73.109.60.182> has quit IRC (Quit: xaxxon)[09:24:15] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has joined ##OpenGL[09:27:52] *** xerpi <xerpi!~xerpi@61.red-83-45-192.dynamicip.rima-tde.net> has joined ##OpenGL[09:28:45] *** xerpi <xerpi!~xerpi@61.red-83-45-192.dynamicip.rima-tde.net> has quit IRC (Remote host closed the connection)[09:29:06] *** xerpi <xerpi!~xerpi@61.red-83-45-192.dynamicip.rima-tde.net> has joined ##OpenGL[09:29:10] <bookmark> wow check this out[09:29:11] <bookmark> https://stackoverflow.com/questions/11807344/problems-about-allocating-opengl-3d-texture-size-of-1g[09:29:36] <bookmark> it seems that a 3d texture can handle being fairly large if it is compiled under 64 bit[09:29:50] <bookmark> his was 1024x1024x1024[09:30:36] <bookmark> if he's not fibbing[09:31:15] <bookmark> ah then again he had a quadro[09:31:31] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[09:33:43] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has joined ##OpenGL[09:33:47] <bookmark> ill just text it on this crappy old laptop[09:33:57] <bookmark> if it runs on there it should run on about anything[09:34:06] <bookmark> as far as memory goes[09:34:23] <bookmark> mobility ati from the stone age so[09:38:16] <Yaniel> you are aware that we're in the age of 4096x4096 textures, right?[09:38:59] <Yaniel> and that a 3d texture will be *always* reading from two layers on every access[09:39:21] <Stragus> Yaniel: I already told him that about 4 times, but eh, good luck[09:39:59] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[09:40:22] <Yaniel> Stragus: well "badly cropped" "it's how I want it" is kinda telling[09:40:59] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:b0c3:23b6:caaf:24b> has joined ##OpenGL[09:40:59] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:b0c3:23b6:caaf:24b> has quit IRC (Changing host)[09:40:59] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[09:41:48] *** Quetzal2 <Quetzal2!~Quetzal2@unaffiliated/quetzal2> has joined ##OpenGL[09:43:11] *** toblorone <toblorone!~toblorone@172.58.91.131> has quit IRC (Remote host closed the connection)[09:44:30] <bookmark> snobs[09:45:03] *** hellozee <hellozee!~hellozee@45.118.157.211> has quit IRC (Remote host closed the connection)[09:45:04] <bookmark> its better than zid's game[09:45:30] <bookmark> and like i said the 3d textures will be replaced by array textures[09:45:39] <Yaniel> that attitude is why we have things like meltdown and WannaCry[09:45:46] <bookmark> games are supposed to be fun you guys are so serious[09:45:50] <Yaniel> but sure, it's more of a game - it has some sort of user input[09:46:24] <bookmark> Yaniel, like i know what thos things are or respect you enough now to go look[09:46:27] <bookmark> thanks a lot snob[09:46:35] *** Keniyal <Keniyal!~Keniyal@unaffiliated/keniyal> has joined ##OpenGL[09:46:44] <bookmark> grow up[09:47:13] <zid> I like that definition of insanity of "repeating the same actions and expecting different results"[09:48:00] <bookmark> zid you don't even have a game so zip it[09:48:16] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 265 seconds)[09:48:44] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[09:50:01] <Yaniel> tbf zids level looked a lot more interesting than yours[09:50:03] *** wuji2016 <wuji2016!~Thunderbi@112.31.70.31> has joined ##OpenGL[09:50:07] <Yaniel> but of course that's none of my business either[09:50:20] <Stragus> Anyway, just note that we are trying to help, and some of us have a lot of experience with OpenGL[09:50:51] <bookmark> Stragus, i said thank you didn't i?[09:51:09] <bookmark> It's not like i just like to go around calling people snobs[09:51:11] <bookmark> you gusy are[09:51:40] <bookmark> I mean i'm taking your advice in a way[09:51:47] <bookmark> maybe just not right this second[09:51:47] <Stragus> Cool then, all right[09:54:03] <bookmark> but its like joan city[09:54:21] <bookmark> not that i care[09:58:12] <bookmark> i think it's someone in here that recomended i get 3d textures working too[09:58:18] <bookmark> so i did[09:58:47] <zid> bookmark: Is that mesh animation or bonezz?[09:58:53] <bookmark> bones[09:59:09] <bookmark> i know how to do both together though[09:59:21] <bookmark> both kinds[09:59:45] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##OpenGL[10:00:12] <bookmark> i had to basically reverse engineer the glRotatef and write a whole bunch of weight importing stuff to get bones working[10:00:43] <zid> I was going to ask if you're doing the texture filtering hacks or anything I read about, I guess not[10:01:32] <bookmark> man i've been working on like collision math for so long i rarely get a chance to even venture into much opengl[10:01:44] <zid> opengl should be the easy part[10:01:55] <bookmark> like i said[10:01:59] <bookmark> no time[10:02:17] <bookmark> i've been writing networking code and collision maths[10:03:03] <bookmark> https://www.youtube.com/user/aspeersc1[10:03:04] <zid> Stragus: Is the texture filtering machinery being used to do bone interpolation a real thing people use or just a gimmick someone came up with and flooded the internet with[10:03:44] <bookmark> hmm ive been using the vertex shader[10:03:59] <bookmark> new map footage is kind of neat[10:04:16] <Stragus> I haven't heard of that... Interpolating between two "nearby" bone rotations by sampling between them in some texture?[10:04:21] <zid> yea[10:04:28] <zid> It's all over the internet if you google for how do do bones[10:04:45] <spear2> lol bookmark you should get rich kyanka to play your game[10:05:07] <Stragus> That seems awkward in many cases, limited. You do save a bit of math if the limitations are acceptable[10:05:14] <Stragus> I wouldn't worry about it[10:05:18] <bookmark> kyanka? who's he?[10:05:26] <zid> Plus it seems weird to throw EVERYTHING onto the gpu, at this rate my cpu will be 100% idle :P[10:05:34] <spear2> bookmark: https://www.youtube.com/user/lowtaxico[10:05:35] <zid> I wanna write some matrix math damnit :P[10:06:06] <zid> I have a few tens of millions of bogomips to waste doing something dmanit[10:06:15] <bookmark> spear2, stow it[10:06:22] <bookmark> good lord its not done[10:06:51] <zid> bookmark: You brought it on yourself trying to wave your dick using.. /that/ video[10:06:59] <zid> Suck it up[10:07:07] <bookmark> wave my dick?[10:07:24] <bookmark> i just posted a clip of my game[10:07:26] <bookmark> wtf[10:08:37] <bookmark> well you'll all be seeing a lot more of my game or however you see it[10:08:38] <spear2> fwiw i liked it[10:08:42] *** CoolerX <CoolerX!~coolerext@27.97.176.75> has joined ##OpenGL[10:08:56] <bookmark> as a dick i guess[10:09:54] <spear2> if you make programmer art you have to own it[10:10:15] <bookmark> no you don't[10:10:17] <zid> That's why I stole mine from mario :D[10:10:18] <bookmark> not at first[10:10:30] <bookmark> its just a hobby until you are done[10:10:49] <bookmark> youtube don't care[10:11:02] <bookmark> thats like saying people can't cus[10:11:07] <bookmark> yeah they can[10:11:18] <zid> any chance you could tone it down like 4 or 5 notches[10:11:30] <bookmark> what is it?[10:11:32] <zid> nobody cares about your philosophy of life, much less written 4 words at a time over irc[10:11:50] <bookmark> ;p[10:11:59] *** Cooler <Cooler!~coolerext@27.97.175.106> has quit IRC (Ping timeout: 248 seconds)[10:12:06] <bookmark> well i'm trying to fing code[10:12:38] <bookmark> not even trying to be on this window[10:12:43] <zid> well you're failing, go do it[10:12:46] <spear2> i just mean if you make crappy art don't try and deny its crappy[10:13:16] <zid> I think if I import more mario models I'm going to end up reading mips assembly to see how they're supposed to move..[10:13:20] <bookmark> its crap but i don't want to hear anyone joan unless they have a better game[10:13:31] <bookmark> themself[10:14:07] <spear2> i don't have networking yet so you win there =)[10:19:12] *** _borkr_ <_borkr_!~borkr@static130-244.mimer.net> has joined ##OpenGL[10:19:12] *** Keniyal <Keniyal!~Keniyal@unaffiliated/keniyal> has quit IRC (Ping timeout: 265 seconds)[10:19:53] *** Kingsquee <Kingsquee!~kingsquee@d108-180-237-219.bchsia.telus.net> has joined ##OpenGL[10:20:09] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 264 seconds)[10:20:25] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[10:20:33] *** ville <ville!~ville@188-67-10-70.bb.dnainternet.fi> has quit IRC (Ping timeout: 248 seconds)[10:24:37] *** kasper^ <kasper^!~safaf@82.137.10.92> has quit IRC ()[10:29:50] *** Neomex <Neomex!~quassel@net-37-117-5-106.cust.vodafonedsl.it> has quit IRC (Read error: Connection reset by peer)[10:31:58] *** Neomex <Neomex!~quassel@net-37-117-5-106.cust.vodafonedsl.it> has joined ##OpenGL[10:35:33] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has quit IRC (Quit: *waves frantically*)[10:37:33] *** Keniyal <Keniyal!~Keniyal@unaffiliated/keniyal> has joined ##OpenGL[10:38:57] *** cfoch_ <cfoch_!uid270777@gateway/web/irccloud.com/x-riiptfcdpxzelsrq> has quit IRC (Quit: Connection closed for inactivity)[10:39:30] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Ping timeout: 265 seconds)[10:41:59] *** wuji2016 <wuji2016!~Thunderbi@112.31.70.31> has quit IRC (Ping timeout: 255 seconds)[10:42:51] *** xaxxon <xaxxon!~xaxxon@73.109.61.174> has joined ##OpenGL[10:48:32] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 276 seconds)[10:48:43] *** wuji2016 <wuji2016!~Thunderbi@112.31.70.31> has joined ##OpenGL[10:49:06] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[10:50:03] *** ASvideniuk <ASvideniuk!~oleksandr@195.234.75.138> has quit IRC (Read error: Connection reset by peer)[11:00:20] *** xaxxon <xaxxon!~xaxxon@73.109.61.174> has quit IRC (Quit: xaxxon)[11:00:49] *** Serpent7776 <Serpent7776!~Serpent77@90-156-68-175.internetia.net.pl> has joined ##OpenGL[11:05:06] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[11:05:59] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[11:07:54] *** notadeveloper <notadeveloper!~textual@2600:1700:89c0:1780:b5d6:6b7:e85d:c170> has joined ##OpenGL[11:08:01] *** notadeveloper <notadeveloper!~textual@2600:1700:89c0:1780:b5d6:6b7:e85d:c170> has left ##OpenGL[11:08:50] *** notadeveloper <notadeveloper!~textual@2600:1700:89c0:1780:b5d6:6b7:e85d:c170> has joined ##OpenGL[11:10:51] <notadeveloper> hi neure[11:11:26] <neure> hi[11:11:28] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[11:12:14] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[11:13:47] *** ngm <ngm!~nishanth@183.82.187.154> has quit IRC (Ping timeout: 276 seconds)[11:24:53] *** delicado <delicado!~delicado@110.54.152.26> has joined ##OpenGL[11:30:12] *** ZeroWalker <ZeroWalker!~Zerowalke@78-67-154-24-no268.tbcn.telia.com> has joined ##OpenGL[11:48:43] <iderik> Stragus: excuse me, but i saw you said that 3D textures are slower than 2D array textures. just to be sure, is this a 2D array texture: glTexImage3D(GL_TEXTURE_2D_ARRAY, ...)? i just get abit confused with the "3D" in the function name there.[11:49:41] *** ngm <ngm!~nishanth@183.82.187.154> has joined ##OpenGL[11:50:32] <Stragus> iderik: That's a 2D array texture (...which has 3 dimensions, so it uses 3D calls)[11:50:33] <iderik> i guess the "3D" part in the name is actually that the storage is 3D[11:50:37] <Stragus> Correct[11:51:33] <Chipzz> bookmark: checked out some of the videos in your channel, but I think it were the first one. plenty of glitches left it looks like, but looks like a lot fo things are working already[11:51:34] <iderik> Stragus: "... so it uses 3D calls", so you're meaning that is slower methods you warned him about?[11:51:42] *** notadeveloper <notadeveloper!~textual@2600:1700:89c0:1780:b5d6:6b7:e85d:c170> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)[11:51:51] <iderik> that is the slower method*[11:51:51] <Chipzz> bookmark: I do agree on the music though. Not it being bad, but there being music at all[11:52:16] <Chipzz> I hate it when people feel the need to add a random soundtrack to their clips for no fucking reason at all[11:52:21] <Stragus> iderik: I meant it uses GL functions for 3D storage[11:52:37] <iderik> oh ok[11:53:14] <Chipzz> personally I prefer silence, but other people may prefer listening to their own music instead of having to turn off whatever random track you choose to purposely put on your videos[11:53:36] <Chipzz> purposeless(ly?)[11:53:39] <spear2> youtube videos can be easily muted :p[11:53:50] <Stragus> The problem with a sampler3D is that it will blend two layers, twice the memory bandwidth, compared to fetching from a single layer of an array texture with a sampler2DArray[11:54:05] <Chipzz> I prefer not having to have to look for the mute button in the first place[11:54:18] <Chipzz> and I imagine most people do[11:54:47] <spear2> lol yeah youtube has such a terrible UI takes ages just to find the volume =|[11:55:05] <Chipzz> especially because in one of the videos you can see him switching windows to his media player and turning on the msuic. bah :P[11:55:07] <spear2> </s>[11:56:12] <iderik> Stragus: interesting. not a feature i require tho. thanks[11:56:52] <zid> I'd like to do think of a reason to need 3D textures, more flags in my object struct is always needed ;)[11:56:53] *** ornitorrincos <ornitorrincos!~ornitorri@unaffiliated/ornitorrincos> has quit IRC (Quit: ZNC 1.6.5 - http://znc.in)[11:56:56] <zid> s/do //[11:57:31] <iderik> Stragus: you and derhass should get paid for being to active and helpful in this channel, atleast what i've seen in my timezone[11:57:41] <zid> iderik: ##c owes me a fortune then[11:57:42] <iderik> for being so active *[11:57:54] *** ornitorrincos <ornitorrincos!~ornitorri@163.172.62.96> has joined ##OpenGL[11:57:54] *** ornitorrincos <ornitorrincos!~ornitorri@163.172.62.96> has quit IRC (Changing host)[11:57:54] *** ornitorrincos <ornitorrincos!~ornitorri@unaffiliated/ornitorrincos> has joined ##OpenGL[11:58:26] <zid> Oh hmm, coloured marble tile, that'd be a cool use for 3D textures[11:58:28] <iderik> zid: hehe :) maybe a donation feature would be great. not sure if its along freenode's way of living tho[11:58:49] <zid> https://slm-assets2.secondlife.com/assets/11219805/view_large/In_World_Example_Photo_marble_tile_2.jpg?1425835682 looks like a decent use of 3D textures[11:58:55] <zid> have a stock 'ripple' texture and a colour texture on top[11:59:08] <Stragus> iderik: Eh, you are welcome. I remember I did receive a lot of IRC help back in ~2000 on Efnet's #opengl[11:59:39] <zid> Stragus: Got a hot tech demo idea for 3D textures[11:59:43] <zid> ?*[11:59:57] *** Gama11 <Gama11!~quassel@p5DCDB3CC.dip0.t-ipconnect.de> has joined ##OpenGL[12:00:18] <Stragus> zid: Try volumetric fog, that typically uses 3D textures[12:01:09] <zid> I assumed that was done with a depth field[12:01:15] <zid> well, fog, maybe not volumetic fog[12:01:18] <Stragus> People also use 3D textures for animated 2D textures[12:01:28] <zid> ah that's a good point![12:01:31] *** bnka <bnka!~niklas@c-89-47.eduroam.liu.se> has quit IRC (Quit: leaving)[12:01:39] <zid> interpolated 2D animation specifically?[12:01:48] <zid> otherwise a 2D_ARRAY seems like it'd be the choice[12:01:54] <Stragus> Yup, with smooth interpolation[12:02:27] <zid> I wonder what 2 frames of perlin with a HUGE interpolation looks like visually[12:02:44] <zid> thinking of something like 2 frame lava or something[12:02:59] <zid> where the blobs 'sink' and 'raise' because of interpolation between two frames[12:03:46] <Stragus> Animated noise is another good case for 3D textures[12:04:16] <zid> I'm thinking procedural, at least[12:04:21] <zid> lava, noise, etc[12:04:43] <zid> I bet rain drops would work nicely[12:05:13] <zid> or at least 'wetness'[12:08:01] <zid> Stragus: I take it I am stuck with a specific hw implementation's blend function with a 3D texture, and if I want something special I can just manually double sample two textures from an array?[12:09:09] <Stragus> If you don't want GL_LINEAR interpolation but some other operation, then you would sample yourself, yes[12:09:48] <zid> My intuition is getting sharper, which is a nice improvement[12:10:02] *** YungMoonHodler_ <YungMoonHodler_!~me@2a02:810c:c7c0:1965:d4ac:f2b9:659d:da93> has joined ##OpenGL[12:10:02] *** YungMoonHodler_ <YungMoonHodler_!~me@2a02:810c:c7c0:1965:d4ac:f2b9:659d:da93> has quit IRC (Changing host)[12:10:02] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has joined ##OpenGL[12:13:14] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[12:17:12] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[12:18:33] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:999b:279c:3862:5b99> has joined ##OpenGL[12:18:33] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:999b:279c:3862:5b99> has quit IRC (Changing host)[12:18:33] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[12:24:28] *** telex <telex!teletype@freeshell.de> has quit IRC (Remote host closed the connection)[12:26:28] *** telex <telex!teletype@freeshell.de> has joined ##OpenGL[12:30:09] *** watered_ <watered_!~dagger@gateway/tor-sasl/watered> has quit IRC (Remote host closed the connection)[12:32:28] *** spear2 <spear2!~spear2@71-95-117-135.dhcp.mdfd.or.charter.com> has quit IRC (Quit: Leaving)[12:33:46] <ZeroWalker> is there some extension or something that can easy up binding/uploading bufferdata. Think i saw it somewhere but can't seem to find it[12:41:00] *** kasper^ <kasper^!~safaf@82.137.10.187> has joined ##OpenGL[12:48:46] *** DarkUranium <DarkUranium!~DarkUrani@77.38.34.248> has joined ##OpenGL[12:50:18] *** TzilTzal <TzilTzal!~yaron@59.189.105.109> has joined ##OpenGL[12:51:13] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has joined ##OpenGL[12:52:57] *** immibis <immibis!~chatzilla@122-59-200-50.jetstream.xtra.co.nz> has quit IRC (Ping timeout: 240 seconds)[12:56:15] *** xerpi <xerpi!~xerpi@61.red-83-45-192.dynamicip.rima-tde.net> has quit IRC (Quit: Leaving)[12:57:36] *** eto <eto!~eto@unaffiliated/eto> has quit IRC (Read error: Connection reset by peer)[12:57:50] *** ipe <ipe!~ipe@91-156-244-112.elisa-laajakaista.fi> has joined ##OpenGL[12:59:01] *** eto <eto!~eto@unaffiliated/eto> has joined ##OpenGL[13:00:17] *** ColaEuphoria <ColaEuphoria!~ColaEupho@unaffiliated/colaeuphoria> has quit IRC (Read error: Connection reset by peer)[13:01:36] *** Quetzal2 <Quetzal2!~Quetzal2@unaffiliated/quetzal2> has quit IRC (Remote host closed the connection)[13:01:39] *** rizzo <rizzo!~RizzoTheR@p54B6BDA4.dip0.t-ipconnect.de> has joined ##OpenGL[13:02:04] *** YungMoonHodler_ <YungMoonHodler_!~me@2a02:810c:c7c0:1965:999b:279c:3862:5b99> has joined ##OpenGL[13:02:04] *** YungMoonHodler_ <YungMoonHodler_!~me@2a02:810c:c7c0:1965:999b:279c:3862:5b99> has quit IRC (Changing host)[13:02:04] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has joined ##OpenGL[13:04:36] *** slime <slime!~slime73@24.215.81.93> has joined ##OpenGL[13:05:22] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[13:07:17] *** ColaEuphoria <ColaEuphoria!~ColaEupho@unaffiliated/colaeuphoria> has joined ##OpenGL[13:07:55] *** raynold <raynold!uid201163@gateway/web/irccloud.com/x-rmryuwavgxxyguzg> has quit IRC (Quit: Connection closed for inactivity)[13:15:35] <iderik> is it "safe" to use glTexStorageXD in an application targeting OpenGL 3.3 even tho that it was introduced to core at OpenGL 4.2? someone said that ARB_texture_storage was purely driver-sided and most OpenGL 3.3 drivers supports it.[13:16:05] *** CoolerX <CoolerX!~coolerext@27.97.176.75> has quit IRC (Ping timeout: 240 seconds)[13:16:21] <DarkUranium> iderik, why not just check for the extension?[13:16:23] <Stragus> Check if the extension is there before using it[13:18:00] *** Kingsquee <Kingsquee!~kingsquee@d108-180-237-219.bchsia.telus.net> has quit IRC (Quit: Just Monica.)[13:18:20] *** CoolerX <CoolerX!~coolerext@27.97.176.75> has joined ##OpenGL[13:18:55] <iderik> if i am planning to sell my application and saying that OpenGL 3.3 is required. im wondering if its wise to depend on that extensions[13:21:19] *** charlie5 <charlie5!~rod@124-170-207-183.dyn.iinet.net.au> has quit IRC (Ping timeout: 248 seconds)[13:22:52] *** slime <slime!~slime73@24.215.81.93> has quit IRC (Quit: This computer has gone to sleep)[13:25:13] <Stragus> You just put an if() to call glTexStorage, otherwise glTexImage, depending on extension support[13:44:49] <roxlu> hi[13:45:40] <bookmark> can a uniform buffer object be made up of samper2Ds?[13:46:23] <bookmark> isn't a sampler 2d just and int really?[13:46:29] <roxlu> I have a vbo/ebo with skinned vertices. I want to calculate the final world position and velocity. I want to use a compute shader so I can directly write the results in to a SSBO. I'm wondering about the approach I should follow.[13:46:50] <roxlu> Any thoughts / ideas? E.g. how do I feed the indices/vertices to my compute shader?[13:54:11] *** Murii <Murii!~Murii@79.113.205.114> has joined ##OpenGL[13:59:38] *** slvn_ <slvn_!~slvn_@c2s31-1-78-245-90-111.fbx.proxad.net> has joined ##OpenGL[14:02:16] <DarkUranium> roxlu, both as buffers.[14:02:55] *** ignatiz- <ignatiz-!~scott@82.138.221.18> has joined ##OpenGL[14:02:56] <DarkUranium> `layout(binding=0) buffer Verts { float[] verts; }`[14:03:14] <DarkUranium> and `uint[] indices` for the latter, unless you use uint16 indices, then you'll have to be creative (namely: manually mask & shift)[14:03:49] <roxlu> Thanks DarkUranium! I've got uint32 indices luckily[14:04:20] *** echotangoecho <echotangoecho!~echotango@92-108-127-60.cable.dynamic.v4.ziggo.nl> has joined ##OpenGL[14:04:50] <DarkUranium> well, uint16 wouldn't have been complicated either.[14:04:56] <roxlu> And just curious about how to setup the work space for compute; e.g. should I just set `layout (local_size_x = NUMBER_OF_INDICES)` ?[14:05:16] <DarkUranium> (i&1) == 0 ? indices[i>>1] & 0xFFFF : indices[i>>1] >> 16[14:06:32] <DarkUranium> local size tends to be limited to 1024 total (or a similar small number)[14:06:37] <DarkUranium> that's for X*Y*Z[14:06:54] <DarkUranium> so no.[14:07:54] <roxlu> ah yeah exactly. that makes me wonder how to set this up? e.g. what if I have 1025 indices[14:08:56] *** CoolerZ <CoolerZ!~coolerext@27.97.191.81> has joined ##OpenGL[14:09:12] <DarkUranium> that's what global size is for.[14:09:43] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[14:10:06] <roxlu> So, would I use local_size_x = 1 and global X 1025 ?[14:10:23] <roxlu> I'm a bit new with this and not sure how to decide what sizes to use[14:10:28] <DarkUranium> you generally want local to be big. As big as you can manage, in my experience[14:10:39] <DarkUranium> though that does mean some wasted work, so in practice, a good compromise is needed[14:10:58] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:75e2:1d24:bf8c:8c4f> has joined ##OpenGL[14:10:58] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:75e2:1d24:bf8c:8c4f> has quit IRC (Changing host)[14:10:58] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[14:11:03] <DarkUranium> while developing, however, *IF* you don't need to do any sort of shared memory shenanigans, then you can use local_size_x=1 and global=N[14:12:13] <roxlu> Ok thanks! when I perform some extra work, I guess it's undefined when I write into a buffer index that is out of range?[14:12:14] *** CoolerX <CoolerX!~coolerext@27.97.176.75> has quit IRC (Ping timeout: 256 seconds)[14:12:47] <DarkUranium> you can have a bigger buffer, or just check with a branch[14:13:30] <DarkUranium> the branch should be pretty fast in theory, as it *should* be coherent[14:13:39] <DarkUranium> bigger buffer is the safer choice here, though[14:13:47] <DarkUranium> safer in terms of performance implications, I mean[14:13:55] <DarkUranium> (though when in doubt, profile!)[14:14:04] <roxlu> Yep! Thanks so much for your advice![14:14:14] <DarkUranium> mind you, you'll have relatively terrible performance until you increase that local size (and ofc decrease global)[14:14:16] <DarkUranium> so keep that in mind[14:14:27] <DarkUranium> for dev though, it'll mean one less thing to keep in mind[14:18:02] <roxlu> and I was thinking about how to layout my skinned vertex struct. Now I have something like: struct vertex { vec3 pos; vec2 uv; vec3 norm; etc.. }, so not nicely aligned in such a way that I can use the same structure in glsl.[14:18:41] <roxlu> I can either add some paddings so everything is nicely aligned at 4 floats ...or maybe I use a buffer as you suggested above[14:18:48] <DarkUranium> you can, but vec3 is a portability nightmare[14:19:04] <DarkUranium> brb[14:19:06] <roxlu> yeah[14:21:11] *** RonaldsMazitis <RonaldsMazitis!~quassel@78.84.29.65> has joined ##OpenGL[14:22:54] <roxlu> ah and I the skinning indices and weights that I have for each vertex are uint8_t atm. that's probably ok[14:32:46] *** Tobbi <Tobbi!~Tobbi@supertux/tobbi> has joined ##OpenGL[14:34:35] *** rizzo <rizzo!~RizzoTheR@p54B6BDA4.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)[14:34:46] <DarkUranium> back[14:34:58] <roxlu> yo[14:35:02] <DarkUranium> you can just mask&shift, and it'll be fine[14:35:11] <DarkUranium> ... assuming you have a multiple of 4 of 'em[14:35:24] <DarkUranium> (well, even if not you can, but y'know)[14:35:43] <roxlu> Yeah can't I just use char/uchar or something?[14:35:55] <roxlu> or do you suggest using one uint?[14:36:14] <DarkUranium> there is no char/uchar in GLSL.[14:37:28] <roxlu> ha, well that makes it easy then :)[14:38:37] *** ngm <ngm!~nishanth@183.82.187.154> has quit IRC (Ping timeout: 256 seconds)[14:45:46] *** RonaldsMazitis <RonaldsMazitis!~quassel@78.84.29.65> has quit IRC (Remote host closed the connection)[14:45:55] *** RonaldsMazitis <RonaldsMazitis!~quassel@78.84.29.65> has joined ##OpenGL[14:46:59] *** wuji2016 <wuji2016!~Thunderbi@112.31.70.31> has quit IRC (Ping timeout: 260 seconds)[14:49:34] *** qeed <qeed!~qeed@pool-98-118-249-109.clppva.fios.verizon.net> has joined ##OpenGL[14:54:10] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[14:55:28] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:24a9:a8f:6871:de57> has joined ##OpenGL[14:55:28] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:24a9:a8f:6871:de57> has quit IRC (Changing host)[14:55:28] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[14:59:44] <ZeroWalker> been trying to solve a weird issue. I bind and upload 3 different buffers, positions etc. And i can't update it, even when u bind and use glBufferData it doesn't seem to have any impact at all[15:00:07] <ZeroWalker> i made sure the same shader program and vao is used, is there something else i might be missing?[15:07:32] *** RajRajRaj <RajRajRaj!uid72176@gateway/web/irccloud.com/x-qczlwhqmvffxrpmh> has joined ##OpenGL[15:08:39] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[15:09:57] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[15:10:28] <roxlu> ZeroWalker: maybe use renderdoc to inspect your buffer to see if the data is really not uploaded[15:12:28] *** Murii <Murii!~Murii@79.113.205.114> has quit IRC (Ping timeout: 252 seconds)[15:15:01] <ZeroWalker> never used that, seems complicated, do i have to inject that into the code or something?[15:15:16] <ZeroWalker> and the buffer is uploaded once at least, when it's first created, it's updating that for some reason doesn't work[15:15:32] <ratchetfreak> no you launch your application from within renderdoc and it will inject itself[15:15:41] <ZeroWalker> i know it has worked, but i don't know when it broke, i even do it all overkill by re uploading the entire thing every frame[15:15:53] <ZeroWalker> ah nice, sounds simple enough[15:17:19] <ZeroWalker> btw did you guys see my last question a bit back?[15:17:22] <roxlu> ZeroWalker: it's really worth diving into renderdoc, it will speed up debugging a lot[15:17:55] <ZeroWalker> that sounds awesome, cause i feel that when you are doing stuff gpu wise, you are quite limited in knowing what actually goes on so to speak[15:19:00] <roxlu> Yeah, renderdoc fixes that :)[15:19:01] *** ngm <ngm!~nishanth@183.82.187.154> has joined ##OpenGL[15:19:30] *** korans <korans!~korans@83.137.252.187> has quit IRC (Remote host closed the connection)[15:19:57] <pa> any1 tried swiftshader on linux?[15:20:20] <pa> i'm trying to run glxinfo after LD_PRELOADing the swiftshader libs, but i get a segfault[15:22:29] <pa> hm[15:22:35] <pa> might be that im missing linux-vdso[15:22:37] <pa> not sure[15:25:03] <ZeroWalker> hmm, well using renderdoc now, trying to figure out what to look for. I at least get hte overlay[15:29:01] <roxlu> There is a panel called "Resource Inspector", there you can find your 'resources'. One of them is your array buffer[15:29:18] <roxlu> ZeroWalker: you can use glObjectLabel to give your buffer a name and it will show up in the list[15:29:50] *** bookmark <bookmark!~IceChat77@47.196.110.8> has quit IRC (Ping timeout: 268 seconds)[15:29:56] <ZeroWalker> got no such command, it's new?[15:30:01] <roxlu> ZeroWalker: When you find it, click it and click the "View contents" button. There you can specify how the data should be interpreted (e.g. float3 pos; float2 uv; etc..)[15:30:14] <roxlu> It's not a command[15:30:29] <roxlu> oh glObjectLabel ? .. that's a function .. but yeah it's newish[15:31:00] <ZeroWalker> ah yeah my bad, meant function. Okay dont have it sadly (3.3 core)[15:31:36] <roxlu> then you have to step through your calls and see what buffer is used[15:31:43] *** Gama11_ <Gama11_!~quassel@p5DCDBA0D.dip0.t-ipconnect.de> has joined ##OpenGL[15:31:58] <ZeroWalker> well everything is basically empty in renderdoc[15:32:12] <ZeroWalker> API Calls is empty for example[15:32:18] *** Gama11 <Gama11!~quassel@p5DCDB3CC.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 268 seconds)[15:32:24] <roxlu> did you make a capture?[15:32:39] <ZeroWalker> ah you need to capture and load it?[15:32:40] *** Orion] <Orion]!~H0i@unaffiliated/orion/x-3970838> has joined ##OpenGL[15:32:53] <roxlu> https://www.youtube.com/results?search_query=using+renderdoc <-- take some time to watch a couple of videos[15:34:48] <ZeroWalker> will do that, i see some API calls but none of those i want, let's see what youtube can tell me[15:35:27] *** Asu <Asu!~sdelang@90.37.234.95> has joined ##OpenGL[15:36:16] <ratchetfreak> objectLabel can be part of an extension so it's possible that renderdoc enables it anyway[15:36:43] *** Albori <Albori!~Albori@64-251-148-158.fidnet.com> has quit IRC (Quit: Albori)[15:49:57] *** irrenhaus3 <irrenhaus3!~xenon@ip-37-201-7-18.hsi13.unitymediagroup.de> has joined ##OpenGL[15:54:46] *** hampusw <hampusw!~Hampus@37.139.156.40> has quit IRC (Quit: Leaving)[15:55:35] *** Keniyal <Keniyal!~Keniyal@unaffiliated/keniyal> has quit IRC (Remote host closed the connection)[16:00:20] <ZeroWalker> hmm, well kinda hard to find info about the stuff i want, been trying to look for bindbuffer, or bufferdata, but nothing comes up on google with renderdoc[16:01:02] *** bpmedley <bpmedley!~bpm@c-24-72-144-105.ni.gigamonster.net> has quit IRC (Ping timeout: 256 seconds)[16:01:55] <ZeroWalker> oh wait, was me being stupid[16:02:10] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[16:03:42] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:a470:fb66:eaf2:8390> has joined ##OpenGL[16:03:42] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:a470:fb66:eaf2:8390> has quit IRC (Changing host)[16:03:42] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[16:04:02] <ZeroWalker> or well not it crashed on capture instead xd[16:04:03] *** zeduckmaster <zeduckmaster!~zeduckmas@85.106.1.181> has quit IRC (Quit: Leaving)[16:05:39] <roxlu> For me renderdoc only crashed when I was trying to upload data into a gpu buffer that wasn't allocated[16:05:44] <roxlu> so that could be a hint[16:06:05] <ZeroWalker> yeah checked it out, the weird thing is, it doesn't sync up[16:06:21] <ZeroWalker> if i run and debug the program myself, the "location" numbers are all the same all the times[16:06:42] <ZeroWalker> when renderdock crashes and i debug it, the location numbers are higher[16:06:47] <roxlu> What do you mean with location numbers?[16:06:50] <ZeroWalker> like it has generated more ids[16:06:59] <ZeroWalker> oh wait, not location numbers.. meant ids[16:07:00] <ZeroWalker> names[16:07:03] <roxlu> the ids in the resources are not the same as your vbo ids[16:07:14] <ZeroWalker> yeah know[16:07:17] <ZeroWalker> so forget the location[16:07:22] <ZeroWalker> the ids are wrong[16:08:03] <roxlu> Can you paste your code otherwise? Maybe there is a obvious thing I can spot[16:09:05] <ZeroWalker> okay only reason i can happen is if it somehow runs my initialization several times, and that code is like this:[16:09:46] <ZeroWalker> http://paste.awesom.eu/HkSh[16:10:01] <ZeroWalker> so, if i am not missing something, it's impossible for the "SetupBuffers" to run more than once[16:10:12] <ZeroWalker> unless i guess you ran multiple threads[16:13:00] <roxlu> runOnce is not initialized[16:13:21] *** _borkr_ <_borkr_!~borkr@static130-244.mimer.net> has quit IRC (Quit: Leaving)[16:13:30] <roxlu> e.g. use something like `static int runOnce = 0;`[16:14:00] <ZeroWalker> isn't static automatically always initialized to 0?[16:14:18] <roxlu> Hmm not that I'm aware of tbh, but could be[16:14:42] <ZeroWalker> pretty sure it is. Nevertheless tried it, same results sadly[16:14:48] <roxlu> ah seems to be yeah[16:14:57] <ZeroWalker> makes no sense why renderdoc achives to run it multiple times[16:15:02] <ZeroWalker> but normally launching it does not[16:15:05] <roxlu> can you paste SetupBuffers too[16:15:10] *** CoolerZ <CoolerZ!~coolerext@27.97.191.81> has quit IRC (Ping timeout: 240 seconds)[16:16:04] <ZeroWalker> well that one is shitty, but will show it anyhow, basially just a bunch of repeated stuff[16:16:16] <ZeroWalker> http://paste.awesom.eu/vBJB&ln[16:16:48] <ZeroWalker> GL_SetupVertexBuffer basically just generate an id, bind and buffer, and enable it, then return the id[16:16:53] <roxlu> DarkUranium: do you know if a glsl struct like: struct SkinnedVertex { vec4 position; uint indices; uint weights }, is nicely aligned?[16:17:27] <ZeroWalker> if the ints are 32bit, i don't see why not?[16:18:48] <roxlu> ZeroWalker: with GLSL that will not always align memory nicely[16:19:09] <roxlu> where is your `VertData` ?[16:19:11] <zid> roxlu: the = 0; is redundant if it's also static, fyi[16:19:23] <ZeroWalker> oh, damn GLSL[16:19:30] <ZeroWalker> will check[16:19:43] <ZeroWalker> it's there[16:19:47] <roxlu> zid: yeah thanks[16:19:48] <ZeroWalker> but it's named vertices_position[16:19:58] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##OpenGL[16:20:26] * zid just did a thousand line diff and broke something, yay[16:21:51] <roxlu> ZeroWalker: can't see anything from that code[16:22:06] *** wuji2016 <wuji2016!~Thunderbi@112.31.70.31> has joined ##OpenGL[16:22:09] <roxlu> What you could do... is just download the gpu data again right after uploading it[16:22:23] <ZeroWalker> maybe you didn't mean this: mainGL.vertData = GL_SetupVertexBuffer(VertData, sizeof(vertices_position), vertices_position, 2, GL_FLOAT, 0);[16:22:26] <roxlu> ZeroWalker: just to be sure it's there. If it's not then your glBufferData call is wrong[16:22:46] <zid> ah damn forgot the shader api *back to shuffling code around*[16:22:47] <ZeroWalker> oh, you can download the data?[16:23:04] <roxlu> yep[16:23:34] <roxlu> ZeroWalker: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetBufferSubData.xhtml[16:26:52] <ZeroWalker> yeah, 4.5 sadly[16:27:24] <ZeroWalker> well just setup a safe mechanism to break if an id is different from what i expect[16:27:39] <ZeroWalker> renderdoc crashes immediatly now, otherwise it works fine[16:27:53] <karalaine> only the glGetNamedBufferSubData is 4.5[16:28:13] <karalaine> glGetBufferSubData is from 2.0[16:28:27] <ZeroWalker> yeah, but that can't grab the data, can it?[16:28:33] <ZeroWalker> oh i am blind[16:28:43] <ZeroWalker> throught it said "glBufferSubData" -_-[16:29:56] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[16:29:58] <ZeroWalker> seems to be updated as expected, weird[16:30:46] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:146b:ea88:8ce0:dc4a> has joined ##OpenGL[16:30:46] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:146b:ea88:8ce0:dc4a> has quit IRC (Changing host)[16:30:46] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[16:30:57] *** borkr <borkr!~borkr@static130-244.mimer.net> has joined ##OpenGL[16:31:41] *** krystcich_ <krystcich_!~krystcich@178235146053.dynamic-zab-01.vectranet.pl> has joined ##OpenGL[16:33:18] <roxlu> Ok, well that's good ZeroWalker, then I expect it's an issue with your VAO[16:34:02] <ZeroWalker> that has been on my list of possible issues, but there's not much to do there. There's one vao generated and bound, then afterwards everything else is created etc[16:34:33] *** echotangoecho <echotangoecho!~echotango@92-108-127-60.cable.dynamic.v4.ziggo.nl> has quit IRC (Quit: Lost terminal)[16:35:11] <roxlu> when the buffer data is correctly uploaded (also after a couple of frames) then you at least know that your buffer is okay[16:35:30] <roxlu> I would then check my shaders (e.g. are your matrices in order) and your vao[16:38:44] *** Cooler <Cooler!~coolerext@27.97.191.81> has joined ##OpenGL[16:39:58] <ZeroWalker> i can at least confirm the vertex data itself is in order, and the rest of the data seems to be at whatever it was when first uploaded[16:40:25] <ZeroWalker> which makes no sense as the data is indeed updated.[16:40:38] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Read error: Connection reset by peer)[16:41:04] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:146b:ea88:8ce0:dc4a> has joined ##OpenGL[16:41:04] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:146b:ea88:8ce0:dc4a> has quit IRC (Changing host)[16:41:04] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[16:41:15] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[16:44:28] <DarkUranium> roxlu, is `indices` the element array? It doesn't make much sense to mix vertex & element arrays in the same buffer[16:45:12] <roxlu> DarkUranium: yeah, I realised that indeed, I've removed the indices as I don't need them[16:45:30] <roxlu> I had an issue with my GLSL struct; I had to align it at 16 bytes[16:45:34] *** hellozee <hellozee!~hellozee@150.242.175.114> has joined ##OpenGL[16:48:37] *** Murii <Murii!~Murii@79.113.205.114> has joined ##OpenGL[16:49:18] <zid> damn you shader var, I need you in so many places :([16:49:41] <ZeroWalker> what i would want is a GLSL struct for vertex attribute, that would be awesome[16:50:36] <roxlu> GL 4.3+ is so much nicer to work with :)[16:50:53] <ZeroWalker> do they allow GLSL struct for input?[16:51:20] *** wuji2016 <wuji2016!~Thunderbi@112.31.70.31> has quit IRC (Quit: wuji2016)[16:51:32] <ZeroWalker> remember checking what's new in later versions, couldn't see anything "special", probably cause i didn't understand what it was[16:51:47] <roxlu> Not in that sense, no[16:52:32] <roxlu> But in general I find it a lot nicer to work with. E.g. before I used transform feedback to do gpu based particles and ribbons and vertex emitting which was -a lot- more work and complex[16:54:48] <ZeroWalker> never done any such stuff, but simpler for the same results without reducing usability is a win win[17:01:16] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has quit IRC (Quit: *waves frantically*)[17:01:52] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has joined ##OpenGL[17:07:56] *** delicado <delicado!~delicado@110.54.152.26> has quit IRC (Ping timeout: 255 seconds)[17:08:10] *** delicado <delicado!~delicado@110.54.226.47> has joined ##OpenGL[17:11:59] *** MrFlibble <MrFlibble!MrFlibble@90.196.204.40> has joined ##OpenGL[17:14:32] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has joined ##OpenGL[17:16:59] *** Tobbi <Tobbi!~Tobbi@supertux/tobbi> has quit IRC (Remote host closed the connection)[17:17:40] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 240 seconds)[17:21:09] <pa> is it possible to have mesa llvm driver on an ubuntu installed alongside with another driver (say nvidia)?[17:22:47] <ZeroWalker> vertices data and UV etc, that should be: glVertexAttribDivisor(location, 0); right? (if you only have one batch of them)[17:26:02] <zid> 13 files changed, 363 insertions(+), 270 deletions(-)[17:26:07] <zid> Finally it builds and runs again :P[17:27:02] *** stefkos <stefkos!~Pawel@82.177.144.226> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))[17:27:37] <roxlu> ZeroWalker: yes[17:27:47] <roxlu> ZeroWalker: but if you dont use instancing you can leave the default[17:28:04] *** neurre <neurre!~tsuoranta@62.209.167.43> has joined ##OpenGL[17:28:32] <ZeroWalker> yeah but i use the same function to do the stuff and as much use instancing i like to have it there. And just set 0 for the ones that don't need it, but i could just skip it if it's 0 as well[17:28:34] *** YungMoonHodler__ <YungMoonHodler__!~me@2a02:810c:c7c0:1965:9c9a:cbd9:18d8:d08d> has joined ##OpenGL[17:28:34] *** YungMoonHodler__ <YungMoonHodler__!~me@2a02:810c:c7c0:1965:9c9a:cbd9:18d8:d08d> has quit IRC (Changing host)[17:28:34] *** YungMoonHodler__ <YungMoonHodler__!~me@unaffiliated/boscop> has joined ##OpenGL[17:29:47] *** mijowh <mijowh!~mijowh@75.97.236.147.res-cmts.leh.ptd.net> has joined ##OpenGL[17:30:15] *** acksys <acksys!~acksys@ip72-208-121-9.ph.ph.cox.net> has joined ##OpenGL[17:31:20] *** mij <mij!~mijowh@75.97.236.147.res-cmts.leh.ptd.net> has quit IRC (Ping timeout: 255 seconds)[17:32:16] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[17:34:02] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has quit IRC (Ping timeout: 276 seconds)[17:34:11] <roxlu> DarkUranium: https://mega.nz/#!DV9xSQqD!hCJXyIG6OahFLlQ6gJrlcUzd7tBG3NeUG3oMCtpuKU0 using compute to get velocity from skinned vertices[17:36:04] *** MrFlibble <MrFlibble!MrFlibble@90.196.204.40> has quit IRC (Quit: MrFlibble)[17:36:11] *** MrFlibble <MrFlibble!MrFlibble@90.196.204.40> has joined ##OpenGL[17:38:28] *** raynold <raynold!uid201163@gateway/web/irccloud.com/x-ejnqxruzcipzmryj> has joined ##OpenGL[17:42:05] *** ngm <ngm!~nishanth@183.82.187.154> has quit IRC (Quit: Leaving)[17:44:19] *** Albori <Albori!~Albori@64-251-148-158.fidnet.com> has joined ##OpenGL[17:50:49] *** ertes <ertes!~ertes@haskell/developer/ertes> has joined ##OpenGL[17:52:58] <pa> any1 using swiftshader?[17:53:25] <pa> i am trying to use it on a linux with nvidia drivers, and it seems LD_LIBRARY_PATH is not working. Is it because i have nvidia kernel module loaded?[17:55:54] *** ttoocs <ttoocs!~ttoocs@S0106bcaec5c4f1ed.cg.shawcable.net> has joined ##OpenGL[17:56:49] <ttoocs> Q: How would one go about getting a base-Opengl of 2.1, and then extending it to 4.1 if the hardware supports it?[17:57:11] <ZeroWalker> okay well it's going well with debugging, something is wrong with my function that creates the buffers, but it's weird, if i do it manually (the same way) it works. So there must be some kind of typo or similar that goes under the radar for me[17:57:44] *** Kane <Kane!~Kane@home.yarg.fr> has joined ##OpenGL[18:00:39] <ttoocs> I am aware of extensions, but I'm not sure how powerful they are in regards to this.. I'm aware most things in core seem to also have an extension-esk name to it... do you just use that extension and see if it works?[18:00:46] <Shockk> ttoocs: the first thing is going to be, certain features should only be enabled if you have the gl version for them, like for example, geometry shaders are only available in version 3.2 (or with the use of an extension)[18:01:31] <Shockk> so if you're wanting to support a base version of 2.1, what you should start with is something that works just in base 2.1, and then optionally enable stuff on top of that[18:01:39] <ttoocs> Aye.[18:02:25] <ttoocs> That part is what does make sense, I'm more curious on how _much_ can be enabled (supposing whatever hardware supports it etc..)[18:02:30] <Shockk> you'll probably need multiple versions of your shaders, or some domain-specific language that you can transpile down into whichever GLSL version is available[18:03:03] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has joined ##OpenGL[18:03:08] *** hellozee <hellozee!~hellozee@150.242.175.114> has quit IRC (Remote host closed the connection)[18:03:18] <ttoocs> Ie: basically all of OpenGL accessible via extension loading?[18:04:55] <Shockk> hmm, I'm not sure, do you mean like, if the hw supports gl 3.2 but you have a 2.1 context, would it be guaranteed to support the ARB_geometry_shader4 extension?[18:05:50] <Shockk> if that's the question, I don't know the answer, but I would prefer to go and request the highest context version available, and initially enable features based on context version[18:06:08] <Shockk> rather than request everything through extensions[18:06:29] <zid> Or be like me and just assume gl4 and pray[18:06:36] <ttoocs> xD[18:07:20] <ttoocs> Let's try this: Is OpenGL core just a set of garanteed/enabled extensions per version?[18:08:34] *** CoolerX <CoolerX!~coolerext@49.15.80.128> has joined ##OpenGL[18:08:45] <ttoocs> As when I see this: https://www.khronos.org/registry/OpenGL/index_gl.php[18:09:34] <ttoocs> I see 500+ extensions, and 57 seems to define what a uniform is.[18:09:53] *** greysleeper <greysleeper!~greysleep@cpe-76-85-20-240.tx.res.rr.com> has quit IRC (Ping timeout: 276 seconds)[18:10:36] <ttoocs> And compute is 122... etc.[18:11:40] *** Cooler <Cooler!~coolerext@27.97.191.81> has quit IRC (Ping timeout: 240 seconds)[18:11:50] <ttoocs> So, it looks like it can be composed of just a set of extensions... I'm just not sure if that's /actually/ how it's setup.[18:16:54] *** Tobbi <Tobbi!~Tobbi@supertux/tobbi> has joined ##OpenGL[18:17:05] *** Serpent7776 <Serpent7776!~Serpent77@90-156-68-175.internetia.net.pl> has quit IRC (Quit: Leaving)[18:17:06] *** CoolerZ <CoolerZ!~coolerext@42.109.180.182> has joined ##OpenGL[18:17:16] <Shockk> ttoocs: I might be wrong in saying this, but I don't think for example that the separate profiles (core, compatibility, ES) which came in 3.2 are an extension in that sense[18:18:07] <Shockk> I don't know if there's anything else[18:20:50] *** CoolerX <CoolerX!~coolerext@49.15.80.128> has quit IRC (Ping timeout: 255 seconds)[18:22:17] <ttoocs> Aye, I think I'll just have to play around with it or something.[18:28:14] *** YungMoonHodler__ <YungMoonHodler__!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[18:29:04] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[18:33:44] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 260 seconds)[18:34:05] *** jokoon <jokoon!~jokoon@2a01:e35:2e08:9f10:6d10:a157:5a85:23dc> has joined ##OpenGL[18:34:29] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 255 seconds)[18:34:52] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:d43a:fe10:9c5f:c89c> has joined ##OpenGL[18:34:52] *** YungMoonHodler <YungMoonHodler!~me@2a02:810c:c7c0:1965:d43a:fe10:9c5f:c89c> has quit IRC (Changing host)[18:34:52] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has joined ##OpenGL[18:42:23] *** BearishMushroom <BearishMushroom!~BearishMu@82-209-154-59.cust.bredband2.com> has joined ##OpenGL[18:43:59] <ttoocs> huh, apprently I've never used anything not in shaders 2.1, (well, except when I did a compute shader once.)[18:50:35] <ZeroWalker> CS[18:57:08] *** Kane <Kane!~Kane@home.yarg.fr> has quit IRC (Ping timeout: 256 seconds)[19:01:13] *** toblorone <toblorone!~toblorone@162.246.216.28> has joined ##OpenGL[19:01:25] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[19:05:07] <chrisf> ttoocs: /roughly/.[19:05:35] <chrisf> there are occasional changes in the core spec that arent in the extensions[19:06:01] <chrisf> and you'd want to start from at least 3.2[19:11:44] *** suhdood <suhdood!~Thaelim@2601:281:c502:25d9:5cd:bbd3:d92b:e035> has joined ##OpenGL[19:13:02] *** Kane <Kane!~Kane@home.yarg.fr> has joined ##OpenGL[19:18:23] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7n8nco8egy36si.18120a2.ip6.access.telenet.be> has joined ##OpenGL[19:24:10] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has joined ##OpenGL[19:27:12] *** jokoon <jokoon!~jokoon@2a01:e35:2e08:9f10:6d10:a157:5a85:23dc> has quit IRC (Quit: Leaving)[19:32:59] *** tobloron_ <tobloron_!~toblorone@162.246.216.28> has joined ##OpenGL[19:37:07] *** toblorone <toblorone!~toblorone@162.246.216.28> has quit IRC (Ping timeout: 268 seconds)[19:44:12] *** rizzo <rizzo!~RizzoTheR@p54B6BDA4.dip0.t-ipconnect.de> has joined ##OpenGL[19:46:06] *** YungMoonHodler_ <YungMoonHodler_!~me@2a02:810c:c7c0:1965:d43a:fe10:9c5f:c89c> has joined ##OpenGL[19:46:06] *** YungMoonHodler_ <YungMoonHodler_!~me@2a02:810c:c7c0:1965:d43a:fe10:9c5f:c89c> has quit IRC (Changing host)[19:46:06] *** YungMoonHodler_ <YungMoonHodler_!~me@unaffiliated/boscop> has joined ##OpenGL[19:49:20] <ZeroWalker> DarkUranium, you there?[19:49:24] *** YungMoonHodler <YungMoonHodler!~me@unaffiliated/boscop> has quit IRC (Ping timeout: 256 seconds)[19:53:34] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7n8nco8egy36si.18120a2.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)[19:54:02] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7n8nco8egy36si.18120a2.ip6.access.telenet.be> has joined ##OpenGL[19:57:23] <DarkUranium> ZeroWalker, I am now.[19:57:28] <DarkUranium> sup?[19:58:04] <ZeroWalker> yay, well, it's about the spatial hashing thingy, harder than i thought, but i get now why you didn't understand before why a 2D array split into 32 blocks would be limited[19:58:44] <ZeroWalker> when i talked bout it, i meant simply that you split up the map into 32x32, and then 1 block = 1 texture. So it just have one sprite available per index[19:58:49] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[19:59:05] <ZeroWalker> hence why sprites with different sizes would mess things up a bit[19:59:18] <ZeroWalker> but if i understand the spatial hashing correct. You first have one array with basically the entire data[19:59:56] <ZeroWalker> then you have a 2D (for 2D stuff) split up into blocks, and each block have some available spaces where you can put data, and that data should be used to look up the original data[19:59:59] <ZeroWalker> or something?[20:02:26] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Ping timeout: 256 seconds)[20:05:44] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has joined ##OpenGL[20:07:22] *** ttoocs <ttoocs!~ttoocs@S0106bcaec5c4f1ed.cg.shawcable.net> has quit IRC (Quit: WeeChat 2.0.1)[20:12:18] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Ping timeout: 240 seconds)[20:14:43] *** Tobbi <Tobbi!~Tobbi@supertux/tobbi> has quit IRC (Remote host closed the connection)[20:19:54] *** Tobbi <Tobbi!~Tobbi@supertux/tobbi> has joined ##OpenGL[20:21:31] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has joined ##OpenGL[20:21:50] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Remote host closed the connection)[20:25:28] *** iderik <iderik!~idk@h-0-97.A147.priv.bahnhof.se> has quit IRC (Quit: iderik)[20:32:55] *** suhdood_ <suhdood_!~Thaelim@2600:380:9914:a394:5cd:bbd3:d92b:e035> has joined ##OpenGL[20:34:43] *** suhdood_ <suhdood_!~Thaelim@2600:380:9914:a394:5cd:bbd3:d92b:e035> has quit IRC (Remote host closed the connection)[20:35:18] *** suhdood <suhdood!~Thaelim@2601:281:c502:25d9:5cd:bbd3:d92b:e035> has quit IRC (Ping timeout: 240 seconds)[20:39:10] *** suhdood <suhdood!~Thaelim@2600:380:9914:a394:9857:b7f0:21ce:c792> has joined ##OpenGL[20:41:26] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[20:44:05] *** Kane_ <Kane_!~Kane@home.yarg.fr> has joined ##OpenGL[20:45:07] *** neurre <neurre!~tsuoranta@62.209.167.43> has quit IRC (Ping timeout: 265 seconds)[20:47:28] <ZeroWalker> guess i was all wrong cause of the silence xd[20:48:02] *** Kane <Kane!~Kane@home.yarg.fr> has quit IRC (Ping timeout: 268 seconds)[20:52:46] <DarkUranium> sorry, was AFK again >_<[20:53:36] *** Kane_ <Kane_!~Kane@home.yarg.fr> has quit IRC (Quit: Leaving)[20:53:50] <DarkUranium> ZeroWalker, spatial hashing is ... it's basically (depending on approach) using a simple hash table, where you use buckets for 2D data *or* some locality-preserving hashing scheme in a more linear structure[20:54:02] <DarkUranium> the former being easiest here[20:54:17] <DarkUranium> in other words, instead of searching through the whole list, just use a NxM grid.[20:54:26] <DarkUranium> Now, that limits you to NxM in size --- which is where the hashing comes in.[20:55:00] <DarkUranium> so, a (cell_x,cell_y) => object multimap[20:56:44] *** stefkos <stefkos!~Pawel@82.177.144.226> has joined ##OpenGL[20:59:13] *** ertes <ertes!~ertes@haskell/developer/ertes> has quit IRC (Ping timeout: 256 seconds)[20:59:50] <ZeroWalker> multimap?[21:01:43] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has joined ##OpenGL[21:07:13] *** Quetzal2 <Quetzal2!~Quetzal2@unaffiliated/quetzal2> has joined ##OpenGL[21:16:17] *** derhass <derhass!~derhass@dslb-094-222-155-209.094.222.pools.vodafone-ip.de> has joined ##OpenGL[21:19:32] *** ipe <ipe!~ipe@91-156-244-112.elisa-laajakaista.fi> has left ##OpenGL ("Leaving")[21:20:08] *** Fr0stBit <Fr0stBit!5150@2a02:2149:8167:1b00:922b:34ff:fe36:b288> has joined ##OpenGL[21:20:27] *** Kingsquee <Kingsquee!~kingsquee@d108-180-237-219.bchsia.telus.net> has joined ##OpenGL[21:21:47] *** tambre <tambre!~tambre@e0b8-5873-0797-1dfa-ab80-8a0a-07d0-2001.dyn.estpak.ee> has quit IRC (Ping timeout: 260 seconds)[21:23:47] *** ipe <ipe!~ipe@91-156-244-112.elisa-laajakaista.fi> has joined ##OpenGL[21:29:37] *** halbeno_ <halbeno_!~halbeno@node-1w7jra22dpc6yrvo9wam83mu0.ipv6.telus.net> has quit IRC (Quit: Leaving)[21:44:06] <DarkUranium> ZeroWalker, https://en.wikipedia.org/wiki/Multimap[21:44:29] <DarkUranium> it's a map where you can have multiple values for the same key.[21:45:10] *** borkr <borkr!~borkr@static130-244.mimer.net> has quit IRC (Ping timeout: 240 seconds)[21:47:08] <ZeroWalker> hmm, think i saw that about hashing, someone had an array, and if both pointed to the same place he linked it away or something, guess that was some multimap thingy[21:48:11] <ZeroWalker> damn this is hard stuff xd[21:50:58] <chrisf> ZeroWalker: this is where some theoretical CS background helps :)[21:51:40] <derhass> huh? theory never helps. it only confuses and makes things complicated![21:52:21] <ZeroWalker> CS backgrounds?[21:52:26] * chrisf prescribes another layer of indirection for derhass[21:52:26] <ZeroWalker> Counter Strike backgrounds?[21:52:31] <derhass> LOL[21:52:32] <Fr0stBit> Computer Science[21:52:41] <ZeroWalker> xD[21:53:03] <derhass> chrisf: I certainly have enough of those[21:53:58] <ZeroWalker> well been watching around ppl explaining stuff. Theory helps a ton, but i need practical demonstration of things as well, i can't go theory to practical (unless i am very used to the thing i guess)[21:54:29] <ZeroWalker> currently watching this, and it just confuses me haha xD: https://youtu.be/IELWpIGtjRg?t=157[21:54:45] <Spark> As someone who did a CS theory PhD, I concur with this assessment[21:55:00] <ZeroWalker> which off them[21:55:04] <ZeroWalker> that it's good or bad[21:55:13] <Spark> it only confuses and makes things complicated[21:55:35] <ZeroWalker> ah[21:57:25] <Stragus> ZeroWalker: You can forget hashing for 2D collision detection, just store a list of things per sector/area/region/whatever, and check them for collision[21:57:32] <Stragus> That should be pretty simple[21:57:50] <ZeroWalker> so basically just spam through the entire "object list"[21:58:35] <ZeroWalker> currently doing that as i couldn't figure out the hashing for now. So just trying to implement a simple collision detection, which "kinda" works.[21:58:41] <Stragus> No, the local object list, per sector/area/region[21:58:53] <derhass> grid cell[21:58:59] <ZeroWalker> simple If(x <= wall && x + width >= wall) stuff[21:59:11] *** LurchMan <LurchMan!~LurchMan@8.28.55.10> has quit IRC (Ping timeout: 248 seconds)[21:59:39] <ZeroWalker> but wait, wouldn't that be the point of using the hashing thing, ti have the world in cells?[22:00:35] <derhass> well. in a way, it would be, just with a trivial hash function[22:01:00] <Stragus> Forget the hash, it's just a way to store many cells in the same data structure, but you get collisions and more computations. I wouldn't do that[22:01:03] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Read error: Connection reset by peer)[22:01:19] * Stragus wrote plenty of 2D collision stuff a very long time ago[22:03:35] *** LurchMan <LurchMan!~LurchMan@8.28.55.10> has joined ##OpenGL[22:05:40] <ZeroWalker> well, now i am a bit lost. Do i want to have cells, so basically a 2D Array, and in those Cells it should have everything that's within it?[22:06:39] *** ravior <ravior!~crapitea@38.132.111.173> has joined ##OpenGL[22:10:40] *** slvn_ <slvn_!~slvn_@c2s31-1-78-245-90-111.fbx.proxad.net> has quit IRC (Quit: Leaving)[22:10:45] <Stragus> That's an easy and efficient solution, a 2D grid of cells with list of objects in them[22:11:20] <Stragus> Then you want to check for collision with an object X of radius Y, you check the objects from all the cells that overlap said area[22:12:07] <Fr0stBit> Stragus, chrisf: Just found out what we have been working on yesterday from unity resources! https://github.com/Unity-Technologies/experimental-ARInterface/blob/61e2d7bfa63dfa1b8f24e599d4c6d57f7c94c5b1/Assets/TanksNetworkingAR/PostProcessing/Resources/Shaders/EyeHistogram.compute[22:12:24] <Fr0stBit> Seems pretty much the same like the code we hacked yd[22:13:09] <ZeroWalker> yeah i kinda get the concept of that, seem videos that visually show it. Though the hard parts for me is the structuring itself. But then the damn math to calculate what goes where cause of the width/height etc. My math skills are equal to kindergarten, not to brag of course[22:13:32] <ZeroWalker> https://www.youtube.com/watch?v=e5VQ1EBQXtU[22:13:48] <ZeroWalker> i am guessing we are talking about something like this[22:14:07] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[22:15:22] <Stragus> ZeroWalker: cellx = object.x / cellsize; celly = object.y / cellsize;[22:15:32] <Stragus> (not going to watch a video, I hate videos)[22:15:50] <ZeroWalker> it's just blocks flying around getting red in their "cell" for collision xd[22:16:11] <ZeroWalker> yeah That i get, that calculation[22:16:12] <Stragus> Flagging whole cells is a way, but that's more limited[22:16:16] <derhass> Stragus: that's only tyrue if your objects are just points[22:16:33] <derhass> *true[22:16:47] <ZeroWalker> but object.x might be in Cell[0] let's say. But it's width goes into Cell[1][22:17:09] <Stragus> derhass: Not necessarily, but it helps if there's a maximum object radius to check an area for overlap[22:17:19] <ZeroWalker> and, if it's like my stuff where everything it basically 32x32 neatly placed, calculating that jumps two places (most likely wrong)[22:17:21] <ZeroWalker> basically[22:17:30] <ZeroWalker> cellx = object.x / cellsize;[22:17:31] <derhass> Stragus: that's one way to di it[22:17:44] <ZeroWalker> cellx2 = (object.x + object.w) / cellsize;[22:19:18] *** Neomex <Neomex!~quassel@net-37-117-5-106.cust.vodafonedsl.it> has quit IRC (Remote host closed the connection)[22:21:52] *** jdashg <jdashg!~jdashg@corp-nat.fw1.untrust.mtv2.mozilla.net> has joined ##OpenGL[22:23:38] *** davr0s <davr0s!~textual@host86-147-196-14.range86-147.btcentralplus.com> has joined ##OpenGL[22:27:09] <ZeroWalker> Well i guess i will begin with doing the collision to a basic level, as it should be the same no matter how i get the data[22:27:15] *** RajRajRaj <RajRajRaj!uid72176@gateway/web/irccloud.com/x-qczlwhqmvffxrpmh> has quit IRC (Quit: Connection closed for inactivity)[22:27:15] *** delicado <delicado!~delicado@110.54.226.47> has quit IRC ()[22:27:29] <ZeroWalker> and guess SAT is the shit as it's mentioned all over[22:27:49] *** stefkos <stefkos!~Pawel@82.177.144.226> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))[22:28:32] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[22:28:48] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Remote host closed the connection)[22:31:32] *** slime <slime!~slime73@24.215.81.93> has joined ##OpenGL[22:35:32] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[22:39:53] *** suhdood <suhdood!~Thaelim@2600:380:9914:a394:9857:b7f0:21ce:c792> has quit IRC (Read error: Connection reset by peer)[22:47:24] *** Tee_Pee <Tee_Pee!uid23783@gateway/web/irccloud.com/x-vtrvilsyihiitcro> has quit IRC (Quit: Connection closed for inactivity)[22:51:06] *** krystcich_ <krystcich_!~krystcich@178235146053.dynamic-zab-01.vectranet.pl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))[22:52:31] *** xerpi <xerpi!~xerpi@61.red-83-45-192.dynamicip.rima-tde.net> has joined ##OpenGL[22:53:36] *** xerpi <xerpi!~xerpi@61.red-83-45-192.dynamicip.rima-tde.net> has quit IRC (Remote host closed the connection)[22:53:57] *** xerpi <xerpi!~xerpi@61.red-83-45-192.dynamicip.rima-tde.net> has joined ##OpenGL[22:59:12] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has joined ##OpenGL[23:02:35] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Ping timeout: 240 seconds)[23:03:57] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has quit IRC (Client Quit)[23:04:09] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has joined ##OpenGL[23:06:18] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Remote host closed the connection)[23:08:04] *** CoolerZ <CoolerZ!~coolerext@42.109.180.182> has quit IRC (Ping timeout: 260 seconds)[23:08:25] *** Murii <Murii!~Murii@79.113.205.114> has quit IRC (Quit: WeeChat 1.4)[23:08:51] *** immibis <immibis!~chatzilla@122-59-200-50.jetstream.xtra.co.nz> has joined ##OpenGL[23:08:54] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[23:09:52] *** spear2 <spear2!~spear2@71-95-117-135.dhcp.mdfd.or.charter.com> has joined ##OpenGL[23:11:38] *** suhdood <suhdood!~Thaelim@2600:380:9914:a394:ad0d:31cb:f6f2:9ad0> has joined ##OpenGL[23:18:47] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has joined ##OpenGL[23:20:20] *** Keniyal <Keniyal!~Keniyal@unaffiliated/keniyal> has joined ##OpenGL[23:22:19] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has quit IRC (Client Quit)[23:27:03] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[23:38:33] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has joined ##OpenGL[23:39:01] *** Asu <Asu!~sdelang@90.37.234.95> has quit IRC (Remote host closed the connection)[23:40:49] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has quit IRC (Client Quit)[23:43:39] *** ravior <ravior!~crapitea@38.132.111.173> has quit IRC (Ping timeout: 260 seconds)[23:44:14] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has joined ##OpenGL[23:45:27] *** devbug <devbug!~textual@node-1w7jr9qla337m4oj07pdodu3n.ipv6.telus.net> has joined ##OpenGL[23:45:54] <devbug> So, I'm using GL_ARB_clip_control to set up a sane coordinate system: GL_UPPER_LEFT + GL_ZERO_TO_ONE.[23:46:43] <devbug> Then I build a left-handed projection matrix, making sure to flip Y, i.e. scale by {1, -1, 1}.[23:47:08] <devbug> However, when I do so, clipping gets messed up -- the insides of geometry are now rendered.[23:48:13] <chrisf> you've flipped the winding of everything by flipping y[23:48:27] <devbug> Except the Issue 4 of the specification covers this: the sign of polygon area should be flipped to deal with the change in handedness.[23:49:01] *** suhdood_ <suhdood_!~Thaelim@2600:380:9914:a394:ad0d:31cb:f6f2:9ad0> has joined ##OpenGL[23:49:23] *** suhdood <suhdood!~Thaelim@2600:380:9914:a394:ad0d:31cb:f6f2:9ad0> has quit IRC (Read error: Connection reset by peer)[23:51:06] <chrisf> it's possible that your driver is messing this up[23:51:13] *** castleboar <castleboar!~bes@unaffiliated/castlelore> has quit IRC (Ping timeout: 248 seconds)[23:51:42] *** No0n3Left <No0n3Left!~No0n3Left@2600:100d:b100:8e35:e1fb:b307:2c86:a302> has quit IRC (Ping timeout: 260 seconds)[23:53:34] <Fr0stBit> Has anyone used nsight eclipse edition (on Linux)?[23:54:11] <chrisf> i have not, but if it's eclipse you're might be in for a bad time :)[23:54:12] *** Keniyal <Keniyal!~Keniyal@unaffiliated/keniyal> has quit IRC (Ping timeout: 256 seconds)[23:54:31] <devbug> yeah, that's my thought[23:54:37] *** suhdood_ <suhdood_!~Thaelim@2600:380:9914:a394:ad0d:31cb:f6f2:9ad0> has quit IRC (Ping timeout: 260 seconds)[23:55:23] <devbug> It shouldn't though. It's up to date and handles DOOM perfectly.[23:55:35] <Fr0stBit> chrisf: I made the damn thing launch my app, but i get nothing as result[23:55:38] <chrisf> devbug: the internal flipping accounts for the glClipControl induced flip[23:55:50] <chrisf> devbug: not for anything else you do[23:56:46] <devbug> oh ouch, yeah[23:56:48] <devbug> you're right[23:58:49] <chrisf> y+ being down is also obscene[23:59:01] <chrisf> but, *shrug*