September 4, 2016 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
September 4, 2016 [00:00:32] <sadtaco> Oh oops. Looks like I nuked the normals some how.[00:03:51] *** zagabar <zagabar!~zagabar@c213-89-112-5.bredband.comhem.se> has joined ##OpenGL[00:03:51] *** zagabar <zagabar!~zagabar@c213-89-112-5.bredband.comhem.se> has quit IRC (Changing host)[00:03:51] *** zagabar <zagabar!~zagabar@unaffiliated/zagabar> has joined ##OpenGL[00:06:10] *** Cooler <Cooler!~CoolerExt@59.96.6.103> has joined ##OpenGL[00:06:30] *** kasper^ <kasper^!~safaf@82.137.9.229> has quit IRC (Ping timeout: 265 seconds)[00:10:31] *** Murloc992 <Murloc992!~Murloc992@213.159.37.162> has quit IRC (Quit: Leaving)[00:11:03] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Ping timeout: 250 seconds)[00:24:28] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has joined ##OpenGL[00:29:49] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has quit IRC (Ping timeout: 260 seconds)[00:31:27] *** rweichler <rweichler!~irc@192.241.212.206> has joined ##OpenGL[00:32:54] <rweichler> i have a shader question[00:32:59] *** t0by <t0by!~t0by@host200-59-dynamic.17-79-r.retail.telecomitalia.it> has quit IRC (Quit: Bye!)[00:33:04] <rweichler> basically... i suck at matrix manipulation[00:33:16] <rweichler> im trying to get the location of a fragment in world coordinates[00:34:46] <rweichler> which is just this:[00:34:46] <rweichler> vec3 fragPosition = vec3(model * vec4(fragVert, 1));[00:35:19] <rweichler> but the thing is, my mesh is anchored to the camera[00:35:46] <rweichler> a "kind-of-works" fix for that is adding the camera's position to fragPosition[00:35:54] <rweichler> but it doesn't account for the camera's rotation[00:36:17] <rweichler> i also have access to the camera's transformation matrix but idk how to multiply it to make it work :/[00:41:02] <dahlia> rweichler: you want world position from fragment position? I think you need depth also[00:41:32] <rweichler> wat[00:41:33] *** Ploppz <Ploppz!~ploppz@2001:700:303:b:f3ce:ca7c:3834:8e44> has quit IRC (Quit: WeeChat 1.5)[00:43:09] *** fodil <fodil!~fodil@bea13-5-83-156-146-12.fbx.proxad.net> has joined ##OpenGL[00:43:13] *** stefkos_ <stefkos_!~stefkos@pc11-226.chomiczowka.waw.pl> has quit IRC (Quit: Leaving)[00:43:15] <fodil> Hi ![00:43:21] <fodil> Can someone help me please , :)[00:43:24] <fodil> ?*[00:43:35] <fodil> I am learning opengl 4.5[00:43:47] *** Gama11 <Gama11!~quassel@p57A9AD7D.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)[00:43:55] <fodil> and I am trying to compile a TCS[00:46:24] <fodil> http://pastebin.com/FuLCGE0d[00:56:20] <rweichler> nvm, figured it out[00:58:29] *** TechnoCrunch <TechnoCrunch!~Tech@101.100.137.146> has joined ##OpenGL[01:01:58] <rweichler> clsg[01:02:15] <fodil> clsg ,[01:02:18] <fodil> ?*[01:03:39] <fodil> nvm, found the bug[01:04:58] *** kmnt <kmnt!~k@69.63.37.65> has joined ##OpenGL[01:05:52] *** shakesoda <shakesoda!~shake@celestiaradio/shark/soda> has quit IRC (Ping timeout: 250 seconds)[01:06:17] *** w4ffles <w4ffles!w4ffles@2600:3c01::f03c:91ff:fe69:8613> has quit IRC (Ping timeout: 258 seconds)[01:10:00] *** nepgear <nepgear!~shake@excessive.moe> has joined ##OpenGL[01:10:08] *** nepgear is now known as Guest85298[01:10:18] *** Wagoo <Wagoo!~wagoo@116.167.203.62.dynamic.wline.res.cust.swisscom.ch> has quit IRC (Ping timeout: 265 seconds)[01:17:05] <sadtaco> God the variable names so many OpenGL docs and such use just don't seem very intuitive to me. modelViewMatrix or mvMatrix, normalMatrix, those make sense. But "m_3x3_inv_transp" or just "m, v, p" on the other hand :|[01:18:32] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[01:19:10] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[01:25:22] <fodil> hi[01:26:05] <fodil> is there a way to make a vec4 value go from a geo shader to a frag shader ,[01:26:16] <fodil> please[01:27:52] *** spacelord <spacelord!~spacelord@46.193.160.126> has joined ##OpenGL[01:31:33] <sadtaco> varying doesn't work in them?[01:31:45] <sadtaco> You might just not want to use geom shaders with how slow they tend to be.[01:32:33] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[01:32:52] *** dusted <dusted!~dusted@77.68.146.169> has quit IRC (Quit: Leaving)[01:33:09] *** w4ffles <w4ffles!w4ffles@2600:3c01::f03c:91ff:fe69:8613> has joined ##OpenGL[01:34:00] <fodil> oh ! :o[01:34:02] <fodil> ok[01:34:04] <fodil> I found tho[01:34:20] <fodil> I needed to get a group of values[01:34:25] <fodil> and not just 1 per 1[01:34:31] <fodil> and send them 1 by 1[01:35:05] <fodil> thanks for the advice sadtaco[01:35:07] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has joined ##OpenGL[01:35:13] <fodil> and then, varying works with them ! :p[01:40:12] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 276 seconds)[01:47:27] *** ravior <ravior!~ravior@79.115.204.165> has joined ##OpenGL[01:59:47] <fodil> what is the point of using homogeneous coordinates ?[01:59:52] <fodil> please :D[02:02:14] <sadtaco> I'm moving the position of vertices in my vertex shader to move them around in the world. And that's making my normalMatrix passed as a uniform wrong, now isn't it? That's why I'm having so much trouble getting proper world or camera normals, isn't it?[02:05:42] <derhass> sadtaco: I can't follow[02:05:43] *** zagabar <zagabar!~zagabar@unaffiliated/zagabar> has quit IRC (Quit: WeeChat 1.5)[02:05:52] <derhass> sadtaco: directions don't move[02:06:06] <sadtaco> Directions don't move?[02:06:09] <derhass> fodil: perspective[02:06:29] <derhass> sadtaco: normals are direction vectors. and translating a direction doesn't change a thing[02:06:58] <sadtaco> I'm rotating them as well[02:07:18] <fodil> derhass: can you explain me why ? :P[02:07:25] <fodil> derhass: please*[02:07:32] <sadtaco> So my normals for the faces are changing in my vertex shader. And now I need their real normals..[02:08:00] <derhass> sadtaco: well. if you modify the geometry, you have to modify the normals as well[02:08:14] <derhass> fodil: why we want perspective?[02:08:18] <sadtaco> That just hit me, yeah..[02:08:51] <fodil> derhass: why using homogeneous coordinates makes perspective easier[02:09:15] *** Tulah <Tulah!~tulah@durhur.fi> has quit IRC (Quit: restart irssi boo)[02:09:34] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has quit IRC (Ping timeout: 260 seconds)[02:09:46] *** Guest85298 is now known as shakesoda[02:09:52] <sadtaco> Okay so that was simple. I really just needed to apply my same transform mat3 that I apply to vertices to my normals... I think[02:10:00] *** Tulah <Tulah!~tulah@durhur.fi> has joined ##OpenGL[02:10:01] <derhass> fodil: well, thatt's the mathematical concept of a projective space[02:11:03] <derhass> fodil: it is really hard to explain this without a background[02:11:16] <fodil> derhass: i got a good background[02:11:32] *** Coldseeker <Coldseeker!~Frosty@as-syd-4-1-55.ozonline.com.au> has joined ##OpenGL[02:11:39] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-175-76.w90-58.abo.wanadoo.fr> has quit IRC (Remote host closed the connection)[02:11:44] <derhass> fodil: but I don't know what exactly you already know, and what not[02:12:14] <fodil> derhass: i already know about matrices, applications, and perspective (but I don't know anything about "homogeneous coordinates")[02:12:17] <sadtaco> Hm wait how should the result of my normals look. my y axis is green, so my faces that face up should be green, right?[02:12:35] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-175-76.w90-58.abo.wanadoo.fr> has joined ##OpenGL[02:12:56] <derhass> fodil: the nice thing about homogenous coordinates is that we can represent both affine transformations as well as the perspective distortion as simple linear matrix multiplications[02:13:26] <derhass> fodil: which means they give us a nice tool to describe any chain of transformations we want[02:13:58] <derhass> fodil: try to represent a simple translation without homogenous coords[02:14:18] <fodil> derhass: ok it gives me the power to do compositions with with matrices really easily[02:16:00] <fodil> derhass: thank you (i've looked at it, it's just because working in a (n+1) space is easier, that nice !)[02:16:01] <derhass> yes, that is one important aspect[02:16:35] <fodil> that's nice*[02:16:57] <derhass> it allsow allows you to represent perspective distortion via linaer operations[02:17:15] <derhass> the nonlinear step is deferred until after all transformations are done[02:17:30] <fodil> it's the (x/w, y/w, z/w) with (x,y,z,w), w being the scale ,[02:17:33] <fodil> ?*[02:17:40] <derhass> yes[02:17:53] <fodil> ok[02:17:59] <fodil> it's mastered know[02:18:02] <fodil> thank you derhass[02:18:05] <derhass> it also has nice properties that we can calculate the intersection of parallel lines[02:18:10] <derhass> which is a point at infinity[02:18:15] <fodil> :o[02:18:17] <derhass> so w = 0[02:18:44] <derhass> the system of equations is totally solveable in homogenous space[02:18:55] <fodil> but we can't use w=0 here[02:19:06] <derhass> not in the devide[02:19:10] <fodil> scaling by 0 doesn't exist ?[02:19:35] <derhass> vectors with w=0 represent infinite points[02:19:41] <derhass> which, in turn, are just directions[02:19:51] *** pffffffft <pffffffft!~pffffffft@unaffiliated/pffffffft> has quit IRC (Ping timeout: 276 seconds)[02:20:15] <derhass> (x1,y1,z1,1) - (x2,y2,z2,1) will yield (..., 0)[02:20:20] <derhass> shich is also a direction[02:20:23] <derhass> *which[02:20:28] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has quit IRC (Quit: Leaving)[02:21:17] <fodil> but that doesn't give me the solution to the intersection of parallel lines[02:21:18] <fodil> :o[02:21:23] <derhass> no[02:21:34] <derhass> you can just solve the system for yourself[02:22:15] <derhass> if you have two parallel lines, they intersect "in their direction"[02:22:22] <fodil> ok i see[02:22:28] <fodil> it's because if I look to the sky[02:22:34] <fodil> and draw parallel lines[02:22:49] <fodil> they'll look as if they intersect each other[02:22:55] <derhass> in perspective[02:23:38] <derhass> the fact that we can caluclate with infinitely far away points is very important for perspective[02:23:55] <derhass> vanishing points are just where parallel lines intersect[02:24:13] <derhass> and such an infinitely far awy point is mapped to a finite point in a perspective projection[02:24:22] <fodil> ok[02:24:49] <fodil> that's very interesting[02:24:56] <fodil> thank you for this[02:25:01] <fodil> i didn't know until now[02:25:21] <fodil> then Euclid's wrong ?[02:26:06] <derhass> no[02:26:34] <derhass> nothing of that contraditcs euclidean geometry[02:27:15] <fodil> he said that parralel lines don't intersect[02:27:31] <derhass> well, they never touch each other[02:27:48] <derhass> euclidean space isn't well-suited to work with infinitely far away points[02:28:13] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has quit IRC (Quit: stelarcf_)[02:28:53] <fodil> ok that's nice[02:28:57] <fodil> thank you again ![02:29:32] <derhass> but the fact that they intersect in infinity (which is actually _never_), is still conceivable in euclidean space[02:30:23] <fodil> why would it be ?[02:30:32] <fodil> it will break everything[02:30:42] <derhass> no, it breaks nothing[02:31:11] <derhass> you don't get a solution for that system of equations. they don't intersect[02:31:44] <derhass> the fact "they don't intersect" is compatible with the claim "they intersect in infinity", because, as I said, this means they never intersect[02:32:16] *** Gaulois94 <Gaulois94!~mickael@67.108.72.86.rev.sfr.net> has quit IRC (Ping timeout: 264 seconds)[02:32:30] <derhass> but maybe you should discuss this with some mathematican, which I'm not[02:32:32] <fodil> wooooooooooow, i understand[02:32:35] <fodil> that was subtle[02:32:46] <derhass> a mathematican would probably kill me for my imprecise statements[02:32:56] <fodil> i was reading next to it[02:33:02] <fodil> and you were quite precise about it[02:33:15] <fodil> +1 ! :P[02:33:33] <fodil> i was even reading that because of it[02:33:51] <fodil> parabola intersects twice at infinity[02:34:25] <fodil> thank you again ! :)[02:35:04] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has joined ##OpenGL[02:35:39] *** tristanseifert <tristanseifert!~tristanse@128.194.3.4> has joined ##OpenGL[02:42:04] *** fodil <fodil!~fodil@bea13-5-83-156-146-12.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds)[02:50:21] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has quit IRC (Remote host closed the connection)[02:55:04] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has joined ##OpenGL[02:55:52] <danhedron> irc[02:56:01] <danhedron> oops[02:59:26] <derhass> danhedron: ^^[03:04:59] *** Codex2 <Codex2!~terop@91-157-91-164.elisa-laajakaista.fi> has quit IRC (Ping timeout: 260 seconds)[03:11:15] *** rixxxo <rixxxo!~razieliyo@unaffiliated/razieliyo> has joined ##OpenGL[03:16:03] *** Cooler <Cooler!~CoolerExt@59.96.6.103> has quit IRC (Ping timeout: 265 seconds)[03:16:19] *** Ardeshir <Ardeshir!~Ardeshir@2.187.125.186> has quit IRC (Quit: Leaving)[03:17:03] *** Cooler <Cooler!~CoolerExt@117.216.87.73> has joined ##OpenGL[03:20:33] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has quit IRC (Remote host closed the connection)[03:21:10] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has joined ##OpenGL[03:25:26] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has quit IRC (Ping timeout: 258 seconds)[03:29:26] <sadtaco> Is there a way to output a gl_FragColor to a different pixel? Another render target isn't enough. I have a frag shader running on a 30x30 texture, and I need it to output to a like 600x600 one, so 20 outputs.[03:30:38] *** drewbarbs <drewbarbs!~drewbarbs@c-76-26-155-253.hsd1.va.comcast.net> has quit IRC (Quit: ZNC 1.6.2 - http://znc.in)[03:30:46] <derhass> render to a 600x600 target, then[03:30:47] *** spacelord <spacelord!~spacelord@46.193.160.126> has quit IRC (Quit: Leaving)[03:31:03] <derhass> or, if you absolutely have to, use image load store[03:31:21] *** drewbarbs <drewbarbs!~drewbarbs@c-76-26-155-253.hsd1.va.comcast.net> has joined ##OpenGL[03:36:24] *** TheChubu <TheChubu!~TheChubu@190.221.200.203> has joined ##OpenGL[03:37:25] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has quit IRC (Quit: gravitation)[03:37:34] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has joined ##OpenGL[03:39:50] <sadtaco> derhass, that means doing 600x600 calculations instead of 30x30[03:39:59] <sadtaco> repeatedly calculating the same hting[03:40:30] <sadtaco> well, I know what I can do. In another pass.[03:40:46] <sadtaco> I'm doing compute stuff with the data on textures.[03:42:27] <Stragus> sadtaco: A fragment shader is run per-fragment, and that same shader can write to various outputs[03:43:03] <Stragus> So it wouldn't make sense for a same shader to write to 30x30 and 600x600 surfaces[03:47:36] <sadtaco> Well let me give me detail. I have 900 points I'm computing on the gpu, so 30x30. Well I need them to shoot. So I figure I can have 2 larger textures for the position and velocity for their projectiles. So in that 30x30 shader I have a lot going on and can't make it 600x600.[03:48:36] <sadtaco> I'm thinking in my textures that handle the 900 points, I can have one channel for behavior like firing. Then have a 600x600 frag running that looks for their appropriate point that's firing and does that computing there..[03:49:13] *** realz <realz!~realz@unaffiliated/realazthat> has joined ##OpenGL[03:50:20] <Stragus> Why are you even using 2D textures for this?... It's linear, you don't need 2D cache coherency, use 1D buffer textures[03:50:50] <sadtaco> No support for that in GL ES 2.0[03:51:05] <Stragus> Right nevermind, you are writing through the fragment shader rather than using compute shaders[03:51:14] <sadtaco> mhm[03:52:00] <Stragus> I don't understand what the 600x600 texture would be for[03:52:12] <sadtaco> Each of the 900 points would have 20+20 texels for projectile position/velocity. So I guess it's simple enough from reading from the 900 points position/vector, the delta, and its own output from the last frame to know where to output texel for that bullet.[03:52:17] <sadtaco> For the projectiles.[03:52:40] <sadtaco> Up to 20 projectiles per 900(30x30) points.[03:53:21] <sadtaco> That's simple enough I guess and there's not really another way to do it. Just seems wasteful to have 360,000 fragment shader programs running every frame when 99% of the time they'll have nothing to do.[03:53:59] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has quit IRC (Ping timeout: 260 seconds)[03:54:45] <Stragus> 40 texels per projectile? 160 values per projectile?[03:55:08] <sadtaco> no per point. The points that control the behavior of the 900 units.[03:55:45] <sadtaco> And that's uh 720,000 fragment shader programs actually.[03:56:18] <Stragus> I guess I don't understand what you are planning, but what I see doesn't sound right[03:58:14] <sadtaco> I'm not sure how else to say it. I have AI/behavior/movement running on the GPU to handle hundreds of units in a way that wouldn't work on the CPU. I also need them to shoot. I need a way to store/animate those projects and have them exist to check collisions and intersections. I can't simply instance a particle system for all 900 units because that could mean 900 particle systems. So I need one particle system for all 900 of them combined.[03:58:46] <sadtaco> Which means I need to address texel space for all the bullets each can fire.[03:58:47] <Stragus> One system to process them all certainly sounds like the proper way[03:59:17] <Stragus> So 900 "structs" of projectile data possibly split over various textures, that's fine[04:00:23] *** spacelord <spacelord!~spacelord@ppp-seco21parth2-46-193-160-126.wb.wifirst.net> has joined ##OpenGL[04:01:32] <sadtaco> Yes so say each can shoot 20 projectiles, I need 20 texels for each one of those 900 units. So 18,000. Then for velocity too. 36,000. Oh did I say 360,000 before? Huh.[04:02:45] <Stragus> Got it, so it's really 18000 projectiles. I had understood 900[04:03:02] <sadtaco> The ai/behavior/movement stuff for each unit is on the 900.[04:03:04] <Stragus> 36000 already sounds a lot better than 360000 :)[04:03:13] <sadtaco> Yeah lol. That doesnt' seem like it'd be a problem, really..[04:03:20] <Stragus> 36000 is fine[04:03:25] <btipling> https://youtu.be/QxUyue2qm2s[04:03:26] <btipling> yay[04:03:28] <sadtaco> It'd still be better if I could bring it down, but eh..[04:03:32] <btipling> my first not buggy 3d thing[04:03:33] <btipling> :D[04:04:17] <Stragus> Well sadtaco, you could, although it will be slightly complex and I think the limitations of GL ES 2.0 will be very troublesome[04:04:21] *** spacelord <spacelord!~spacelord@ppp-seco21parth2-46-193-160-126.wb.wifirst.net> has quit IRC (Client Quit)[04:04:26] <sadtaco> So in my 36000 shader programs it'd look up the output from the 900, see if one should be firing, and look for the next available texel to set a new projectile position and velocity for... At least I can generally just discard; if the "firing" behavior isn't flagged for any of the 900.[04:04:47] <sadtaco> Well I was going to move to GL ES 3.0 or 3.1 after I finish this prototype. Wanted to see what I could do in 2.0 first.[04:05:18] <Stragus> With proper compute shaders and atomics, you could only process the count of "live" projections at any time[04:05:24] <Stragus> Which I suppose will be less than 360000[04:05:28] <sadtaco> I could possibly use some openCL as well but I've been trying to target like an Adreno 320 or Adreno 400. Around that level of hardware.[04:06:19] <Stragus> ... of live projectiles, I meant[04:06:23] <sadtaco> 36,000 but yeah. I don't imagine there will generally be more than 1/3rd, 1/5th, or even less projectiles.[04:06:46] <Stragus> Meh, I wouldn't worry too much about it for 36000[04:07:21] <sadtaco> 36000 is still going to be a significant amount on an Adreno 320. But, well I'm not sure, since it won't be that many actually rendered and no n-body stuff.[04:07:33] <Stragus> The overhead of a more complex approach requiring multiple steps might not win out against parallel brute force, for such a small acount[04:07:39] <sadtaco> I just need to look up some of the 900 within the 36000 to look for collisions.[04:07:50] <Stragus> amount*[04:08:08] <sadtaco> Wait.. I have another problem them.[04:08:24] *** Birchy <Birchy!~Birchy@178-164-108.52.3p.ntebredband.no> has quit IRC (Ping timeout: 276 seconds)[04:09:14] <sadtaco> I was planning on radix sorting the 900 units so they can find nearby collisions and interactions by looking around their uv. If I keep resorting them as they move around, they break their respective indexing that was supposed to match with the projectiles.[04:09:20] <sadtaco> then*[04:09:54] <Stragus> Can you do a radix sort GL ES 2.0?[04:10:08] <sadtaco> I would think so. Hold on.[04:10:52] <Stragus> A good GPU radix sort implies accumulating counts in on-chip shared memory, merging the final counts through global memory atomics[04:11:41] <sadtaco> Right. Well I could also sort on the CPU. Some sort of multi-pass one that is quick and not fully accurate, but will gradually sort it better with each frame. They don't move too much each frame.[04:13:11] *** Twipply <Twipply!~Dunno@cpc1-mapp10-2-0-cust641.12-4.cable.virginm.net> has quit IRC (Quit: Leaving)[04:13:24] <Stragus> Sorting 36000 items by radix on the CPU should be blazzingly fast. How many bits do you have to sort?[04:14:42] <sadtaco> How many bits? I don't know what you mean. It'd be 190x190 texture to sort.[04:15:01] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has joined ##OpenGL[04:15:18] <Stragus> I'm talking about the number of bits in the "key" for the radix sort[04:15:22] *** hexagoxel <hexagoxel!~hexagoxel@p4FCCCFD3.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 244 seconds)[04:15:57] <sadtaco> Not sure how to answer. Haven't looked into it much. It is a float texture, I should have mentioned.[04:15:59] *** redpill <redpill!~redpill@unaffiliated/redpill> has quit IRC (Ping timeout: 265 seconds)[04:16:10] <sadtaco> But that's not what I mean for the problem here. There is a problem of the no longer matching indices.[04:16:35] *** hexagoxel <hexagoxel!~hexagoxel@p200300798F093600021E33FFFE2231E9.dip0.t-ipconnect.de> has joined ##OpenGL[04:17:18] <Stragus> You intend to sort by comparing some per-element values, right? How many significant bits do you need to sort properly?[04:17:31] <sadtaco> Each unit should be able to have 20 projectiles exist. If I move unit 0 to unit 1s position, and it's fired 20 that are still flying, well if unit 1 hasn't fired any it gets to shoot 20 more. I guess it's a matter that I need projectile lifetime to be equal to 20x the fire rate... then that won't matter.[04:17:44] <Stragus> The performance of a radix sort depends on the bit count, it defines how many passes you need, and how much it trashes the L1 cache[04:17:59] <sadtaco> Oh I need to compare x,z floats. Going to ignore y.[04:18:07] <Stragus> Ouch.[04:18:14] <Stragus> Can you drop least significant bits?[04:18:32] <sadtaco> Yeah.[04:19:08] <sadtaco> I was planning on sorting them instead of 900*900 operations per unit, I can lower it to like 900*50 or so. Search in a circle around the texture.[04:19:49] <sadtaco> Have the noise looking texture ordered so the r and b roughly blend like a smooth normal and just the g(y) is noisy.[04:21:11] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has joined ##OpenGL[04:21:27] <sadtaco> Wouldn't there be a better sort than radix to use on the cpu, though?[04:22:15] <Stragus> Can't beat radix sort for integer keys, and all positive (or all negative) floats can be sorted as if they were integers[04:23:51] <sadtaco> Well I thought something else might be better because there are multi-pass sorts that overall are slower, but a pass is fast. They don't need to be perfect sorted, but if they get better each frame that's all that's needed. And they'll start out sorted when initiatil positions are generated[04:25:09] *** madsy_ <madsy_!~madsy@fu/coder/madsy> has joined ##OpenGL[04:25:18] <Stragus> A radix sort is only a bad idea if the key size is too large compared to the count of items[04:25:37] <sadtaco> Hm. Okay.[04:27:28] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has joined ##OpenGL[04:28:43] <sadtaco> I don't like that I'm going to have to limit projectiles so much, though, bleh. It would have looked nicer if they seemingly flew infinitely.[04:35:30] <sadtaco> Thanks for all your help, though. :o[04:35:44] *** kleii <kleii!~kleii@unaffiliated/kleii> has joined ##OpenGL[04:36:22] <Stragus> Sure, no problem. The GL ES 2.0 limitations seem troublesome to design more efficient and flexible solutions[04:38:06] *** redpill <redpill!~redpill@unaffiliated/redpill> has joined ##OpenGL[04:38:07] <sadtaco> Yeah I'm going to drop that a little later and move to 3.0 or 3.1. Hm I thought of one last problem..[04:38:13] *** vitimiti <vitimiti!~vitimiti@unaffiliated/vitimiti> has quit IRC (Ping timeout: 265 seconds)[04:38:16] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has quit IRC (Ping timeout: 258 seconds)[04:39:22] *** ravior <ravior!~ravior@79.115.204.165> has quit IRC (Quit: Konversation terminated!)[04:39:32] *** shingshang <shingshang!~shingshan@115-64-27-246.static.tpgi.com.au> has joined ##OpenGL[04:41:03] <sadtaco> The collision of projectiles to units. I guess it'd be best to check for that in the projectiles shader program, since the units are sorted and it'll be quick to figure out if there isn't one near by. But.. the output for units health is on the 900 units shader program. So I'm stumped there.[04:42:46] <Stragus> Perhaps each unit should check if it collides with projectiles, rather than projectiles colliding with units?[04:43:06] *** bzztploink <bzztploink!~bzztploin@gateway/vpn/privateinternetaccess/bzztploink> has quit IRC (Remote host closed the connection)[04:43:20] <sadtaco> Yes but.. then it's looping over 36,000 unsorted bullets to try and find one that collides[04:43:49] <Stragus> Why wouldn't they be sorted?[04:44:13] <Stragus> Ah, can't really do GPU sorting with GL ES 2.0, right[04:44:18] <sadtaco> no that's not why[04:44:48] <sadtaco> How would I sort them? Sort each chunk of 20? Because I can't just sort them to the front of the texture, because those 20 texels there are for unit0's bullets.[04:45:58] <Stragus> Seriously, I really would consider doing all this on the CPU. Just write optimized C code with NEON intrinsics (assuming ARM), and it will fly[04:47:01] <sadtaco> I'm certain the units behavior stuff wouldn't really work on the CPU. But the projectiles might, given games like total annihilation and homeworld that had a good deal of projectiles with actual physics.[04:47:44] <sadtaco> I dunno.. tests for the units themselves on the CPU were super poor but ran great on the gpu.[04:47:52] <Stragus> What tests?[04:48:11] <sadtaco> like crowd simulation n-body stuff.[04:49:03] <Stragus> Did you use proper space partitioning?[04:49:51] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has quit IRC (Remote host closed the connection)[04:50:29] <sadtaco> No but lots of others have, right? There's lots of attempts of large crowds on the cpu. There's always heavy concessions made.[04:51:04] <sadtaco> Like only updating AI every few seconds, or a turn even.[04:51:37] <Stragus> Well, a GPU can generally be 10-20 times faster, but that's assuming optimized GPU code exploiting on-chip shared memory, atomics, lane shuffles, etc.[04:52:23] <Stragus> I wouldn't be so confident with GPU code dealing with the GL ES 2.0 limitations[04:52:37] <sadtaco> Even without those things, there's lots of benefits to doing the AI and updating positions on the gpu. Yeah, drawbacks, too. I've solved a ton of problems I wanted to solve with this, I just have this one problem with projectile collisions.[04:53:16] *** bzztploink <bzztploink!~bzztploin@gateway/vpn/privateinternetaccess/bzztploink> has joined ##OpenGL[04:53:18] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has quit IRC (Quit: nine_milli)[04:55:21] <sadtaco> I guess what I could do is uh.. again, seems like I need to calculate collision on the projectiles 36000 shader programs. I can... basically output the index it detects a collision with, and have the cpu loop over that channel of the texture output to read the collisions and update the health on the ships texture where health is.[04:56:11] <Stragus> You really do *not* want the CPU to read anything computed by the GPU[04:56:27] <sadtaco> You're worried it won't all be done in frame?[04:56:33] <derhass> 36k shader _invocations_ isn't much per say[04:56:42] <sadtaco> derhass, ya it's not.[04:56:52] <sadtaco> But 900 each doing 36k loops would be a lot if I did it that way.[04:56:52] <Stragus> sadtaco: the CPU will wait until the GPU is done, then the GPU will stall because it has nothing else to do[04:57:19] <sadtaco> No? The GPU will then do rendering.[04:57:38] <Stragus> You just said the CPU would loop over the texture output[04:57:42] <sadtaco> yeah[04:57:51] <sadtaco> And while it's rendering I read for collisions and update the health before the next compute stage.[04:58:02] <grim002> you can't easily read back data from the GPU without causing a massive stall in the rendering pipeline[04:58:17] <grim002> when you can, it's delayed by several frames[04:58:24] <Stragus> Never read GPU stuff on the CPU, unless it's asynchronous and 2 frames later after it has been written[04:59:15] *** therue <therue!~therue@1-162-47-146.dynamic.hinet.net> has joined ##OpenGL[04:59:21] <sadtaco> I'm actually doing that already because GL ES 2.0 limitations require that. I have to render to texture to the cpu, then pass that as a uniform. And it's not stalling.[04:59:42] <grim002> CPU to GPU is fine, GPU to CPU is not.[04:59:50] <sadtaco> GPU to CPU is what rendering to texture is.[04:59:54] <sadtaco> And I'm doing that.[04:59:54] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-175-76.w90-58.abo.wanadoo.fr> has quit IRC (Ping timeout: 260 seconds)[05:00:30] <sadtaco> I want to not do that, and I'd like to have solution that uses the integrated graphics on intel CPUs and like A8 CPUs. But there's not a drop in one-size-fits-all solution for it.[05:00:31] <grim002> rendering to a texture isn't GPU to CPU, if you're reading back that texture and modifying it and re-uploading it every frame then sure[05:01:00] <grim002> but if you're doing that, you are never going to leverage the full power of the GPU since it can't operate asynchronously[05:01:30] <sadtaco> Oh. Huh.[05:06:29] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has quit IRC (Quit: gravitation)[05:06:56] <TheChubu> i very much doubt there is any GLES "limitation" on that.[05:07:01] <sadtaco> So when I'm supplying a texture2D to one shader that's the render output from a render, I'm not supplying it the way I supply a texture from disk, but it's just using what's still in the GPU's memory?[05:07:10] <TheChubu> yeah[05:07:43] <TheChubu> well, you have an FBO, that fbo has texture attachments[05:07:48] <TheChubu> those texture attachments live on the GPU[05:08:03] <TheChubu> so in a draw call, you bind that FBO for drawing, and draw on some texture, as render target.[05:08:23] <TheChubu> now in the next pass, you bind one of those attachments as a normal texture, and sample that.[05:08:37] <TheChubu> thats all in the GPU side. CPU only issues the draw calls and state changes.[05:09:11] <sadtaco> Hm I thought I read something about it being limited here.[05:09:13] <Stragus> More importantly, the CPU never reads anything back from the GPU, the GPU always has worked queued and ready to go[05:09:36] <TheChubu> CPU says "use X as render target" then the GPU does it. CPU says "now bind X to the sampling slot" and the GPU does that. in its own time, asynchronously (ideally).[05:09:37] *** kmnt <kmnt!~k@69.63.37.65> has quit IRC (Ping timeout: 244 seconds)[05:09:47] <sadtaco> Well there aren't compute shaders, that's one thing. That might be it.[05:10:17] <sadtaco> I don't get why the GPU can't asynchronously output to the CPU while still doing its next job.[05:10:30] <TheChubu> GPU doesnt outputs to the CPU.[05:10:52] <sadtaco> On APUs, they share memory, though.[05:10:57] <TheChubu> and?[05:11:01] <TheChubu> thats irrelevant.[05:11:45] <sadtaco> Why can't the shared memory for some data be read by the CPU after each frame?[05:11:57] <TheChubu> ah sorry, iread that previous phrase wrong.[05:12:16] <TheChubu> yes it could. thats how current consoles work for example.[05:12:42] <slime> "after each frame" may still be 1 or more frames *after* you tell the GPU to do the work[05:12:59] <sadtaco> A 1 frame delay is perfectly fine. Most games have a 1 or 2 frame delay now days anyway.[05:13:04] *** tristanseifert <tristanseifert!~tristanse@128.194.3.4> has quit IRC (Ping timeout: 244 seconds)[05:14:20] <TheChubu> cant help with that since i havent done that kind of work but i know there are synchronization primitives for that kind of stuff, memory fences.[05:14:25] <TheChubu> so the CPU can check when the GPU is ready[05:16:21] <sadtaco> erg so.. regardless, save for being able to do that, and being able to read off shared memory on the cpu, I have 36000 unsorted projectiles and 900 sorted targets where I need to find collisions and update "health" on the 900, which is one of the channels of data they have besides position, vector, velocity.[05:17:00] <sadtaco> It's easy for the 36000 projectiles to find collisions since the 900 targets are sorted, but they can't output the health for those 900...[05:17:03] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has joined ##OpenGL[05:19:30] <TheChubu> smartphones have various cores these days[05:19:37] <TheChubu> have you tried paralellizing from the cPU?[05:20:18] <TheChubu> like, use some thread pool, and issue a bunch of jobs computing everything, collect the results and update the targets.[05:20:42] <sadtaco> I think they could probably do collision physics, but they can't do all the other things I need. So we're talking about the problem of reading back and forth from gpu and cpu[05:20:42] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has quit IRC (Read error: Connection reset by peer)[05:21:21] <TheChubu> it'll be easier to parallelize on the CPU[05:21:24] <TheChubu> you should test that first[05:21:26] <sadtaco> wah?[05:21:33] <sadtaco> easier? It'll be slower..[05:21:45] <TheChubu> have you tried it?[05:21:47] <sadtaco> So I can't simply do collisions on the cpu when their behavior and movement and so on is all on the gpu.[05:21:50] <sadtaco> Lots of others have...[05:22:05] <TheChubu> ... on smartphones?[05:22:16] <sadtaco> http://www.passmark.com/products/pt_advphys.htm like this for example...[05:22:22] *** d4ryus <d4ryus!~d4ryus@p549883B6.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 255 seconds)[05:22:29] <sadtaco> Why would it be faster on a smartphone than pc? And I'm making for PC as well.[05:22:45] <sadtaco> I'm actually primarily targetting PC, but want to target older ones and not just DX12/Vulkan.[05:22:46] <TheChubu> one thing is a nVidia card on a desktop with CUDA.[05:23:00] <TheChubu> i didnt said CPU was faster on smartphones[05:23:07] <TheChubu> i implied GPUs were slower[05:23:35] <TheChubu> so you trying to compute stuff on the GPU might not help with that[05:23:54] <TheChubu> because i have never heard anyone doing physics on mobile GPUs[05:24:00] <sadtaco> Oh no the compute is running fine on an Adreno 320 for me that I've done so far.[05:24:17] <sadtaco> It's just I know that 900*36000 ops will not run fine on it.[05:24:34] <sadtaco> That's 32 million operations.[05:25:04] <TheChubu> have you tried to do that on the CPU? with a proper physics libs?[05:25:07] *** d4ryus <d4ryus!~d4ryus@p54988950.dip0.t-ipconnect.de> has joined ##OpenGL[05:25:08] <TheChubu> *lib[05:26:14] <sadtaco> even if I could, I ahve to pull my targets positions from the gpu to the cpu.. I ran similar tests for crowd sims on my phone and they were atrociously slow, could only handle a few dozen and not the thousands I have with higher fidelity.[05:26:51] *** arescorpio <arescorpio!~arescorpi@144-166-16-190.fibertel.com.ar> has joined ##OpenGL[05:27:20] <TheChubu> but you used a physics lib or you just brute forced all collisions?[05:27:22] <sadtaco> Do you have an example?[05:27:27] <sadtaco> It was others implementations[05:28:42] <TheChubu> http://box2d.org/[05:29:19] <TheChubu> no one ever bruteforces all collisions. usually physics libs implement various intermediary structures to reduce drastically the amount of checks they have to make.[05:29:40] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has quit IRC (Quit: leaving)[05:29:54] <sadtaco> I'm not saying they should bruteforce all collisions..[05:30:15] <TheChubu> "36 million ops" thats brute forcing all collisions[05:30:18] <sadtaco> What I'm saying is I can't think of an example of thousands of units with individual ai running on a Nexus 4[05:30:31] <TheChubu> it might be for a reason[05:30:34] <sadtaco> TheChubu, right.. I want to avoid doing that.[05:31:04] <sadtaco> you're jumping to conclusions.[05:31:16] <sadtaco> I'm saying what I want to avoid and you're for some reason assuming I REALLY want to do that.[05:32:22] <sadtaco> As I said, for my targets, I have them sorted. So instead of 900*36000 = 32 million ops, if I'm detecting collision on the projectiles against the sorted targets I can do an operation that's more like 36000*5 to 36000*10, or 180,000 to 360,000 ops.[05:32:44] <sadtaco> which is very doable. The problem is that I can't update the targets health from the projectiles shader..[05:33:03] <sadtaco> So I'm wondering what else I can do to avoid 900*36000 ops since I can't sort the projectiles.[05:41:46] *** tristanseifert <tristanseifert!~tristanse@128.194.3.4> has joined ##OpenGL[05:42:04] *** kleii <kleii!~kleii@unaffiliated/kleii> has quit IRC (Ping timeout: 240 seconds)[05:42:33] <sadtaco> I also can't really find examples of large interacting crowds for mobile. Let alone something 3 years old like a Nexus4.[05:46:19] <sadtaco> I don't think the Adreon 320 is that slow. 16x400mhz 57 GFlops. A little less than half that of an HD 3000. Ultimately I think an HD 3000 is going to be what I target for min spec, though.[05:54:19] <sadtaco> Oh. Transform Feedback is what I was thinking that I'm missing in GL ES 2.0[05:55:51] <Stragus> sadtaco, it won't necessarily be slower on the CPU because you'll be able to write "smart" code compared to brute force[05:56:20] <Stragus> And don't forget SSE/AVX/NEON for a 3-12x CPU speed-up for properly written code[05:57:47] <sadtaco> Yeah I know.. but in practice I haven't seen anything that does that. Why else hasn't someone made a game that runs on Nexus4 with thousands of units? I am trying to do optimizations, but the brute forcing is obviously simpler code.[05:58:15] <Stragus> I am pretty sure it can be done, depending what kind of per-unit processing you need[05:58:20] <sadtaco> I certainly don't want to do a 900x36000 op though :/ I'm trying to figure out how else I can handle it..[05:58:59] <sadtaco> So in the same vain we're talking about 900 units, and really I have 2 sets of those, so 1800, plus projectiles which don't have to be 36000 anymore on the cpu, but still probably like 10,000.[05:59:17] <Stragus> Many, many years ago, I wrote something that had thousands of units on a Pentium 2 333mhz or something: http://www.rayforce.net/war2clone1600.png[05:59:24] <sadtaco> And it means every frame I need to update the vertices in that projectile geometry for all those points to move them on the cpu instead of gpu, which is going to be at least 20 times slower right there.[05:59:30] <Stragus> So yes, a Nexus 4 can handle that, you just need very smart and optimized code[06:00:13] <sadtaco> Yeah there were games that did thousands of units way back when. Cosacks: Back to War is an example. That was 2d.[06:00:30] <sadtaco> I mean I think you're right.. but.. erg.[06:02:21] <sadtaco> Stragus, take those thousands of units, and update their AI at least many times per second, say 12 at least but 60 is better. Have them aim for the the most convenient enemy *not* the closest, give them complicated ranges of movements to decide between, etc. I don't think it works then..[06:04:25] <sadtaco> It's like you said, the GPU is going to be 10-20 faster. Just.. not when you brute force compared to smart optimizations built around sharing results between threads.[06:04:58] <Stragus> Do units need to take a decision 12-60 times per second? Can they really interrupt any kind of action or quarter of step they take?[06:05:31] <sadtaco> I'm not having them aim at the nearest enemy. They have limited turn rates and would keep spinning around trying to target the closest around them without shooting at something that's actually in their "sights".[06:05:40] <sadtaco> It's very different than a traditional rts or whatever.[06:05:52] <Stragus> As for targeting the "most convenient enemy", some calculations are redundant between units in proximity. Find a way to avoid that work duplication[06:06:13] <sadtaco> And from the research I've done, I'm pretty certain this is the way to go. I just have that one little problem I mentioned, I've been able to solve all the others.[06:06:56] <Stragus> What about the problem of the CPU needing to know the results of GPU calculations? Can you afford a 2-3 frames delay?[06:07:02] <sadtaco> Yes I can[06:08:05] <sadtaco> So *is* there a way to asynchronously recall a texture back from the gpu without stalling it so I can, as I thought of earlier, make collisions on the GPU output for the projectiles, read them on the cpu, then supply an attribute to the units/targets? That seems the way to do this..[06:08:37] <Stragus> You can read back, but 2-3 frames after the data has been written by the GPU[06:08:47] <sadtaco> I mean that's "realistic", frankly. Not immediately blowing up after taking a shot. Talking like 33ms delay[06:08:53] <sadtaco> That's perfectly fine then.[06:08:58] <sadtaco> On an APU shouldn't it be faster, though?[06:09:14] <Stragus> Not really, you don't want to starve the GPU of work either way[06:09:36] <sadtaco> Well yeah I don't want it to stall as you guys mentioned before. What's the process for that, anyway?[06:10:19] <Stragus> Like we said, if you do any GPU->CPU, read data that was generated 2-3 frames ago[06:10:43] <sadtaco> Yes. But it will be 2-3 frames ago sent asynchronously, without stalling anything?[06:10:46] <Stragus> And don't update GPU buffers from the CPU while the GPU might still be using them for rendering, use a cycle of buffers[06:11:28] <Stragus> Kind of, yes. If you have Pixel Buffer Objects, then it really can be asynchronous without stalling[06:13:20] <sadtaco> So I'll need GL ES 3.0 for that. Mkay. Thanks.[06:14:11] *** tailsx <tailsx!~tailsx@dpc6744140031.direcpc.com> has joined ##OpenGL[06:14:23] <Stragus> Without PBOs, it's not the GPU that is stalling, it's the CPU waiting for the data[06:15:45] <sadtaco> I didn't nessisarily need a GL ES 2.0 solution here, I probably should have been clear on that. I can brute force for this proto type then I have a number of optimizations to do when switching over to GL ES 3.0[06:16:11] <sadtaco> So okay, problem solved it'd seem, unless there's a better non-cpu-oriented solution?[06:17:44] <Stragus> Sounds reasonable, support both GLES 2 and 3 and use whatever is available[06:18:52] *** BilboTheHobbit <BilboTheHobbit!~Emma@112.10.171.146> has joined ##OpenGL[06:24:51] <sadtaco> Oh no I was going to plan on GLES 3 as the minimum. Most mobile devices run that. Nexus4, LG G2, HTC One, Galaxy S4. Super long list of popular devices, 3 years old and newer pretty much.[06:25:12] <sadtaco> And on PC, pretty much everything. Like 90%+ of Steam hardware I think, maybe even closer to 97%?[06:26:14] <sadtaco> i just started with GLES2 because I'm playing with WebGL, and that's what it is essentially. The Firefox Shader Editor is super convenient to debug quickly so long as it doesn't bug out.[06:26:54] <sadtaco> After like.. tomorrow problably I'm switching over to working on a real application with GLES 3[06:30:40] <sadtaco> http://store.steampowered.com/hwsurvey Yeah looks like at least 97% support for GLES 3.0 to me[06:31:40] <sadtaco> Now.. if I required an APU, no idea. :/ No break down. I would imagine at least 75%..[06:34:03] <slime> the steam survey is only for desktop and laptop computers[06:34:40] <slime> http://hwstats.unity3d.com/mobile/gpu.html (although the demographics of those stats may not line up with your target audience)[06:35:10] <sadtaco> Well I'm not sure I'll do mobile. I just use it for perf testing.[06:35:59] <slime> oh[06:36:07] <slime> then yeah, GL3 is basically ubiquitous on desktops[06:36:23] <sadtaco> But like I said... Nexus4, LG G2, HTC One, Galaxy S4. Long list of devices support GLES3.0[06:36:31] <sadtaco> Now 3.1, and 3.2, much less support on mobile[06:39:59] <sadtaco> I dont think there is any point at all to use GLES2 over 3 besides webgl.[06:46:19] *** Nach0z <Nach0z!~nach0z@unaffiliated/nach0z> has quit IRC (Quit: leaving)[06:51:29] *** Nach0z <Nach0z!~nach0z@c-73-137-19-29.hsd1.ga.comcast.net> has joined ##OpenGL[06:51:29] *** Nach0z <Nach0z!~nach0z@c-73-137-19-29.hsd1.ga.comcast.net> has quit IRC (Changing host)[06:51:29] *** Nach0z <Nach0z!~nach0z@unaffiliated/nach0z> has joined ##OpenGL[06:53:16] *** MrFlibble <MrFlibble!MrFlibble@90.220.166.75> has quit IRC (Quit: MrFlibble)[06:55:21] *** kleii <kleii!~kleii@unaffiliated/kleii> has joined ##OpenGL[06:55:28] *** arescorpio <arescorpio!~arescorpi@144-166-16-190.fibertel.com.ar> has quit IRC (Excess Flood)[06:57:14] *** xaxxon <xaxxon!~xaxxon@c-24-18-184-142.hsd1.wa.comcast.net> has joined ##OpenGL[07:14:28] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has quit IRC (Read error: Connection reset by peer)[07:15:20] *** tailsx <tailsx!~tailsx@dpc6744140031.direcpc.com> has quit IRC (Quit: Leaving)[07:18:34] *** Ad1_RN <Ad1_RN!~adrian@aaww142.neoplus.adsl.tpnet.pl> has joined ##OpenGL[07:21:54] *** Ad1_RnR <Ad1_RnR!~adrian@dnf190.neoplus.adsl.tpnet.pl> has quit IRC (Ping timeout: 244 seconds)[07:22:40] *** nikki93 <nikki93!~nikki93@1.186.105.7> has joined ##OpenGL[07:22:57] *** nikki93 <nikki93!~nikki93@1.186.105.7> has quit IRC (Remote host closed the connection)[07:24:29] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has joined ##OpenGL[07:25:00] *** TheChubu <TheChubu!~TheChubu@190.221.200.203> has quit IRC (Quit: WeeChat 1.5)[07:26:37] *** unreal <unreal!~unreal@unaffiliated/unreal> has quit IRC (Ping timeout: 252 seconds)[07:34:05] *** tambre <tambre!~tambre@9fe7-b5cb-e368-1847-a980-8a3e-07d0-2001.dyn.estpak.ee> has joined ##OpenGL[07:40:13] *** xaxxon <xaxxon!~xaxxon@c-24-18-184-142.hsd1.wa.comcast.net> has quit IRC (Quit: xaxxon)[07:44:13] *** joshsyn <joshsyn!~swoorup@124-148-250-150.dyn.iinet.net.au> has joined ##OpenGL[08:03:28] *** PlasmaStar <PlasmaStar!Plasma@unaffiliated/plasmastar> has quit IRC (Ping timeout: 252 seconds)[08:04:04] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has joined ##OpenGL[08:04:34] *** BilboTheHobbit <BilboTheHobbit!~Emma@112.10.171.146> has quit IRC (Ping timeout: 240 seconds)[08:04:41] *** PlasmaStar <PlasmaStar!Plasma@unaffiliated/plasmastar> has joined ##OpenGL[08:04:51] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has quit IRC (Quit: nine_milli)[08:09:54] *** kleii <kleii!~kleii@unaffiliated/kleii> has quit IRC (Read error: Connection reset by peer)[08:13:21] *** Wagoo <Wagoo!~wagoo@116.167.203.62.dynamic.wline.res.cust.swisscom.ch> has joined ##OpenGL[08:18:52] *** rixxxo <rixxxo!~razieliyo@unaffiliated/razieliyo> has quit IRC (Ping timeout: 252 seconds)[08:19:30] *** therue <therue!~therue@1-162-47-146.dynamic.hinet.net> has quit IRC (Quit: therue)[08:25:03] <btipling> such a sad state of affairs[08:25:21] <btipling> boggles the mind why they went with that for webgl[08:27:13] *** SwiftMatt <SwiftMatt!~Objective@162.242.94.81> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)[08:34:31] *** SwiftMatt <SwiftMatt!~Objective@162.242.94.196> has joined ##OpenGL[08:37:28] *** irrenhaus3 <irrenhaus3!~xenon@HSI-KBW-046-005-253-080.hsi8.kabel-badenwuerttemberg.de> has joined ##OpenGL[08:42:42] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[08:46:08] *** t0by <t0by!~t0by@host247-252-dynamic.4-87-r.retail.telecomitalia.it> has joined ##OpenGL[08:46:19] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[08:53:00] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has joined ##OpenGL[08:57:25] *** Hink <Hink!~Hink@2001:19f0:200:65a8::f6cf:8507> has quit IRC (Disconnected by services)[08:57:36] *** Hink <Hink!~Hink@2001:19f0:200:65a8::f6cf:8507> has joined ##OpenGL[09:02:21] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has joined ##OpenGL[09:02:52] *** Hink <Hink!~Hink@2001:19f0:200:65a8::f6cf:8507> has quit IRC (Ping timeout: 255 seconds)[09:03:26] *** Kkiro <Kkiro!~yoo200181@unaffiliated/kkiro> has quit IRC (Ping timeout: 260 seconds)[09:03:48] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has quit IRC (Quit: nine_milli)[09:05:14] *** Kkiro <Kkiro!~yoo200181@119.192.41.62> has joined ##OpenGL[09:05:14] *** Kkiro <Kkiro!~yoo200181@119.192.41.62> has quit IRC (Changing host)[09:05:14] *** Kkiro <Kkiro!~yoo200181@unaffiliated/kkiro> has joined ##OpenGL[09:06:35] *** mat^2 <mat^2!~Mathias@87-55-0-192-dynamic.dk.customer.tdc.net> has joined ##OpenGL[09:10:22] *** Hink <Hink!~Hink@2001:19f0:200:65a8::f6cf:8507> has joined ##OpenGL[09:15:25] *** Vag <Vag!~Vag@ppp-2-85-242-122.home.otenet.gr> has quit IRC (Quit: Linkinus - http://linkinus.com)[09:17:33] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[09:18:07] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Remote host closed the connection)[09:18:26] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[09:19:07] *** pa <pa!~pa@unaffiliated/pa> has joined ##OpenGL[09:19:44] *** therue <therue!~therue@1-162-47-146.dynamic.hinet.net> has joined ##OpenGL[09:20:01] *** Gama11 <Gama11!~quassel@pD9F9867E.dip0.t-ipconnect.de> has joined ##OpenGL[09:26:41] *** Vlad__ <Vlad__!~vlad@86.125.206.235> has joined ##OpenGL[09:29:14] *** Th30n <Th30n!~Th30n@93-142-73-5.adsl.net.t-com.hr> has joined ##OpenGL[09:29:26] *** Vlad__ <Vlad__!~vlad@86.125.206.235> has quit IRC (Client Quit)[09:29:43] *** Murii <Murii!~Murii@86.125.206.235> has joined ##OpenGL[09:31:38] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-175-76.w90-58.abo.wanadoo.fr> has joined ##OpenGL[09:34:44] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has joined ##OpenGL[09:40:55] *** SwiftMatt <SwiftMatt!~Objective@162.242.94.196> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[09:55:34] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has joined ##OpenGL[09:59:07] *** Jackneill <Jackneill!~Jackneill@unaffiliated/jackneill> has joined ##OpenGL[10:06:32] *** Murii <Murii!~Murii@86.125.206.235> has quit IRC ()[10:06:38] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:40f8:76d5:1756:b833> has quit IRC (Read error: Connection reset by peer)[10:08:29] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[10:10:20] *** Vtec234 <Vtec234!~wn@178235041132.dynamic-ww-06.vectranet.pl> has joined ##OpenGL[10:16:14] *** xaxxon <xaxxon!~xaxxon@24.18.184.142> has joined ##OpenGL[10:16:23] *** xaxxon <xaxxon!~xaxxon@24.18.184.142> has quit IRC (Remote host closed the connection)[10:19:52] *** tm604 <tm604!~tom@pdpc/supporter/professional/tm604> has quit IRC (Ping timeout: 240 seconds)[10:24:18] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has joined ##OpenGL[10:25:59] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Ping timeout: 260 seconds)[10:26:27] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[10:28:20] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has joined ##OpenGL[10:29:18] *** sandeepkr <sandeepkr!~sandeepkr@182.75.187.110> has quit IRC (Ping timeout: 276 seconds)[10:29:18] *** kuldeep_ <kuldeep_!~kuldeep@unaffiliated/kuldeepdhaka> has quit IRC (Ping timeout: 276 seconds)[10:30:12] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Quit: Leaving)[10:30:27] *** kuldeep_ <kuldeep_!~kuldeep@unaffiliated/kuldeepdhaka> has joined ##OpenGL[10:33:44] *** kuldeep_ <kuldeep_!~kuldeep@unaffiliated/kuldeepdhaka> has quit IRC (Excess Flood)[10:34:51] *** kuldeep <kuldeep!~kuldeep@unaffiliated/kuldeepdhaka> has joined ##OpenGL[10:35:40] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 244 seconds)[10:36:38] *** sandeepkr <sandeepkr!~sandeepkr@111.235.65.5> has joined ##OpenGL[10:37:40] *** pa <pa!~pa@unaffiliated/pa> has joined ##OpenGL[10:38:00] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[10:39:45] *** Cooler <Cooler!~CoolerExt@117.216.87.73> has quit IRC (Ping timeout: 265 seconds)[10:41:03] *** ertesx <ertesx!~never@pD9FCB3E5.dip0.t-ipconnect.de> has joined ##OpenGL[10:42:25] *** afl_ext <afl_ext!~afl_ext3@aatc100.neoplus.adsl.tpnet.pl> has joined ##OpenGL[10:42:25] *** afl_ext <afl_ext!~afl_ext3@aatc100.neoplus.adsl.tpnet.pl> has quit IRC (Changing host)[10:42:25] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has joined ##OpenGL[10:44:34] *** ertes <ertes!~never@p5485EE5D.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)[10:47:16] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-175-76.w90-58.abo.wanadoo.fr> has quit IRC (Ping timeout: 264 seconds)[10:48:55] *** kuldeep <kuldeep!~kuldeep@unaffiliated/kuldeepdhaka> has quit IRC (Ping timeout: 244 seconds)[10:49:04] *** sandeepkr <sandeepkr!~sandeepkr@111.235.65.5> has quit IRC (Ping timeout: 255 seconds)[11:03:22] *** Vtec234 <Vtec234!~wn@178235041132.dynamic-ww-06.vectranet.pl> has quit IRC (Quit: Bye!)[11:05:30] <tomaka> Is there a way to know in a fragment shader where you are within a triangle?[11:05:44] <tomaka> similar to a tessellation evaluation shader[11:06:02] <tomaka> or is there a hack-ish way to know that?[11:06:16] <exDM69> not sure if there's a built in for the barycentric coordinates[11:06:35] <exDM69> but at least you can use a geom shader to "inject" a custom attribute to each vertex[11:06:42] *** Cooler <Cooler!~CoolerExt@36.255.14.160> has joined ##OpenGL[11:06:55] <tomaka> hmm right[11:07:18] <tomaka> I'd prefer not to use geometry shaders though, because of compatibility[11:07:26] <exDM69> http://prideout.net/blog/?p=48 <<--- see the geom shader here used for wireframes[11:07:31] <exDM69> the same trick should be applicable[11:10:03] *** kuldeep <kuldeep!~kuldeep@unaffiliated/kuldeepdhaka> has joined ##OpenGL[11:10:07] *** sandeepkr <sandeepkr!~sandeepkr@103.49.155.114> has joined ##OpenGL[11:10:45] <ratchetfreak> if it's not indexed then you can add a 1,0,0 0,1,0 or 0,0,1 output to the vertex shader[11:11:00] <ratchetfreak> based on the vertexID % 3[11:12:22] <tomaka> it's indexed though :o[11:12:27] <tomaka> but that's a good idea[11:14:09] <exDM69> yeah, that trick works if there are no shared vertices[11:14:20] <exDM69> it's essentially the same as the geometry shader trick[11:15:13] <ratchetfreak> but without the overhead and backwards compatible[11:17:03] <exDM69> but with a huge caveat on shared vertices :)[11:17:20] <tomaka> my plan is to make the program work on android, if possible[11:17:28] <tomaka> but of course the definition of "if possible" may include that[11:17:29] <exDM69> tomaka: looks like there isn't a GLSL builtin variable for the barycentric coordinates :/[11:17:50] <exDM69> I wonder why[11:18:03] <ratchetfreak> unless you can adjust the model so that the shared vertices can emit the same barycentrics[11:19:14] <exDM69> I don't think that's possible for most models...[11:19:26] <ratchetfreak> it's graph coloring with 3 colors[11:19:33] <tomaka> well, my model is a subdivided icosahedron[11:19:47] <tomaka> which I generate in my code[11:19:55] <tomaka> (ie. this: https://lh5.ggpht.com/_c8F5-iXvm-A/SQ5O7ZEhmHI/AAAAAAAAKLg/DUAhvF8QyUg/s800/Picture%208.png)[11:19:56] <ratchetfreak> and you can duplicate some vertices to make it work[11:20:06] <tomaka> so it should be possible, but that looks like a mathematical nightmare[11:20:26] <tomaka> s/nightmare/difficult problem for me/[11:20:56] <ratchetfreak> actually you can make the vertex shader also emit 0,0,0,1 so you have 4 "colors"[11:21:14] <ratchetfreak> then in the fragment shader you can select the 3 non zero components[11:23:12] <exDM69> tomaka: I think that particular model should be numberable[11:24:04] <exDM69> tomaka: I drew an unwrapped icosahedron on paper and it looks like it's pretty easy to assign number 0,1,2 for each vertex[11:24:15] <exDM69> although I didn't take a look at the way it wraps around[11:24:56] <exDM69> there's 4x5 = 20 triangles in an icosahedron, right?[11:25:05] <tomaka> yes[11:25:28] <tomaka> 12 vertices[11:26:06] <tomaka> actually the approach I went with is to take a random triangle in the model, assign 0,0,1 0,1,0 1,0,0 to the three vertices[11:26:09] <tomaka> and then fill the rest[11:29:58] *** feliwir <feliwir!Elite16673@gateway/shell/elitebnc/x-lyvtxosjmzrclbbt> has quit IRC (Ping timeout: 258 seconds)[11:31:26] <exDM69> tomaka: are you rendering planets or similar spherical terrain shapes=[11:31:30] <exDM69> all-procedural?[11:32:10] <tomaka> exDM69, yes[11:32:41] <exDM69> you're not planning to texture it with a rectangular texture are you?[11:33:10] <tomaka> the colors are generated in the fragment shader depending on the elevation, temperature and humidity[11:33:57] <tomaka> and I'll see what the result is[11:34:30] <phaazon> 11:08 < tomaka> Is there a way to know in a fragment shader where you are within[11:34:33] <phaazon> a triangle?[11:34:36] <phaazon> barycentric coordinates? :)[11:34:42] <exDM69> tomaka: I can quite easily find a numbering for an icosahedron[11:34:48] <exDM69> phaazon: that exactly, but how do you find it out?[11:34:55] <exDM69> there's no gl_Barycentric or whatever[11:34:59] <phaazon> exactly like you do with RGB color triangle[11:35:16] <exDM69> tomaka: but the numbering scheme doesn't wrap around the equator nicely[11:35:18] <tomaka> exDM69, yes actually I followed a paper explaining exactly how to number the faces of a icosahedron[11:35:20] <phaazon> I’ve already done that to create nice « wireframe » effects[11:35:23] <phaazon> with round corners[11:35:23] <tomaka> but that doesn't really help[11:35:39] <exDM69> tomaka: not sure if that matters actually[11:35:54] <exDM69> phaazon: you're late to the game, we've discussed these simple schemes already :)[11:36:06] <exDM69> tomaka: got a link to said paper?[11:36:27] <tomaka> exDM69, https://www.cs.umd.edu/~hjs/pubs/leesdh98short.pdf[11:36:30] <phaazon> exDM69: well, you actually need only two coordinates, not three[11:36:34] <phaazon> I don’t see the problem[11:36:38] <tomaka> it's very interesting, you can find the neighbours of a face in constant time[11:36:56] <tomaka> I wrote an implementation of this, works very well[11:37:13] <tomaka> the generated assembly is like 20 instructions to find the right neighbour of a tile[11:37:28] <tomaka> no, more like 10[11:37:34] <tomaka> I'm trying to remember visually[11:37:47] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has joined ##OpenGL[11:38:50] <tomaka> if you exclude the special case where you need to jump from a side of the icosahedron to another side, which doesn't happen often[11:39:33] <exDM69> tomaka: http://rikusalminen.kapsi.fi/IMG_20160904_123813.jpg[11:40:18] <tomaka> heh that's not correct[11:40:27] <tomaka> all the vertices at the left and the right are the same vertex[11:40:42] <exDM69> yes... and all the vertices at top and bottom are shared[11:41:13] <afl_ext> I need a bit of help with cascade shadow maps because somehow I managed to forget things and im struggling for 2 days now trying to get it working[11:41:18] <tomaka> anyway, I'm going to go with the method of assigning arbitrary values to the first three values, and then fill the rest[11:41:32] <tomaka> to the first three vertices*[11:41:44] <afl_ext> so to start: What the hell is depth in orthographic projection when near is negative and far is positive?[11:41:47] <tomaka> thanks for the help[11:42:02] <afl_ext> or near is positive and far is negative[11:43:50] <afl_ext> and also should Far be negative in GLM ortho function? I suppose yes because Z- is forward but im not really sure[11:44:31] <exDM69> tomaka: but does that work consistently?[11:44:32] *** Ploppz <Ploppz!~ploppz@2001:700:303:b:f3ce:ca7c:3834:8e44> has joined ##OpenGL[11:45:14] <tomaka> exDM69, it should ; if you once you assigned 0, 1 or 2 to two vertices of a triangle, the remaining vertex can only have one value[11:45:27] <tomaka> and then you can repeat for the neighbouring triangles[11:45:59] <exDM69> tomaka: yeah, sure that's the trivial part... but it falls apart at the equatorial wraparound and the poles, doesn't it?[11:46:20] <tomaka> we'll see[11:46:27] <tomaka> I'll add some asserts and see[11:46:44] <tomaka> either it's possible or it's not, but I don't think the way I assign the arbitrary values changes something[11:47:03] <tomaka> there are only three possibilities for the initial condition, so if it fails I'll try each of them[11:47:15] <exDM69> tomaka: I guess it's easier just to stop sharing vertices...[11:47:32] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[11:47:42] <tomaka> my planets are really big, like 300k vertices[11:47:53] <exDM69> OTOH, you won't be sharing the north/south pole vertices if you want to assign decent UV coordinates[11:48:30] <exDM69> tomaka: perhaps you should add some culling because all 300k can't be visible at once[11:48:43] <ratchetfreak> I believe that classic 1 rect map projections aren't good for texturing spheres[11:48:52] <exDM69> e.g. split the model to 20 parts, one per "original" triangle of icosahedron[11:48:55] <tomaka> I don't plan on texturing the sphere[11:49:17] <exDM69> yeah, if you planned on texturing, you'd be using cubespheres and not icospheres...[11:49:25] <exDM69> (I went down this path once, learned the hard way :)[11:50:30] <exDM69> tomaka: perhaps this would be more "malleable" if you split each original triangle edge to three (not two) parts[11:51:14] <tomaka> that would destroy my coordinates system[11:51:59] <exDM69> I was tinkering with this idea when I was looking if I could put a hexagon map on an icosahedron... you can do it if you divide by 3 and don't mind the pentagons around the original 12 vertices of icosahedron :)[11:52:39] <exDM69> tomaka: https://github.com/rikusalminen/triangles/blob/icosphere_shader/shaders/icosphere/icosphere.glslv this might also be of interest to you[11:54:24] <exDM69> you can do attributeless rendering to get the base shape... it should be pretty easy to make that emit a subdivided ico[11:55:00] *** zagabar <zagabar!~zagabar@unaffiliated/zagabar> has joined ##OpenGL[11:55:44] <exDM69> that might reduce the pain from not being able to share the vertices (because I don't think the numbering scheme you suggest will work on the wraparound)[11:56:22] *** ManDay <ManDay!~ManDay@unaffiliated/manday> has joined ##OpenGL[11:57:37] *** hackkitten <hackkitten!~hackkitte@HSI-KBW-149-172-240-159.hsi13.kabel-badenwuerttemberg.de> has quit IRC (Ping timeout: 244 seconds)[11:58:01] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has joined ##OpenGL[12:03:27] *** Th30n <Th30n!~Th30n@93-142-73-5.adsl.net.t-com.hr> has quit IRC (Quit: leaving)[12:06:22] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has quit IRC (Quit: stelarcf_)[12:06:43] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has joined ##OpenGL[12:07:24] *** Vag <Vag!~Vag@ppp-2-85-242-122.home.otenet.gr> has joined ##OpenGL[12:07:30] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[12:07:39] <exDM69> tomaka: nope, the "start with one triangle and work from there" numbering doesn't work for icosahedron[12:07:59] <exDM69> at least at the LOD 0 level...[12:13:08] <tomaka> it looks like you're right, my asserts are failing[12:13:17] <tomaka> I'll just split the triangles[12:13:54] <tomaka> (I try to assign a value to a vertex that already has a value, and it's not the same)[12:14:06] <exDM69> I just drew it on pen and paper and did numbering starting from one of the triangles in the middle[12:14:53] <exDM69> tomaka: soo... did you consider attributeless rendering / generating the geometry in the vertex shader?[12:15:12] <tomaka> I have attributes like temperature and elevation, so no attributeless rendering[12:15:38] <exDM69> it's not really a solution to the problem, because it removes the shared edges[12:15:48] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[12:15:51] <exDM69> tomaka: just put your temp/elev data in a texture or a buffer?[12:15:55] <exDM69> and go attribless?[12:16:12] <exDM69> this would also allow easier culling without having to re-generate VBOs or index buffers[12:16:23] <tomaka> but how do I match the generated geometry with the attributes?[12:16:51] <exDM69> you should be able to come up with a scheme for that[12:20:27] <exDM69> similarly to the way you come up with UV coordinates, you can get the index of an array that corresponds to the vertex[12:21:34] <exDM69> this will reduce memory and bandwidth use but I have no idea how fast attributeless rendering is[12:27:06] *** hackkitten <hackkitten!~hackkitte@HSI-KBW-149-172-240-159.hsi13.kabel-badenwuerttemberg.de> has joined ##OpenGL[12:34:58] *** feliwir_ <feliwir_!Elite16673@gateway/shell/elitebnc/x-snvzvogngcvxjrpm> has joined ##OpenGL[12:35:20] *** feliwir_ is now known as feliwir[12:39:34] *** cden <cden!~cden@unaffiliated/cden> has joined ##OpenGL[12:40:39] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has joined ##OpenGL[12:42:22] *** Coldseeker <Coldseeker!~Frosty@as-syd-4-1-55.ozonline.com.au> has quit IRC (Quit: The one good thing about repeating your mistakes is that you know when to cringe.)[12:44:03] *** fodil <fodil!~fodil@bea13-5-83-156-146-12.fbx.proxad.net> has joined ##OpenGL[12:46:11] *** toor <toor!~toor@76.ip-51-254-204.eu> has quit IRC (Ping timeout: 244 seconds)[12:49:08] *** stefkos <stefkos!~stefkos@82.177.144.226> has joined ##OpenGL[12:51:23] *** Vtec234 <Vtec234!~wn@178235041124.dynamic-ww-06.vectranet.pl> has joined ##OpenGL[12:58:57] *** Cooler <Cooler!~CoolerExt@36.255.14.160> has quit IRC (Ping timeout: 265 seconds)[12:59:55] *** toor <toor!~toor@eth-east-parth2-46-193-65-52.wb.wifirst.net> has joined ##OpenGL[13:00:16] *** Cooler <Cooler!~CoolerExt@36.255.14.160> has joined ##OpenGL[13:00:25] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[13:11:31] *** bjz_ <bjz_!~bjz@104.222.140.46> has joined ##OpenGL[13:11:46] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[13:12:33] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Ping timeout: 250 seconds)[13:15:55] *** Th30n <Th30n!~Th30n@93-142-73-5.adsl.net.t-com.hr> has joined ##OpenGL[13:18:03] *** stefkos <stefkos!~stefkos@82.177.144.226> has quit IRC (Ping timeout: 240 seconds)[13:22:09] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has quit IRC (Read error: No route to host)[13:26:39] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has joined ##OpenGL[13:27:15] *** stefkos <stefkos!~stefkos@82.177.144.226> has joined ##OpenGL[13:27:59] *** Twipply <Twipply!~Dunno@cpc1-mapp10-2-0-cust641.12-4.cable.virginm.net> has joined ##OpenGL[13:33:28] *** cden <cden!~cden@unaffiliated/cden> has quit IRC (Quit: Leaving)[13:40:07] *** TechnoCrunch <TechnoCrunch!~Tech@101.100.137.146> has quit IRC (Read error: Connection reset by peer)[13:40:33] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[13:40:54] *** Gamecubic <Gamecubic!~Gamecubic@modemcable022.28-20-96.mc.videotron.ca> has joined ##OpenGL[13:46:49] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[13:48:17] *** Vtec234 <Vtec234!~wn@178235041124.dynamic-ww-06.vectranet.pl> has quit IRC (Quit: Bye!)[13:51:40] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC (Quit: Bye bye! o/)[14:08:11] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[14:08:22] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[14:10:49] *** afl_ext1 <afl_ext1!~afl_ext3@arj233.neoplus.adsl.tpnet.pl> has joined ##OpenGL[14:13:35] <fodil> hi ![14:13:53] *** afl_ext <afl_ext!~afl_ext3@unaffiliated/afl-ext/x-2796036> has quit IRC (Ping timeout: 250 seconds)[14:14:07] <fodil> is there anything good in changing the winding order ,[14:14:09] <fodil> ?*[14:14:15] <fodil> (please)[14:17:43] *** notadeveloper <notadeveloper!~notadevel@2602:306:bd2a:a160:610a:1c:6fbd:4acd> has joined ##OpenGL[14:20:39] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has joined ##OpenGL[14:25:29] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has joined ##OpenGL[14:26:54] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 260 seconds)[14:29:02] *** Ryp_ <Ryp_!~ryp@gateway/vpn/privateinternetaccess/ryp> has joined ##OpenGL[14:29:48] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has quit IRC (Ping timeout: 276 seconds)[14:45:43] *** Birchy <Birchy!~Birchy@178-164-108.52.3p.ntebredband.no> has joined ##OpenGL[14:46:03] *** Wutata <Wutata!~Wutata@91-158-232-113.elisa-laajakaista.fi> has quit IRC (Ping timeout: 276 seconds)[14:48:03] <fodil> is there a nice application from [0,1]^2 to [0,1] please ?[14:48:04] *** notadeveloper <notadeveloper!~notadevel@2602:306:bd2a:a160:610a:1c:6fbd:4acd> has quit IRC (Quit: Leaving)[14:48:15] <fodil> (i know it's maths, but it's for my fragShader)[14:49:40] *** toor <toor!~toor@eth-east-parth2-46-193-65-52.wb.wifirst.net> has quit IRC (Ping timeout: 264 seconds)[14:52:04] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[14:52:20] *** rixxxo <rixxxo!~razieliyo@unaffiliated/razieliyo> has joined ##OpenGL[14:54:00] <afl_ext1> first time in my life i see freenode maintenace[14:55:19] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has joined ##OpenGL[15:02:06] <t0by> afl_ext1, how do you tell freenode mantenance? :|[15:02:11] <t0by> i'm not seeing anything fancy[15:02:17] *** toor <toor!~toor@76.ip-51-254-204.eu> has joined ##OpenGL[15:03:19] *** BilboTheHobbit <BilboTheHobbit!~Emma@112.10.171.146> has joined ##OpenGL[15:03:26] *** crziter <crziter!~crziter@27.74.227.244> has joined ##OpenGL[15:04:33] *** fodil <fodil!~fodil@bea13-5-83-156-146-12.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds)[15:06:46] *** pazul <pazul!~pazul@ptr-2hj4tbi3h8zz81s2j7xokbjug.ip6.access.telenet.be> has joined ##OpenGL[15:07:23] <ratchetfreak> they didn't announce in theis room?[15:07:41] <ratchetfreak> maybe only some servers get cycled[15:08:11] <ratchetfreak> and the high traffic channels get to stay up[15:15:25] *** Lunatrius <Lunatrius!~Lunatrius@77.38.21.26> has quit IRC (Read error: Connection reset by peer)[15:16:50] <t0by> uh[15:17:15] <t0by> afl_ext1, ratchetfreak, I've just seen a bunch of chanservs leave and rejoin.[15:17:20] *** crziter <crziter!~crziter@27.74.227.244> has quit IRC (Changing host)[15:17:20] *** crziter <crziter!~crziter@unaffiliated/crziter> has joined ##OpenGL[15:17:25] *** Lunatrius <Lunatrius!~Lunatrius@77.38.21.26> has joined ##OpenGL[15:23:56] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[15:32:58] *** vitimiti <vitimiti!~vitimiti@unaffiliated/vitimiti> has joined ##OpenGL[15:34:20] *** fodil <fodil!~fodil@bea13-5-83-156-146-12.fbx.proxad.net> has joined ##OpenGL[15:35:48] *** therue <therue!~therue@1-162-47-146.dynamic.hinet.net> has quit IRC (Quit: therue)[15:41:43] *** pril <pril!userid@unaffiliated/pril> has joined ##OpenGL[15:43:37] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[15:47:13] *** Ryp_ <Ryp_!~ryp@gateway/vpn/privateinternetaccess/ryp> has quit IRC (Quit: Konversation terminated!)[15:51:11] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[15:53:39] *** therue <therue!~therue@1-162-47-146.dynamic.hinet.net> has joined ##OpenGL[15:53:53] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has joined ##OpenGL[15:59:32] *** Suchorski <Suchorski!~regex@unaffiliated/suchorski> has joined ##OpenGL[16:01:54] *** Joefish <Joefish!~Joefish@p5B121948.dip0.t-ipconnect.de> has joined ##OpenGL[16:05:13] *** Wutata <Wutata!~Wutata@91-158-232-113.elisa-laajakaista.fi> has joined ##OpenGL[16:12:59] *** _BearishMushroom <_BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has joined ##OpenGL[16:15:06] *** Cooler <Cooler!~CoolerExt@36.255.14.160> has quit IRC (Ping timeout: 265 seconds)[16:16:31] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has quit IRC (Ping timeout: 250 seconds)[16:19:33] *** afl_ext1 <afl_ext1!~afl_ext3@arj233.neoplus.adsl.tpnet.pl> has quit IRC (Ping timeout: 250 seconds)[16:29:55] *** kmnt <kmnt!~k@69.63.37.65> has joined ##OpenGL[16:30:25] *** p3rs3us <p3rs3us!~jduro@host86-177-61-75.range86-177.btcentralplus.com> has quit IRC (Quit: Leaving)[16:32:25] *** pazul <pazul!~pazul@ptr-2hj4tbi3h8zz81s2j7xokbjug.ip6.access.telenet.be> has quit IRC (Quit: Leaving)[16:38:13] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has quit IRC (Read error: Connection reset by peer)[16:38:36] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has joined ##OpenGL[16:43:26] *** DrGonzo <DrGonzo!~DrBenway@190.18.153.73> has joined ##OpenGL[16:45:19] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has quit IRC (Ping timeout: 250 seconds)[16:52:56] *** lucaswang <lucaswang!~lucaswang@183.167.211.74> has quit IRC ()[16:56:16] *** lucaswang <lucaswang!~lucaswang@59.53.67.224> has joined ##OpenGL[16:59:57] *** lucaswang <lucaswang!~lucaswang@59.53.67.224> has quit IRC (Remote host closed the connection)[17:00:31] *** lucaswang <lucaswang!~lucaswang@61-216-40-223.HINET-IP.hinet.net> has joined ##OpenGL[17:02:44] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has quit IRC (Remote host closed the connection)[17:03:35] *** lucaswan_ <lucaswan_!~lucaswang@183.167.211.74> has joined ##OpenGL[17:06:54] *** lucaswang <lucaswang!~lucaswang@61-216-40-223.HINET-IP.hinet.net> has quit IRC (Ping timeout: 265 seconds)[17:09:28] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[17:09:50] *** xCrypto <xCrypto!~xCrypto@drmons0544w-142177154202.dhcp-dynamic.FibreOp.ns.bellaliant.net> has quit IRC (Quit: Nettalk6 - www.ntalk.de)[17:09:57] *** t0by <t0by!~t0by@host247-252-dynamic.4-87-r.retail.telecomitalia.it> has quit IRC (Quit: Bye!)[17:19:26] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[17:21:01] *** pffffffft <pffffffft!~pffffffft@unaffiliated/pffffffft> has joined ##OpenGL[17:21:22] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Client Quit)[17:22:34] *** Th30n <Th30n!~Th30n@93-142-73-5.adsl.net.t-com.hr> has quit IRC (Ping timeout: 240 seconds)[17:24:24] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[17:25:16] *** lucaswan_ <lucaswan_!~lucaswang@183.167.211.74> has quit IRC ()[17:31:37] *** lucaswang <lucaswang!~lucaswang@183.167.211.74> has joined ##OpenGL[17:38:22] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-175-76.w90-58.abo.wanadoo.fr> has joined ##OpenGL[17:41:12] *** MrFlibble <MrFlibble!MrFlibble@90.220.166.75> has joined ##OpenGL[17:43:43] *** lucaswang <lucaswang!~lucaswang@183.167.211.74> has quit IRC (Remote host closed the connection)[17:44:12] *** lucaswang <lucaswang!~lucaswang@61-216-40-223.HINET-IP.hinet.net> has joined ##OpenGL[17:44:55] *** lucaswang <lucaswang!~lucaswang@61-216-40-223.HINET-IP.hinet.net> has quit IRC (Read error: Connection reset by peer)[17:45:23] *** lucaswang <lucaswang!~lucaswang@59.53.67.224> has joined ##OpenGL[17:46:23] *** crziter <crziter!~crziter@unaffiliated/crziter> has quit IRC (Read error: Connection reset by peer)[17:56:22] *** mat^2 <mat^2!~Mathias@87-55-0-192-dynamic.dk.customer.tdc.net> has quit IRC (Ping timeout: 258 seconds)[18:05:03] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has joined ##OpenGL[18:09:37] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[18:11:48] *** lucaswang <lucaswang!~lucaswang@59.53.67.224> has quit IRC (Remote host closed the connection)[18:12:16] *** lucaswang <lucaswang!~lucaswang@61-216-40-223.HINET-IP.hinet.net> has joined ##OpenGL[18:15:33] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has joined ##OpenGL[18:17:49] *** Albori <Albori!~Albori@216-229-75-197.fidnet.com> has quit IRC (Quit: WeeChat 1.6-rc1)[18:18:28] *** t0by <t0by!~t0by@host23-232-dynamic.51-79-r.retail.telecomitalia.it> has joined ##OpenGL[18:18:39] *** lucaswan_ <lucaswan_!~lucaswang@183.167.211.74> has joined ##OpenGL[18:19:04] *** pril <pril!userid@unaffiliated/pril> has quit IRC (Ping timeout: 264 seconds)[18:21:48] *** ornitorrincos <ornitorrincos!~ornitorri@unaffiliated/ornitorrincos> has quit IRC (Quit: ZNC 1.6.3 - http://znc.in)[18:22:04] *** lucaswang <lucaswang!~lucaswang@61-216-40-223.HINET-IP.hinet.net> has quit IRC (Ping timeout: 264 seconds)[18:22:28] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has quit IRC (Remote host closed the connection)[18:22:56] *** ornitorrincos <ornitorrincos!~ornitorri@2001:41d0:8:4b96::1> has joined ##OpenGL[18:22:56] *** ornitorrincos <ornitorrincos!~ornitorri@2001:41d0:8:4b96::1> has quit IRC (Changing host)[18:22:56] *** ornitorrincos <ornitorrincos!~ornitorri@unaffiliated/ornitorrincos> has joined ##OpenGL[18:24:00] *** atk <atk!Arch-TK@fsf/member/Arch-TK> has quit IRC (Quit: You should never see this quit message.)[18:26:05] *** t0by <t0by!~t0by@host23-232-dynamic.51-79-r.retail.telecomitalia.it> has quit IRC (Ping timeout: 252 seconds)[18:26:50] *** Jonas___ <Jonas___!~Jonas__@unaffiliated/jonas/x-7723671> has joined ##OpenGL[18:27:49] *** PlasmaStar <PlasmaStar!Plasma@unaffiliated/plasmastar> has quit IRC (Ping timeout: 260 seconds)[18:28:23] *** Jonas__ <Jonas__!~Jonas__@unaffiliated/jonas/x-7723671> has quit IRC (Ping timeout: 244 seconds)[18:29:11] *** harha_ <harha_!harha_@y55.ip4.netikka.fi> has joined ##OpenGL[18:30:42] *** t0by <t0by!~t0by@host23-232-dynamic.51-79-r.retail.telecomitalia.it> has joined ##OpenGL[18:32:28] *** t0by <t0by!~t0by@host23-232-dynamic.51-79-r.retail.telecomitalia.it> has quit IRC (Read error: Connection reset by peer)[18:39:59] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[18:40:14] *** fodil <fodil!~fodil@bea13-5-83-156-146-12.fbx.proxad.net> has quit IRC (Quit: Leaving)[18:42:21] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[18:43:49] *** xCrypto <xCrypto!~xCrypto@drmons0544w-142177154202.dhcp-dynamic.FibreOp.ns.bellaliant.net> has joined ##OpenGL[18:49:31] *** jediminer543 <jediminer543!57518682@gateway/web/freenode/ip.87.81.134.130> has joined ##OpenGL[18:50:45] <jediminer543> hello[18:52:04] *** rixxxo <rixxxo!~razieliyo@unaffiliated/razieliyo> has quit IRC (Ping timeout: 264 seconds)[18:53:19] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[18:54:09] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[18:58:17] *** pril <pril!userid@unaffiliated/pril> has joined ##OpenGL[19:04:30] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[19:04:59] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[19:05:33] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[19:08:44] *** vassagus <vassagus!~vassagus@186.4.2.162> has quit IRC (Read error: Connection reset by peer)[19:09:11] *** vassagus <vassagus!~vassagus@186.4.2.162> has joined ##OpenGL[19:14:37] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has joined ##OpenGL[19:14:53] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has joined ##OpenGL[19:16:59] *** DrGonzo <DrGonzo!~DrBenway@190.18.153.73> has quit IRC (Ping timeout: 250 seconds)[19:20:05] *** shakesoda <shakesoda!~shake@excessive.moe> has quit IRC (Ping timeout: 244 seconds)[19:21:04] *** edenist <edenist!~edenist@li280-110.members.linode.com> has quit IRC (Ping timeout: 240 seconds)[19:21:19] *** kenzierocks <kenzierocks!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has quit IRC (Ping timeout: 250 seconds)[19:22:14] *** w4ffles <w4ffles!w4ffles@2600:3c01::f03c:91ff:fe69:8613> has quit IRC (Ping timeout: 258 seconds)[19:23:49] *** nine_milli <nine_milli!~nine_mill@ool-6894ef96.dyn.optonline.net> has joined ##OpenGL[19:26:41] *** mat^2 <mat^2!~Mathias@94.191.189.133.bredband.3.dk> has joined ##OpenGL[19:27:35] *** atk <atk!~Arch-TK@fsf/member/Arch-TK> has joined ##OpenGL[19:27:44] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[19:28:24] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has joined ##OpenGL[19:29:30] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[19:29:50] *** PlasmaStar <PlasmaStar!Plasma@unaffiliated/plasmastar> has joined ##OpenGL[19:29:55] *** edenist <edenist!~edenist@li280-110.members.linode.com> has joined ##OpenGL[19:30:04] *** nepgear <nepgear!~shake@excessive.moe> has joined ##OpenGL[19:30:22] *** nepgear is now known as Guest16138[19:30:22] *** kenzierocks <kenzierocks!~kenzieroc@yes.quite.indeed.old.chap.it.is.kenzierocks.me> has joined ##OpenGL[19:30:27] *** bookmark <bookmark!~IceChat77@173-169-112-35.res.bhn.net> has joined ##OpenGL[19:30:44] *** ArkaZeen <ArkaZeen!~ArkaZeen@wn-res-nat-129-97-125-27.dynamic.uwaterloo.ca> has joined ##OpenGL[19:32:16] *** w4ffles <w4ffles!w4ffles@2600:3c01::f03c:91ff:fe69:8613> has joined ##OpenGL[19:34:33] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has joined ##OpenGL[19:34:54] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has quit IRC (Ping timeout: 260 seconds)[19:35:09] *** xaxxon <xaxxon!~xaxxon@2601:602:9d00:d58b:1fb:bb44:df4f:8b50> has joined ##OpenGL[19:37:58] <bookmark> anyone here ever done sphere packing?[19:38:45] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has quit IRC (Client Quit)[19:39:01] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has joined ##OpenGL[19:40:53] <bookmark> [13:34] * Codex_ (~terop at 91-157-91-164 dot elisa-laajakaista.f i) Quit ( Ping timeout: 260 seconds )[19:40:53] <bookmark> [13:35] * xaxxon (~xaxxon@2601:602:9d00:d58b:1fb:bb44:d f4f:8b50) has joined ##OpenGL[19:40:53] <bookmark> [13:37] <bookmark> anyone here ever done sphere packing?[19:41:03] <xaxxon> no[19:41:07] <xaxxon> maybe[19:41:08] <xaxxon> wtf is it[19:41:10] <bookmark> ooops[19:41:26] <bookmark> https://www.youtube.com/watch?v=RJedjs8s0rA[19:41:32] <bookmark> see here[19:41:56] <ImQ009> bookmark, why in the world are you using such an ancient IRC client[19:42:03] *** SrPx <SrPx!b3d23a8a@gateway/web/freenode/ip.179.210.58.138> has joined ##OpenGL[19:42:10] <ImQ009> Just a side question[19:42:32] <bookmark> dunno[19:42:34] <xaxxon> ahh, I see interesting[19:42:34] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has quit IRC (Client Quit)[19:42:42] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has joined ##OpenGL[19:43:07] <bookmark> the algorithm seems very loosly defined[19:43:21] <SrPx> Is there any way, on ES 2.0, to have anything resembling an array, but that I can actually write to? The only way I can think of is a series of if (if (idx == 0) arr[0] = val; if (idx == 1) arr[1] = val; ...) - but that is too expensive[19:44:47] <Stragus> SrPx, a fragment share writing to a texture?[19:44:51] <Stragus> fragment shader*[19:45:36] <SrPx> not really, I want to make many writes/reads on the same pass for each vertex[19:46:16] <SrPx> basically I'm splitting a callular-automaton in many slices and each vertex is responsible for a part of it[19:46:22] <Stragus> Ah, temporary indexed storage inside the shader[19:46:28] <SrPx> yes[19:46:52] <Stragus> I don't think it can be done on GL ES 2.0[19:47:01] <SrPx> ): I expected that answer[19:47:03] <ImQ009> What about textures?[19:47:14] <ImQ009> 1D textures in that case[19:47:17] <SrPx> damn I hate ES 2.0, when is the web getting something better?[19:47:43] <ImQ009> You can treat them as simple arrays IIRC[19:50:05] <Stragus> I think the point is temporary indexed storage inside the shader, using on-chip shared memory, not global read/write with separate shader invocations[19:50:49] *** bookmark <bookmark!~IceChat77@173-169-112-35.res.bhn.net> has quit IRC (Quit: If your not living on the edge, you're taking up too much space)[19:51:28] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[19:51:33] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has quit IRC (Ping timeout: 276 seconds)[19:53:16] *** Th30n <Th30n!~Th30n@93-142-73-5.adsl.net.t-com.hr> has joined ##OpenGL[19:54:08] *** afl_ext1 <afl_ext1!~afl_ext3@arj233.neoplus.adsl.tpnet.pl> has joined ##OpenGL[19:56:02] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has joined ##OpenGL[19:57:37] *** Albori <Albori!~Albori@67-43-242-100.fidnet.com> has joined ##OpenGL[20:01:40] *** BilboTheHobbit <BilboTheHobbit!~Emma@112.10.171.146> has quit IRC (Ping timeout: 255 seconds)[20:05:30] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 250 seconds)[20:08:43] *** matpow2 <matpow2!~Mathias@94.191.186.184.mobile.3.dk> has joined ##OpenGL[20:08:50] *** SrPx <SrPx!b3d23a8a@gateway/web/freenode/ip.179.210.58.138> has quit IRC (Ping timeout: 264 seconds)[20:10:32] *** mat^2 <mat^2!~Mathias@94.191.189.133.bredband.3.dk> has quit IRC (Ping timeout: 258 seconds)[20:10:44] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[20:12:44] *** razdaman <razdaman!~rasmus@3224057-cl69.boa.fiberby.dk> has joined ##OpenGL[20:12:59] *** razdaman <razdaman!~rasmus@3224057-cl69.boa.fiberby.dk> has left ##OpenGL[20:14:56] *** sandeepkr <sandeepkr!~sandeepkr@103.49.155.114> has quit IRC (Read error: Connection reset by peer)[20:16:14] *** sandeepkr <sandeepkr!~sandeepkr@103.49.155.114> has joined ##OpenGL[20:21:30] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has joined ##OpenGL[20:22:09] *** joshsyn <joshsyn!~swoorup@124-148-250-150.dyn.iinet.net.au> has quit IRC (Remote host closed the connection)[20:24:34] *** ManDay <ManDay!~ManDay@unaffiliated/manday> has quit IRC (Quit: WeeChat 1.4)[20:27:33] *** derhass <derhass!~derhass@ltea-047-065-098-100.pools.arcor-ip.net> has quit IRC (Ping timeout: 240 seconds)[20:31:33] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has quit IRC (Quit: Konversation terminated!)[20:31:48] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has joined ##OpenGL[20:33:40] *** mat^2 <mat^2!~Mathias@94.191.188.59.bredband.3.dk> has joined ##OpenGL[20:34:53] *** derhass <derhass!~derhass@ltea-047-066-224-247.pools.arcor-ip.net> has joined ##OpenGL[20:35:27] *** matpow2 <matpow2!~Mathias@94.191.186.184.mobile.3.dk> has quit IRC (Ping timeout: 258 seconds)[20:39:36] *** Ardeshir <Ardeshir!~Ardeshir@2.187.125.186> has joined ##OpenGL[20:40:28] *** Ardeshir <Ardeshir!~Ardeshir@2.187.125.186> has quit IRC (Remote host closed the connection)[20:43:58] *** rixxxo <rixxxo!~razieliyo@unaffiliated/razieliyo> has joined ##OpenGL[20:44:07] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has quit IRC (Quit: Konversation terminated!)[20:44:24] *** ravior <ravior!~ravior@5-13-192-211.residential.rdsnet.ro> has joined ##OpenGL[20:44:28] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has joined ##OpenGL[20:46:06] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[20:47:47] *** afl_ext1 <afl_ext1!~afl_ext3@arj233.neoplus.adsl.tpnet.pl> has quit IRC (Read error: Connection reset by peer)[20:51:01] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[20:51:43] *** matpow2 <matpow2!~Mathias@94.191.184.253.mobile.3.dk> has joined ##OpenGL[20:52:34] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[20:54:42] *** matpow3 <matpow3!~Mathias@94.191.189.12.bredband.3.dk> has joined ##OpenGL[20:55:00] *** mat^2 <mat^2!~Mathias@94.191.188.59.bredband.3.dk> has quit IRC (Ping timeout: 258 seconds)[20:56:52] *** matpow2 <matpow2!~Mathias@94.191.184.253.mobile.3.dk> has quit IRC (Ping timeout: 264 seconds)[21:02:26] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has quit IRC (Read error: Connection reset by peer)[21:03:29] *** telex <telex!teletype@freeshell.de> has quit IRC (Remote host closed the connection)[21:04:37] *** telex <telex!teletype@freeshell.de> has joined ##OpenGL[21:05:12] <noizex> how to achieve morph targets with gl, assuming I will have a lot of sliders (think character customization)[21:05:50] <noizex> could blend in vertex shader but this means as many vertex inputs as there are targets, and this may be around ~10-15[21:05:59] <ratchetfreak> set up a several positions per vertex and pass weights as uniforms[21:06:24] <ratchetfreak> you will probably need to restrict the "active"[21:06:28] <ratchetfreak> *number of[21:06:53] *** abs25 <abs25!~abs25@89-164-116-158.dsl.iskon.hr> has joined ##OpenGL[21:07:24] *** linearain <linearain!~linearain@clients-217-17-89-207.mikrovisata.net> has joined ##OpenGL[21:07:36] *** PlasmaStar <PlasmaStar!Plasma@unaffiliated/plasmastar> has quit IRC (Ping timeout: 265 seconds)[21:08:04] *** kasper^ <kasper^!~safaf@82.137.11.0> has joined ##OpenGL[21:08:18] <ratchetfreak> only send the active forms and let the weights of the remaining targets be 0[21:08:31] <sadtaco> Oh SrPx left, but the web is literally getting GLES 3.0 basically now. The spec was complete like a month or two ago iirc and is being implemented.[21:08:31] <noizex> ok[21:08:41] <noizex> also, I just send full mesh targets, right?[21:08:48] <noizex> even if only part of the mesh actually changes?[21:08:48] <linearain> is the "red book" good?[21:08:59] <sadtaco> And yeah what SrPx asked can't be done in GLES 2.0[21:09:09] *** Salvakiya <Salvakiya!~Salvakiya@host109-155-136-209.range109-155.btcentralplus.com> has quit IRC (Quit: Leaving)[21:09:27] <ratchetfreak> you can partition the mesh if it makes sense to do so[21:09:28] <sadtaco> Don't think it can in 3.0 either.. maybe 3.1, but certainly can for 3.2.[21:10:59] <Stragus> linearain: The Red Book used to be amazing, but I think it's quite outdated[21:12:48] <slime> the latest edition targets like 4.4 or so[21:13:14] <linearain> i c[21:13:30] <sadtaco> Hey Strag, not OpenGL but what you were saying earlier. Where can I read more about doing those large parrelism ops on the cpu? You mentioned NEON. What about AVF? Is there some material I can read on how I utilize these? And obviously I don't want to write assembly, and want the compiler to utilize. What I found is basically a bunch of computer science, and I better understand in practice programing.[21:13:43] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has joined ##OpenGL[21:13:45] <sadtaco> Or.. is this something I just write code for and the compiler magically takes advantage of?[21:14:12] *** partycoder <partycoder!~partycode@2604:5500:1a:7c7:2072:c9e0:f2db:8934> has joined ##OpenGL[21:14:12] *** partycoder <partycoder!~partycode@2604:5500:1a:7c7:2072:c9e0:f2db:8934> has quit IRC (Changing host)[21:14:12] *** partycoder <partycoder!~partycode@unaffiliated/partycoder> has joined ##OpenGL[21:14:23] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[21:14:46] <sadtaco> http://www.doulos.com/knowhow/arm/using_your_c_compiler_to_exploit_neon/Resources/using_your_c_compiler_to_exploit_neon.pdf Oh I did find some example..[21:15:35] *** DrGonzo <DrGonzo!~DrBenway@190.18.153.73> has joined ##OpenGL[21:16:23] *** Wutata <Wutata!~Wutata@91-158-232-113.elisa-laajakaista.fi> has quit IRC (Ping timeout: 250 seconds)[21:16:51] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has quit IRC (Ping timeout: 258 seconds)[21:17:50] <Stragus> It's not automatic and you don't write assembly; you use intrinsics[21:18:06] <linearain> what is opengl es? the one in old j2me non-smartphones[21:18:17] <linearain> is it hardware supported or just a library?[21:19:04] <sadtaco> https://software.intel.com/en-us/articles/soa-cloth-simulation-with-256-bit-intel-advanced-vector-extensions-intel-avx here is a good example. It does seem like what I ideally should be using, really. Though it would support much less hardware.[21:19:07] <xaxxon> linearain, both?[21:19:49] <sadtaco> Yeah Strag, that's what that pdf basically goes over. Intrinsics of how to write c code that the compiler assembles. I see then.[21:19:56] <Stragus> sadtaco: It's SSE/AVX on x86, NEON on mobile[21:21:08] <sadtaco> SIMD 8/AVX is the only one that seems to do this level of physics fast enough that it's better to handle this on the CPU than GPU, it seems to me.[21:21:56] *** xaxxon <xaxxon!~xaxxon@2601:602:9d00:d58b:1fb:bb44:df4f:8b50> has quit IRC (Quit: xaxxon)[21:22:03] *** Th30n <Th30n!~Th30n@93-142-73-5.adsl.net.t-com.hr> has quit IRC (Quit: leaving)[21:22:04] <Stragus> Meh... NEON will still provide you with a 3-8x boost, depending on parallelism and the instructions[21:22:33] <sadtaco> 3-8x boost compared to basic CPU programming, not compared to the GPU doing it.[21:22:42] <Stragus> I say 8x rather than 4x because some instructions have no "plain C code" equivalent, like reciprocial approximate square roots[21:22:46] <Stragus> Correct[21:24:14] <sadtaco> But eh. This gets quite complicated. And means two code bases for that part of the game for the two targets. And it means Working on 71% of Steam hardware instead of 97%+. My plan was, so I wouldn't spend so much time in QA hell and such, and to target the widest hardware, was to do my game programming in nodejs. And with what JS can't do well, AVX/SIMD for example, I'd have the GPU do with GP compute which is much easier to have working fine on a[21:24:14] <sadtaco> wide range of hardware.[21:24:19] <ratchetfreak> fast_invsqrt?[21:24:28] <sadtaco> I want to do some neat stuff, but I want it to be easy and not spend forever on this.[21:24:55] <Stragus> sadtaco: The point is only optimizing the tiniest most critical loops[21:25:16] <sadtaco> Oh I know.[21:25:27] <ratchetfreak> focus on optimizing what is slowing you down[21:25:28] <sadtaco> Well what I COULD do is write that part in C with JS bindings to it.[21:25:42] <sadtaco> Or you know. I just GPGPU it and deal with the 2-3 frame delay.[21:26:32] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Ping timeout: 250 seconds)[21:27:21] <sadtaco> But that'll still be less efficient on hardware that doesnt' support AVX. Which is quite a bit.[21:27:29] <Stragus> Simple GPGPU is fine for problems that require parallel brute force[21:28:03] <sadtaco> Not to mention that not only does that older hardware/mobile not support AVX, but they're too slow to do this level of physics and n-body interactions in any way.[21:28:04] <Stragus> Problems that require "smart" solutions can generally be implemented well on parallel hardware when the API used is flexible enough, like CUDA, OpenCL, compute shaders[21:28:32] <sadtaco> Does OpenCL not have the frame delay and stalling problems you mentioned?[21:28:34] <Stragus> You can use SSE, for 60% of the performance of AVX[21:28:36] <sadtaco> Because I can use that.[21:28:46] <Stragus> OpenCL would also run on the GPU[21:28:50] <sadtaco> Yes 60% of the performance on hardware that's significantly slower to start with.[21:29:11] <Stragus> SSE would be 3-8x scalar code where AVX would be 6-16x[21:29:26] <sadtaco> Right I know. But.. is there something different about it that means less delay to retrieve data back from the GPU faster without locking?[21:29:31] <Stragus> Well, more like 4-14x for AVX, some things are very messy in AVX land[21:29:59] <Stragus> No, the same issues exist as with OpenGL[21:32:14] *** partycoder <partycoder!~partycode@unaffiliated/partycoder> has quit IRC (Quit: zzz)[21:32:40] *** tambre <tambre!~tambre@9fe7-b5cb-e368-1847-a980-8a3e-07d0-2001.dyn.estpak.ee> has quit IRC (Read error: Connection reset by peer)[21:32:52] <sadtaco> There has to be something, no? Like won't atomicAdd results be there are shared APU memory for the CPU to read immediately afterward? Though I'm not sure how I can simply target the integrated APU graphics instead of their primary display card.[21:33:39] <Stragus> GPUs work on buffered queues of work, it's all asynchronous[21:34:06] <Stragus> With PBOs, you can reasonably synchronize the CPU and GPU without having wait for the other, just checking when it's ready to go[21:34:20] <Stragus> Fences can also help, depending on the workload[21:34:29] <sadtaco> Fences? I'm not aware of those.[21:34:30] *** Raz0r <Raz0r!~none@173-19-70-35.client.mchsi.com> has joined ##OpenGL[21:35:56] <sadtaco> nvm found it[21:38:22] *** pa <pa!~pa@unaffiliated/pa> has joined ##OpenGL[21:39:40] *** PlasmaStar <PlasmaStar!Plasma@unaffiliated/plasmastar> has joined ##OpenGL[21:40:24] *** AfroThundr <AfroThundr!~AfroThund@50-197-119-217-static.hfc.comcastbusiness.net> has joined ##OpenGL[21:40:25] *** AfroThundr <AfroThundr!~AfroThund@50-197-119-217-static.hfc.comcastbusiness.net> has quit IRC (Max SendQ exceeded)[21:41:03] *** matpow3 <matpow3!~Mathias@94.191.189.12.bredband.3.dk> has quit IRC (Quit: Leaving)[21:48:41] *** therue <therue!~therue@1-162-47-146.dynamic.hinet.net> has quit IRC (Quit: therue)[21:48:46] *** kasper^ <kasper^!~safaf@82.137.11.0> has quit IRC (Ping timeout: 255 seconds)[21:56:52] *** shingshang <shingshang!~shingshan@115-64-27-246.static.tpgi.com.au> has quit IRC (Ping timeout: 264 seconds)[21:58:03] *** shirt <shirt!~shirt@adsl-v01-3db14831dc15da1b.tau.ac.il> has joined ##OpenGL[21:58:51] *** Hink <Hink!~Hink@2001:19f0:200:65a8::f6cf:8507> has quit IRC (Read error: Connection reset by peer)[22:05:35] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has quit IRC (Quit: Konversation terminated!)[22:05:52] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has quit IRC (Read error: Connection reset by peer)[22:07:20] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has joined ##OpenGL[22:08:08] *** linearain <linearain!~linearain@clients-217-17-89-207.mikrovisata.net> has quit IRC (Quit: Leaving)[22:08:26] *** soulz <soulz!~soulz@unaffiliated/soulz> has quit IRC (Quit: leaving)[22:11:17] *** shirt <shirt!~shirt@adsl-v01-3db14831dc15da1b.tau.ac.il> has quit IRC (Ping timeout: 258 seconds)[22:15:03] *** soulz <soulz!~soulz@zen.luflow.net> has joined ##OpenGL[22:15:20] *** soulz <soulz!~soulz@zen.luflow.net> has quit IRC (Changing host)[22:15:20] *** soulz <soulz!~soulz@unaffiliated/soulz> has joined ##OpenGL[22:18:15] <jediminer543> How do I determine why glGetAttribLocation is returning -1?[22:19:09] <ratchetfreak> double check compilation succeeds and then trace the data flow to ensure it actually ends up affecting the output of the render[22:19:45] <sadtaco> Stragus, you might be interested in this yourself: http://uu.diva-portal.org/smash/get/diva2:641061/FULLTEXT01.pdf They were able to get gpu->cpu download times as fast as 10.5ms on the worst configured computer.[22:19:50] *** pril <pril!userid@unaffiliated/pril> has quit IRC (Ping timeout: 250 seconds)[22:20:39] <derhass> why wouldn't they?[22:20:55] <sadtaco> Using a combination of GPU Direct(nVidia), HSA (AMD), AMD_pinned_memory, INTEL_map_texture, PBO with FBO[22:22:10] *** parasite_ <parasite_!~parasite@mar75-4-82-230-46-11.fbx.proxad.net> has joined ##OpenGL[22:23:15] *** shirt <shirt!~shirt@adsl-v01-3db14831dc15da1b.tau.ac.il> has joined ##OpenGL[22:28:13] <derhass> that document is really, really bad[22:28:18] <sadtaco> oh wait that's the upload to gpu. For download, it's 16ms, except for an edge case that's stupidly slow, a rugged laptop with windows7 and integrated HD 3000.[22:28:20] <sadtaco> Is it?[22:28:31] <derhass> yes[22:28:37] <sadtaco> Why?[22:28:41] <derhass> the author does a lot of guesswork, and his guesses are wrong[22:29:24] <sadtaco> But there are tests with various methods and hardware?[22:29:36] <derhass> sure[22:29:42] *** PlasmaStar <PlasmaStar!Plasma@unaffiliated/plasmastar> has quit IRC (Ping timeout: 244 seconds)[22:29:48] <sadtaco> Do you think there are flaws on how he's measuring the upload/download rates?[22:30:23] <sadtaco> Even if he doesn't come to the best conclusion, well I see a lot of methods that are saving times to get data from the gpu to the cpu on various hardware, all within the time of 1 frame.[22:31:26] <sadtaco> ideally though, like I said, I'd like to be able to do the compute on APUs where I just have to worry about AMD or Intel with integrated graphics and don't have to worry about if it's AMD+nVidia, Intel+AMD, Intel+nVidia, etc.[22:32:22] <Stragus> I'm pretty sure I was waaayy below 10ms using CUDA[22:32:45] <Stragus> Never really measured it, because it's designed to be asynchronous without either CPU or GPU stalling/waiting[22:33:26] <sadtaco> This is showing ranges from 1-16ms besides that rugged laptop outlier using the best method they tried. So this seems very reasonable to work with.[22:33:29] <derhass> sadtaco: it is not described what was measured at all[22:33:40] <sadtaco> Oh yes that's true and bothering me.[22:33:48] <sadtaco> No size/format for the data and such.[22:34:00] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has joined ##OpenGL[22:34:02] <derhass> sadtaco: he generelly ignores the problem of synchronization, which would have been the key point for this evaluation[22:34:34] <sadtaco> What problem of synchronization? Isn't the PBO tests an async one?[22:34:37] <derhass> sadtaco: I read the PBO download section in detail, and he gets a few major things wrong[22:35:10] <derhass> look at the list in 3.2.2[22:35:29] <derhass> point 6 is where he forces a synchronization[22:35:33] <sadtaco> Yeah I saw some problems myself, but I haven't found something better to give me an idea without doing my own detail tests that are probably beyond my current ability[22:35:51] <derhass> and he also got it wrong in that he would get a pointer to the PBO in VRAM[22:36:20] <derhass> the PBO would of course reside in system RAM[22:36:52] <sadtaco> I thought PBOs reside in GPU RAM as well.[22:36:58] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has joined ##OpenGL[22:37:10] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[22:37:28] <sadtaco> And how you get them to be asynchronous is because you have two of them, and one PBO on the GPU reads from the working memory there and communicates to the CPU.[22:37:48] <derhass> they nvidia driver will even tell you were they reside[22:37:51] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 250 seconds)[22:37:51] <derhass> *the[22:38:33] <derhass> and it will even tell you that it is going to ignore the usage hints you provided if it detects that you lied about it[22:39:04] *** pffffffft <pffffffft!~pffffffft@unaffiliated/pffffffft> has quit IRC (Ping timeout: 252 seconds)[22:39:31] <derhass> doing an async transfer from GPU to system memory would also be completely pointless, if the end result would be the data still lying around in VRAM, don't you think?[22:39:42] *** tm604 <tm604!~tom@cpc12-lewi14-2-0-cust47.2-4.cable.virginm.net> has joined ##OpenGL[22:39:48] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has joined ##OpenGL[22:44:17] *** pril <pril!~userid@unaffiliated/pril> has joined ##OpenGL[22:44:26] *** pril <pril!~userid@unaffiliated/pril> has quit IRC (Client Quit)[22:46:31] <sadtaco> derhass, no because the GPU uses that data in VRAM to render the frame at the time it's also uploading to the CPU.[22:47:15] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[22:47:35] <derhass> that is not what this is about[22:49:22] <sadtaco> Oh another way I can address my problem would probably be with a compute shader that outputs attributes used to "register" a hit on my targets for the target's shader, right?[22:49:30] *** pril <pril!~userid@unaffiliated/pril> has joined ##OpenGL[22:51:22] <sadtaco> In my 36000 shader programs for the projectiles, I output a float to point which target unit they collided with of the 900. IE .001-.901. Then couldn't a compute shader do a pass over that to make array for attributes to supply to the 900 target/units shader program?[22:51:28] *** abs25 <abs25!~abs25@89-164-116-158.dsl.iskon.hr> has quit IRC (Read error: Connection reset by peer)[22:51:55] *** Jackneill <Jackneill!~Jackneill@unaffiliated/jackneill> has quit IRC (Remote host closed the connection)[22:52:34] *** stefkos <stefkos!~stefkos@82.177.144.226> has quit IRC (Read error: Connection reset by peer)[22:52:42] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC (Read error: Connection reset by peer)[22:54:43] *** harha_ <harha_!harha_@y55.ip4.netikka.fi> has quit IRC ()[22:55:17] <sadtaco> Or.. straight compute shader for the collisions. They output ints. But I need to pass that as attributes in a 900 count array from the 36000.[22:55:40] <sadtaco> My whole problem here is really the converting of 36000 down to 900.[22:56:22] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[22:56:44] <ratchetfreak> 40 to 1 reduction...[22:57:29] <sadtaco> mhm[22:58:02] <sadtaco> I need to calculate collisions on the 36000 because I can sort the 900. But the 900 is what really needs to know about the collision happening.[23:00:00] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[23:00:00] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has quit IRC (Quit: gravitation)[23:01:08] *** Gama11 <Gama11!~quassel@pD9F9867E.dip0.t-ipconnect.de> has quit IRC (Read error: Connection reset by peer)[23:03:01] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has joined ##OpenGL[23:03:58] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[23:05:42] *** jediminer543 <jediminer543!57518682@gateway/web/freenode/ip.87.81.134.130> has quit IRC (Quit: Page closed)[23:07:04] *** Nach0z <Nach0z!~nach0z@unaffiliated/nach0z> has quit IRC (Ping timeout: 255 seconds)[23:08:07] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has quit IRC (Quit: Leaving)[23:09:23] *** Nach0z <Nach0z!~nach0z@unaffiliated/nach0z> has joined ##OpenGL[23:09:23] *** Gama11 <Gama11!~quassel@pD9F9867E.dip0.t-ipconnect.de> has joined ##OpenGL[23:11:07] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has quit IRC (Ping timeout: 255 seconds)[23:14:13] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has quit IRC (Remote host closed the connection)[23:25:56] *** mat^2 <mat^2!~Mathias@130.226.161.124> has joined ##OpenGL[23:27:16] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[23:30:54] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[23:32:58] *** SwiftMatt <SwiftMatt!~Objective@162.242.94.232> has joined ##OpenGL[23:35:50] *** Emersont1 <Emersont1!~Emersont1@host109-154-152-120.range109-154.btcentralplus.com> has joined ##OpenGL[23:35:57] <Emersont1> Hi[23:36:21] *** khlorghaal <khlorghaal!~quassel@76-202-65-254.lightspeed.brbnca.sbcglobal.net> has joined ##OpenGL[23:37:07] <Emersont1> Is there an OpenGL extension for either A) creating system dependent shader caches or B) loading an SPIR-V shader to save compilation[23:38:46] <derhass> Emersont1: https://www.opengl.org/registry/specs/ARB/gl_spirv.txt[23:38:50] <derhass> this is for B)[23:39:12] <derhass> if you want A) https://www.opengl.org/registry/specs/ARB/get_program_binary.txt[23:41:54] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has joined ##OpenGL[23:41:59] *** elect <elect!~elect@ip5f5afdd1.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 250 seconds)[23:42:01] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has quit IRC (Client Quit)[23:42:34] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has joined ##OpenGL[23:44:34] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has quit IRC (Ping timeout: 260 seconds)[23:46:05] <Emersont1> derhass: does gl_spirv look like it will become core?[23:46:42] *** DrBenway <DrBenway!~DrBenway@190.18.153.73> has joined ##OpenGL[23:46:52] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has quit IRC (Ping timeout: 240 seconds)[23:46:56] *** Ryp_ <Ryp_!~ryp@gateway/vpn/privateinternetaccess/ryp> has joined ##OpenGL[23:48:55] *** DrGonzo <DrGonzo!~DrBenway@190.18.153.73> has quit IRC (Ping timeout: 255 seconds)[23:49:05] <slime> i don't think loading a spir-v shader will save much compilation time[23:52:06] *** Ploppz <Ploppz!~ploppz@2001:700:303:b:f3ce:ca7c:3834:8e44> has quit IRC (Quit: WeeChat 1.5)[23:54:57] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Ping timeout: 244 seconds)[23:55:26] *** Ryp_ <Ryp_!~ryp@gateway/vpn/privateinternetaccess/ryp> has quit IRC (Ping timeout: 244 seconds)[23:57:10] <Emersont1> Will it not? Is it just the possibility of multiple shading languages that's SPIR-V s main highlight?[23:57:13] *** bjz_ <bjz_!~bjz@104.222.140.46> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[23:59:27] <slime> it's easier for tools to operate on spirv than glsl[23:59:47] <slime> so for example now we have things like https://github.com/KhronosGroup/SPIRV-Cross