July 19, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
July 19, 2019 [00:14:25] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[00:26:50] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[00:40:47] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[00:57:08] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Ping timeout: 245 seconds)[01:00:12] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Read error: Connection reset by peer)[01:00:18] *** bayoubengal01 <bayoubengal01!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has joined ##OpenGL[01:07:21] *** gehn <gehn!gehn@gateway/vpn/privateinternetaccess/gehn> has quit IRC (Quit: Leaving)[01:17:10] *** snyp <snyp!~Snyp@49.207.49.74> has quit IRC (Quit: WeeChat 2.5)[01:24:40] *** bayoubengal01 <bayoubengal01!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Read error: Connection reset by peer)[01:24:45] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has joined ##OpenGL[01:25:02] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Read error: Connection reset by peer)[01:25:21] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has joined ##OpenGL[01:35:01] *** tab-key <tab-key!~mantra@2601:601:c980:8fd:98da:9738:613c:5fde> has quit IRC (Ping timeout: 276 seconds)[01:44:49] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Ping timeout: 246 seconds)[01:55:28] *** lilabsence <lilabsence!~RizzoTheR@dyndsl-037-138-177-113.ewe-ip-backbone.de> has quit IRC (Remote host closed the connection)[01:55:51] *** lilabsence <lilabsence!~RizzoTheR@dyndsl-037-138-177-113.ewe-ip-backbone.de> has joined ##OpenGL[01:56:42] *** lilabsence <lilabsence!~RizzoTheR@dyndsl-037-138-177-113.ewe-ip-backbone.de> has quit IRC (Max SendQ exceeded)[01:57:04] *** lilabsence <lilabsence!~RizzoTheR@dyndsl-037-138-177-113.ewe-ip-backbone.de> has joined ##OpenGL[02:12:40] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 264 seconds)[02:22:48] *** reddd <reddd!~red@pool-96-244-64-132.bltmmd.fios.verizon.net> has joined ##OpenGL[02:43:57] *** glYoda <glYoda!~kristinam@c-73-25-27-206.hsd1.or.comcast.net> has joined ##OpenGL[02:46:07] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[03:49:25] *** charlie5 <charlie5!~rod@pa49-181-153-64.pa.nsw.optusnet.com.au> has quit IRC (Ping timeout: 246 seconds)[04:18:02] *** KAHR-Alpha <KAHR-Alpha!~Alpha@2a01cb0d024a66007827d539bbe8d1d5.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 252 seconds)[04:20:36] *** mefesto <mefesto!~user@107.145.49.162> has joined ##OpenGL[04:31:31] *** lucid-lullaby <lucid-lullaby!~lucid-lul@66.115.169.212> has quit IRC (Quit: Leaving)[04:34:49] *** Plagman <Plagman!~quassel@2001:41d0:203:10a7::> has quit IRC (Read error: Connection reset by peer)[04:34:58] *** Plagman <Plagman!~quassel@2001:41d0:203:10a7::> has joined ##OpenGL[04:37:32] *** cshzg <cshzg!~dietary@181.53.12.207> has quit IRC (Quit: Leaving.)[04:42:40] *** Plagman <Plagman!~quassel@2001:41d0:203:10a7::> has quit IRC (Ping timeout: 264 seconds)[04:43:40] *** CoolerY <CoolerY!~coolerext@14.139.38.135> has joined ##OpenGL[04:44:18] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has quit IRC (Ping timeout: 248 seconds)[04:51:31] *** cshzg <cshzg!~dietary@181.53.12.207> has joined ##OpenGL[04:52:06] *** guardianx <guardianx!~neon@pa49-197-25-130.pa.qld.optusnet.com.au> has joined ##OpenGL[04:59:53] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[05:05:59] *** Plagman <Plagman!~quassel@2001:41d0:203:10a7::> has joined ##OpenGL[05:06:20] *** guardianx <guardianx!~neon@pa49-197-25-130.pa.qld.optusnet.com.au> has quit IRC (Quit: Konversation terminated!)[05:09:12] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Ping timeout: 245 seconds)[05:31:06] *** SwiftMatt <SwiftMatt!~Objective@2601:282:4300:3e:9541:a657:5b4b:ae80> has joined ##OpenGL[05:40:54] *** Jeanne-Kamikaze <Jeanne-Kamikaze!~Jeanne-Ka@205.234.124.69> has joined ##OpenGL[05:42:42] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[05:43:11] *** guardianx <guardianx!~neon@60-241-62-242.tpgi.com.au> has joined ##OpenGL[05:59:31] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[06:13:04] <ville> here's a fairly interesting looking paper for font rendering http://jcgt.org/published/0006/02/02/ at least i had missed this previously[06:16:16] <ville> few years back i remember someone implemented an improved sdf that promised sharp corners? did that paper ever get published. kind of lost track[06:24:12] *** gb_away <gb_away!~hhhhh@3-230-16-190.fibertel.com.ar> has quit IRC (Ping timeout: 245 seconds)[06:26:00] *** gb_away <gb_away!~hhhhh@3-230-16-190.fibertel.com.ar> has joined ##OpenGL[06:29:59] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Ping timeout: 244 seconds)[06:50:26] *** rizzo <rizzo!~RizzoTheR@dyndsl-037-138-070-225.ewe-ip-backbone.de> has joined ##OpenGL[06:53:22] *** lilabsence <lilabsence!~RizzoTheR@dyndsl-037-138-177-113.ewe-ip-backbone.de> has quit IRC (Ping timeout: 245 seconds)[06:53:53] *** cshzg <cshzg!~dietary@181.53.12.207> has quit IRC (Quit: Leaving.)[07:47:31] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[07:47:32] *** northcode <northcode!~northcode@vps-29.35.101.185.stwvps.net> has quit IRC (Ping timeout: 245 seconds)[07:47:32] *** karalaine <karalaine!karalaine@unaffiliated/karalaine> has quit IRC (Ping timeout: 245 seconds)[07:47:57] *** BobBarker <BobBarker!~null@basedhost.com> has quit IRC (Ping timeout: 245 seconds)[07:48:38] *** BobBarker <BobBarker!~null@2607:5300:60:1c3f::> has joined ##OpenGL[07:48:59] *** northcode <northcode!~northcode@vps-29.35.101.185.stwvps.net> has joined ##OpenGL[07:49:18] *** immibis <immibis!~immibis@222-153-90-196-fibre.sparkbb.co.nz> has joined ##OpenGL[07:50:16] *** karalaine <karalaine!karalaine@unaffiliated/karalaine> has joined ##OpenGL[07:55:21] *** guardianx <guardianx!~neon@60-241-62-242.tpgi.com.au> has quit IRC (Quit: Konversation terminated!)[07:59:12] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[08:11:28] *** Jeanne-Kamikaze <Jeanne-Kamikaze!~Jeanne-Ka@205.234.124.69> has quit IRC (Remote host closed the connection)[08:20:59] *** glYoda <glYoda!~kristinam@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[08:23:03] *** glYoda <glYoda!~kristinam@c-73-25-27-206.hsd1.or.comcast.net> has joined ##OpenGL[08:28:22] *** CoolerY <CoolerY!~coolerext@14.139.38.135> has quit IRC (Ping timeout: 245 seconds)[08:42:54] *** JernejL <JernejL!~JernejL@cpe-212-18-43-254.static.amis.net> has quit IRC (Read error: Connection reset by peer)[08:43:11] *** JernejL <JernejL!~JernejL@cpe-212-18-43-254.static.amis.net> has joined ##OpenGL[08:46:00] *** Takums <Takums!~Tak@73.90.207.81> has joined ##OpenGL[08:46:31] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has quit IRC (Read error: Connection reset by peer)[08:48:18] *** Nicmavr <Nicmavr!~Nicmavr@unaffiliated/nicmavr> has joined ##OpenGL[08:51:37] *** Takums <Takums!~Tak@73.90.207.81> has quit IRC (Disconnected by services)[08:51:38] *** Takums54 <Takums54!~Tak@73.90.207.40> has joined ##OpenGL[08:52:12] *** Takums54 is now known as Takums[09:00:34] *** crankslider <crankslider!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[09:19:31] *** glYoda <glYoda!~kristinam@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[09:21:48] *** glYoda <glYoda!~kristinam@c-73-25-27-206.hsd1.or.comcast.net> has joined ##OpenGL[09:31:49] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[09:44:22] *** pie_ <pie_!~pie_@unaffiliated/pie-/x-0787662> has quit IRC (Ping timeout: 252 seconds)[09:45:46] *** pie_ <pie_!~pie_@unaffiliated/pie-/x-0787662> has joined ##OpenGL[09:50:14] *** pie_ <pie_!~pie_@unaffiliated/pie-/x-0787662> has quit IRC (Ping timeout: 252 seconds)[09:57:03] *** SwiftMatt <SwiftMatt!~Objective@2601:282:4300:3e:9541:a657:5b4b:ae80> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[10:00:34] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has joined ##OpenGL[10:20:01] *** wrobinson <wrobinson!~0x@102.119.214.123> has joined ##OpenGL[10:21:35] <wrobinson> hi. new here. ayone able to help diagnose an issue with linux optirun (using nvidia card)?[10:23:11] <wrobinson> when I run a basic window with one triangle (can you guess I'm not an expert yet?) using mesa, running on built-in intel chip, there's little to no cpu usage[10:23:36] <wrobinson> but running with optirun, which uses my nvidia card, I see 12-14% cpu usage, which seems a little strange[10:23:39] <zid> nvidia driver likes to while(1) CheckForVblank(); in opengl[10:23:48] <zid> at least on windows[10:24:27] <wrobinson> damn, guess that could be it[10:25:02] <zid> testable with a sleep call[10:25:27] <wrobinson> ack, I'll look into it[10:25:29] <wrobinson> thanks a lot[10:25:59] <Yaniel> easy to check - is vsync on?[10:29:18] <wrobinson> sleep definitely lowers cpu usage[10:29:32] <zid> That'll be $200[10:29:35] <wrobinson> not sure how to check if vsync is on (shall go research)[10:29:49] * wrobinson 's jaw hits the floor[10:30:07] <Yaniel> glfwSwapInterval(1 or 0) to enable/disable respectively[10:30:27] <Yaniel> or whatever the equivalent on your windowing library is[10:30:45] <wrobinson> (using glfw) thanks Yaniel[10:30:47] <Yaniel> and make sure you don't have vsync forced by the driver or compositor[10:31:08] *** BPL <BPL!~BPL@102.56.27.77.dynamic.reverse-mundo-r.com> has joined ##OpenGL[10:31:09] <Yaniel> ...then again you can also see it by measuring frame times[10:31:25] <zid> My prefered method is to just flicker between two colours[10:31:41] <wrobinson> something is niggling in the back of my brain - from couple years back - possibly having set vsync for comp, to prevent tearing (sound possible?)[10:31:42] <zid> because it's incredibly simple and I an incredibly simple[10:31:54] <Yaniel> yes, the point of vsync is to prevent tearing[10:31:57] <zid> s/an/am[10:32:00] <wrobinson> :)[10:33:55] <wrobinson> so, it's one thing diagnosing this. is it then practical to turn off vsync for my app? I assume using sleep would hurt performance ;)[10:34:06] <zid> depends what you mean by performance[10:34:23] <zid> vsync off will use about the same amount of cpu[10:34:35] <Yaniel> vsync means glfwSwapBuffers literally pauses until the screen refreshes[10:34:37] <zid> because you'll just be rendering 6000 frames instead of 60 frames + spinning[10:36:59] <Yaniel> how the pausing is done depends on the driver, it can just spin in a NOP loop, or it can do something smarter[10:37:51] <zid> good news, if you use d3d it is interrupt driven and works properly[10:37:58] <zid> opengl 100% first class citizen[10:38:11] <Yaniel> you probably aren't using d3d on linux[10:38:15] <BPL> it feels to me turning off v-sync is a good recipe to shorten the life of the GPU[10:38:21] <zid> Try to stop me![10:38:31] <Yaniel> I mean yes, dxvk exists[10:38:55] <zid> Don't worry BPL, the stalls from the cpu having to calculate things then issue commands limits your framerate[10:39:02] <zid> easiest way to burn a gpu up is to have a very LOW framerate[10:39:15] <zid> and just fully load it as long and hard as possible[10:41:34] <wrobinson> probably won't be using d3d[10:41:51] <zid> yea we covered that I think, just raging at nvidia[10:41:59] <wrobinson> no worries[10:42:07] <Yaniel> you can just quote linus for that :P[10:42:11] <wrobinson> i'm not keen on microsoft either[10:42:50] <zid> You know, I don't think I've ever rendered an triangle in opengl[10:42:55] <zid> I always went for the cube[10:43:59] <wrobinson> I'm just trying to get my head around the basics, prepping for forgetting all the fixed pipeline stuff from last time I learnt opengl[10:44:13] <zid> the basics are pretty easy honestly[10:45:09] <wrobinson> so ultimately, there's not much I can do to lower cpu usage when using the nvidia driver? or am I misunderstanding and being a plank?[10:45:28] <zid> make the gpu work harder than the cpu :P[10:45:50] <zid> If you can get one draw call to take 10ms for barely any cpu work, cpu use is going to plummet ;)[10:45:55] <wrobinson> zid: true. And i've written my own matrix transforms before and quaternions and the like, so I should be alright-ish[10:46:04] <zid> oh I still can't do quats I'm dumb[10:46:53] <wrobinson> zid: heh, didn't look at the issue that way - makes sense. The more I learn, the more stupid I feel[10:47:08] *** Takums <Takums!~Tak@73.90.207.40> has quit IRC (Ping timeout: 245 seconds)[10:47:28] <zid> anyway modern ogl is easy, transform your shit into a -1,-1 to 1,1 cube, vertex shader is ran over every vert, frag shader is ran over every texel[10:47:42] <zid> and you can pass shit between, and have them vary over the range, or have them be static[10:47:43] <Yaniel> *fragment[10:47:55] <zid> err yea I literally said frag *and* texel, how did I manage that[10:47:55] *** Takums <Takums!~Tak@73.90.207.40> has joined ##OpenGL[10:50:27] *** crankslider <crankslider!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Ping timeout: 245 seconds)[10:51:14] <wrobinson> :)[11:01:34] <wrobinson> Also found that mesa defaults to opengl version 3, but my nvidia card to 4.6[11:01:46] <wrobinson> my mesa driver can handle 4.5 if i force it[11:02:17] <Yaniel> that's because your mesa driver probably doesn't do compatibility profile[11:02:31] <wrobinson> it does compatability by default[11:02:31] <Yaniel> and you only ever get core profile if you ask explicitly[11:02:40] <wrobinson> exactly[11:02:51] <Yaniel> profiles didn't exist before 3.1[11:03:09] <Yaniel> IIRC they were introduced in 3.2 but mesa sort of started doing them in 3.1[11:03:16] <zid> wrobinson: Were you planning to pay by cash or gift card btw?[11:03:37] <wrobinson> ack - but if i ask for 4.5, then the nvidia driver obviously won't use 4.6[11:04:02] <wrobinson> should i stop fussing about this and just write for 4.5 at most ?[11:04:03] <Yaniel> it absolutely can give you 4.6 if you ask for 4.5[11:04:29] <Yaniel> the requirement is that you get something that is compatible with what you ask for[11:04:47] <wrobinson> i see[11:05:03] <Yaniel> compat does not count as compatible with core though, I thnk[11:05:11] <Yaniel> because the point of core is that old stuff is *removed[11:05:12] * wrobinson starts to sweat a little noting zid's comment[11:05:34] <wrobinson> Yaniel: I'm trying to stick with core. Have no reason not to for my little project[11:05:53] <Yaniel> there isn't much reason not to even in larger projects[11:05:57] <Yaniel> or especially there[11:06:19] <wrobinson> that's my feeling too[11:06:22] <immibis> unless you don't understand core yet[11:06:34] <immibis> (in which case learn it)[11:06:40] <wrobinson> immibis: I'm learning so may as well learn core[11:06:46] <immibis> is there a reason to use compatibility mode in ANY project?[11:07:00] <wrobinson> immibis: old projects that don't want to migrate[11:07:02] <wrobinson> i guess[11:07:04] <Yaniel> if there is a lot of existing legacy gl code then yes[11:07:08] <zid> wrobinson: I've got a discount code you can use if you like, 40% off[11:07:13] <immibis> true. if you want to mix legacy and modern code[11:07:16] <wrobinson> :s[11:07:24] <immibis> btw when is opengl itself officially becoming legacy?[11:07:37] *** Takums <Takums!~Tak@73.90.207.40> has quit IRC (Ping timeout: 246 seconds)[11:07:39] <wrobinson> zid: you know, I would if I could[11:07:41] <Yaniel> not anytime soon[11:08:01] <immibis> daily reminder that opengl is almost legacy and vulkan is not[11:08:21] <zid> daily reminder that nobody can actually kill opengl[11:08:43] <wrobinson> i never wanted to code only for windows, so for me that makes d3d a no[11:08:47] <Yaniel> sure you can, just look at apple[11:08:49] <immibis> zid: well if that's your criteria, then opengl 1.1 is not legacy[11:08:58] <immibis> legacy doesn't mean dead, necessarily[11:08:58] <zid> opengl 1.1 is not dead[11:08:59] <Yaniel> and all the CAD software made for mac[11:09:00] <wrobinson> other than opengl that basically leaves me with vulkan, but i've read it's still a little too young[11:09:02] <zid> it is legacy[11:09:05] <zid> but isn't dead[11:09:38] <zid> vulkan doesn't seem useful unless your main perf problem after spending thousands of hours on other stuff, is that the driver is being silly with caches[11:09:39] <Yaniel> the real question is when does someone finally implement gl on top of vulkan[11:09:42] <zid> but maybe I'm dumb[11:09:43] <wrobinson> and I don't have the energy to write multiple custom implementations for each platform[11:10:16] <immibis> Yaniel: probably when driver maintainers don't like maintaining the old version. I think Mesa implements GL<3 on top of GL>3[11:10:43] <Yaniel> https://github.com/kbiElude/VKGL there it is already :3[11:11:25] <wrobinson> sorry to jump back slightly; but requesting profile 4.5 gives me version string of 4.5 for both mesa and nvidia - is there a way (is it necessary?) to get 4.6 for nv and 4.5 for mesa?[11:11:48] <Yaniel> why would you[11:11:57] <wrobinson> that's what I'm trying to make sense of[11:11:58] <Yaniel> you code for a specific version and request that[11:12:14] <wrobinson> ack[11:12:29] <wrobinson> ...I have a tendency to over-complicate things[11:12:33] <Yaniel> as long as whatever you get supports the things you use you don't need to care[11:12:42] <wrobinson> makes sense[11:12:43] <zid> yea, what 4.6 feature do you want? :P[11:12:53] <zid> I couldn't even tell you what 4.6 did[11:12:55] <Yaniel> and the easiest way to ensure you get what you need is to settle on the features provided by a specific version[11:13:00] <wrobinson> chances are, I probably won't need anything above 4.0[11:13:17] <Yaniel> you'll want 4.3 for the debug callback[11:13:34] <wrobinson> checking features means reading the OpenGL sepcs right?[11:13:39] <wrobinson> Yaniel: ooh, good point[11:13:41] <Yaniel> and probably compute shaders[11:13:44] <zid> That's handy because I just plucked a random number out of thin air and coded against 4.3[11:13:52] <wrobinson> hehe[11:14:02] <Yaniel> not sure when compute shaders were added[11:14:23] <wrobinson> I remember last time I wrote opengl, debugging gpu was horrendous[11:14:41] <zid> does nvidia nsight work on linux[11:14:43] <Yaniel> docs.gl is pretty good for quickly checking stuff, but when in doubt read the spec[11:14:49] <Yaniel> renderdoc works everywhere :3[11:14:58] <zid> nsight is badass, nto used renderdoc[11:15:15] <zid> There's a thing called "linux graphics debugger" at least[11:15:29] <Yaniel> apitrace has a gui nowadays too[11:15:30] <zid> oh it's like nsight but 10 versions behind by the looks of it[11:15:43] <zid> apitrace + dumps uniforms[11:15:56] <zid> nsight lets you click geometry and stuff :P[11:17:29] <wrobinson> zid: apparently i have nsight installed so I guess, yes[11:17:32] <zid> cool[11:17:44] <zid> ooh yea renderdoc looks good too[11:17:55] <zid> almost identical to codexl[11:17:56] <wrobinson> dear god, it uses java[11:18:13] <zid> but seems to have more features a bit closer to nsight[11:18:27] *** charlie5 <charlie5!~rod@pa49-181-153-64.pa.nsw.optusnet.com.au> has joined ##OpenGL[11:21:35] <wrobinson> shall look into renderdoc, thanks for the info[11:25:33] *** ratchetfreak <ratchetfreak!c351a8d8@195.81.168.216> has joined ##OpenGL[11:28:57] *** Takums <Takums!~Tak@73.90.204.126> has joined ##OpenGL[11:39:28] *** Takums <Takums!~Tak@73.90.204.126> has quit IRC (Ping timeout: 272 seconds)[11:40:35] <wrobinson> i forgot nsight was for eclipse :/[11:40:51] <wrobinson> I have actively avoided that heavy app for years, but seems it snuck by and is also installed...[11:44:38] *** bitwinery <bitwinery!~bruno@c-71-59-192-149.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 244 seconds)[11:57:07] *** Takums <Takums!~Tak@73.90.204.191> has joined ##OpenGL[12:01:52] *** Takums <Takums!~Tak@73.90.204.191> has quit IRC (Ping timeout: 246 seconds)[12:05:51] *** charlie5 <charlie5!~rod@pa49-181-153-64.pa.nsw.optusnet.com.au> has quit IRC (Ping timeout: 258 seconds)[12:05:51] *** Takums <Takums!~Tak@73.90.205.41> has joined ##OpenGL[12:06:51] *** mukunda <mukunda!mukunda@adsl-68-19-251-109.bna.bellsouth.net> has quit IRC (Ping timeout: 244 seconds)[12:12:05] *** Takums <Takums!~Tak@73.90.205.41> has quit IRC (Read error: Connection reset by peer)[12:15:01] *** Takums <Takums!~Tak@73.90.205.41> has joined ##OpenGL[12:25:17] *** Takums <Takums!~Tak@73.90.205.41> has quit IRC (Ping timeout: 268 seconds)[12:31:08] *** pie_ <pie_!~pie_@unaffiliated/pie-/x-0787662> has joined ##OpenGL[12:32:00] *** pie_ <pie_!~pie_@unaffiliated/pie-/x-0787662> has quit IRC (Remote host closed the connection)[12:32:24] *** pie_ <pie_!~pie_@unaffiliated/pie-/x-0787662> has joined ##OpenGL[12:34:24] <wrobinson> trying out renderdoc; looks cool[12:34:34] <wrobinson> of course i'm stumped when trying to use along with optirun[12:37:03] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined ##OpenGL[12:38:33] <Yaniel> I suggest you forget about optirun for now[12:38:50] <Yaniel> until you really need that extra power of the dedicated GPU[12:39:35] <Yaniel> from what I've heard it's nothing but trouble anyway[12:45:49] <wrobinson> fair point[12:46:08] <wrobinson> appreciated[12:46:37] <wrobinson> dedicated GPU nothing but trouble, or optirun? I'm guessing the latter[12:46:56] <Yaniel> GPU switching[12:47:05] <Yaniel> especially on linux[12:48:23] <wrobinson> aye, it was a bit of a pain to get it sorted in the first place[12:49:00] <Yaniel> and if you want to write correct gl code the nvidia drivers are worse anyway :P[12:49:23] <Yaniel> since they let you do stuff that is against the gl spec[12:50:07] <wrobinson> ah[12:50:22] <wrobinson> but haven't they also implemented some things better than mesa?[12:50:49] <wrobinson> or if not better, then implemented some things that mesa has not?[12:50:54] <Yaniel> sure[12:51:03] <Yaniel> compatibility profile for all gl versions they support for oen[12:51:37] <Yaniel> one*[12:52:15] <Yaniel> but they also allow you to draw without shaders and VAOs in core profile contexts, which is not allowed[12:52:25] <Yaniel> not allowed by the spec[12:52:43] <wrobinson> oh, weird[12:52:45] <Yaniel> and pretty much defeats the point of using core profile in the first place[12:52:51] <wrobinson> exactly[12:52:55] <wrobinson> again, I guess I should look into the specs and see what I really need for my project, and if mesa covers it (likely it does)[12:53:09] <Yaniel> what are you doing?[12:53:49] <Yaniel> if you don't need compute or tessellation, 3.3 is an excellent target[12:54:11] <Yaniel> it has most of the modern ergonomics improvements and runs on stuff from 15 years ago[12:55:00] <wrobinson> initially going to write a simple graphics engine[12:55:13] <Yaniel> that doesn't really say anything[12:55:39] <zid> I wanted to do that but it turned out I hated data processing[12:55:47] <zid> so I just started making plasma in shaders instead[12:56:11] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[12:56:57] <wrobinson> 2d camera, 3d camera, perspective, orthographic, keyboard, mouse input, some basic ui components (sliders, etc) - initially for use in visualising the suns movement through the sky at arbitrary coordinates[12:57:33] <wrobinson> zid: I'm not entirely looking forward to that either, but really want to get my head around "sensible" data-oriented design[12:58:04] <zid> I spent more hours messing with model formats and texture formats etc than I did with opengl or shaders[12:58:09] <zid> and eventually got bored of it[12:59:12] <wrobinson> also, will need to handle transparent, double-sided surfaces that can view themselves through themselves (can't remember the terminology...)[12:59:36] <wrobinson> zid: I'm trying not to focus on the hours of work ahead :)[13:00:27] <zid> https://cdn.discordapp.com/attachments/417023075348119556/451155845892276244/unknown.png I did made a dragonboi though[13:01:29] <wrobinson> and some level of accurate shadows[13:01:38] <zid> no shadows, that's just lighting[13:01:40] <zid> which is why it's wrong af[13:02:04] <zid> The light is coming from behind the dragon which is why his foot is lit up like that, but it'd technically be occluded by the neck[13:02:07] <wrobinson> so yeah, shouldn't need compute or tessellation[13:03:17] <wrobinson> sorry zid I was still blabbering about what I'll need to implement for my project[13:03:21] <Yaniel> then request 3.3 core andd enable debug output if one of the relevant extensions is present[13:03:28] <wrobinson> not bad work on the dragon though :)[13:03:36] <wrobinson> Yaniel: ack thanks[13:03:43] <Yaniel> glad has some nice helpers for extension checking[13:03:44] <zid> took me forever to go from the input data to something I could render how I rendered it >_<[13:03:59] <Yaniel> as in, it generates global booleans for each extension you enable in the generator[13:04:19] <Yaniel> and sets them in gladLoadGL()[13:04:25] <zid> I wrote an X-Macro and my own extention loader :D[13:04:28] <wrobinson> cool - though I thought globals are frowned upon ;)[13:04:32] <zid> <-- slightly insane[13:04:37] <wrobinson> zid: yes[13:04:45] <Yaniel> they are[13:04:50] <dav1d> wrobinson: all OpenGL functions are basically globals[13:04:56] <zid> all functions*[13:04:57] <wrobinson> good point[13:04:59] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##OpenGL[13:05:13] <Yaniel> welllll there's the contexts-may-have-different-function-pointers thing[13:05:18] <dav1d> zid: not in a way opengl functions are[13:05:31] <Yaniel> but if you only have one context that's not a problem[13:05:39] <zid> dav1d: It's no different from libpng, if I am linking against libpng I can call them from any TU regardless[13:05:44] <dav1d> Also glad2 can generate into a struct instead of global functions and booleans :)[13:05:58] <zid> linker symbols be global[13:06:03] <dav1d> zid: it is, because libpng functions are not context specific[13:06:15] <Yaniel> you don't link against gl nowadays though[13:06:29] <Yaniel> you dlopen it at runtime[13:06:31] <dav1d> hence why you can link against libpng[13:06:56] <zid> filled out function pointer globals gives you the same visibility as linking, is what I am saying[13:07:04] <zid> it's no different to normal, in practice[13:07:26] <zid> if anything the fact they're function pointers allows you to limit the visibility more than normal linking, as an added bonus[13:11:45] <wrobinson> is glad basically an alternative to using GLEW?[13:12:05] <dav1d> yes, pretty much accomplishes the same[13:15:27] <Yaniel> did glew manage to get past glewExperimental=true; yet?[13:16:00] <wrobinson> looks like it[13:22:59] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has quit IRC (Quit: This computer has gone to sleep)[13:25:54] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Ping timeout: 248 seconds)[13:46:56] *** Foaly <Foaly!~Foaly@ppp-188-174-7-158.dynamic.mnet-online.de> has joined ##OpenGL[14:02:34] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[14:03:20] <wrobinson> also, I lie, glew still requires glewExperimental = GL_TRUE; "D[14:06:06] <wrobinson> well, not "requires"[14:06:41] <Yaniel> oh well[14:06:56] <Yaniel> there are way better alternatives now anyway[14:07:59] <wrobinson> to glew you mean?[14:08:04] <Yaniel> yes[14:08:19] <wrobinson> damn, every time i think i'm getting somewhere, i realise i still don't knwo anything[14:08:22] <zid> I've still yet to use a helper lib[14:08:30] <wrobinson> any reading suggestions Yaniel ?[14:08:43] <zid> my little xmacros and a 10 line boilerplate for windows/linux init were plenty[14:09:00] <Yaniel> channel topic[14:09:13] <wrobinson> cheers[14:09:25] <Yaniel> basically use SDL2 or GLFW and glad[14:09:47] <wrobinson> figured glad might be the way[14:11:52] *** Kingsquee <Kingsquee!~kingsquee@node-1w7jr9qmxqrpow98mke9t5qou.ipv6.telus.net> has quit IRC (Quit: https://i.imgur.com/qicT3GK.gif)[14:26:17] *** DrBenway <DrBenway!~DrBenway@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[14:32:39] *** Foaly <Foaly!~Foaly@ppp-188-174-7-158.dynamic.mnet-online.de> has quit IRC (Quit: When in doubt, hit it with the wrench.)[14:36:10] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Ping timeout: 244 seconds)[14:41:14] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has joined ##OpenGL[15:03:31] *** dansho <dansho!~dansho4@71-84-161-204.dhcp.astr.or.charter.com> has quit IRC (Quit: Leaving)[15:04:47] *** Cyp_ <Cyp_!~Cyp_@2a05:f6c7:2883::2> has quit IRC (Remote host closed the connection)[15:07:48] *** Cyp_ <Cyp_!~Cyp_@2a05:f6c7:2883::2> has joined ##OpenGL[15:12:32] *** DrGonzo <DrGonzo!~DrGonzo@modemcable080.164-57-74.mc.videotron.ca> has quit IRC (Ping timeout: 245 seconds)[15:13:16] *** Cyp_ <Cyp_!~Cyp_@2a05:f6c7:2883::2> has quit IRC (Ping timeout: 252 seconds)[15:31:43] *** SwiftMatt <SwiftMatt!~Objective@2601:282:4300:3e:998f:8c58:f85e:1d41> has joined ##OpenGL[15:40:07] *** Cyp_ <Cyp_!~Cyp_@2a05:f6c7:2883::2> has joined ##OpenGL[15:44:37] *** immibis <immibis!~immibis@222-153-90-196-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 245 seconds)[15:44:48] *** Cyp_ <Cyp_!~Cyp_@2a05:f6c7:2883::2> has quit IRC (Ping timeout: 252 seconds)[15:49:15] *** bayoubengal <bayoubengal!~bayoubeng@rrcs-50-84-94-202.sw.biz.rr.com> has quit IRC (Quit: Leaving...)[15:50:30] *** Cyp_ <Cyp_!~Cyp_@2a05:f6c7:2883::2> has joined ##OpenGL[15:51:47] *** SwiftMatt <SwiftMatt!~Objective@2601:282:4300:3e:998f:8c58:f85e:1d41> has quit IRC (Ping timeout: 250 seconds)[15:59:18] *** mukunda <mukunda!mukunda@adsl-68-19-251-109.bna.bellsouth.net> has joined ##OpenGL[16:12:55] *** Vasco_O is now known as Vasco[16:21:22] *** pa <pa!~pa@unaffiliated/pa> has quit IRC (Ping timeout: 248 seconds)[16:34:10] *** pa <pa!~pa@unaffiliated/pa> has joined ##OpenGL[16:56:25] *** groton <groton!~groton@unaffiliated/groton> has joined ##OpenGL[17:38:04] *** learningc <learningc!~learningc@121.122.92.39> has joined ##OpenGL[17:52:09] *** cfoch <cfoch!uid153227@gateway/web/irccloud.com/x-lhgrelulefzsygks> has joined ##OpenGL[17:58:22] *** mukunda <mukunda!mukunda@adsl-68-19-251-109.bna.bellsouth.net> has quit IRC (Ping timeout: 245 seconds)[18:03:57] *** ratchetfreak <ratchetfreak!c351a8d8@195.81.168.216> has quit IRC (Remote host closed the connection)[18:08:44] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has joined ##OpenGL[18:08:50] *** blackpawn <blackpawn!blackpawn@gateway/vpn/privateinternetaccess/blackpawn> has joined ##OpenGL[18:12:36] *** gehn <gehn!gehn@gateway/vpn/privateinternetaccess/gehn> has joined ##OpenGL[18:19:57] *** groton <groton!~groton@unaffiliated/groton> has quit IRC (Quit: groton)[18:23:21] *** Singmyr <Singmyr!~Singmyr@c83-253-123-62.bredband.comhem.se> has joined ##OpenGL[18:40:47] *** nitroxis <nitroxis!n@nxs.re> has quit IRC (Read error: Connection reset by peer)[18:48:22] *** glYoda <glYoda!~kristinam@c-73-25-27-206.hsd1.or.comcast.net> has quit IRC (Quit: glYoda)[18:49:12] *** moser <moser!~moser@113.119.56.174> has joined ##OpenGL[18:51:29] *** nitroxis <nitroxis!n@nxs.re> has joined ##OpenGL[18:52:40] *** moser_ <moser_!~moser@113.119.70.167> has quit IRC (Ping timeout: 272 seconds)[19:05:14] *** loomy__ <loomy__!~loomy__@modemcable227.52-19-135.mc.videotron.ca> has joined ##OpenGL[19:05:20] *** learningc <learningc!~learningc@121.122.92.39> has quit IRC (Ping timeout: 272 seconds)[19:05:57] *** learningc <learningc!~learningc@121.122.92.39> has joined ##OpenGL[19:06:11] *** loomy__ <loomy__!~loomy__@modemcable227.52-19-135.mc.videotron.ca> has quit IRC (Client Quit)[19:23:43] *** mkoncek <mkoncek!~Thunderbi@adsl-d94.84-47-66.t-com.sk> has joined ##OpenGL[19:29:08] *** cshzg <cshzg!~dietary@181.53.12.207> has joined ##OpenGL[19:40:39] *** learningc <learningc!~learningc@121.122.92.39> has quit IRC (Ping timeout: 268 seconds)[20:05:44] *** ratchetfreak <ratchetfreak!~ratchetfr@ptr-82s3g7l9r42569r41f4.18120a2.ip6.access.telenet.be> has joined ##OpenGL[20:07:11] *** CoolerY <CoolerY!~coolerext@14.139.38.134> has joined ##OpenGL[20:08:10] *** CoolerZ <CoolerZ!~coolerext@14.139.38.135> has quit IRC (Remote host closed the connection)[20:08:42] *** CoolerX <CoolerX!~coolerext@14.139.38.135> has joined ##OpenGL[20:11:31] *** CoolerY <CoolerY!~coolerext@14.139.38.134> has quit IRC (Ping timeout: 246 seconds)[20:12:07] *** wrobinson <wrobinson!~0x@102.119.214.123> has quit IRC (Ping timeout: 245 seconds)[20:27:56] <zid> Finally bothered to check out why my visualizer crashed if you gave it data files from the xbox360 port[20:28:09] <zid> Some idiot set some fields to -1 to mean 'unused'[20:28:24] *** mukunda <mukunda!mukunda@adsl-68-19-251-109.bna.bellsouth.net> has joined ##OpenGL[20:28:54] <derhass> if a software crashes with invalid input data, I would say the "idiot" is somewhere else[20:30:23] <zid> derhass: The crash was actually just because I ended up passing 0 indicies to opengl[20:30:50] <zid> my code bailed out early but still tried to render it with some empty fields[20:31:23] <zid> supporting this means changing my render path a bit, bleh[20:32:03] <zid> the PC ones use indexes this apparently does not, idk wht it's doing, un-rolled verts and you reconstruct the indicies with a for loop? *shrug*[20:33:15] <mkoncek> still wondering how to integrate a GUI into my application which uses GLFW[20:33:41] <mkoncek> i don't know if i should use opengl for GUI[20:34:03] <zid> I wouldn't if you don't have to, as personal preferance[20:34:27] <zid> I hate not having my own widgets[20:34:51] <mkoncek> i would like something more robust and this is not what i feel like reinventing[20:34:53] <zid> "ah yes, a really shitty menu implementation rather than windows', just what I always wanted, thanks, I hate it" :P[20:35:57] <mkoncek> but that would mean combining GLFW with even more libraries, like Qt or whatever[20:40:11] <mkoncek> i wonder what OpenMW uses, i know they have something called mygui[20:51:19] *** rook_flood <rook_flood!~ubuntu@ec2-3-218-42-239.compute-1.amazonaws.com> has quit IRC (Quit: WeeChat 1.9.1)[20:53:47] *** cshzg <cshzg!~dietary@181.53.12.207> has quit IRC (Ping timeout: 245 seconds)[20:55:31] *** rook_flood <rook_flood!~ubuntu@ec2-3-218-42-239.compute-1.amazonaws.com> has joined ##OpenGL[21:02:00] <zid> hmmmm wtf is going on with this, why is the index data missing :([21:02:13] <zid> not like I can render it without them unless I want a lovely spiderweb instead of a model[21:04:39] <zid> oh I bet the strip data is still there, but using the verts, duh[21:07:12] *** snyp <snyp!~Snyp@49.207.49.74> has joined ##OpenGL[21:09:49] *** cshzg <cshzg!~dietary@181.53.12.207> has joined ##OpenGL[21:17:12] *** crankslider <crankslider!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[21:19:14] <zid> no strip data either >_<[21:19:27] <zid> So the verts have just gotta be ordered somehow I guess[21:20:58] *** crankslider is now known as slidercrank[21:38:27] *** Foaly <Foaly!~Foaly@ppp-188-174-7-158.dynamic.mnet-online.de> has joined ##OpenGL[21:45:05] <Yatekii> anyone here using nsight and can help me set it up?[21:46:02] <Yatekii> when I want to profile the shader pileine I always get the error that either profiling is not available or I don't have the permission. I already enabled all permission stuff and run as admin. I have a GTX970 ... so I assume it should be able to profile ...[22:04:38] *** cshzg <cshzg!~dietary@181.53.12.207> has quit IRC (Ping timeout: 245 seconds)[22:06:07] *** RonaldsMazitis <RonaldsMazitis!~quassel@78.84.6.1> has joined ##OpenGL[22:07:37] *** Vasco is now known as Vasco_O[22:14:27] *** bitwinery <bitwinery!~bruno@c-71-59-192-149.hsd1.wa.comcast.net> has joined ##OpenGL[22:17:36] *** Kingsqueee <Kingsqueee!~kingsquee@node-1w7jr9qmxqrpow98mke9t5qou.ipv6.telus.net> has joined ##OpenGL[22:18:32] *** cshzg <cshzg!~dietary@181.53.12.207> has joined ##OpenGL[22:19:04] *** tab-key <tab-key!~mantra@2601:601:c980:8fd:4f8:144c:df39:87da> has joined ##OpenGL[22:21:26] <tab-key> what is the reason again for why the w component of the normal direction is set to 0 in the vertex shader?[22:21:54] <zid> because you set it to 0 somewhere?[22:22:11] <tab-key> yes but it's done to avoid perspective division or something[22:22:22] <tab-key> or to avoid scaling?[22:22:24] <tab-key> i forgot[22:22:58] <Foaly> doesn't perspective division only happen with the position?[22:23:00] <derhass> tab-key: the reason is that it is a direction[22:23:30] <tab-key> yes, so we don't want to perspective divide on a direction[22:23:47] *** KAHR-Alpha <KAHR-Alpha!~Alpha@2a01cb0d024a6600f9400fbb5ce81975.ipv6.abo.wanadoo.fr> has joined ##OpenGL[22:23:56] <Foaly> no, i mean, it wouldn't happen anyway?[22:24:08] <DarkUranium> Foaly, how would it not happen anyway?[22:24:20] <DarkUranium> There is no concept of a point/position vs direction at the matrix level.[22:24:23] <DarkUranium> It's all just linear algebra.[22:24:39] <DarkUranium> Hardware doesn't care either.[22:24:42] <Foaly> ahh, you mean the matrix multiplication[22:24:56] <Foaly> i thought you meant the perspective division[22:25:27] <Foaly> i think the 4th component as zero mostly means it won't be affected by translation[22:25:32] <DarkUranium> Same answer.[22:25:42] <derhass> tab-key: I wouldn't put it that way. setting w to 0 doesn't prevent perspective division. it is just no finite result any more[22:25:47] <DarkUranium> Perspective divide is done on a (x,y,z,w) vector. What that vector represents is irrelevant.[22:25:57] <DarkUranium> (we *say* it represents something, but mathematically ...)[22:26:02] <derhass> tab-key: more or less a meaningless operation[22:26:11] <Foaly> but there wouldn't be a perspecitive division done either way on the normal[22:26:19] <DarkUranium> Foaly, by what logic?[22:26:26] <DarkUranium> There is no concept of a normal at that level, like I already said.[22:26:26] <Foaly> why would it do?[22:26:32] <DarkUranium> How would it know it's a normal?[22:26:38] <derhass> what is "it"?[22:26:54] <DarkUranium> derhass, that (x,y,z,0) vector, I'd assume.[22:27:13] <derhass> a vector is a vector and not a divide operation[22:27:17] <DarkUranium> Though post-projection matrix, obviously not (...,0)[22:27:43] <DarkUranium> derhass, I'm referring to this <Foaly> doesn't perspective division only happen with the position?[22:27:56] <zid> DarkUranium: I'm content with my "Because you set it to 0" answer :P[22:28:05] <DarkUranium> zid, ha[22:28:09] <derhass> DarkUranium: and Foaly is right (when interpreting that statement in context)[22:28:38] <derhass> the most practical effect is that we don't want to translate directions[22:28:43] <DarkUranium> derhass, he also said this right after, implying that something "magically" knows what it is: <Foaly> no, i mean, it wouldn't happen anyway?[22:29:19] <derhass> DarkUranium: perspective divide is automatically done on gl_Position (as per the space) somewhere down the pipeline[22:29:21] <DarkUranium> Ignoring the fact that this is mangling up 2 concepts (w=0 in a vector that's about to be multiplied by [I guess, given the context] MVP matrix with perspective divide)[22:29:22] <Foaly> perspective division happens after the vertex shader afaik[22:29:29] <DarkUranium> (or at least projection)[22:29:31] <DarkUranium> derhass, that's my point.[22:29:43] <DarkUranium> derhass, it cannot know what's a normal and what isn't. All it cares about is (x,y,z,w).[22:29:56] <derhass> DarkUranium: strange, I understand that as Foaly's point[22:30:01] <DarkUranium> *shrug*[22:30:05] <DarkUranium> I blame it on English being ambigious then.[22:30:44] <Foaly> what i'm saying is that no perspective division takes place on the normal. no matter whether the 4th component it zero or not[22:31:10] *** slime <slime!~slime73@blk-215-81-93.eastlink.ca> has joined ##OpenGL[22:32:55] <tab-key> vNormal = (gWorld*vec4(Normal, 0.0)).xyz;[22:32:57] <zid> is there *any* use case for a 4 component normal?[22:33:01] <snyp> Foaly: no... the normals are simply interpolated over the triangle. it's only the positions that need to be brought to clip space (and then persp div).[22:33:03] <zid> I just keep them as vec3[22:33:04] <tab-key> so that is done just to avoid translating the normal[22:33:25] <Foaly> snyp, you may have misread my statement[22:33:35] <snyp> Foaly: sorry[22:33:39] <snyp> missed the 'no'[22:33:54] * snyp increases terminal font[22:34:01] * snyp size[22:34:06] <Foaly> zid, to muliply it with a 4x4 matrix[22:34:46] <DarkUranium> tab-key, note that your equation is only correct in some cases.[22:34:52] <DarkUranium> (granted, they are common)[22:34:57] *** Takums <Takums!~Tak@73.90.204.132> has joined ##OpenGL[22:35:07] <derhass> depending on what gWorld is[22:35:11] <DarkUranium> derhass, exactly.[22:35:25] <derhass> so who can say if it is "correct" or not without further context?[22:35:26] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has quit IRC (Remote host closed the connection)[22:35:27] <tab-key> just the world matrix for the vertex[22:35:34] <DarkUranium> Non-uniform scaling is the usual one.[22:35:58] <DarkUranium> derhass, well, when giving an equation without a context, I think it's important to point out it doesn't always work.[22:36:38] *** learningc <learningc!~learningc@121.122.92.39> has joined ##OpenGL[22:36:55] <tab-key> so if there is a 1 for the 4th component instead of 0 then it can get translated?[22:37:14] <derhass> tab-key: what is a translated direction?[22:37:42] <tab-key> ok ic[22:38:19] *** lone-pine <lone-pine!~lone-pine@2600:8800:1d00:2d5::bf80> has joined ##OpenGL[22:38:53] <lone-pine> What is it called when a fragment is discarded because it is too close to the camera? (Z value is too small)[22:39:10] <lone-pine> Is that the same as the depth test? Because I have depth test disabled and fragments are still being discarded[22:39:13] <Foaly> clipping?[22:39:15] <tab-key> near plane clipping?[22:39:24] <lone-pine> How can I prevent or disable that?[22:39:39] <tab-key> change the near plane in projection matrix if i remember right[22:39:41] <zid> change your matrix[22:40:00] <DarkUranium> You can't, there's a mathematical reason behind it. You can make it closer, though (at the cost of precision)[22:40:02] <zid> Not that it's particiularly nice I imagine[22:40:39] <derhass> well, you can enable depth clamping[22:40:53] <derhass> but you need to know what you're doing[22:40:56] <tab-key> just set near plane to something small like .1f[22:41:06] *** learningc <learningc!~learningc@121.122.92.39> has quit IRC (Ping timeout: 248 seconds)[22:41:12] <derhass> so yes, clipping against near and far plane _can_ be disabled. sort of[22:47:53] *** slidercrank <slidercrank!~slidercra@ircpuzzles/2015/april-fools/fifth/slidercrank> has joined ##OpenGL[22:49:28] <lone-pine> yeah depth clamping means no real depth test for the fragments that are clamped[22:51:21] *** Foaly <Foaly!~Foaly@ppp-188-174-7-158.dynamic.mnet-online.de> has quit IRC (Quit: When in doubt, hit it with the wrench.)[22:51:46] *** salamanderrake <salamanderrake!~quassel@cpe-24-165-200-146.neo.res.rr.com> has joined ##OpenGL[22:52:08] *** Takums <Takums!~Tak@73.90.204.132> has quit IRC (Ping timeout: 245 seconds)[22:53:28] <zid> I imagine if you don't have the near plane set to something reasonably far away you'd end up with like, 1 texel covering the entire screen[22:53:36] <zid> as you walked up to a wall[22:54:04] <lone-pine> So, a source game?[22:54:35] <zid> did someone at valve piss on your christmas presents?[22:54:36] <derhass> lone-pine: so what problem do you actually try to solve here?[22:55:20] <derhass> if you need the depth test, it automatically follows that you can only represent a discrete number of different depths[22:56:03] <lone-pine> derhass, I have a rain/snow effect in my game, it's an inverted layered sphere that surrounds the camera, and some of the layers were being clipped[22:56:29] <derhass> sounds more like far plane than near plane to me[22:56:38] <derhass> but maybe not[22:56:41] <lone-pine> yeah it was far plane actually[22:56:56] <derhass> far plane is easy to get rid of[22:58:02] <lone-pine> I fixed it by adjusting the space between the layers... it's just frustrating because I feel like I don't have a lot of space to work with, I must be doing my viewport wrong[22:59:11] *** Takums <Takums!~Tak@73.90.205.122> has joined ##OpenGL[22:59:27] <zid> view.. truncated square based pyramid of infinite height?[22:59:31] <zid> geometry is hard[23:00:04] *** GyroW <GyroW!~GyroW@unaffiliated/gyrow> has quit IRC (Ping timeout: 276 seconds)[23:00:42] <lone-pine> My z window is set to (2*camera_dist*factor_based_on_aspect_ratio, 1*...) and I'm using orthographic perspective[23:01:47] <zid> if you're doing ortho you don't need to care about how far away your back plane is at least right[23:02:23] <zid> You could divide it by a gajillion for all it mattered[23:02:41] <lone-pine> how can I disable far-plane clipping?[23:03:12] <zid> idk if gl lets you do it, but if it didn't technically you could do your own z-sorting and treat everything as 2D, if it's ortho?[23:04:16] <lone-pine> zid, well for this render pass it's just one relatively simple mesh. I could set gl_fragDepth = constant in the shader[23:04:19] <derhass> lone-pine: besides depth clamping, you really can't. in perspective projections, you can use an infinite far plane[23:05:12] <lone-pine> well I care about how far my far plane is because of the shadow map. I'm already not getting the resolution I want in the shadow map, which might be another viewport issue[23:05:13] <chrisf> lone-pine: gl_FragDepth is too late.[23:05:55] <derhass> lone-pine: please don't use the term viewport here[23:06:02] <chrisf> lone-pine: you need whatever transforms you're doing in your *vertex* shader to place things at the appropriate depths.[23:06:21] *** GyroW <GyroW!~GyroW@ptr-48ujrfdr5yxyejffeup.18120a2.ip6.access.telenet.be> has joined ##OpenGL[23:06:22] *** GyroW <GyroW!~GyroW@ptr-48ujrfdr5yxyejffeup.18120a2.ip6.access.telenet.be> has quit IRC (Changing host)[23:06:22] *** GyroW <GyroW!~GyroW@unaffiliated/gyrow> has joined ##OpenGL[23:06:34] <zid> You can have as much depth in your scene as you like in ortho though[23:06:44] <lone-pine> derhass, is projection the correct term?[23:06:57] <zid> Just multiply all your coordinates by 10000 right now and it should all look the same[23:07:25] <zid> scale by 10k, multiply position by 10k, divide by 10k in perspective transform[23:08:03] <lone-pine> zid, well I use the z value in the fragment shader to look up the fragment's location in the shadow map, which means that I need good precision (a relatively close near and far plane)[23:08:35] <zid> it has float precision regardless though[23:08:49] <zid> it's just about how you spread the values out in that same precision[23:09:24] <derhass> lone-pine: projection is much better in this contexts (just not in the mathematical sense)[23:09:42] *** mkoncek <mkoncek!~Thunderbi@adsl-d94.84-47-66.t-com.sk> has quit IRC (Quit: mkoncek)[23:09:42] *** salamanderrake <salamanderrake!~quassel@cpe-24-165-200-146.neo.res.rr.com> has quit IRC (Ping timeout: 268 seconds)[23:10:19] <derhass> lone-pine: so how does this all interact with the shadow mapping? are we talking about the shadow map render pass?[23:10:23] *** salamanderrake <salamanderrake!~quassel@2605:a000:122a:2139:3dbe:c8d6:f55b:7577> has joined ##OpenGL[23:11:31] <lone-pine> well for the weather object it doesn't matter except that I'm using the same matrix. I wouldn't have to, and maybe I'll use a different matrix for the weather box idk[23:12:29] <lone-pine> But since I'm thinking about it, I'm not getting the resolution I'd like on my shadows, and I think it's because I'm not using the right projection or bad math, either on the shadow pass or the main render pass[23:12:41] <derhass> or both[23:13:05] <lone-pine> (To be clear, the weather box doesn't cast or recieve shadows, it's a separate issue)[23:13:37] <derhass> the whole concept of a "wheather box" sounds werid[23:13:38] <derhass> *weird[23:14:12] <lone-pine> It's like a skybox, but rendered in front of the scene instead of behind, and it's a transparent texture of raindrops or snowflakes[23:14:24] <lone-pine> It actually looks pretty good for a simple hack[23:14:55] <lone-pine> It moves over time and has multiple layers so there's parallax[23:15:16] *** cshzg <cshzg!~dietary@181.53.12.207> has quit IRC (Ping timeout: 246 seconds)[23:15:37] <derhass> I think you can achieve that much easier by rendering a quad[23:16:05] *** unreal <unreal!~unreal@unaffiliated/unreal> has joined ##OpenGL[23:16:43] <lone-pine> well it needs to look correct with the camera pointed downward or toward the horizon, and it needs to rotate around the camera[23:17:13] *** Takums <Takums!~Tak@73.90.205.122> has quit IRC (Disconnected by services)[23:17:13] *** Takums50 <Takums50!~Tak@73.90.207.27> has joined ##OpenGL[23:17:28] <derhass> lone-pine: it can look good[23:17:35] <derhass> just reander a _full screen quad_[23:17:47] *** Takums50 is now known as Takums[23:17:54] <lone-pine> I'm not going to reimplement it now[23:18:06] <derhass> well, just saying[23:18:16] <lone-pine> yeah I see where you're going[23:18:52] <zid> fun bug in a game I played recently is that they did 'night time' by just overlaying a dark quad on the screen, but they gave it a static size so if you made the window bigger than 1080p it'd just be.. in the middle[23:18:54] <derhass> the whole idea of some enclosing geometry (skyboxes, skydomes etc) is usally completely bogus. we don't need that since we have shaders[23:18:58] <zid> not reaching the edges[23:19:57] <lone-pine> derhass, well then you have to do a lot of math to align the image with the position of the camera and uh, math is hard[23:20:09] <lone-pine> easier just to use the projection matrix that I already know works[23:20:12] <derhass> the math isn't hard[23:20:37] <zid> I suck at math and I think I could handle that one[23:20:42] <lone-pine> you'd somehow have to reverse engineer the UV[23:21:57] <lone-pine> zid, so the game didn't have any real lighting math? What a weird hack[23:22:53] <lone-pine> derhass, how would you implement this with a quad? https://d2436y6oj07al2.cloudfront.net/spff/previews/vbme0577.jpg keep in mind it has to be animated[23:23:47] <derhass> lone-pine: depends on what this is supposed to represent[23:24:03] <lone-pine> rain from a top-down view[23:25:12] <derhass> lone-pine: well. with that image alone, I can't tell you[23:25:22] <derhass> but you said you're using textured spheres[23:26:11] <derhass> the sphere mapping will be not too hard[23:26:29] <lone-pine> https://youtu.be/66f6bI2uIdQ?t=870 <= like this without a particle system[23:26:46] <reddd> should every model have its own model matrix?[23:28:56] <derhass> basically, you project the view rays back to object space (using some potentially animated model matrix), and form there to texture space[23:30:55] *** cshzg <cshzg!~dietary@181.53.12.207> has joined ##OpenGL[23:31:34] *** ImQ009 <ImQ009!~ImQ009@unaffiliated/imq009> has quit IRC (Quit: Leaving)[23:33:22] *** Takums <Takums!~Tak@73.90.207.27> has quit IRC (Ping timeout: 245 seconds)[23:33:44] *** SwiftMatt <SwiftMatt!~Objective@2601:282:4300:3e:10f0:966d:fcc3:96c5> has joined ##OpenGL[23:36:15] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has quit IRC (Read error: Connection reset by peer)[23:36:18] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has joined ##OpenGL[23:36:47] <lone-pine> reddd, yes, unless you don't scale or rotate the model, in which case you could get away with just the worldspace vec3[23:41:53] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has quit IRC (Read error: Connection reset by peer)[23:42:16] *** RonaldsMazitis <RonaldsMazitis!~quassel@78.84.6.1> has quit IRC (Remote host closed the connection)[23:43:21] *** d3x0r <d3x0r!~d3x0r@ip174-72-226-164.lv.lv.cox.net> has joined ##OpenGL[23:44:24] *** lone-pine <lone-pine!~lone-pine@2600:8800:1d00:2d5::bf80> has quit IRC (Remote host closed the connection)[23:47:32] *** mirage335 <mirage335!~mirage335@204.141.172.74> has quit IRC (Ping timeout: 245 seconds)[23:53:40] *** Kingsqueee <Kingsqueee!~kingsquee@node-1w7jr9qmxqrpow98mke9t5qou.ipv6.telus.net> has quit IRC (Remote host closed the connection)[23:54:03] *** Kingsqueee <Kingsqueee!~kingsquee@node-1w7jr9qmxqrpow98mke9t5qou.ipv6.telus.net> has joined ##OpenGL[23:54:56] *** SwiftMatt <SwiftMatt!~Objective@2601:282:4300:3e:10f0:966d:fcc3:96c5> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)[23:58:13] *** bitwinery <bitwinery!~bruno@c-71-59-192-149.hsd1.wa.comcast.net> has quit IRC (Quit: Leaving)