September 7, 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 7, 2016 [00:00:59] *** Twey <Twey!~twey@unaffiliated/twey> has quit IRC (Quit: ZNC - http://znc.in)[00:01:34] *** vitimiti <vitimiti!~vitimiti@unaffiliated/vitimiti> has quit IRC (Read error: Connection reset by peer)[00:05:12] <bookmark> Hi. Anyone ever used sphere packing of creature meshes for collision?[00:05:36] <bookmark> like protosphere?[00:05:47] *** _leb <_leb!~leb@pool-108-53-167-179.nwrknj.fios.verizon.net> has joined ##OpenGL[00:06:00] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: leaving)[00:06:38] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has quit IRC (Read error: Connection reset by peer)[00:06:53] *** Mission-Critical <Mission-Critical!~MissionCr@unaffiliated/missioncritical> has joined ##OpenGL[00:07:13] <bookmark> https://www.youtube.com/watch?v=RJedjs8s0rA[00:08:00] <Stragus> bookmark: Seems like you would miss collisions[00:08:18] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##OpenGL[00:08:27] <Stragus> I would suggest making a very crude mesh with the right general shape[00:08:44] <bookmark> enlarge the inner spheres some?[00:08:56] <chrisf> capsules from bones works[00:09:09] <bookmark> i dont know mesh to mesh collisions[00:09:21] <chrisf> but, what problem are you trying to solve really?[00:09:24] <bookmark> only sphere to mesh and ray to mesh[00:09:55] <bookmark> like say i want my player to pick up a sword[00:10:04] *** GarrettShields <GarrettShields!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 255 seconds)[00:10:07] <bookmark> with his hand[00:10:09] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC (Read error: Connection reset by peer)[00:10:35] <bookmark> or walk with his feet up some stairs[00:10:38] <chrisf> so far this is sounding like an IK problem, not a collision problem[00:10:58] <bookmark> i mean i can keep them up right[00:11:07] <bookmark> so they dont fall[00:11:34] <bookmark> https://www.youtube.com/watch?v=-VZRzz2X4Ls[00:11:37] <bookmark> see here[00:12:06] <bookmark> there im using 4 spheres[00:12:47] *** _leb <_leb!~leb@pool-108-53-167-179.nwrknj.fios.verizon.net> has quit IRC (Quit: Computer has gone to sleep.)[00:12:52] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 240 seconds)[00:13:21] *** unreal <unreal!~unreal@unaffiliated/unreal> has quit IRC (Quit: Very funny Scotty. Now beam down my clothes!)[00:13:39] <Stragus> And you would fill a large floor with spheres to detect collisions? Come on...[00:14:11] <Stragus> Ah, you said you know how to do "sphere to mesh"[00:14:27] <Stragus> Might be time to move on to "mesh to mesh" :)[00:14:52] <bookmark> well if one were to enlarge the inner spheres the small ones[00:15:15] <bookmark> and it was a catmull like smooth mesh[00:15:29] <bookmark> darn i dunno[00:16:19] <bookmark> well there could bee an outside mesh[00:16:48] <bookmark> the collisions wouldnt be perfect but its just a game[00:19:44] *** Ploppz <Ploppz!~ploppz@2001:700:303:b:f3ce:ca7c:3834:8e44> has quit IRC (Quit: WeeChat 1.5)[00:19:48] <bookmark> maybe this soft body a mesh in maya fill the mesh with the soft body mesh using particle[00:20:00] <bookmark> bind that mangled mess[00:20:26] <bookmark> then the sphere points wound be bounds to the skeleton[00:21:01] <bookmark> cool?[00:21:47] <chrisf> i think you're down a rabbit hole[00:22:15] <bookmark> well hmm[00:22:35] <bookmark> i dont know anything else to try[00:30:41] *** Ryp <Ryp!~ryp@laf94-4-88-190-202-176.fbxo.proxad.net> has quit IRC (Quit: Konversation terminated!)[00:30:47] <kmnt> bookmark: i think libigl or cgal have sphere packing stuff[00:38:21] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.42.44> has joined ##OpenGL[00:38:58] *** irrenhaus3 <irrenhaus3!~xenon@HSI-KBW-046-005-253-022.hsi8.kabel-badenwuerttemberg.de> has quit IRC (Quit: Lost terminal)[00:42:04] *** michauds <michauds!~michauds@199.91.185.156> has quit IRC (Ping timeout: 240 seconds)[00:42:50] <noizex> hm, I might have created a monstar: https://www.youtube.com/watch?v=ouuGwh53giQ[00:43:15] <noizex> unicorness[00:45:28] *** toor <toor!~toor@80.12.63.145> has quit IRC (Ping timeout: 264 seconds)[00:46:04] *** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined ##OpenGL[00:46:41] <foobaz> wtf[00:47:58] *** Twey <Twey!~twey@unaffiliated/twey> has joined ##OpenGL[00:48:12] <noizex> yeah, that's what my first thought was[00:49:30] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[00:51:49] *** flavi0 <flavi0!~anon@unaffiliated/flavi0> has quit IRC (Quit: leaving)[00:58:10] *** realz <realz!~realz@unaffiliated/realazthat> has joined ##OpenGL[00:59:18] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Read error: Connection reset by peer)[01:00:05] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[01:01:19] *** Birchy <Birchy!~Birchy@178-164-108.52.3p.ntebredband.no> has quit IRC (Ping timeout: 252 seconds)[01:01:27] *** bjz <bjz!~bjz@104.222.140.37> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[01:05:15] *** dubuc <dubuc!84cde53f@gateway/web/freenode/ip.132.205.229.63> has joined ##OpenGL[01:09:21] *** toor <toor!~toor@80.12.63.145> has joined ##OpenGL[01:10:11] *** TheHackOps <TheHackOps!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has joined ##OpenGL[01:10:23] <mudlord> is vector arithmetic by scalars allowed in glsl[01:10:27] <mudlord> or is it just a nvidia hack[01:10:37] <mudlord> for instance "vec3 * float"[01:10:43] <mudlord> or vec3 += float[01:10:52] <foobaz> multiplication, definitely[01:10:57] <foobaz> not sure about addition[01:11:13] <foobaz> but if not, vec3 += vec3(float) would definitely work[01:11:25] <mudlord> yeah, thats what i thought[01:11:28] <foobaz> that's shorthand for vec3(float, float, float)[01:11:35] <mudlord> which is the intent[01:11:43] <mudlord> but i noticed some weird nvidia oddities[01:11:51] <mudlord> like vec3 += float without the cast[01:12:17] <foobaz> it might be defined, check the GLSL spec[01:13:23] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 244 seconds)[01:13:31] *** NotTheFBI <NotTheFBI!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has quit IRC (Ping timeout: 255 seconds)[01:14:27] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has quit IRC (Read error: Connection reset by peer)[01:15:26] *** GarrettShields <GarrettShields!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has joined ##OpenGL[01:15:37] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has joined ##OpenGL[01:15:50] *** Neomex_ <Neomex_!~Neomex@bvs49.neoplus.adsl.tpnet.pl> has quit IRC (Quit: Leaving)[01:17:00] *** bzztploink <bzztploink!~bzztploin@gateway/vpn/privateinternetaccess/bzztploink> has quit IRC (Remote host closed the connection)[01:17:30] *** bzztploink <bzztploink!~bzztploin@gateway/vpn/privateinternetaccess/bzztploink> has joined ##OpenGL[01:18:12] *** BusFactor1 <BusFactor1!~textual@adsk-nat-ip6.autodesk.com> has quit IRC (Ping timeout: 240 seconds)[01:20:09] *** vassagus <vassagus!~vassagus@186.4.2.162> has quit IRC (Remote host closed the connection)[01:21:36] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has joined ##OpenGL[01:22:00] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has quit IRC (Read error: No route to host)[01:22:08] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has quit IRC (Quit: Leaving)[01:24:40] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[01:26:06] *** Lucretia <Lucretia!~laguest@pdpc/supporter/active/lucretia> has joined ##OpenGL[01:27:47] *** ertes <ertes!~never@p5485F2E5.dip0.t-ipconnect.de> has joined ##OpenGL[01:28:32] *** Gama11 <Gama11!~quassel@p57A9A8E5.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)[01:28:51] *** dubuc <dubuc!84cde53f@gateway/web/freenode/ip.132.205.229.63> has quit IRC (Quit: Page closed)[01:30:52] *** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC (Ping timeout: 240 seconds)[01:32:14] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[01:34:23] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.42.44> has quit IRC (Read error: Connection reset by peer)[01:35:00] *** ville <ville!~ville@87-93-83-99.bb.dnainternet.fi> has quit IRC (Quit:)[01:35:25] *** toor <toor!~toor@80.12.63.145> has quit IRC (Ping timeout: 252 seconds)[01:37:59] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 244 seconds)[01:38:24] *** Deadhand <Deadhand!~deadf00t@69-196-158-136.dsl.teksavvy.com> has quit IRC (Quit: Leaving)[01:39:16] *** SwiftMatt <SwiftMatt!~Objective@162.242.95.141> has joined ##OpenGL[01:39:47] *** pril <pril!~userid@unaffiliated/pril> has quit IRC (Ping timeout: 250 seconds)[01:45:22] *** notadeveloper <notadeveloper!~notadevel@2602:306:bd2a:a160:8560:992f:a64e:963a> has joined ##OpenGL[01:47:09] *** ArkaZeen <ArkaZeen!~ArkaZeen@wn-res-nat-129-97-125-28.dynamic.uwaterloo.ca> has quit IRC (Ping timeout: 250 seconds)[01:49:29] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[01:49:40] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has quit IRC (Ping timeout: 264 seconds)[01:56:15] <sadtaco> How does perf compare when you output 8bit>float packed textures, and unpack as needed, versus ouputting 3 or 4 normal RGBA textures? IE, you pack the entire albedo in one float texture channel, normals in another, so on. I would think this is a common question but google doesn't give a result.[01:59:28] <Stragus> Are you asking about sampling one GLRGBA texture versus 4 GL_RED textures?[01:59:40] <Stragus> If not, try reformulating the question[01:59:50] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has joined ##OpenGL[02:01:26] *** GarrettShields <GarrettShields!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has quit IRC (Quit: twitter.com/GarrettShields)[02:02:20] *** unreal <unreal!~unreal@unaffiliated/unreal> has joined ##OpenGL[02:02:28] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has joined ##OpenGL[02:03:18] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 250 seconds)[02:11:50] *** MrFlibble <MrFlibble!MrFlibble@90.220.166.75> has quit IRC (Quit: MrFlibble)[02:13:50] <sadtaco> Yeah I phrased that crappily. I am asking about outputting and sampling 1 GL_RGBA32F texture versus 3 or 4 GL_RGBA textures.[02:14:25] <sadtaco> I say 3 because some hardware seems to only do 24bit precision in the fragment shader even if it supports GL_RGBA32F, if I'm not mistaken.[02:17:13] *** realz_ <realz_!~realz@unaffiliated/realazthat> has joined ##OpenGL[02:17:31] <slime> what hardware?[02:19:07] <foobaz> old AMD[02:19:16] <slime> how old?[02:19:31] <foobaz> HD 3000 series maybe?[02:19:41] <sadtaco> Eh well I'm trying to target as much as I can. I guess what's most important is the lower end hardware, so, say, HD 3000 integrated graphics.[02:20:03] *** realz <realz!~realz@unaffiliated/realazthat> has quit IRC (Ping timeout: 240 seconds)[02:20:04] <slime> i think the hd 3000 will not do well with a 128 bit gbuffer, heh[02:20:58] <sadtaco> Compared to 3 or 4 32bit ones, though?[02:21:12] *** vassagus <vassagus!~vassagus@186.4.2.162> has joined ##OpenGL[02:21:29] <slime> that's still 96 or 128 bits either way[02:21:42] <foobaz> when you say float packed textures, do you mean extracting 3-4 integers from a single float?[02:21:44] <sadtaco> Mhm[02:21:49] <sadtaco> Ye, foobaz.[02:21:50] <foobaz> dpm[02:21:53] <foobaz> oops[02:21:57] <slime> i don't think you'll get acceptable performance on the intel hd 3000 with that kind of gbuffer bandwidth[02:22:03] <foobaz> don't do that, it's bad for performance, and it's not reliable[02:22:04] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-57-173.w90-47.abo.wanadoo.fr> has quit IRC (Ping timeout: 244 seconds)[02:22:05] *** lucaswan_ <lucaswan_!~lucaswang@183.167.211.74> has quit IRC (Remote host closed the connection)[02:22:08] <chrisf> depends how much he hits the gbuffer, i guess.[02:22:22] <foobaz> much better to use separate textures and express to the driver/hardware what you are actually doing[02:22:25] <chrisf> if you care about bit representations, unsigned integer textures.[02:22:50] <chrisf> ~ if you have some reason that you /must/ care.[02:23:04] *** NateRiver <NateRiver!~IceChat9@c148005.net61215.cablenet.ne.jp> has joined ##OpenGL[02:23:12] <foobaz> if you want performance, minimize the amount of data, like see if you can use 4-bit textures[02:23:34] <sadtaco> Hm well I'm currently using a GL_RGBA32F because I do need float vectors in 3 channels. And then I need 2, maybe 3 other values that are er.. 4 bit or less.[02:23:56] <slime> do you really need 32 bit float and 16 bit float just won't work?[02:24:02] <sadtaco> I guess I might not really need 32bits of precision, yeah.[02:24:05] <foobaz> yea try 16-bit float[02:24:46] <slime> also depending on the range of input values, r11g11b10f is a good one[02:24:47] <foobaz> keep in mind that the range of magnitudes only goes from 1/65k - 65k[02:24:52] <slime> for HDR input data[02:25:10] <slime> (it's 32 bits per pixel instead of the 64 bits of rgba16f)[02:25:15] <sadtaco> They are positions and vectors of units. But I don't have a massive sized scene at all.[02:25:15] <foobaz> the maximum value trips me up more often than the precision[02:25:18] <chrisf> or rgb9e5[02:25:35] <sadtaco> Yes my other question was going to be HDR, and to ask if r11g11b10f is a good call to use there.[02:25:39] <slime> chrisf: afaik most drivers don't support rendering to that one, maybe i'm wrong though[02:25:50] <chrisf> slime: yeah, it's trouble.[02:25:51] <foobaz> rgb9e5 has more precision than r11g11b10[02:26:23] <foobaz> also try compressed textures[02:26:33] <slime> (is there any particular reason why drivers don't support it? i know apple recently added support for it on ios)[02:26:33] *** vassagus <vassagus!~vassagus@186.4.2.162> has quit IRC (Ping timeout: 244 seconds)[02:26:50] <sadtaco> but rgb9e5 messes up if you have a scene that's predominantly one color?[02:27:13] <chrisf> slime: a lot of /hw/ cant do it.[02:27:18] <slime> ah[02:28:34] <chrisf> slime: tilers can have a bit of an advantage here, if you're doing the pixel backend in the shader anyway[02:28:38] <sadtaco> Also if I do 32bit floats erm... I'm gonna uh.. well I can't do 255^3 in the A channel. I guess I can fit 255^2 though if I only need that much.[02:28:45] <slime> chrisf: ah, right[02:28:54] <foobaz> if a pixel is red, do you really need that much precision in the green/blue componenets?[02:29:31] <sadtaco> Or er another way to do it would be if I used the RGBA32F but I pack position, vector, velocity, and my extras all in their own channel? Won't an xyz fit in 32bit float, like 8 or 9 bits of precision times 3?[02:29:57] <sadtaco> foobaz, I think so because you can really notice blocky gradients in the dark parts.[02:30:39] <slime> what are you using position and such for?[02:30:39] <sadtaco> Oh wait[02:30:42] <sadtaco> IT's per pixel.. huh[02:30:47] <foobaz> it's more precise than rgba8888[02:30:50] <sadtaco> slime, think like a GPGPU particle system.[02:30:54] <slime> ah[02:31:06] <sadtaco> These are textures for compute.[02:31:36] <chrisf> if it's for compute, are you really winning by using images rather than buffers here?[02:31:37] <slime> well, the intel hd 3000 doesn't support compute shaders[02:31:55] <slime> so you can ditch that as a min spec[02:32:10] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has quit IRC (Quit: stelarcf_)[02:32:19] <sadtaco> chrisf, not sure at the moment. Though I am using GLES 2.0 right now. I'm really not sure if I'd actually get much beneift NOT using textures though. The GPU are good at working with textures.[02:32:40] <slime> and afaik you can rely on floats in shaders being 32 bit precision (even if the actual calculations may take some shortcuts)[02:32:43] <chrisf> sadtaco: you'll have to unwarp your brain from ES2's insanity[02:32:53] <slime> yeah...[02:32:58] <sadtaco> haha well I'm going to go to GLES3.0 or 3.1 in a bit[02:33:13] <foobaz> rgb9e5 is ideal for normals because you don't need precise x or y if the normal is mostly z[02:33:36] <foobaz> eh ES2 isn't that bad, it's better than opengl 2.1 imo[02:34:03] <sadtaco> Hm but the basis of the question is still something I can't figure the answer for. Is 4 textures that are 32bits per pixel each the same overhead as 1 128bit one? I would think it'd be more, because of the additional overhead for making each texture, no?[02:34:04] <slime> how is it better, aside from a reduced api? it has fewer modern features D:[02:34:05] <chrisf> foobaz: o_O it's not that great, the shared exponent isnt buying you much.[02:34:24] <chrisf> foobaz: but good normal encodings are a deep rabbit hole[02:35:10] <chrisf> the simple obvious ways all waste most of the bits[02:36:18] <sadtaco> Why would you not just want 255^3 for normals?[02:37:50] <Stragus> I like 10,10,10,2 for normals. And there's often something to put in these 2 bits of alpha[02:38:13] <foobaz> alpha normals? lol[02:38:22] <sadtaco> something besides the alpha he means[02:39:12] <chrisf> sadtaco: consider how many of the points in that space actually lie /on/ the unit sphere.[02:39:18] <sadtaco> What is your source of normals that's more detailed than 255^3, though? I also feel like the texture size of the normal has to be a way, way bigger deal than the xyz of each texel.[02:39:47] <foobaz> out of curiosity how would you do a fancy non-obvious normal encoding? maybe something based on a map projection?[02:40:05] <chrisf> foobaz: there's some good articles on it, i'll try to dig them out[02:40:44] <foobaz> store 2 components and convert to unit vector with a square map projection like pierce quincuncial?[02:40:50] <Stragus> sadtaco: 8 bits to cover the whole range of -1.0 to 1.0 leads to visible "jumps" on smoothly curved surfaces[02:41:20] <sadtaco> Well yeah but I think that's more to do with your texture resolution.[02:41:38] <sadtaco> I think I'd rather have 30% more texels than 30% more detail per texel.[02:41:59] <chrisf> sadtaco: no, it's quite visible with 8bpc. more texels doesnt save you[02:42:16] <Stragus> sadtaco: That also implies you have something else to store as the alpha channel. RGB textures don't really exist[02:42:31] <Stragus> It's all GL_RED, GL_RG or GL_RGBA once in GPU memory[02:42:56] <sadtaco> What is the source of your textures that you have more than 8bpc to begin with, though? What image format are these on the disk?[02:43:06] <sadtaco> I'm curious[02:43:07] <chrisf> sadtaco: bakes.[02:43:13] *** TheChubu <TheChubu!~TheChubu@190.221.200.203> has joined ##OpenGL[02:43:26] *** realz_ is now known as realz[02:43:33] <sadtaco> What are you baking from that's higher than the 8bpc?[02:43:34] <foobaz> or maybe a larger texture sampled down[02:43:38] <chrisf> and on disk as 10/10/10/2[02:44:05] <sadtaco> What image formats let you save an image as 10/10/10/2? I'm not aware of that side of thing in that detail[02:44:08] <sadtaco> things*[02:44:09] <foobaz> 16-bit image formats are fairly common, deep png and openexr[02:45:40] <chrisf> sadtaco: baking from sculpted meshes, not from hand authored images. and intermediate formats may be all float -- packed to the target format at the end[02:45:54] <sadtaco> Huh. I see.[02:46:23] <chrisf> for gbuffer with world space normals it's more important than for input normal maps[02:46:30] <chrisf> 8/8/8/8 snorm isnt enough[02:46:59] <chrisf> but 10/10/10/2 snorm is a bit better[02:47:18] <sadtaco> You can also do 11,11,10 for normals and swap your z into the g or r for more z detail, isn't that desireable?[02:47:51] <chrisf> there's piles of options[02:47:56] <sadtaco> heh[02:48:29] <chrisf> dont need to store all 3 components either[02:48:32] <sadtaco> I don't think I'll be getting into that much. Doing stylized graphics instead of emulating reality. Don't think I'll even have normals. I might not even have textures at all.[02:49:01] <foobaz> imo 2d with normals and lighting looks amazing[02:49:06] <foobaz> it's a modern yet retro look[02:49:07] <Stragus> 10_11_11 is also quite fine. I tend to favor 10_10_10_2 because it appeared earlier (more common support?), and there's often some extra little bit of data that could use a channel with 2 bits[02:49:20] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[02:49:22] <sadtaco> I'm doing a different type of retro look. Not 2d or 8bit[02:49:28] <sadtaco> For a like.. vector graphics kinda look.[02:51:11] *** Cooler <Cooler!~CoolerExt@117.242.75.238> has joined ##OpenGL[02:54:00] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 250 seconds)[02:54:39] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[02:55:18] *** bookmark <bookmark!~IceChat77@173-169-112-35.res.bhn.net> has quit IRC (Quit: He who laughs last, thinks slowest)[02:55:18] *** glYoda <glYoda!~MTLYoda@c-50-137-137-82.hsd1.or.comcast.net> has quit IRC (Ping timeout: 250 seconds)[02:56:31] *** razieliyo <razieliyo!~razieliyo@unaffiliated/razieliyo> has joined ##OpenGL[02:56:46] *** NotTheFBI <NotTheFBI!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has joined ##OpenGL[03:00:04] *** TheHackOps <TheHackOps!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has quit IRC (Ping timeout: 250 seconds)[03:00:31] *** TheHackOps <TheHackOps!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has joined ##OpenGL[03:02:14] *** NotTheFBI <NotTheFBI!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has quit IRC (Ping timeout: 250 seconds)[03:07:23] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 265 seconds)[03:09:29] *** NotTheFBI <NotTheFBI!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has joined ##OpenGL[03:10:02] *** TheHackOps <TheHackOps!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has quit IRC (Ping timeout: 250 seconds)[03:10:04] *** notadeveloper <notadeveloper!~notadevel@2602:306:bd2a:a160:8560:992f:a64e:963a> has quit IRC (Ping timeout: 264 seconds)[03:22:57] *** leb <leb!~leb@pool-108-53-167-179.nwrknj.fios.verizon.net> has joined ##OpenGL[03:24:46] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[03:30:20] *** leb <leb!~leb@pool-108-53-167-179.nwrknj.fios.verizon.net> has quit IRC (Quit: Computer has gone to sleep.)[03:38:31] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 250 seconds)[03:38:32] *** _leb <_leb!~leb@pool-108-53-167-179.nwrknj.fios.verizon.net> has joined ##OpenGL[03:39:11] *** _leb <_leb!~leb@pool-108-53-167-179.nwrknj.fios.verizon.net> has quit IRC (Max SendQ exceeded)[03:47:27] *** ArkaZeen <ArkaZeen!~ArkaZeen@wn-res-nat-129-97-125-28.dynamic.uwaterloo.ca> has joined ##OpenGL[03:48:19] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has joined ##OpenGL[03:49:27] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[03:51:17] *** Joefish <Joefish!~Joefish@p5B120E35.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 244 seconds)[03:53:06] *** Joefish <Joefish!~Joefish@p5B1218A3.dip0.t-ipconnect.de> has joined ##OpenGL[03:54:56] *** lucaswang <lucaswang!~lucaswang@117.135.159.4> has joined ##OpenGL[03:56:06] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has quit IRC (Ping timeout: 244 seconds)[03:57:46] *** TheChubu <TheChubu!~TheChubu@190.221.200.203> has quit IRC (Quit: WeeChat 1.5)[03:58:07] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has joined ##OpenGL[03:58:20] *** kuma__ <kuma__!~kuma@p8447f1.tokynt01.ap.so-net.ne.jp> has quit IRC (Quit: Lost terminal)[03:59:58] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Read error: Connection reset by peer)[04:00:07] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[04:00:11] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has quit IRC (Quit: ZZZzzz…)[04:00:17] *** glYoda <glYoda!~MTLYoda@c-50-137-137-82.hsd1.or.comcast.net> has joined ##OpenGL[04:01:56] *** lucaswang <lucaswang!~lucaswang@117.135.159.4> has quit IRC (Remote host closed the connection)[04:03:57] *** shingshang <shingshang!~shingshan@115-64-27-246.static.tpgi.com.au> has joined ##OpenGL[04:12:03] *** NateRiver <NateRiver!~IceChat9@c148005.net61215.cablenet.ne.jp> has quit IRC (Ping timeout: 240 seconds)[04:12:10] *** hexagoxel <hexagoxel!~hexagoxel@p200300798F1CFE00021E33FFFE2231E9.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 255 seconds)[04:12:36] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has quit IRC (Quit: nine_milli)[04:13:03] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 240 seconds)[04:16:51] *** FrancoGP <FrancoGP!~quassel@58-7-17-190.fibertel.com.ar> has joined ##OpenGL[04:17:09] *** hexagoxel <hexagoxel!~hexagoxel@p4FCCC599.dip0.t-ipconnect.de> has joined ##OpenGL[04:19:46] *** Twipply <Twipply!~Dunno@cpc1-mapp10-2-0-cust641.12-4.cable.virginm.net> has quit IRC (Quit: Leaving)[04:24:52] *** arescorpio <arescorpio!~arescorpi@154-58-245-190.fibertel.com.ar> has joined ##OpenGL[04:25:04] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[04:28:10] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has quit IRC (Read error: Connection reset by peer)[04:28:37] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has joined ##OpenGL[04:29:45] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 276 seconds)[04:30:44] *** notadeveloper <notadeveloper!~notadevel@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has joined ##OpenGL[04:31:40] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has joined ##OpenGL[04:45:13] *** razieliyo <razieliyo!~razieliyo@unaffiliated/razieliyo> has quit IRC (Ping timeout: 244 seconds)[04:52:22] *** Suchorski <Suchorski!regex@unaffiliated/suchorski> has quit IRC ()[04:54:39] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[04:57:13] *** fqtw_ <fqtw_!~me@x590e17d6.dyn.telefonica.de> has joined ##OpenGL[05:01:07] *** fqtw <fqtw!~me@x590d1eec.dyn.telefonica.de> has quit IRC (Ping timeout: 252 seconds)[05:07:44] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Ping timeout: 265 seconds)[05:10:32] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[05:20:18] *** Cooler <Cooler!~CoolerExt@117.242.75.238> has quit IRC (Ping timeout: 265 seconds)[05:22:43] *** d4ryus <d4ryus!~d4ryus@p54988E45.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 265 seconds)[05:24:46] *** pffffffft <pffffffft!~pffffffft@unaffiliated/pffffffft> has quit IRC (Ping timeout: 252 seconds)[05:25:23] *** d4ryus <d4ryus!~d4ryus@p54988DC9.dip0.t-ipconnect.de> has joined ##OpenGL[05:29:38] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[05:30:20] *** przm <przm!~przm@ool-44c79cfa.dyn.optonline.net> has joined ##OpenGL[05:50:45] *** vassagus <vassagus!~vassagus@186.4.2.162> has joined ##OpenGL[05:54:09] *** d4rkforc1 <d4rkforc1!~darkforce@pdpc/supporter/student/d4rkforce> has joined ##OpenGL[05:55:27] *** vassagus <vassagus!~vassagus@186.4.2.162> has quit IRC (Ping timeout: 250 seconds)[05:57:04] *** d4rkforce <d4rkforce!~darkforce@pdpc/supporter/student/d4rkforce> has quit IRC (Ping timeout: 240 seconds)[06:01:02] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has quit IRC (Quit: nine_milli)[06:01:07] *** NotTheFBI <NotTheFBI!~TheHackOp@dsl-124-150-17-198.vic.westnet.com.au> has quit IRC (Changing host)[06:01:07] *** NotTheFBI <NotTheFBI!~TheHackOp@unaffiliated/thehackops> has joined ##OpenGL[06:01:10] *** NotTheFBI is now known as TheHackOps[06:09:32] *** tambre <tambre!~tambre@8389-33cb-8f43-29d6-a980-8a3e-07d0-2001.dyn.estpak.ee> has joined ##OpenGL[06:15:05] *** arescorpio <arescorpio!~arescorpi@154-58-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 244 seconds)[06:21:51] *** lucaswang <lucaswang!~lucaswang@117.135.159.4> has joined ##OpenGL[06:27:02] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.242.75.238> has joined ##OpenGL[06:33:17] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.242.75.238> has quit IRC (Ping timeout: 265 seconds)[06:33:52] *** TechnoCrunch <TechnoCrunch!~Tech@101.100.137.146> has joined ##OpenGL[06:43:21] *** neure <neure!~tsuorant@a88-112-89-144.elisa-laajakaista.fi> has joined ##OpenGL[06:51:28] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.221.150.24> has joined ##OpenGL[06:57:56] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.221.150.24> has quit IRC (Ping timeout: 265 seconds)[07:09:53] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.221.150.24> has joined ##OpenGL[07:13:24] *** Occulus2057 <Occulus2057!~Alfred@24-113-48-48.wavecable.com> has quit IRC (Quit: Leaving)[07:15:36] *** cam_y <cam_y!~cam_y@162.222.103.203> has joined ##OpenGL[07:16:11] *** FrancoGP <FrancoGP!~quassel@58-7-17-190.fibertel.com.ar> has quit IRC (Remote host closed the connection)[07:16:18] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.221.150.24> has quit IRC (Ping timeout: 265 seconds)[07:17:52] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has joined ##OpenGL[07:24:35] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.221.150.24> has joined ##OpenGL[07:30:48] *** CoolerExtreme <CoolerExtreme!~CoolerExt@117.221.150.24> has quit IRC (Ping timeout: 265 seconds)[07:32:53] *** therue <therue!~therue@1-162-71-124.dynamic.hinet.net> has joined ##OpenGL[07:34:09] *** upgrdman <upgrdman!~upgrdman@blender/artist/upgrdman> has quit IRC (Quit: Leaving)[07:38:33] *** SorcererX <SorcererX!~SorcererX@cm-84.212.210.160.getinternet.no> has joined ##OpenGL[07:41:35] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC (Quit: Bye bye! o/)[07:41:50] *** fqtw_ <fqtw_!~me@x590e17d6.dyn.telefonica.de> has quit IRC (Ping timeout: 265 seconds)[07:42:16] *** Sorcerer1 <Sorcerer1!~SorcererX@2.149.145.73.tmi.telenormobil.no> has joined ##OpenGL[07:43:52] *** notadeveloper <notadeveloper!~notadevel@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has quit IRC (Ping timeout: 240 seconds)[07:47:44] *** therue <therue!~therue@1-162-71-124.dynamic.hinet.net> has left ##OpenGL ("WeeChat 1.5")[08:07:57] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Remote host closed the connection)[08:10:28] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[08:20:30] *** kmnt <kmnt!~k@69.63.37.65> has quit IRC (Ping timeout: 276 seconds)[08:21:23] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##OpenGL[08:24:27] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[08:25:04] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Remote host closed the connection)[08:25:10] *** Zerflag_ <Zerflag_!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[08:26:49] *** Sorcerer1 <Sorcerer1!~SorcererX@2.149.145.73.tmi.telenormobil.no> has quit IRC (Ping timeout: 252 seconds)[08:32:06] *** robot-beethoven <robot-beethoven!~robot-bee@c-73-65-29-166.hsd1.mn.comcast.net> has quit IRC (Quit: leaving)[08:32:24] *** ArkaZeen <ArkaZeen!~ArkaZeen@wn-res-nat-129-97-125-28.dynamic.uwaterloo.ca> has quit IRC (Ping timeout: 260 seconds)[08:34:12] *** iljamal <iljamal!c128f4c5@gateway/web/cgi-irc/kiwiirc.com/ip.193.40.244.197> has quit IRC (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)[08:36:54] *** Zerflag_ <Zerflag_!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Remote host closed the connection)[08:46:34] *** Birchy <Birchy!~Birchy@178.164.108.52> has joined ##OpenGL[08:46:35] *** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined ##OpenGL[08:46:37] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[08:48:16] *** drewbarbs <drewbarbs!~drewbarbs@c-76-26-155-253.hsd1.va.comcast.net> has quit IRC (Ping timeout: 252 seconds)[08:49:06] *** drewbarbs <drewbarbs!~drewbarbs@c-76-26-155-253.hsd1.va.comcast.net> has joined ##OpenGL[08:53:06] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-57-173.w90-47.abo.wanadoo.fr> has joined ##OpenGL[08:57:08] *** fkaa <fkaa!~tundmatu@c83-254-208-131.bredband.comhem.se> has quit IRC (Ping timeout: 250 seconds)[09:02:20] *** lucaswang <lucaswang!~lucaswang@117.135.159.4> has quit IRC (Remote host closed the connection)[09:05:19] *** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has quit IRC (Ping timeout: 252 seconds)[09:05:58] *** SHC <SHC!~quassel@160.202.180.137> has joined ##OpenGL[09:06:49] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has joined ##OpenGL[09:08:22] *** cam_y <cam_y!~cam_y@162.222.103.203> has quit IRC ()[09:09:02] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has joined ##OpenGL[09:09:20] *** fkaa <fkaa!~tundmatu@c83-254-208-131.bredband.comhem.se> has joined ##OpenGL[09:09:42] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has joined ##OpenGL[09:11:12] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has quit IRC (Client Quit)[09:11:43] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has joined ##OpenGL[09:15:25] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has joined ##OpenGL[09:17:40] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[09:24:28] *** Vag <Vag!~Vag@ppp-2-85-242-122.home.otenet.gr> has quit IRC (Ping timeout: 255 seconds)[09:25:03] *** Gama11 <Gama11!~quassel@p57A9A6C3.dip0.t-ipconnect.de> has joined ##OpenGL[09:26:20] *** ravior <ravior!~ravior@2a02:2f0e:c310:10d5:224:d7ff:feb5:311c> has joined ##OpenGL[09:26:42] *** fodil <fodil!935eebe0@gateway/web/freenode/ip.147.94.235.224> has joined ##OpenGL[09:27:49] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has joined ##OpenGL[09:28:04] *** Ploppz <Ploppz!~ploppz@2001:700:303:b:f3ce:ca7c:3834:8e44> has joined ##OpenGL[09:35:01] *** ravior <ravior!~ravior@2a02:2f0e:c310:10d5:224:d7ff:feb5:311c> has quit IRC (Ping timeout: 265 seconds)[09:35:57] *** bookmark <bookmark!~IceChat77@173-169-112-35.res.bhn.net> has joined ##OpenGL[09:36:01] <bookmark> sup[09:36:31] <bookmark> chech this out https://youtu.be/R4qg8PqnbzQ[09:36:41] <bookmark> check[09:37:04] <bookmark> gonna do sphere filling for collisions :D[09:38:44] *** TheHackOps <TheHackOps!~TheHackOp@unaffiliated/thehackops> has quit IRC (Quit: Leaving)[09:39:02] *** ravior <ravior!~ravior@5-13-208-250.residential.rdsnet.ro> has joined ##OpenGL[09:39:11] <bookmark> im gonna replace each spere with a triangle so i can find sphere center in open gl[09:39:54] <bookmark> on the binded mesh[09:40:37] <bookmark> but right now im doing the bending in the vertex shader[09:41:06] <bookmark> its possible do do that with the cpu though isnt it?[09:41:39] <bookmark> to do[09:41:57] <bookmark> sorry im typing one handed[09:42:41] *** fodil <fodil!935eebe0@gateway/web/freenode/ip.147.94.235.224> has quit IRC (Quit: Page closed)[09:44:12] *** ravior <ravior!~ravior@5-13-208-250.residential.rdsnet.ro> has quit IRC (Ping timeout: 265 seconds)[09:44:40] <bookmark> oh ill have to mimic what it does on the gpu[09:45:29] *** SHC_ <SHC_!~quassel@160.202.180.137> has joined ##OpenGL[09:46:03] <bookmark> err.. yeah because i need the results in c++ cpu calculation for collisions not in the glsl for render[09:46:45] *** SHC <SHC!~quassel@160.202.180.137> has quit IRC (Disconnected by services)[09:46:47] *** SHC_ is now known as SHC[09:48:13] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has joined ##OpenGL[09:49:26] *** ravior <ravior!~ravior@5-13-208-250.residential.rdsnet.ro> has joined ##OpenGL[09:51:14] *** ravior <ravior!~ravior@5-13-208-250.residential.rdsnet.ro> has quit IRC (Remote host closed the connection)[09:51:24] *** ravior <ravior!~ravior@2a02:2f0e:c310:10d5:224:d7ff:feb5:311c> has joined ##OpenGL[09:56:17] *** ravior <ravior!~ravior@2a02:2f0e:c310:10d5:224:d7ff:feb5:311c> has quit IRC (Ping timeout: 265 seconds)[09:59:32] *** glYoda <glYoda!~MTLYoda@c-50-137-137-82.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[10:00:05] <bookmark> anyone here?[10:00:21] <bookmark> just wondering[10:02:03] <sadtaco> I should be able to pack 2 16bit floats into a 32bit, shouldn't I?[10:04:24] *** Serpent7776 <Serpent7776!~Serpent77@90-156-68-175.internetia.net.pl> has joined ##OpenGL[10:05:07] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has joined ##OpenGL[10:05:22] <gravitation> Do you strictly need an alpha channel in the color buffer to do transparancy in the style of gl.blendFunc(gl.SRC_ALPHA, gl.ONE_MINUS_SRC_ALPHA)?[10:05:29] <sadtaco> https://www.opengl.org/registry/specs/ARB/shading_language_packing.txt hm I found this[10:05:41] *** GinoManWrx <GinoManWrx!~GinoMan@50.251.53.110> has quit IRC (Read error: Connection reset by peer)[10:06:05] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[10:06:54] *** chirpsal1 <chirpsal1!~Chirps@S0106b81619e91574.ed.shawcable.net> has quit IRC (Ping timeout: 260 seconds)[10:08:09] *** flavi0 <flavi0!~anon@unaffiliated/flavi0> has joined ##OpenGL[10:11:54] *** matavenrath <matavenrath!~matavenra@194.196.8.195> has joined ##OpenGL[10:15:02] <sadtaco> Which is not ES 2.0. But I would think I can make a function that does the same exact thing[10:15:59] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-57-173.w90-47.abo.wanadoo.fr> has quit IRC (Ping timeout: 250 seconds)[10:16:41] *** Beetny <Beetny!~Beetny@14-202-48-200.tpgi.com.au> has joined ##OpenGL[10:17:30] *** bairyn <bairyn!~bairyn@unaffiliated/bob0> has quit IRC (Ping timeout: 276 seconds)[10:23:01] <sadtaco> Why can't I find a function to pack 2 16bit floats into a 32bit float, and unpack? Well I think it'd just be float1 + float2* 65536.0 to pack, right?[10:23:43] <sadtaco> Well really it's 2 32bit floats I need to lower to 16bit and pack, but should be the same.[10:24:08] *** bairyn <bairyn!~bairyn@unaffiliated/bob0> has joined ##OpenGL[10:24:46] *** Curious <Curious!~chatzilla@dslb-188-107-142-250.188.107.pools.vodafone-ip.de> has joined ##OpenGL[10:32:54] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has joined ##OpenGL[10:34:34] *** chirpsal1 <chirpsal1!~Chirps@S0106b81619e91574.ed.shawcable.net> has joined ##OpenGL[10:35:07] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has quit IRC (Ping timeout: 255 seconds)[10:36:34] *** swebb <swebb!~swebb@192.152.130.179> has quit IRC (Ping timeout: 240 seconds)[10:38:13] *** ClaudiusMaximus <ClaudiusMaximus!~claude@unaffiliated/claudiusmaximus> has quit IRC (Quit: hols)[10:40:58] *** ertesx <ertesx!~never@p4FC92A50.dip0.t-ipconnect.de> has joined ##OpenGL[10:44:52] *** ertes <ertes!~never@p5485F2E5.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 264 seconds)[10:51:54] *** razieliyo <razieliyo!~razieliyo@unaffiliated/razieliyo> has joined ##OpenGL[10:53:15] *** swebb <swebb!~swebb@192.152.130.179> has joined ##OpenGL[10:58:53] *** fergal <fergal!~fergal@62.6.144.250> has joined ##OpenGL[11:05:23] *** Vag <Vag!~Vag@ppp-2-85-27-198.home.otenet.gr> has joined ##OpenGL[11:10:04] *** BlackPhoenix <BlackPhoenix!~BlackFox@ip-6317.proline.net.ua> has joined ##OpenGL[11:12:22] *** BlackPhoenix_ <BlackPhoenix_!~BlackFox@ip-6317.proline.net.ua> has joined ##OpenGL[11:13:24] *** BlackFox <BlackFox!~BlackFox@ip-6317.proline.net.ua> has quit IRC (Ping timeout: 276 seconds)[11:16:00] *** BlackPhoenix <BlackPhoenix!~BlackFox@ip-6317.proline.net.ua> has quit IRC (Ping timeout: 276 seconds)[11:17:17] *** ravior <ravior!~ravior@89.121.200.106> has joined ##OpenGL[11:18:14] *** vitimiti <vitimiti!~vitimiti@unaffiliated/vitimiti> has joined ##OpenGL[11:19:32] *** BlackPhoenix_ is now known as BlackFox[11:23:01] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has joined ##OpenGL[11:24:09] *** notadeveloper <notadeveloper!~notadevel@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has joined ##OpenGL[11:24:33] *** xaxxon <xaxxon!~xaxxon@2601:602:9d00:d58b:4d61:1bc:35a5:2d96> has quit IRC (Quit: xaxxon)[11:25:07] *** matavenrath <matavenrath!~matavenra@194.196.8.195> has quit IRC (Quit: Leaving)[11:28:05] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has joined ##OpenGL[11:32:11] *** rleigh <rleigh!~rleigh@unaffiliated/rleigh> has joined ##OpenGL[11:36:57] *** irrenhaus3 <irrenhaus3!~xenon@HSI-KBW-046-005-253-022.hsi8.kabel-badenwuerttemberg.de> has joined ##OpenGL[11:42:07] <elect> in our app there are a lot of gl resource that depends on settings[11:42:24] <elect> like textures, buffers and vertexArrays[11:42:39] <elect> is it bad if I allocate (glGen*) all of them[11:42:50] <elect> and then use it or not?[11:43:05] <elect> are they gonna take space or impact performances?[11:43:44] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has quit IRC (Ping timeout: 260 seconds)[11:44:05] <elect> for example, if I glGen textures, but I am not gonna call any glTexImage/Storage on some of them, they are not going to impact, right?[11:46:05] *** bjz <bjz!~bjz@pa49-185-231-131.pa.vic.optusnet.com.au> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[11:46:59] <elect> or even glBindTexture to say[11:47:44] <exDM69> elect: glGen* doesn't really asllocate anything[11:47:54] <exDM69> it just reserves a "name" (the integer id) for it[11:47:55] <elect> not even a pointer?[11:48:02] <elect> ok[11:48:21] <exDM69> it probably takes a handful of bytes and some clock cycles but that's hardly an issue[11:48:25] <elect> then I'll glGen all at once at begin and then use as needed[11:48:33] <elect> thanks[11:48:57] <exDM69> as long as there isn't billions of them, you're fine[11:49:41] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC (Quit: Bye bye! o/)[11:50:43] <elect> not the case :p[11:53:10] *** vassagus <vassagus!~vassagus@186.4.2.162> has joined ##OpenGL[11:55:59] *** Ploppz <Ploppz!~ploppz@2001:700:303:b:f3ce:ca7c:3834:8e44> has quit IRC (Quit: WeeChat 1.5)[11:57:33] <pa> OT: what's the standard acceleration approach to calculate the minimum distance of a point to a polyline, without having to test every polyline segment?[11:57:55] *** vassagus <vassagus!~vassagus@186.4.2.162> has quit IRC (Ping timeout: 255 seconds)[11:58:49] <exDM69> pa: does your polyline have a lot of segments?[11:59:00] <Codex_> pa: one good approach is to put your polyline to a bounding box, and calc distance to the box.[11:59:03] <pa> exDM69, potentially..[11:59:18] <Codex_> or bounding sphere[11:59:32] <pa> Codex_, but that won't be accurate, right[11:59:34] <pa> ?[11:59:39] <pa> i would still have to refine[11:59:42] <exDM69> pa: I can think of many approaches, but they'd only be beneificial if you have a lot of segments... ie. many thousands[11:59:46] <Codex_> well, you need to switch to real version once you're inside the box[11:59:57] <pa> exDM69, let's say a few thousands[12:00:12] <exDM69> pa: a few thousand... just loop over an array and call it a day[12:00:12] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has quit IRC (Read error: Connection reset by peer)[12:00:15] <pa> Codex_, good point[12:00:29] <Codex_> but it speeds up the access very much everywhere else than near the polyline[12:00:37] <pa> right[12:00:43] <pa> yeah, that's a good idea, thanks[12:00:52] <exDM69> pa: a million or more, when it doesn't change often, use a BSP tree[12:01:53] *** bookmark <bookmark!~IceChat77@173-169-112-35.res.bhn.net> has quit IRC (Quit: Why is the alphabet in that order? Is it because of that song?)[12:02:08] <exDM69> doing a line-point distance is just a few clock cycles... doing it a few thousand times is really cheap... if you care about performance, you should be looking at the number of cache misses (which goes up with acceleration structures)[12:02:24] <pa> hm right[12:02:35] <exDM69> I don't think that adding bounding boxes or circles will help much... it'll only add more arithemtic and branches to your code[12:02:53] <pa> ok i think i won't be clever, and just loop then :)[12:03:01] <pa> i might had an initial bbox test though[12:03:05] <pa> add[12:03:23] <exDM69> yes... do that first and then revisit if it turns out to be too slow (or your polylines too big)[12:03:28] <Codex_> exdm69: it did speed up my shaders enough to make them run 60fps instead of 20fps :)[12:04:11] <Codex_> but I was doing shadertoy like marching distance fields[12:05:29] <exDM69> Codex_: I find that a bit odd... were you using square roots to calculate distance to end point?[12:06:06] <exDM69> hmmmh... that's unavoidable if you want real distance not, "hit/miss" on a threshold[12:06:29] <exDM69> pa: doing it on CPU or GPU?[12:08:05] *** przm <przm!~przm@ool-44c79cfa.dyn.optonline.net> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)[12:14:14] <notadeveloper> did cgfx became spir-v[12:14:20] <notadeveloper> oh nvm[12:14:53] <sadtaco> Is there a way to split a 32bit float into 2 16bit, and reverse, without bitwise operations?[12:15:15] <notadeveloper> float32/2[12:15:20] <notadeveloper> jk[12:15:33] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has joined ##OpenGL[12:15:41] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has joined ##OpenGL[12:15:58] <sadtaco> lol[12:19:15] *** TechnoCrunch <TechnoCrunch!~Tech@101.100.137.146> has quit IRC (Read error: Connection reset by peer)[12:19:26] <pa> exDM69, cpu[12:20:10] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has joined ##OpenGL[12:38:33] *** xissburg <xissburg!~xissburg@unaffiliated/xissburg> has joined ##OpenGL[12:39:07] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[12:41:15] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has joined ##OpenGL[12:42:19] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has quit IRC (Client Quit)[12:42:43] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has joined ##OpenGL[12:44:02] *** SHC_ <SHC_!~quassel@160.202.180.137> has joined ##OpenGL[12:45:18] *** SHC <SHC!~quassel@160.202.180.137> has quit IRC (Disconnected by services)[12:45:20] *** SHC_ is now known as SHC[12:45:43] *** avtolstoy <avtolstoy!~avtolstoy@gateway/vpn/privateinternetaccess/avtolstoy> has quit IRC (Ping timeout: 244 seconds)[12:52:55] *** BearishMushroom <BearishMushroom!~BearishMu@90-231-174-194-no159.tbcn.telia.com> has joined ##OpenGL[12:56:08] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Read error: Connection reset by peer)[12:58:54] *** Cooler <Cooler!~CoolerExt@103.208.235.102> has joined ##OpenGL[12:59:43] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has joined ##OpenGL[13:01:46] *** shakesoda <shakesoda!~shake@celestiaradio/shark/soda> has quit IRC (Quit: how many neps would a nep-nep nep if a nep nep could nep neps?)[13:02:31] *** Nyyuu <Nyyuu!Nyyuu@205.201.154.152> has joined ##OpenGL[13:07:45] *** gareppa <gareppa!~gareppa@151.28.158.45> has joined ##OpenGL[13:20:54] *** SwiftMatt <SwiftMatt!~Objective@162.242.95.141> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[13:21:04] *** mat^2 <mat^2!~Mathias@130.226.161.124> has joined ##OpenGL[13:22:24] *** bjz_ <bjz_!~bjz@104.222.140.64> has joined ##OpenGL[13:23:09] *** bjz <bjz!~bjz@14-201-215-168.tpgi.com.au> has quit IRC (Ping timeout: 265 seconds)[13:25:29] *** fergal <fergal!~fergal@62.6.144.250> has quit IRC (Quit: fergal)[13:35:45] *** vitimiti <vitimiti!~vitimiti@unaffiliated/vitimiti> has quit IRC (Ping timeout: 276 seconds)[13:39:47] *** Hink <Hink!~Hink@hink.me> has quit IRC (Quit: quit from client)[13:40:48] *** Hink <Hink!~Hink@hink.me> has joined ##OpenGL[13:47:33] <flavi0> sadtaco: what are those 2 16 bit floats supposed to contain?[13:49:38] <flavi0> i mean you could just cast the memory address of the float to a short*, and offset that by 2 to get your two 16 bit numbers, then copy them somewhere as floats and again reinterpret that memory as a 4 byte float.[13:49:49] <flavi0> i really don't see the point this could have however.[13:50:06] <flavi0> copy them somewhere as shorts*[13:50:48] <flavi0> also i don't see how this relates to opengl[13:51:29] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has quit IRC (Remote host closed the connection)[13:53:23] *** SHC_ <SHC_!~quassel@160.202.180.137> has joined ##OpenGL[13:53:55] *** vassagus <vassagus!~vassagus@186.4.2.162> has joined ##OpenGL[13:53:57] *** stelarcf_ <stelarcf_!~stelarcf@92.81.115.213> has joined ##OpenGL[13:54:30] *** SHC <SHC!~quassel@160.202.180.137> has quit IRC (Disconnected by services)[13:54:39] *** SHC_ is now known as SHC[13:54:47] *** match_ita <match_ita!~Giovanni@dynamic-adsl-78-14-226-13.clienti.tiscali.it> has joined ##OpenGL[13:58:34] *** vassagus <vassagus!~vassagus@186.4.2.162> has quit IRC (Ping timeout: 240 seconds)[13:59:14] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[14:02:20] <match_ita> hi all, something strange happens to my app. I'm using FBO and each call I bind data to display. The problem is the application starts displayng something for some frames( less then a second in time) and then it disappear[14:02:33] <match_ita> some idea on what a problem could be ?[14:03:22] <exDM69> a bug in your app?[14:03:39] <match_ita> I give no error[14:03:50] <match_ita> no error from glGetError[14:03:52] <exDM69> you're probably using the textures and framebuffers incorrectly[14:04:05] <exDM69> glGetError doesn't tell you if you're doing something stupid[14:04:20] <match_ita> I disabled framebuffer in order to test[14:04:43] <exDM69> try building a smaller test case, or desribe your application better[14:04:52] <match_ita> for textures I can try disabling bind, but shaders are flat , so don't use texture for the moment[14:04:54] <exDM69> given what you just said, it's impossible to guess what's going on[14:05:03] <Codex_> match_ita: are you allocating new fbo every frame? (you shouldn't do that :-)[14:05:07] *** Twipply <Twipply!~Dunno@cpc1-mapp10-2-0-cust641.12-4.cable.virginm.net> has joined ##OpenGL[14:05:18] <exDM69> match_ita: you can e.g. try to use glGetTexImage to read back the texture data[14:05:20] <match_ita> fbo are excluded[14:05:42] <match_ita> just a while I try exclude textures[14:06:02] <exDM69> also, check for the obvious texturing mistakes: forgetting to set MIN/MAG filters, etc[14:08:38] *** GinoManWorks <GinoManWorks!~GinoMan@50.251.53.110> has joined ##OpenGL[14:09:21] *** GinoManWorks <GinoManWorks!~GinoMan@50.251.53.110> has quit IRC (Max SendQ exceeded)[14:10:16] *** GinoManWorks <GinoManWorks!~GinoMan@50.251.53.110> has joined ##OpenGL[14:10:49] <grim002> match_ita: it could be memory corruption from not using proper synchronization[14:13:32] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has quit IRC (Ping timeout: 240 seconds)[14:21:33] *** Gamecubic <Gamecubic!~Gamecubic@modemcable022.28-20-96.mc.videotron.ca> has joined ##OpenGL[14:21:36] *** DarkUranium <DarkUranium!~DarkUrani@77.38.70.76> has joined ##OpenGL[14:21:38] <DarkUranium> hey[14:21:51] <DarkUranium> is glVertexAttribDivisor a 3.2 or 3.3 feature?[14:22:01] <DarkUranium> because the docs' table says 3.2, but "Notes" says 3.3: https://www.opengl.org/sdk/docs/man/html/glVertexAttribDivisor.xhtml[14:22:22] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[14:25:18] *** wolfcub <wolfcub!~henrique_@177.131.171.202> has joined ##OpenGL[14:25:29] <karalaine> DarkUranium, 3.3, its not in 3.2 spec[14:25:38] <DarkUranium> karalaine, okay, thanks.[14:25:45] <DarkUranium> karalaine, and I suppose someone should fix the table then-.[14:27:17] *** gareppa <gareppa!~gareppa@151.28.158.45> has quit IRC (Quit: Leaving)[14:27:22] <exDM69> are there platforms where you have only 3.2 but not 3.3?[14:27:40] <karalaine> yeah no idea where one would report bug in doc pages[14:28:25] <DarkUranium> exDM69, some Intel ones, IIRC.[14:28:27] <DarkUranium> but not sure.[14:28:33] <exDM69> pretty sure that isn't the cae[14:28:35] <exDM69> case[14:28:42] <exDM69> at least on linux[14:29:07] <exDM69> I would be concerned about apple platforms[14:29:20] <DarkUranium> or maybe the DeathStation 9000![14:29:21] <match_ita> I have to say sorry to you all because the problem was the mvp matrix. sigh :([14:29:43] <match_ita> thanks thanks a lot[14:30:17] <DarkUranium> exDM69, I wouldn't be surprised if there's trouble there.[14:30:20] <DarkUranium> was mostly just wondering, though.[14:30:41] <exDM69> DarkUranium: don't be overly pedantic about OpenGL (minor) versions[14:30:45] <exDM69> that's pretty useless[14:31:04] <DarkUranium> well, I had to worry about it about ... was it a year ago? dunno.[14:31:08] <DarkUranium> because Mesa only went up to 3.1.[14:31:38] <DarkUranium> also, I'd argue the differences between, say, 4.1 and 4.5 are quite huge.[14:31:56] <exDM69> it's just not very practical to nitpick about the version numbers... you're going to have to test on different platforms if you really care about portability[14:32:22] <exDM69> sometimes a version isn't supported because of a hardware restriction, but a lot of the functionality is available via extensions[14:32:46] <exDM69> the few most recent GL versions are a bit more problematic, not every platform is on GL 4.5 yet[14:33:33] <exDM69> and then there's apple, who've pretty much neglected opengl in favor of metal[14:35:26] <karalaine> nVidia seems to have released couple of extension which required new enough hardware, i.e my OpenGL4.5 capable GTX660ti doesnt support them[14:35:50] <karalaine> so they are practically unusable[14:35:55] <exDM69> sparse textures, etc?[14:37:39] *** fergal <fergal!~fergal@62.6.144.250> has joined ##OpenGL[14:37:55] *** fergal <fergal!~fergal@62.6.144.250> has quit IRC (Remote host closed the connection)[14:38:03] <notadeveloper> are they phasing out opengl[14:38:29] <notadeveloper> cause i want to learn 2 drawing apis[14:38:37] <karalaine> no[14:38:45] <exDM69> notadeveloper: depends on what you mean by "phasing out"[14:38:47] <karalaine> they just give extensions for new hardware features[14:38:49] <notadeveloper> ites ither opengl n vulkan or direct x and vulkan[14:38:54] <exDM69> notadeveloper: it'll remain to be supported for years[14:39:04] <exDM69> notadeveloper: but it's unlikely that there will be new versions of opengl[14:39:30] <karalaine> exDM69, I dont recall if sparse textures was one of them, I was running these https://github.com/NVIDIAGameWorks/GraphicsSamples[14:39:31] <exDM69> learning a graphics API now? don't learn opengl...[14:39:47] *** Hogofwar_ is now known as Hogofwar[14:39:59] <exDM69> notadeveloper: just getting started with computer graphics? learn to use a 3d engine (unity or whatever) first and then get into low level APIs if you _need_ to[14:40:08] <karalaine> basically anything under maxwell folder didnt run with my gpu[14:40:18] <exDM69> karalaine: but that's not surprising, is it?[14:40:24] <karalaine> nah[14:40:26] <exDM69> karalaine: you have a kepler, which is older than maxwell[14:40:47] <exDM69> and a low-end kepler, which might not even have all the goodies of the high-end ones (not sure about that particular generation)[14:41:02] <notadeveloper> thanks[14:41:42] <karalaine> true[14:42:51] *** ArkaZeen <ArkaZeen!~ArkaZeen@wn-res-nat-129-97-125-27.dynamic.uwaterloo.ca> has joined ##OpenGL[14:43:04] <exDM69> notadeveloper: it all depends on what you want to be doing...[14:43:33] <DarkUranium> exDM69, on that note, is there a difference features-wise between 960 and 970?[14:43:44] <DarkUranium> exDM69, because EVGA swapped my 770 for a 960 for warranty -_-[14:44:25] <exDM69> DarkUranium: I don't think so... there were big differences in the 7xx series, basically the 750 was a laptop chip on a PCI-e card[14:45:00] <exDM69> but really, don't ask me, I don't keep up with the graphics features in gaming gpus[14:47:12] *** Beetny <Beetny!~Beetny@14-202-48-200.tpgi.com.au> has quit IRC (Ping timeout: 240 seconds)[14:47:15] *** tristanseifert <tristanseifert!~tristanse@128.194.3.4> has quit IRC (Ping timeout: 250 seconds)[14:50:27] <notadeveloper> i just want to learn and program[14:50:45] *** zerd <zerd!~quassel@bat.slash.no> has quit IRC (Ping timeout: 244 seconds)[14:50:51] <exDM69> but what did you intend to make?[14:51:03] <exDM69> if you want to make a game, learn a 3d engine[14:51:41] <exDM69> if you're just getting started in 3d graphics, ditto. the low level graphics APIs have a lot of complexity that will hinder your learning process. You gotta learn 3d maths, etc[14:52:14] <exDM69> if you already have some 3d graphics knowledge and want to get into GPU programming, then Vulkan or OpenGL might be a good choice[14:53:18] <notadeveloper> i guess i wanna learn 3d graphics[14:53:28] *** Ad1_RN <Ad1_RN!~Ad1_RnR@88-199-45-84.matcom.com.pl> has joined ##OpenGL[14:53:41] <exDM69> perhaps try out unity? or hack with the blender game engine?[14:53:59] <exDM69> learn the math and the principles first... opengl is a lot of complexity to tackle as a newbie[14:54:35] <notadeveloper> ok how do i make opengl apps?[14:54:46] <notadeveloper> can blender do that[14:54:54] <exDM69> blender *is* an opengl app[14:55:00] <exDM69> that contains a whole game engine[14:55:13] <notadeveloper> ok[14:55:19] <notadeveloper> but its not hello world[14:55:22] *** tristanseifert <tristanseifert!~tristanse@nat-165-91-12-37.tamulink.tamu.edu> has joined ##OpenGL[14:55:29] <exDM69> making "opengl apps" is not a good way to get started with 3d graphics, but if you insist... go to the opengl.org wiki and read the tutorials in the channel topic[14:55:45] <exDM69> and get a book on 3d graphics...[14:55:57] <notadeveloper> just kidding[14:56:08] <exDM69> the 3d APIs come and go, but the principles of 3d graphics remain the same[14:56:14] <notadeveloper> i have my rumblings with opengl already[14:56:30] <notadeveloper> but i guess my obession answered my question[14:56:42] <notadeveloper> i want crossplatform drawing api[14:56:51] <notadeveloper> opengl and vulkan are[14:56:55] <notadeveloper> direct x is not[14:57:19] <exDM69> well opengl is pretty low level... it basically just draws triangles... lots of triangles, and very quickly[14:57:27] <notadeveloper> i am also concerned if opengl will be phased out[14:57:43] <exDM69> it will remain supported but it's pretty much end-of-life now[14:57:45] <notadeveloper> how many triangles are there in hello world[14:57:50] <karalaine> sadly ther isnt up to date api atm what would cover all thee major platforms[14:57:56] <exDM69> usually 1 triangle in hello world :P[14:58:09] <karalaine> *three[14:58:11] <notadeveloper> oh yes you got me there[14:58:12] <exDM69> karalaine: apple doesn't want your apps :P[14:58:28] <karalaine> seems so[14:58:32] <exDM69> "three major platforms" would be windows, android and iOS these days... so you're right, it's 2/3[14:58:36] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has quit IRC (Read error: Connection reset by peer)[14:59:41] *** elect_ <elect_!~elect@ip5f5afe4d.dynamic.kabel-deutschland.de> has joined ##OpenGL[15:07:49] *** elect_ <elect_!~elect@ip5f5afe4d.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 255 seconds)[15:08:14] *** Xeronate <Xeronate!~Xeronate@rrcs-74-62-109-222.west.biz.rr.com> has joined ##OpenGL[15:08:26] *** realz <realz!~realz@unaffiliated/realazthat> has quit IRC (Ping timeout: 265 seconds)[15:16:19] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has joined ##OpenGL[15:17:50] *** Codex_ <Codex_!~terop@91-157-91-164.elisa-laajakaista.fi> has joined ##OpenGL[15:18:02] *** avtolstoy <avtolstoy!~avtolstoy@gateway/vpn/privateinternetaccess/avtolstoy> has joined ##OpenGL[15:18:11] *** GarrettShields <GarrettShields!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has joined ##OpenGL[15:19:19] *** Neomex <Neomex!~Neomex@brg31.neoplus.adsl.tpnet.pl> has joined ##OpenGL[15:25:25] *** zerd <zerd!~quassel@bat.slash.no> has joined ##OpenGL[15:27:17] <notadeveloper> wow glsl is a low level glorius look editor[15:27:18] <notadeveloper> lol[15:28:05] <groton> i am not up to date, what do you mean by “OpenGL is end-of-life” ?[15:28:25] <exDM69> groton: that it's very unlikely that it'll get any new versions[15:28:44] <exDM69> but it'll be supported for years (if not decades) to com[15:30:15] <groton> that would mean that either there is nothing new to add, or either something new is going to be used instead of OGL… which one?[15:33:09] <derhass> exDM69: I wouldn't think it that unlikely at all[15:34:00] <exDM69> derhass: I'll buy you a beer if there will be OpenGL 4.6[15:34:10] <exDM69> a few new extensions, perhaps?[15:35:10] <exDM69> but it's a lot of work to actually specify a new API version with conformance tests and all... and most of the effort is going to Vulkan now[15:36:13] <Codex_> I'm sure they'll come up with opengl-to-vulkan conversion library.. :-)[15:36:14] <derhass> exDM69: I will remind you when the time comes[15:36:35] <exDM69> Codex_: I'd hope so too, but so far I have not heard of anyone taking on such an effort[15:37:23] <exDM69> if a conformant OpenGL-on-Vulkan implementation would be out, it would (sooner or later) free up resources from OpenGL driver development[15:37:33] <Curious> Vulkan is the future ofc[15:37:39] <Codex_> yeah, but the libs will only come publicly available once they're pretty much finished and stable.[15:38:22] <zgreg> Codex_: you mean GL-on-Vulkan?[15:38:27] <exDM69> actually, the most useful thing would be to have a new MESA backend on top of vulkan[15:38:33] <Codex_> zgreg: yup[15:38:45] <exDM69> Codex_: who are the "they" you're referring to?[15:39:07] <Codex_> exdm69: the libs[15:39:23] <zgreg> btw, what happened to Vulkan on OSX? nothing, right?[15:39:31] <exDM69> zgreg: apple decided not to have it[15:39:55] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[15:40:02] <exDM69> lots of FUDding from them behind the scenes[15:40:04] <zgreg> I know, and they haven't budged yet?[15:40:19] <zgreg> Metal seems to be a bit inferior, in terms of feature set...[15:40:21] <exDM69> they've pretty much abandoned all interaction with khronos it seems[15:41:06] *** Mysoft <Mysoft!~user@unaffiliated/mysoft> has quit IRC (Disconnected by services)[15:41:06] *** Mysoft[Ware] <Mysoft[Ware]!~user@201-35-195-58.bnut3703.dsl.brasiltelecom.net.br> has joined ##OpenGL[15:41:08] *** Mysoft[Ware] is now known as Mysoft[15:41:10] *** Mysoft <Mysoft!~user@201-35-195-58.bnut3703.dsl.brasiltelecom.net.br> has quit IRC (Changing host)[15:41:10] *** Mysoft <Mysoft!~user@unaffiliated/mysoft> has joined ##OpenGL[15:41:19] <zgreg> and of course, they are completely alone with Metal. MS can pull this because of sheer market domination and games... but Apple? I don't think so.[15:42:01] <zgreg> also, I don't know about the 3D API used by XB1, but I suppose it's quite similar to DX12[15:42:06] <Curious> Vulkan isn't supported on browsers either, WebGL is and will be used for that[15:42:18] <exDM69> games are already primiarly windows... I don't think they see a value in trying to compete[15:42:28] <Curious> XB1 should be DX12[15:42:34] <zgreg> exDM69: what about mobile games?[15:43:07] <exDM69> zgreg: not super valuable to them I guess[15:43:08] <Curious> Vulkan will be used for demanding 3D mobile games[15:43:10] <zgreg> they aren't competing with MS in that area, but with Google - and Android supports Vulkan now[15:43:20] <Curious> Vulkan is pretty damn good for mobile[15:43:33] <zgreg> yeah, saves power[15:44:24] <exDM69> it's just that the highest grossing mobile games are not at all graphically demanding[15:44:55] <zgreg> that's true, of course. could be that GLES is still good enough for most mobile games[15:44:58] <exDM69> and will probably never be, because of the power consumption[15:46:48] <zgreg> it's quite sad how bad 3D API support is on OSX/iOS[15:47:12] <zgreg> the OSX GL implementation seems to be slowly bitrotting away[15:47:28] <exDM69> yes, but it seems to be a deliberate choice from them[15:47:40] <zgreg> Metal can't comepete and doesn't have a full featureset[15:48:03] <exDM69> well they're not shipping fully featured GPUs in their products either[15:48:10] <zgreg> huh?[15:48:18] <exDM69> apart from the pro workstation products[15:48:33] <exDM69> they've been using intel-only mostly for years[15:48:52] *** fqtw_ <fqtw_!~me@x590c726e.dyn.telefonica.de> has joined ##OpenGL[15:49:00] <zgreg> Intel GPUs have full hardware support suitable for GL 4.5, Vulkan and DX12[15:49:15] <zgreg> and Iris isn't that bad in terms of performance either[15:50:35] *** lucaswang <lucaswang!~lucaswang@183.167.211.74> has joined ##OpenGL[15:52:05] *** michauds <michauds!~michauds@199.91.185.156> has joined ##OpenGL[15:52:54] *** kmnt <kmnt!~k@69.63.37.65> has joined ##OpenGL[15:54:39] *** vassagus <vassagus!~vassagus@186.4.2.162> has joined ##OpenGL[15:56:53] <btipling> what would be the problem in my perspective projection math if further away is larger than closer[15:56:56] <btipling> hrmmm[15:57:18] <zgreg> oh GLES is also stuck at 3.0 on iOS[15:57:56] <exDM69> btipling: Z is inverted?[15:57:56] <zgreg> I seriously wonder if apple wants to make itself irrelevant[15:58:04] <btipling> zgreg I use metal[15:58:14] <btipling> it's not irrelevant, it's just not opengl[15:58:25] <btipling> exDM69 let me try that thanks[15:58:39] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has quit IRC (Ping timeout: 260 seconds)[15:59:11] *** vassagus <vassagus!~vassagus@186.4.2.162> has quit IRC (Ping timeout: 250 seconds)[15:59:33] <zgreg> btipling: I'm not saying that metal is irrelevant, but putting all stakes on an unpopular, unfinished API that is only supported by a single vendor without much market force isn't really a good idea[15:59:51] <btipling> in what regard is metal unfinished[16:00:12] *** notadeveloper <notadeveloper!~notadevel@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has quit IRC (Ping timeout: 240 seconds)[16:00:21] <karalaine> like Apple would care what others do or use :)[16:00:22] *** notadeveloper_ <notadeveloper_!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[16:01:11] <zgreg> btipling: some obvious, big feature are missing, e.g. tessellation and geometry shaders and several smaller things[16:01:42] <btipling> zgreg: https://developer.apple.com/library/prerelease/content/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Tessellation/Tessellation.html[16:02:41] <karalaine> only bleeding edge iPhones it seems[16:02:47] <karalaine> 6S and SE[16:02:55] <zgreg> btipling: oh. so they finally delivered it...[16:03:00] <btipling> like a year ago[16:03:05] <exDM69> the first version of Metal was almost a GLES2 feature set[16:03:54] <btipling> zgreg if you're interested in chatting about metal more there's #MetalGL :P[16:04:03] <karalaine> in other hand, tessalation was ES 3.1 so not so wide spead in GL world either[16:04:19] <zgreg> btipling: err, it appeared in OSX 10.12 accoding to apple's documentation... which was released... 2 days ago[16:04:24] <btipling> oh[16:04:34] <btipling> ok[16:04:36] <zgreg> nope, a week ago actuall,y, sorry[16:05:18] <karalaine> and upcoming iOS 10[16:05:36] <zgreg> yeah[16:05:55] <zgreg> so much for "a year ago"... it's still basically unreleased on iOS[16:06:24] <btipling> yes I was mistaken about a year ago, I guess you can just be angry if you want to be[16:07:55] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has joined ##OpenGL[16:07:58] <btipling> I don't think z is inverted[16:08:12] <btipling> so weird[16:08:25] <exDM69> btipling: check your projection matrix then[16:08:35] <zgreg> btipling: i'm just angry that apple unnecessarily fragments the GPU API "market"[16:08:36] <btipling> yes that's what I've been looking at[16:08:49] <btipling> apple does what's in apple's best interest[16:09:13] <btipling> anyway I like metal, it's similar to opengl[16:09:18] <zgreg> btipling: right, but that's often not in the best interest of users and developers[16:09:19] <btipling> I read opengl docs and it helps me with metal[16:09:43] <zgreg> apple also doesn't really indicate what their plans are[16:09:54] <zgreg> so you are SOL as a user or developer[16:10:03] <btipling> maybe you just want to focus on android then[16:12:17] <zgreg> well, if you use Vulkan or GL, you can use whatever platform you want and just ignore OSX/iOS. and that is fine.[16:13:35] <zgreg> I mean, OSX was never big with games, but with the focus on Metal, that'll probably decline further[16:14:13] <btipling> https://i.imgur.com/r6bhTEk.png[16:14:15] <Drakon> why did they chose to implement something new rather than adopting an existing and well used library?[16:14:21] <Drakon> what's in it for them?[16:14:23] <btipling> yeah probably something wrong with the perspective matrix[16:14:40] <btipling> I'm going to do the math by hand and try to figure that out :<[16:15:01] *** delicado <delicado!~delicado@112.198.82.88> has joined ##OpenGL[16:15:28] <zgreg> Drakon: metal was basically developed in parallel to vulkan. so it didn't start as a copycat of some other API.[16:16:09] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[16:16:43] <btipling> I suspect what's in it for apple is having one less thing that limits how they develop core features, iOS and os x/mac os use metal for the operating system level hard ware accelerated animations[16:16:51] *** ragecryx <ragecryx!~ragecryx@178.128.204.72.dsl.dyn.forthnet.gr> has joined ##OpenGL[16:16:52] <btipling> and they probably wanted to do that with their own technology that they control[16:16:55] <btipling> instead of an open standard[16:17:10] <btipling> and because os x is big for games, they decided they don't care[16:17:14] <btipling> is not big*[16:17:17] <Drakon> sounds reasonable[16:18:34] <btipling> most gaming engines will support metal anyway, and big publishers will also[16:18:45] <zgreg> compositing is simple stuff, though. you don't really need a new fancy API for that. GLES2 is mostly enough. CPU overhead and things like that don't matter because there are very few draw calls.[16:18:52] <btipling> it's just cross platform indie game devs who get screwed[16:19:05] <btipling> which is a tiny number of people and not likely to dictate apple's decisions[16:19:12] *** hexagoxel_ <hexagoxel_!~hexagoxel@p200300798F1B6300021E33FFFE2231E9.dip0.t-ipconnect.de> has joined ##OpenGL[16:19:12] *** n0n_ <n0n_!~n0n@2a03:b0c0:2:d0::25a:5001> has joined ##OpenGL[16:19:44] <Drakon> i dunno, it seems to me that half the stuff out on steam is indie stuff atm[16:19:51] <zgreg> btipling: sure about that? various games are already supporting Vulkan, even though the API is very young. Metal was published quite a bit earlier but hasn't seen much support in big-name games yet.[16:20:04] <btipling> no I'm not sure, I'm just conjecturing[16:20:27] <btipling> I think supporting vulkan and modern opengl would be cool[16:20:32] <zgreg> UE4 had a Metal port for some time, but looks like it disappeared again?[16:20:34] *** kmnt <kmnt!~k@69.63.37.65> has quit IRC (*.net *.split)[16:20:34] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC (*.net *.split)[16:20:34] *** Vag <Vag!~Vag@ppp-2-85-27-198.home.otenet.gr> has quit IRC (*.net *.split)[16:20:34] *** neure <neure!~tsuorant@a88-112-89-144.elisa-laajakaista.fi> has quit IRC (*.net *.split)[16:20:34] *** hexagoxel <hexagoxel!~hexagoxel@p4FCCC599.dip0.t-ipconnect.de> has quit IRC (*.net *.split)[16:20:34] *** shingshang <shingshang!~shingshan@115-64-27-246.static.tpgi.com.au> has quit IRC (*.net *.split)[16:20:34] *** Defaultti <Defaultti!defaultti@lakka.kapsi.fi> has quit IRC (*.net *.split)[16:20:34] *** idontcarebear <idontcarebear!~idontcare@50.35.14.24> has quit IRC (*.net *.split)[16:20:34] *** n0n <n0n!~n0n@furiten.club> has quit IRC (*.net *.split)[16:20:34] *** spjoe <spjoe!~spjoe@vserver1877.vserver-on.de> has quit IRC (*.net *.split)[16:20:34] *** begui <begui!~bj@104-136-35-54.res.bhn.net> has quit IRC (*.net *.split)[16:20:34] *** microcol1nel <microcol1nel!~aaron@marumie.magnifi.ca> has quit IRC (*.net *.split)[16:20:34] *** haasn <haasn!~haasn@haasn.xyz> has quit IRC (*.net *.split)[16:20:34] *** decltype <decltype!~decltype@decltype.org> has quit IRC (*.net *.split)[16:20:34] *** dawik <dawik!~davve@bsd.douchedata.com> has quit IRC (*.net *.split)[16:20:34] *** dreda <dreda!~elmindred@h-187-22.a213.priv.bahnhof.se> has quit IRC (*.net *.split)[16:20:35] *** zoktar <zoktar!~zoktar@unaffiliated/zoktar> has quit IRC (*.net *.split)[16:20:35] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (*.net *.split)[16:20:35] *** hadjiszs_ <hadjiszs_!~hadjiszs@ns348042.ip-5-39-92.eu> has quit IRC (*.net *.split)[16:20:35] *** hexagoxel_ is now known as hexagoxel[16:20:41] <btipling> but that's not the reality we live in and it's beyond my control[16:22:04] <zgreg> either one would be fine, I guess... >([16:22:38] <zgreg> also: of course I dislike Metal because the name is a shameless copy from the early days... remember s3 metal? :)[16:22:53] *** SrPx <SrPx!b3d23a8a@gateway/web/freenode/ip.179.210.58.138> has joined ##OpenGL[16:22:58] <zgreg> it was s3's low level API, back in 1997[16:23:06] <SrPx> Is there any reliable way to do int modulus on ES 2.0?[16:23:50] *** haasn <haasn!~haasn@haasn.xyz> has joined ##OpenGL[16:23:52] <SrPx> casting to float gives wrong results in some cases, can't implement with a `while` because of non-constant loop index...[16:24:17] <zgreg> SrPx: GLES2 doesn't guarantee real integers anyway[16:24:34] <SrPx> what[16:25:02] <zgreg> SrPx: that's right, integers in GLES2 are mostly provided for convenience and may map to floats or something else[16:25:15] *** Folkol <Folkol!~Folkol@h-160-222.a137.corp.bahnhof.se> has joined ##OpenGL[16:25:23] <zgreg> SrPx: of course, some GLES2 provides actual integers... some doesn't[16:25:29] <zgreg> *GLES2 hardware[16:27:10] <btipling> that's kind of weird[16:27:21] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has quit IRC (Ping timeout: 276 seconds)[16:27:35] <zgreg> http://pastebin.com/raw/cHjJC8gF[16:28:02] <btipling> oh in the shader[16:28:06] <zgreg> yeah, sure[16:29:14] *** SrPx <SrPx!b3d23a8a@gateway/web/freenode/ip.179.210.58.138> has quit IRC (Ping timeout: 264 seconds)[16:29:18] <btipling> I wish I had time to figure out my perspective projection math problem, but now I have to go get ready for my work :<[16:29:27] <btipling> too much talking about metal :P[16:29:28] <zgreg> SrPx: about modulus, well what do you expect and what doesn't work? isn't not clearly defined how a modulus operator is supposed to work[16:30:06] <zgreg> specifically how to handle negative numbers[16:31:09] *** Th30n <Th30n!~Th30n@78-0-224-255.adsl.net.t-com.hr> has joined ##OpenGL[16:34:30] *** tristanseifert <tristanseifert!~tristanse@nat-165-91-12-37.tamulink.tamu.edu> has quit IRC (Ping timeout: 276 seconds)[16:36:01] *** GarrettShields <GarrettShields!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 255 seconds)[16:38:28] *** nimitz <nimitz!~ztimin@45.73.33.29> has joined ##OpenGL[16:39:00] *** nimitz <nimitz!~ztimin@45.73.33.29> has left ##OpenGL[16:40:40] *** Defaultti <Defaultti!defaultti@lakka.kapsi.fi> has joined ##OpenGL[16:41:11] *** karab44 <karab44!~karab44@unaffiliated/karab44> has joined ##OpenGL[16:42:14] *** neure <neure!~tsuorant@a88-112-89-144.elisa-laajakaista.fi> has joined ##OpenGL[16:42:14] *** decltype <decltype!~decltype@decltype.org> has joined ##OpenGL[16:42:14] *** kmnt <kmnt!~k@69.63.37.65> has joined ##OpenGL[16:42:14] *** Vag <Vag!~Vag@ppp-2-85-27-198.home.otenet.gr> has joined ##OpenGL[16:42:14] *** shingshang <shingshang!~shingshan@115-64-27-246.static.tpgi.com.au> has joined ##OpenGL[16:42:14] *** idontcarebear <idontcarebear!~idontcare@50.35.14.24> has joined ##OpenGL[16:42:14] *** spjoe <spjoe!~spjoe@vserver1877.vserver-on.de> has joined ##OpenGL[16:42:14] *** begui <begui!~bj@104-136-35-54.res.bhn.net> has joined ##OpenGL[16:42:14] *** microcol1nel <microcol1nel!~aaron@marumie.magnifi.ca> has joined ##OpenGL[16:42:14] *** dawik <dawik!~davve@bsd.douchedata.com> has joined ##OpenGL[16:42:14] *** dreda <dreda!~elmindred@h-187-22.a213.priv.bahnhof.se> has joined ##OpenGL[16:42:14] *** zoktar <zoktar!~zoktar@unaffiliated/zoktar> has joined ##OpenGL[16:42:14] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##OpenGL[16:42:14] *** hadjiszs_ <hadjiszs_!~hadjiszs@ns348042.ip-5-39-92.eu> has joined ##OpenGL[16:42:31] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[16:45:07] *** notadeveloper_ <notadeveloper_!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Ping timeout: 250 seconds)[16:48:17] *** seangrove <seangrove!~user@c-50-174-77-118.hsd1.ca.comcast.net> has joined ##OpenGL[16:49:55] *** monsterjamp <monsterjamp!uid156866@gateway/web/irccloud.com/x-cugixtmhfxyzrlge> has joined ##OpenGL[16:51:39] *** BusFactor1 <BusFactor1!~textual@S0106a0639172137a.cg.shawcable.net> has joined ##OpenGL[16:56:09] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has joined ##OpenGL[16:57:19] *** vassagus <vassagus!~vassagus@186.4.2.162> has joined ##OpenGL[16:57:40] *** Xeronate_ <Xeronate_!~Xeronate@rrcs-74-62-109-222.west.biz.rr.com> has joined ##OpenGL[16:59:47] *** ragecryx <ragecryx!~ragecryx@178.128.204.72.dsl.dyn.forthnet.gr> has quit IRC (Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617])[17:01:13] *** Xeronate <Xeronate!~Xeronate@rrcs-74-62-109-222.west.biz.rr.com> has quit IRC (Ping timeout: 255 seconds)[17:05:09] *** toor_ <toor_!~toor@80.12.63.105> has joined ##OpenGL[17:09:24] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[17:12:39] *** nilspin_ <nilspin_!~nilspin@81.4.104.140> has quit IRC (Ping timeout: 244 seconds)[17:13:08] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[17:14:15] *** Matthijs <Matthijs!~quassel@unaffiliated/matthijs> has quit IRC (Remote host closed the connection)[17:16:49] *** noexcept_ <noexcept_!~noexcept@HSI-KBW-078-042-092-084.hsi3.kabel-badenwuerttemberg.de> has quit IRC (Quit: Lost terminal)[17:17:40] *** tristanseifert <tristanseifert!~tristanse@nat-165-91-13-127.tamulink.tamu.edu> has joined ##OpenGL[17:20:13] *** delicado <delicado!~delicado@112.198.82.88> has quit IRC (Read error: Connection reset by peer)[17:21:22] *** delicado <delicado!~delicado@112.198.82.88> has joined ##OpenGL[17:27:29] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Ping timeout: 250 seconds)[17:30:51] *** notadeveloper_ <notadeveloper_!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[17:32:28] *** Sorcerer1 <Sorcerer1!~SorcererX@2.150.200.153.tmi.telenormobil.no> has joined ##OpenGL[17:33:17] *** glYoda <glYoda!~MTLYoda@c-50-137-137-82.hsd1.or.comcast.net> has joined ##OpenGL[17:34:05] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Ping timeout: 250 seconds)[17:34:13] *** gravitation <gravitation!~gravitati@cpe-67-247-58-82.nyc.res.rr.com> has quit IRC (Read error: No route to host)[17:35:08] *** pffffffft <pffffffft!~pffffffft@unaffiliated/pffffffft> has joined ##OpenGL[17:36:55] *** stefkos <stefkos!~stefkos@pc11-226.chomiczowka.waw.pl> has joined ##OpenGL[17:41:46] *** tristanseifert <tristanseifert!~tristanse@nat-165-91-13-127.tamulink.tamu.edu> has quit IRC (Ping timeout: 244 seconds)[17:41:48] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has joined ##OpenGL[17:42:17] *** qptain_Nemo <qptain_Nemo!~qN@37.204.226.194> has quit IRC (Read error: Connection reset by peer)[17:44:23] *** qptain_Nemo <qptain_Nemo!~qN@37.204.226.194> has joined ##OpenGL[17:44:24] *** Ad1_RN <Ad1_RN!~Ad1_RnR@88-199-45-84.matcom.com.pl> has quit IRC (Quit: Wychodzi z Matrixa)[17:45:49] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[17:48:07] *** Nyyuu <Nyyuu!Nyyuu@205.201.154.152> has quit IRC (Read error: Connection reset by peer)[17:52:21] *** GarrettShields <GarrettShields!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has joined ##OpenGL[17:55:03] *** rurza <rurza!~rurza@apn-31-1-75-167.dynamic.gprs.plus.pl> has joined ##OpenGL[17:57:42] *** Sorcerer1 <Sorcerer1!~SorcererX@2.150.200.153.tmi.telenormobil.no> has quit IRC (Quit: ...)[17:59:24] *** Th30n <Th30n!~Th30n@78-0-224-255.adsl.net.t-com.hr> has quit IRC (Ping timeout: 260 seconds)[18:03:28] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[18:03:49] *** doomlord <doomlord!~textual@host81-147-72-23.range81-147.btcentralplus.com> has joined ##OpenGL[18:06:05] *** electrostat <electrostat!~dag@unaffiliated/electrostat> has quit IRC (Quit: uwotm8)[18:11:16] *** electrostat <electrostat!~dag@unaffiliated/electrostat> has joined ##OpenGL[18:14:14] *** ratchetfreak <ratchetfreak!c351a8d8@gateway/web/freenode/ip.195.81.168.216> has quit IRC (Ping timeout: 264 seconds)[18:15:09] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has joined ##OpenGL[18:15:49] *** zagabar <zagabar!~zagabar@c213-89-112-5.bredband.comhem.se> has joined ##OpenGL[18:15:50] *** zagabar <zagabar!~zagabar@c213-89-112-5.bredband.comhem.se> has quit IRC (Changing host)[18:15:50] *** zagabar <zagabar!~zagabar@unaffiliated/zagabar> has joined ##OpenGL[18:16:23] *** elect <elect!~elect@business-092-079-135-041.static.arcor-ip.net> has quit IRC (Read error: Connection reset by peer)[18:17:02] *** nepgear <nepgear!~shake@excessive.moe> has joined ##OpenGL[18:17:14] *** nepgear is now known as Guest6203[18:22:35] *** Zerflag <Zerflag!~zerflag@216-19-179-103.dyn.novuscom.net> has quit IRC (Remote host closed the connection)[18:22:45] *** Serpent7776 <Serpent7776!~Serpent77@90-156-68-175.internetia.net.pl> has quit IRC (Quit: Leaving)[18:23:02] *** CapsAdmin <CapsAdmin!~CapsAdmin@217.70.249.229> has quit IRC (Quit: Leaving)[18:24:00] <dawik> all you ever wanted to know about quaternions[18:24:05] <dawik> http://loopspace.mathforge.org/HowDidIDoThat/Codea/Quaternions/[18:27:02] <Yaniel> ES 2 does not have modern features[18:27:03] <Yaniel> and bitwise operations are modern as far as shaders are considered[18:27:08] <Yaniel> (as are half-floats actually)[18:27:08] <Yaniel> nice page[18:27:09] <Yaniel> but oh boy at css[18:27:10] <Yaniel> dat*[18:29:06] *** notadeveloper_ <notadeveloper_!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Read error: Connection reset by peer)[18:29:34] *** neure <neure!~tsuorant@a88-112-89-144.elisa-laajakaista.fi> has quit IRC (Quit: Leaving)[18:30:03] *** MrFlibble <MrFlibble!MrFlibble@90.220.166.75> has joined ##OpenGL[18:30:08] *** zwiep` <zwiep`!~zwiep@d54c03c0d.access.telenet.be> has quit IRC (Ping timeout: 244 seconds)[18:30:20] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[18:32:05] *** zwiep` <zwiep`!~zwiep@d54c03c0d.access.telenet.be> has joined ##OpenGL[18:33:12] *** Guest6203 is now known as shakesoda[18:33:22] *** shakesoda <shakesoda!~shake@excessive.moe> has quit IRC (Changing host)[18:33:22] *** shakesoda <shakesoda!~shake@celestiaradio/shark/soda> has joined ##OpenGL[18:35:21] *** t0by <t0by!~t0by@87.13.109.176> has joined ##OpenGL[18:38:24] *** fodil <fodil!~user@bea13-5-83-156-146-12.fbx.proxad.net> has joined ##OpenGL[18:38:27] <fodil> Hi ![18:38:59] <Codex_> hi[18:44:29] *** rurza <rurza!~rurza@apn-31-1-75-167.dynamic.gprs.plus.pl> has quit IRC (Read error: Connection reset by peer)[18:44:40] *** ejb <ejb!~ejb@unaffiliated/ejb> has joined ##OpenGL[18:44:41] *** rurza <rurza!~rurza@apn-31-1-75-167.dynamic.gprs.plus.pl> has joined ##OpenGL[18:50:48] <dawik> Yaniel: lol yeah, looked a lot nicer on my cell :)[18:51:12] <Yaniel> well, on a touchscreen it would probably actually be decent[18:51:22] <Yaniel> I was way too confused by the lack of a scrollbar though[18:51:41] <Yaniel> and then by the fact that it was far outside the element it scrolled[18:52:06] <dawik> agreed[18:52:12] *** glYoda <glYoda!~MTLYoda@c-50-137-137-82.hsd1.or.comcast.net> has quit IRC (Ping timeout: 240 seconds)[18:54:06] *** seangrove <seangrove!~user@c-50-174-77-118.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 244 seconds)[18:56:11] *** glYoda <glYoda!~MTLYoda@c-50-137-137-82.hsd1.or.comcast.net> has joined ##OpenGL[18:56:14] *** ejb <ejb!~ejb@unaffiliated/ejb> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[18:57:48] *** qptain_Nemo <qptain_Nemo!~qN@37.204.226.194> has quit IRC (Remote host closed the connection)[18:58:17] *** qptain_Nemo <qptain_Nemo!~qN@37.204.226.194> has joined ##OpenGL[19:00:23] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has joined ##OpenGL[19:02:20] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Ping timeout: 244 seconds)[19:02:31] *** ejb <ejb!~ejb@unaffiliated/ejb> has joined ##OpenGL[19:02:44] *** karab44 <karab44!~karab44@unaffiliated/karab44> has quit IRC (Quit: Bye bye! o/)[19:12:11] *** match_ita <match_ita!~Giovanni@dynamic-adsl-78-14-226-13.clienti.tiscali.it> has quit IRC (Quit: It 's better to be optimistic and be wrong , than to be pessimistic and to be right - Albert Einstein)[19:12:29] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has quit IRC (Quit: Bye Bye)[19:14:24] *** tristanseifert <tristanseifert!~tristanse@nat-165-91-13-127.tamulink.tamu.edu> has joined ##OpenGL[19:17:07] *** Th30n <Th30n!~Th30n@78-0-224-255.adsl.net.t-com.hr> has joined ##OpenGL[19:17:55] *** Cooler <Cooler!~CoolerExt@103.208.235.102> has quit IRC (Ping timeout: 265 seconds)[19:19:04] *** tristanseifert <tristanseifert!~tristanse@nat-165-91-13-127.tamulink.tamu.edu> has quit IRC (Ping timeout: 264 seconds)[19:19:54] <axion> Can someone point me to the relevant spec section talking about attrib alignment offset restrictions?[19:20:42] <axion> I'm getting a lot of conflicting info from peers and I can't seem to find any official information[19:21:02] *** Cooler <Cooler!~CoolerExt@117.248.11.164> has joined ##OpenGL[19:24:00] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has joined ##OpenGL[19:24:04] *** ejb <ejb!~ejb@unaffiliated/ejb> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[19:24:12] *** toor_ <toor_!~toor@80.12.63.105> has quit IRC (Ping timeout: 240 seconds)[19:24:28] <derhass> axion: there are none[19:25:46] <axion> Ok, where does this quote from opengl.org come from? "There is something you should watch out for. The alignment of any attribute's data should be no less than 4 bytes."[19:26:05] <axion> Seems this is conflicting with what some people are telling me, and others not[19:26:09] <derhass> that is a recommendation at best[19:26:32] <derhass> gpu vendors all have some recommendation for optimal alignment[19:27:35] <axion> I see. Thank you.[19:27:40] *** shingshang <shingshang!~shingshan@115-64-27-246.static.tpgi.com.au> has quit IRC (Ping timeout: 244 seconds)[19:29:13] *** Xero <Xero!~Xeronate@rrcs-74-62-109-222.west.biz.rr.com> has joined ##OpenGL[19:29:38] *** Xero is now known as Guest66101[19:30:49] <derhass> axion: and the 4 byte alignment is a very reasonable recommendation[19:31:48] <axion> So tightly packed buffers are not good?[19:32:12] <derhass> I wouldn't say that[19:32:45] <derhass> with most layouts, you naturally get 4 byte alignment[19:32:54] *** Xeronate_ <Xeronate_!~Xeronate@rrcs-74-62-109-222.west.biz.rr.com> has quit IRC (Ping timeout: 265 seconds)[19:33:06] *** nine_milli <nine_milli!~nine_mill@32.211.52.104> has joined ##OpenGL[19:34:33] * atk prefers 1.5 byte alignment.[19:34:41] <atk> makes implementing fat12 easier.[19:35:09] *** fqtw__ <fqtw__!~me@x590c7a26.dyn.telefonica.de> has joined ##OpenGL[19:35:15] *** fqtw_ <fqtw_!~me@x590c726e.dyn.telefonica.de> has quit IRC (Read error: Connection reset by peer)[19:35:25] <derhass> axion: what attribute layout would you have in mind that would not end up with 4 byte alignment? RGB color as 3 bytes?[19:35:27] <axion> Well most layouts is not what I'm after...[19:36:19] <derhass> even if it is perfectly valid as per the spec, I would restrain from using <4 byte alignments[19:36:31] <derhass> unless there would be a _very_ good reason to use them[19:36:40] <axion> I'm writing a VAO utility library for an obscure language, and want to encode everything the user may give into an array of unsigned-byte 32's[19:36:59] <derhass> unsigned byte 32?[19:37:32] <axion> 32bit elements[19:37:39] *** elect_ <elect_!~elect@ip5f5afe5f.dynamic.kabel-deutschland.de> has joined ##OpenGL[19:37:59] <derhass> so you arelade have the 4 byte alignemnt[19:38:02] <derhass> &already[19:39:44] <dawik> a byte is a byte, it is only how you interpret the bits as an integer that decides if it's unsigned or not :p (just thorinwg it out there)[19:39:47] <axion> Even if the 4bytes contain partial attrib elements?[19:41:07] <derhass> axion: no[19:47:26] <axion> suppose i had a vbo consisting of 3 shorts and then a float. my vbo would have 3 32bit quantities.[19:47:40] <axion> so it is not very efficient is what i'm told[19:49:31] <derhass> it is not optimal, at least[19:50:04] <axion> What would you suggest for encoding arbitrary layouts?[19:50:19] *** SwiftMatt <SwiftMatt!~Objective@162.242.94.159> has joined ##OpenGL[19:51:04] *** SwiftMatt <SwiftMatt!~Objective@162.242.94.159> has quit IRC (Client Quit)[19:54:09] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Read error: Connection reset by peer)[19:56:50] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[19:57:25] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 250 seconds)[20:00:19] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-57-173.w90-47.abo.wanadoo.fr> has joined ##OpenGL[20:02:13] *** flavi0 <flavi0!~anon@unaffiliated/flavi0> has quit IRC (Quit: leaving)[20:02:43] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has joined ##OpenGL[20:08:45] <btipling_> dawik that quaternions link is great, thank you for sharing that![20:09:53] *** ejb <ejb!~ejb@unaffiliated/ejb> has joined ##OpenGL[20:10:46] <dawik> btipling_: np![20:11:00] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 265 seconds)[20:11:42] <axion> That isn't everything I would've wanted to know when writing my engine by far.[20:12:01] <axion> It doesn't even talk about dual quaternions, which are much more complex[20:12:27] <Stragus> axion: Basically keep the same alignment as sizeof() for the whole vectorized type, and try to align the stride on cache lines[20:13:14] <axion> Ok[20:13:23] <Stragus> Indexed rendering with a stride that crosses cache lines is detrimental to performance[20:14:54] <Stragus> By the way, that means 16 bytes alignment for float3 or float4 for example (assume 3 components are always padded to 4)[20:15:27] <Stragus> And remember to use int16_t, 10_10_10_2 and such whenever possible[20:16:11] <axion> Ok, thanks[20:17:46] <btipling_> axion what's your engine?[20:18:10] <btipling_> are you afluby?[20:18:19] <axion> No, it's a closed engine for personal stuffs[20:18:28] <btipling_> axion do you have a youtube?[20:18:34] <btipling_> with your engine stuff on it?[20:18:39] <axion> No[20:18:41] <btipling_> :<[20:18:52] <axion> When using dual quaternions, you use half the space and like 70% of the operations of a matrix transform multiply. It is only a few compositions of transform you need before it pays for itself in terms of having to perform the dual quaternion to transformation matrix translation with final model transform.[20:21:15] *** rleigh <rleigh!~rleigh@unaffiliated/rleigh> has quit IRC (Ping timeout: 250 seconds)[20:25:34] <noizex> bah, every time I get lighting done I think it's ok, then something screws ;)[20:26:30] <noizex> normals are first in object space right?[20:26:42] <noizex> so the color shouldn't change when I visualise them on the object[20:27:02] <noizex> (rotating)[20:27:03] *** ejb <ejb!~ejb@unaffiliated/ejb> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[20:27:19] <noizex> red on one side, blue on other, green up[20:27:21] <noizex> seems legit[20:27:25] *** elect_ <elect_!~elect@ip5f5afe5f.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 244 seconds)[20:27:59] <noizex> then I do normalize(mat3(normalMatrix) * normal); and everything screws[20:28:09] <noizex> normal colors are changing as object rotates[20:28:21] *** Th30n <Th30n!~Th30n@78-0-224-255.adsl.net.t-com.hr> has quit IRC (Quit: leaving)[20:28:41] <noizex> so red when object faces right, blue when forward[20:28:55] <noizex> this shouldn't be like this? normal matrix shouldn't cause that?[20:29:26] <Yaniel> well if the normal matrix is identity...[20:29:44] <Yaniel> and depends on what space you do your lighting in[20:29:51] <Stragus> Normally. you want to normalize in fragment shader, but multiply the matrix in the vertex shader[20:30:10] *** ejb <ejb!~ejb@cpe-198-255-244-111.maine.res.rr.com> has joined ##OpenGL[20:30:15] *** ejb <ejb!~ejb@cpe-198-255-244-111.maine.res.rr.com> has quit IRC (Changing host)[20:30:15] *** ejb <ejb!~ejb@unaffiliated/ejb> has joined ##OpenGL[20:30:21] *** notadeveloper_ <notadeveloper_!~notadevel@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has joined ##OpenGL[20:31:45] <noizex> hm, I dot with light direction in world space[20:31:51] <noizex> so probably in world space, right?[20:32:52] <Yaniel> yes then you want to transform the normals from object space to world space[20:34:14] <noizex> m_ModelUniformBuffer.normalMatrix = glm::transpose(glm::inverse(glm::mat4(m_ModelUniformBuffer.modelMatrix)));[20:34:18] <noizex> so this should be correct, right?[20:34:38] <noizex> gawd, I did it so long ago I can't even remember what waas this about transpose inverse of model matrix[20:35:03] <noizex> I hate when I prove my lighting is screwed because I changed something and have to dig it once again[20:35:10] *** joshsyn <joshsyn!~swoorup@124-148-76-43.dyn.iinet.net.au> has joined ##OpenGL[20:35:14] *** swoorup_ <swoorup_!~swoorup@124-148-76-43.dyn.iinet.net.au> has joined ##OpenGL[20:35:37] *** GarrettShields_ <GarrettShields_!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has joined ##OpenGL[20:35:44] <axion> and then you want to multiple that by the vertex normal vector i believe to put it in world space[20:36:35] <axion> at least that's how all my shaders do it. and yeah, it's been ages to make sense out of a lot of this. i wish i commented as much as i do now[20:37:00] <noizex> yeah that's what I do[20:37:07] <noizex> somehow one side of the object is lit when it turns to light[20:37:12] <noizex> and other remains dark[20:37:18] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[20:37:27] <noizex> or actually the other one that's lit remains lit when it turns away from light[20:37:31] <noizex> one sec[20:38:41] *** AlphaOmega82 <AlphaOmega82!~alfa@173.34.98.172> has quit IRC (Ping timeout: 250 seconds)[20:39:01] *** GarrettShields <GarrettShields!~GarrettSh@CPE3497f6605400-CMbc14013107e0.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 255 seconds)[20:39:27] *** AlphaOmega82 <AlphaOmega82!~alfa@CPE48ee0c279953-CMbc140153e510.cpe.net.cable.rogers.com> has joined ##OpenGL[20:39:45] <noizex> sometimes I just can't wrap my damn brain around these things ;)[20:39:58] <noizex> put a video, maybe you can easily figure out what I'm doing wrong[20:40:28] <noizex> https://www.youtube.com/watch?v=7IFiVGLuPOE[20:41:00] <axion> you're not normal mapping are you? wonder if your lighting is in tangent space or something[20:41:06] <noizex> no, I turned it off[20:41:14] <noizex> these are pure vertex normals right now[20:41:20] *** ejb <ejb!~ejb@unaffiliated/ejb> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[20:41:29] <noizex> I checked them and they seem to be correct in Blender[20:41:58] <axion> I could paste some very old code that I am not even sure is correct but seemed so at the time...it's been a long while since I wrote a shader[20:41:58] <noizex> I will check some model I'm certain is ok[20:42:09] <noizex> one sec, I will confirm with some neutral model[20:49:01] *** ejb <ejb!~ejb@unaffiliated/ejb> has joined ##OpenGL[20:54:05] *** SHC <SHC!~quassel@160.202.180.137> has quit IRC (Remote host closed the connection)[20:55:19] *** vitimiti <vitimiti!~vitimiti@unaffiliated/vitimiti> has joined ##OpenGL[21:02:18] *** ArkaZeen <ArkaZeen!~ArkaZeen@wn-res-nat-129-97-125-27.dynamic.uwaterloo.ca> has quit IRC (Ping timeout: 276 seconds)[21:03:00] *** elect_ <elect_!~elect@ip5f5afe5f.dynamic.kabel-deutschland.de> has joined ##OpenGL[21:06:47] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has joined ##OpenGL[21:09:13] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Read error: Connection reset by peer)[21:09:59] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[21:10:00] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-2hj4tbosgukodwskjp6x4qn1s.ip6.access.telenet.be> has joined ##OpenGL[21:11:32] *** sandeepkr <sandeepkr!~sandeepkr@111.235.65.5> has quit IRC (Read error: No route to host)[21:13:08] *** pril <pril!userid@unaffiliated/pril> has joined ##OpenGL[21:13:26] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 265 seconds)[21:13:29] *** sandeepkr <sandeepkr!~sandeepkr@111.235.65.5> has joined ##OpenGL[21:16:22] *** Cooler <Cooler!~CoolerExt@117.248.11.164> has quit IRC (Ping timeout: 255 seconds)[21:16:39] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[21:21:37] <noizex> ok, so my sun is at (0.5, 0.5, 0.5) and I'm using test object that is unlit from the side of sun[21:21:48] <noizex> but is lit on opposite[21:22:06] <noizex> well, my sundir is vec3(0.5)[21:22:55] *** delicado <delicado!~delicado@112.198.82.88> has quit IRC ()[21:27:59] *** tambre <tambre!~tambre@8389-33cb-8f43-29d6-a980-8a3e-07d0-2001.dyn.estpak.ee> has quit IRC (Ping timeout: 250 seconds)[21:29:21] *** ejb <ejb!~ejb@unaffiliated/ejb> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)[21:31:10] *** Ploppz <Ploppz!~ploppz@2001:700:303:b:f3ce:ca7c:3834:8e44> has joined ##OpenGL[21:31:40] *** notadeveloper__ <notadeveloper__!~letsmakej@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has joined ##OpenGL[21:34:09] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Ping timeout: 250 seconds)[21:36:20] *** toor <toor!~toor@80.12.55.121> has joined ##OpenGL[21:47:26] <DarkUranium> noizex, sounds like you have a wrong sign somewhere[21:47:35] <DarkUranium> x-sun instead of sun-x or similar[21:48:09] <derhass> or your normals point into the wrong direction[21:48:36] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has joined ##OpenGL[21:48:49] <derhass> but as you typically use L as the incident light vector, you probably just forget to negate it[21:50:10] *** elect_ <elect_!~elect@ip5f5afe5f.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 265 seconds)[21:52:09] *** Xrayez <Xrayez!~Xrayez@176.104.32.65> has joined ##OpenGL[21:53:31] *** match_ita <match_ita!~Giovanni@dynamic-adsl-78-14-226-13.clienti.tiscali.it> has joined ##OpenGL[21:54:03] *** konom <konom!~tamatias@141.15.138.77.rev.sfr.net> has joined ##OpenGL[21:54:20] *** mukunda <mukunda!praynspray@c-71-205-185-63.hsd1.co.comcast.net> has joined ##OpenGL[21:54:51] *** fqtw_ <fqtw_!~me@x590c24c3.dyn.telefonica.de> has joined ##OpenGL[21:55:17] *** swoorup_ <swoorup_!~swoorup@124-148-76-43.dyn.iinet.net.au> has quit IRC (Ping timeout: 250 seconds)[21:55:17] *** joshsyn <joshsyn!~swoorup@124-148-76-43.dyn.iinet.net.au> has quit IRC (Ping timeout: 250 seconds)[21:58:18] *** fqtw__ <fqtw__!~me@x590c7a26.dyn.telefonica.de> has quit IRC (Ping timeout: 265 seconds)[22:01:49] *** Xrayez <Xrayez!~Xrayez@176.104.32.65> has quit IRC (Quit: Leaving)[22:01:56] *** stefkos <stefkos!~stefkos@pc11-226.chomiczowka.waw.pl> has quit IRC (Read error: Connection reset by peer)[22:02:07] *** match_italia <match_italia!~Giovanni@dynamic-adsl-78-14-227-127.clienti.tiscali.it> has joined ##OpenGL[22:02:07] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has joined ##OpenGL[22:02:18] *** Xrayez <Xrayez!~Xrayez@176.104.32.65> has joined ##OpenGL[22:02:19] *** Xrayez <Xrayez!~Xrayez@176.104.32.65> has quit IRC (Max SendQ exceeded)[22:03:10] *** match_ita <match_ita!~Giovanni@dynamic-adsl-78-14-226-13.clienti.tiscali.it> has quit IRC (Ping timeout: 255 seconds)[22:03:58] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Quit: Sleep)[22:04:46] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has quit IRC (Remote host closed the connection)[22:04:53] *** dwigton <dwigton!~daniel@216.70.20.66> has left ##OpenGL ("WeeChat 0.4.2")[22:05:40] *** Xrayez <Xrayez!~Xrayez@176.104.32.65> has joined ##OpenGL[22:10:31] *** tristanseifert <tristanseifert!~tristanse@128.194.3.4> has joined ##OpenGL[22:16:57] *** MrFlibble <MrFlibble!MrFlibble@90.220.166.75> has quit IRC (Quit: MrFlibble)[22:17:29] *** match_italia <match_italia!~Giovanni@dynamic-adsl-78-14-227-127.clienti.tiscali.it> has quit IRC (Quit: It 's better to be optimistic and be wrong , than to be pessimistic and to be right - Albert Einstein)[22:18:01] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Read error: Connection reset by peer)[22:20:53] <Ploppz> If I have some variable amount of polygons with each their transform.. what's the best way to draw them all? I doubt letting the CPU transform all vertices and upload to one buffer. What I've been doing is to upload model-space geometry, and keep meta-data telling what element indices polygons start at, and what their transform is. It seems wasteful, however, to do one glDrawArrays for each polygon...[22:21:33] *** elect_ <elect_!~elect@ip5f5afe5f.dynamic.kabel-deutschland.de> has joined ##OpenGL[22:22:29] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has quit IRC (Ping timeout: 260 seconds)[22:23:55] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 252 seconds)[22:27:22] <Stragus> Terribly wasteful, transform on the CPU[22:27:27] *** Xrayez <Xrayez!~Xrayez@176.104.32.65> has quit IRC (Quit: Leaving)[22:27:52] <Codex_> ploppz: every polygon has different transform?[22:28:02] <Ploppz> Yes[22:28:06] <Codex_> why?[22:28:13] <Ploppz> It's a physics engine.[22:28:23] <Ploppz> they have translation and orientation[22:28:24] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has joined ##OpenGL[22:28:31] <ratchetfreak> each polygone has the same form?[22:29:00] <Stragus> If the geometry and data are properly batched, you could also do it on the GPU with feedback transform or compute shaders[22:29:09] <Ploppz> No polygons are general, arbitrary[22:29:10] <Stragus> But really don't do that DrawArrays() thing with single polygon[22:30:09] <Ploppz> what about adding a vec3 for (translation, orientation) for each vertex? Still wasteful memory..[22:30:35] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has joined ##OpenGL[22:30:51] <Codex_> ploppz: are you just drawing one frame, or does these objects actually move?[22:30:58] <Ploppz> they move[22:31:02] <Curious> Sound like a case for glDrawArraysInstanced[22:31:17] <Ploppz> their vertices are reuploaded to the GPU every frame[22:31:27] <Ploppz> although that could be handled way better.[22:31:29] <Curious> Don't do that.[22:31:34] <ratchetfreak> Curious: if they were all the same form that could work which is why I asked[22:31:38] <Curious> Instancing is what you want[22:32:00] <Stragus> Ploppz: You really need to rethink what you are doing and how to batch things properly[22:32:05] <Ploppz> but well I need to upload vertices when polygons are added/removed/split/whatever, Curious. I should improve it to only do it when necessary[22:32:08] <Curious> Ok, what kind of transformations are we talking about here?[22:32:11] <Stragus> And no, don't use instances for single polygons[22:32:23] <Ploppz> isn't instancing drawing the same thing over and over again?[22:33:04] <Curious> The same thing over and over again but with each instance having different transformations[22:33:04] <ratchetfreak> removed you can do by transporting the poly offscreen[22:33:04] <Ploppz> I have N polygons each with an arbitrary amount of vertices arbitrarily placed. Each of them has a transformation that most likely changes every frame.[22:33:19] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[22:33:48] <Ploppz> Let's say I upload the polygons only once (although I'm not atm). I need to draw them.[22:34:03] <Ploppz> I'd place a comma after 'N polygons'[22:34:55] <Codex_> ploppz: drawing polygon pretty much means "triangle strips"... there's some nice tricks how triangle strips will convert your polygon to triangles which are easier for hardware to handle.[22:35:19] *** notadeveloper__ <notadeveloper__!~letsmakej@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has quit IRC (Ping timeout: 260 seconds)[22:35:24] <Stragus> I don't think he wants to consider triangle strips at that point[22:35:25] <Ploppz> I draw polygons by drawing triangle fans in a stencil buffer.[22:35:48] <Ploppz> But it doesn't matter. I have some vertex data. Arbitrary chunks of it need different transformation applied.[22:35:48] <Stragus> Use regular indexed triangles, forget fans[22:36:19] <Ploppz> I don't triangulate. I only draw a triangle fan for each polygon.[22:36:25] <Stragus> Ploppz, if it's totally arbitrary and all the data for these transformations are known to the CPU only and change every frame, then transform on the CPU and reupload every frame[22:36:44] <Stragus> Code it properly with AVX, perhaps multithreaded, and it will be blazzingly fast[22:36:56] <ratchetfreak> and with a UBO/SSBO you can add a polygon ID to each polygon and use that to index into the SSBO/UBO[22:37:34] <Curious> If, as you say, all your points of the polygons can be arbitrarily placed then the only way is to upload the data when it changes.[22:37:39] <Ploppz> Hm yeah, multithreading is needed. You think it will perform better than several draw calls?[22:38:18] <Stragus> About a hundred times faster[22:38:44] <Ploppz> Hm ok. I was just concerned that I already need all the CPU I can get for physics computatinos[22:39:41] <chrisf> so dont waste it all in the gl driver setting up tiny draws[22:39:44] <Stragus> Off-load anything you can to the GPU, but while still batching few massive Draw() calls[22:39:47] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Read error: Connection reset by peer)[22:40:05] <Codex_> ploppz: but physics simulations is interesting area -- I've been thinking of moving my code to scientific visualisation area... Hope you get it working nicely..[22:40:25] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has joined ##OpenGL[22:40:27] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has quit IRC (Ping timeout: 276 seconds)[22:40:51] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has joined ##OpenGL[22:40:53] <Ploppz> It is. Hope so too, thanks.[22:41:11] <Ploppz> Thanks for your thoughts on this, I suppose I will transform vertices using multithreaded CPU[22:41:33] <Stragus> And use SSE/AVX[22:41:54] <Curious> If you need a lot of transformations and they can be massively parallelized then you might want to use openCL or compute shaders for that[22:42:08] *** ronaldsmazitis <ronaldsmazitis!~quassel@46.109.139.95> has joined ##OpenGL[22:42:26] *** zagabar <zagabar!~zagabar@unaffiliated/zagabar> has quit IRC (Quit: WeeChat 1.5)[22:43:07] <Ploppz> haven't heard about it Stragus . Is AVX some kind of miniature SIMD in the CPU?[22:43:31] <Stragus> I wouldn't call 8-wide "miniature"[22:43:39] <Stragus> MMX was miniature, eh[22:43:42] *** michauds <michauds!~michauds@199.91.185.156> has quit IRC (Ping timeout: 276 seconds)[22:43:50] <Ploppz> well I was comparing it to GPU-style SIMD :P[22:43:57] <Ploppz> in my mind[22:44:22] <Ploppz> well thanks for the pointer[22:44:32] *** ArkaZeen <ArkaZeen!~ArkaZeen@wn-res-nat-129-97-125-27.dynamic.uwaterloo.ca> has joined ##OpenGL[22:46:47] *** t0by <t0by!~t0by@87.13.109.176> has quit IRC (Quit: Bye!)[22:48:34] *** pril <pril!userid@unaffiliated/pril> has quit IRC (Ping timeout: 265 seconds)[22:48:39] *** fodil <fodil!~user@bea13-5-83-156-146-12.fbx.proxad.net> has quit IRC (Ping timeout: 265 seconds)[22:50:57] <Codex_> ploppz: is the triangle fans splitting your vertex data to different draw calls?[22:51:17] <Codex_> or was there some way to jump from one fan to another inside same data?[22:51:41] <Ploppz> yeah that's what I was just thinking about.. I'm just reading that you can split them using glDrawElements ( http://stackoverflow.com/a/4387342 )[22:53:10] <Codex_> triangle strips had nice feature that you can combine multiple polygons to same data... But you just need degenerate vertexes to separate the polygons.[22:53:10] *** crankslider <crankslider!~slidercra@unaffiliated/slidercrank> has joined ##OpenGL[22:53:36] <chrisf> or you can use primitive restart[22:53:57] <Codex_> chrisf: what's "primitive restart"?[22:54:16] <Ploppz> in the post, it's some kind of sentinel value in the elements buffer[22:54:38] <Stragus> Guys, this is final optimization tricks to grab a few extra percents[22:54:40] <Ploppz> but that's so much more data. Then I might as well just draw triangles instead of fans, as Stragus said.[22:55:08] <chrisf> how many verts do these polygons typically have?[22:55:11] <Stragus> One step at a time, let him switch to general batched indexed triangles[22:55:32] <chrisf> that's going to drive whether you transform on cpu, or whether you use indexing tricks to select a transform in the shader[22:55:37] <Ploppz> indexed triangles? You mean just normal triangles, no fans?[22:55:52] <chrisf> Ploppz: take the whole concept of fans out the back and shoot it.[22:56:27] <Ploppz> yes I'm considering that, I can just make triangles to draw the same things. I'll do that, and do batch drawing with normal triangles. Thanks again al[22:56:29] <Ploppz> all*[22:57:54] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has joined ##OpenGL[22:58:47] *** eivarv <eivarv!~eivarv@cm-84.215.4.97.getinternet.no> has quit IRC (Client Quit)[22:59:33] *** Guest66101 <Guest66101!~Xeronate@rrcs-74-62-109-222.west.biz.rr.com> has quit IRC (Quit: Leaving)[23:00:44] *** mukunda_ <mukunda_!~mukunda@c-71-205-185-63.hsd1.co.comcast.net> has joined ##OpenGL[23:00:48] *** mukunda_ <mukunda_!~mukunda@c-71-205-185-63.hsd1.co.comcast.net> has quit IRC (Client Quit)[23:01:04] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has quit IRC (Quit: Leaving)[23:02:03] <wondiws> hi, I've got an example here that uses GLUT, but this uses quite a few callback functions. I find this make Object Orientated programming more difficult, is this a common issue?[23:02:38] <Stragus> Don't use GLUT[23:03:46] <Stragus> GLFW also uses callbacks for UI events, set and grab the pointer to your "state" through glfwSetWindowUserPointer() glfwGetWindowUserPointer()[23:05:45] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[23:06:24] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[23:07:02] *** przm <przm!~przm@ool-44c79cfa.dyn.optonline.net> has joined ##OpenGL[23:07:33] *** pril <pril!~userid@unaffiliated/pril> has joined ##OpenGL[23:08:36] *** notadeveloper <notadeveloper!~letsmakej@2602:306:bd2a:a160:d513:259e:5b80:43d7> has quit IRC (Ping timeout: 250 seconds)[23:10:51] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Ping timeout: 244 seconds)[23:11:42] <btipling_> GLFW > GLUT[23:11:56] <Xeek> callbacks might actually help[23:12:20] <Xeek> I've considered using glfw for the callbacks so I could more easily integrate events with my object orientation[23:12:42] <Xeek> but I might be bias, I grew up using callbacks with win32api and having to make that object oriented[23:13:26] <Xeek> wondiws: if you want to get away from callbacks then you might consider SDL instead[23:13:54] <Codex_> callbacks would otherwise be ok, but they unfortunately split your algorithms to small pieces using arbitrary dividing lines.[23:14:07] <Curious> SDL2 is awesome.[23:14:35] <Xeek> I use sdl2 most of the time, but after using glfw in a couple of utilities it's growing on me[23:16:26] <Codex_> complex algorithm that requires passing data around might not exactly like if it's being split to several parts..[23:17:05] <Xeek> Codex_: I reallyt dont know what you mean[23:18:11] <Codex_> well, that's what was wrong with glut.. it wanted to place all it's functionality to callbacks with no way to pass data between the passes.[23:18:29] *** carado <carado!~carado@2a01:e34:ec1e:2390:8341:b3f5:2d6:41fa> has quit IRC (Ping timeout: 260 seconds)[23:18:29] *** notadeveloper_ <notadeveloper_!~notadevel@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has quit IRC (Ping timeout: 260 seconds)[23:19:03] <Codex_> so anything more complicated would simply fail to work properly[23:19:15] <Xeek> Codex_: eh ... I couldn't make sense of the lasdt part of your sentence[23:19:20] <Xeek> pass the passes?[23:19:45] *** pffffffft <pffffffft!~pffffffft@unaffiliated/pffffffft> has quit IRC (Quit: pffffffft)[23:19:51] <Xeek> Codex_: whether it's event loops or callbacks my work is divided event by event or frame by frame, either way.[23:20:06] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has joined ##OpenGL[23:20:06] <Codex_> I mean, glut has something like glutDisplayFunc(), glutReshapeFunc() etc[23:20:28] <Xeek> oh well I'm not thinking in terms of glut, just glfw calbacks. Does anyone even use glut anymore?[23:20:54] <Codex_> but it's general problem with any callbacks.[23:21:03] <Xeek> in any case I dont think glut is made for real world applications anyway[23:21:18] <Xeek> glut is just there for some sample some book wnats to show you, not that you would ever really use glut in the real world[23:21:21] <Codex_> glut didn't do anything strange or odd which caused the problem -- they simply used callbacks.[23:21:47] <Xeek> whether its callbacks or event loops it ends up in my class function the same, no different. I dont see how it changes your algorithms.[23:22:34] <Codex_> well, it splits your whole code to 2 separate parts which have troubles communicating...[23:22:34] *** elect_ <elect_!~elect@ip5f5afe5f.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 260 seconds)[23:22:44] <Xeek> Codex_: that happens regardless[23:23:08] <Xeek> Codex_: again, either I'm doing something frame to frame or event to event, how I end up at that point is irrelevant[23:26:25] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 255 seconds)[23:26:31] *** flavi0 <flavi0!~anon@unaffiliated/flavi0> has joined ##OpenGL[23:28:26] *** BlackGold <BlackGold!~yaaic@CPE0c473d35fd91-CM0c473d35fd90.cpe.net.cable.rogers.com> has joined ##OpenGL[23:30:21] <Codex_> xeek: normal process is that events cause changes in the 3d world, so you need to pass data from event handling to the drawing... with glut you needed to use global variables to make that happen...[23:31:47] <Codex_> that was significant problem with the callback design they had.[23:37:43] *** kmnt <kmnt!~k@69.63.37.65> has quit IRC (Ping timeout: 244 seconds)[23:43:44] *** seangrove <seangrove!~user@c-67-169-95-188.hsd1.ca.comcast.net> has joined ##OpenGL[23:46:02] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has quit IRC (Read error: Connection reset by peer)[23:46:18] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-57-173.w90-47.abo.wanadoo.fr> has quit IRC (Remote host closed the connection)[23:47:00] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has joined ##OpenGL[23:48:31] *** Suchorski <Suchorski!regex@unaffiliated/suchorski> has joined ##OpenGL[23:50:34] *** KAHR-Alpha <KAHR-Alpha!~Alpha@AReims-652-1-57-173.w90-47.abo.wanadoo.fr> has joined ##OpenGL[23:55:06] *** Neomex <Neomex!~Neomex@brg31.neoplus.adsl.tpnet.pl> has quit IRC (Quit: Leaving)[23:55:23] *** notadeveloper <notadeveloper!~notadevel@107-210-170-22.lightspeed.sndgca.sbcglobal.net> has joined ##OpenGL[23:56:52] *** ibouvousaime <ibouvousaime!~ibouvousa@41.82.58.218> has quit IRC (Read error: Connection reset by peer)[23:59:54] *** rurza <rurza!~rurza@apn-31-1-75-167.dynamic.gprs.plus.pl> has quit IRC (Remote host closed the connection)