October 31, 2014 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
October 31, 2014 [00:00:17] *** paperManu_ has quit IRC[00:01:28] *** stefkos has quit IRC[00:03:21] *** anivemin has quit IRC[00:03:48] *** Plasmastar has joined ##OpenGL[00:04:05] *** ShadowIce has quit IRC[00:07:41] *** Khlorghaal has joined ##OpenGL[00:07:48] *** kidnapped_robot has joined ##OpenGL[00:17:55] *** hdon has joined ##OpenGL[00:20:40] *** Crehl has quit IRC[00:23:43] *** Plasmastar has quit IRC[00:23:44] *** paperManu_ has joined ##OpenGL[00:24:14] *** shintah has quit IRC[00:24:20] *** qrlpx has joined ##OpenGL[00:26:14] *** Guest89108 has joined ##OpenGL[00:26:49] *** hahuang65 has quit IRC[00:27:00] *** hahuang65 has joined ##OpenGL[00:30:40] *** Guest89108 is now known as bodie_[00:30:50] *** bodie_ has quit IRC[00:30:50] *** bodie_ has joined ##OpenGL[00:33:34] <Stragus> zzuegg, if these are integers, you can use % just like in C although that requires GL_EXT_gpu_shader4[00:33:43] *** stoopdapoop has quit IRC[00:33:52] <Stragus> mod() does exist since the beginning, on floats[00:34:02] <zzuegg> yeah, unfortunately that not quite possible on android[00:34:42] <Stragus> Avoid divides and modulos if you can, remember these are very expensive operations[00:34:58] <Stragus> Just like in CPU land really, and perhaps worse[00:35:10] <zzuegg> kind of have to use mod for sprite animations i think[00:37:15] <Stragus> You should try to find a way without integers and without divides, if you are aiming for low mobile hardware[00:37:59] *** det has quit IRC[00:39:04] *** BitPuffin has joined ##OpenGL[00:39:30] <zzuegg> puh, such hard restrictions... going to think about it then[00:39:45] *** pazul has quit IRC[00:39:55] *** det has joined ##OpenGL[00:40:04] <zzuegg> but i still have 60fps on the s3 (which is the only device i currently have access to) :([00:40:14] *** confusa-est has joined ##OpenGL[00:40:29] *** RyanPridgeon has quit IRC[00:40:45] *** RyanPridgeon has joined ##OpenGL[00:40:51] *** puerum has joined ##OpenGL[00:41:44] *** det has quit IRC[00:42:37] *** TyrfingMjolnir has joined ##OpenGL[00:43:03] *** Majiet has quit IRC[00:43:06] *** roboman2444 has quit IRC[00:44:07] *** det has joined ##OpenGL[00:48:35] *** roboman2444 has joined ##OpenGL[00:51:00] *** PasNox has quit IRC[00:51:10] *** Majiet has joined ##OpenGL[00:51:31] *** pazul has joined ##OpenGL[00:55:17] <meng> dahlia: how do you populate it? based on the position in the world space?[00:57:48] *** Twinklebear has joined ##OpenGL[00:58:18] <dahlia> meng: world space, bounding volume AABB[00:59:27] <meng> dahlia: any quick tip to insert the octree nodes based on position?[01:01:41] *** slidercrank has quit IRC[01:02:25] *** kuldeepdhaka has joined ##OpenGL[01:03:21] *** kidnapped_robot has quit IRC[01:03:44] *** ZeXx86_ has quit IRC[01:03:55] *** b4b has joined ##OpenGL[01:03:57] *** ZeXx86 has joined ##OpenGL[01:12:41] <XMPPwocky> inserting an octree node is simple tree insertion[01:13:21] <meng> shouldn't be sorted based on distance?[01:13:33] <meng> so i can apply occlusion culling ( aka something hiding behind something els )[01:14:04] *** zzuegg has quit IRC[01:14:29] *** slime has quit IRC[01:16:37] *** slime has joined ##OpenGL[01:17:23] <dahlia> meng: the octree I use is arranged spatially in 3D space. Each node is inserted based on position and volume. I don't use it for culling as I don't have any way to know if a bounding volume totally occludes something behind it as it's only a bounding box[01:17:58] <dahlia> it doesnt accurately represent the true shape of the object[01:19:14] *** tcsc has quit IRC[01:19:31] *** tcsc has joined ##OpenGL[01:19:36] *** konom has joined ##OpenGL[01:20:39] *** japro has joined ##OpenGL[01:23:49] *** tkeemon has quit IRC[01:25:15] <meng> thats indeed a problem[01:25:43] *** kidnapped_robot has joined ##OpenGL[01:27:09] *** DolphinDream has joined ##OpenGL[01:29:48] *** hexagoxel_ has joined ##OpenGL[01:30:33] *** razieliyo has quit IRC[01:30:50] *** ozette has quit IRC[01:30:54] *** razieliyo has joined ##OpenGL[01:30:54] *** razieliyo has joined ##OpenGL[01:32:08] *** indefini has quit IRC[01:32:29] <Madsy> I don't see how that's a problem. You wouldn't use occlusion culling on anything *but* boxes.[01:32:48] <Madsy> All that happens is that the test becomes a bit pessimistic[01:33:15] <Madsy> I.e a false negative[01:33:29] *** hexagoxel has quit IRC[01:33:50] <Madsy> So the test would tell you it's not occluded when it is[01:36:34] *** hahuang65 has quit IRC[01:40:48] *** kidnapped_robot has quit IRC[01:41:45] *** SleekoNiko has joined ##OpenGL[01:41:53] *** DrBenway has joined ##OpenGL[01:44:25] *** Guest70518 has joined ##OpenGL[01:47:10] *** anivemin has joined ##OpenGL[01:52:03] *** anivemin has quit IRC[01:53:10] *** Garner has quit IRC[01:54:19] *** hunterco1l has quit IRC[02:04:09] *** Suchorski has quit IRC[02:04:19] *** pazul has quit IRC[02:05:07] *** huntercool has joined ##OpenGL[02:07:06] *** frivolous__- has quit IRC[02:07:34] *** qrlpx has quit IRC[02:08:05] *** kidnapped_robot has joined ##OpenGL[02:11:55] *** indefini has joined ##OpenGL[02:12:04] *** l3dx has quit IRC[02:13:41] *** Ad1_RnR has quit IRC[02:14:18] *** confusa-est has quit IRC[02:18:58] *** kidnapped_robot has quit IRC[02:22:44] *** madjestic has quit IRC[02:22:59] *** hexagoxel_ has quit IRC[02:23:27] *** Doxin has joined ##OpenGL[02:23:39] <Doxin> well I finally got opengl 3.3 to work http://i.imgur.com/WJlJTxg.png[02:23:41] * Doxin weeps a little[02:27:36] *** narcan has joined ##OpenGL[02:29:18] *** Khlorghaal has quit IRC[02:32:25] *** yaakuro has joined ##OpenGL[02:33:03] *** MLM has quit IRC[02:34:05] *** ragecryx has quit IRC[02:34:15] *** kidnapped_robot has joined ##OpenGL[02:39:04] *** Doxin has quit IRC[02:46:27] *** fatalhalt has joined ##OpenGL[02:47:36] *** meng has quit IRC[02:49:33] <dahlia> Madsy: the octree only contains bounding boxes b[02:49:47] <dahlia> but the objects themselves are not boxes[02:49:58] <dahlia> they are arbitrarily shaped meshes[02:50:48] <dahlia> so any algorithm that operates on the octree cannot know if something is occluded or not because it has no knowledge of the actual shape of the objects[02:51:13] <dahlia> nor would it know if anything uses alpha[02:53:15] *** staylor has joined ##OpenGL[02:56:34] *** narcan has quit IRC[02:59:24] *** devbug has joined ##OpenGL[03:03:15] *** slime has quit IRC[03:05:36] *** slime has joined ##OpenGL[03:08:21] *** bodie_ has quit IRC[03:08:37] *** roboman2444 has quit IRC[03:09:05] *** samrat has joined ##OpenGL[03:09:57] <b4b> how similar is macos dev to win32?[03:12:41] *** Ad1 has joined ##OpenGL[03:16:41] <Jonatan> b4b: that's a very broad question[03:16:54] *** mat^2 has quit IRC[03:16:57] <Jonatan> What do you use on win32?[03:17:12] <b4b> the win32 api?[03:17:27] <Jonatan> Ah you mean the api. It's entirely different.[03:18:10] *** mat^2 has joined ##OpenGL[03:18:21] *** pauldachz has quit IRC[03:18:22] <Jonatan> Cocoa uses objective-c to start with[03:18:56] *** roboman2444 has joined ##OpenGL[03:19:03] <b4b> is it message based?[03:19:55] <Jonatan> objective-c is[03:20:29] <Jonatan> It's weird to get used to the look of the syntax, but it's pretty neat once you get used to it[03:22:13] *** samrat has quit IRC[03:22:26] *** roboman2444 has quit IRC[03:22:34] <b4b> ty i’ll look at a tutorial tomorrow[03:22:55] <Jonatan> good luck![03:23:06] *** roboman2444 has joined ##OpenGL[03:23:42] *** razieliyo has quit IRC[03:23:55] *** unreal_ has joined ##OpenGL[03:26:54] *** unreal has quit IRC[03:32:38] *** b4b has quit IRC[03:33:21] *** Guest70518 has quit IRC[03:34:22] *** mat^2 has quit IRC[03:35:49] *** Lucretia has quit IRC[03:35:56] *** anivemin has joined ##OpenGL[03:36:37] *** Lucretia has joined ##OpenGL[03:38:45] *** paperManu_ has quit IRC[03:40:35] *** anivemin has quit IRC[03:42:42] *** shintahW2 has joined ##OpenGL[03:43:12] *** b4b has joined ##OpenGL[03:43:18] *** bodie_ has joined ##OpenGL[03:43:37] *** bodie_ has quit IRC[03:43:37] *** bodie_ has joined ##OpenGL[03:46:37] *** MLM has joined ##OpenGL[03:47:01] *** shintahW has quit IRC[03:47:01] *** shintahW2 is now known as shintahW[03:48:09] *** Hunts has joined ##OpenGL[03:51:39] *** HuntsMan has quit IRC[03:58:07] *** b4b has quit IRC[04:03:05] *** ikrima has joined ##OpenGL[04:08:51] *** Orion] has quit IRC[04:12:29] *** slime has quit IRC[04:15:42] *** stoopdapoop has joined ##OpenGL[04:16:10] *** stoopdapoop has joined ##OpenGL[04:19:28] *** charlie5 has quit IRC[04:21:11] *** bjz has quit IRC[04:22:21] *** stoopdapoop has quit IRC[04:22:28] *** indefini has quit IRC[04:24:01] *** fatalhalt has quit IRC[04:24:39] *** bodie_ has quit IRC[04:25:22] *** ozette has joined ##OpenGL[04:26:18] *** Barrett_ has quit IRC[04:27:12] *** slime has joined ##OpenGL[04:34:37] *** samrat has joined ##OpenGL[04:39:41] *** indefini has joined ##OpenGL[04:40:13] *** TyrfingMjolnir has quit IRC[04:40:43] *** bodie_ has joined ##OpenGL[04:43:21] *** Barrett_ has joined ##OpenGL[04:45:14] *** samrat has quit IRC[04:47:09] *** urraka has quit IRC[04:47:53] *** samrat has joined ##OpenGL[04:48:49] *** DolphinDream has quit IRC[04:50:46] *** ghenriks has quit IRC[04:52:38] *** shingshang has joined ##OpenGL[04:54:13] *** yaakuro has quit IRC[04:56:18] *** Dark_Confidant has joined ##OpenGL[04:56:44] *** Cabanossi has quit IRC[04:57:42] *** Cabanossi has joined ##OpenGL[04:59:55] *** Dark_Confidant|m has quit IRC[05:01:23] *** meoblast001 has quit IRC[05:07:34] *** bodie_ has quit IRC[05:09:01] *** bodie_ has joined ##OpenGL[05:09:55] *** sreich has quit IRC[05:10:16] *** agorecki has joined ##OpenGL[05:11:03] *** bodie_ has quit IRC[05:11:31] *** bodie_ has joined ##OpenGL[05:13:03] *** qeed has quit IRC[05:13:34] *** ozette has quit IRC[05:17:19] *** tcsc has quit IRC[05:24:40] *** anivemin has joined ##OpenGL[05:29:32] *** anivemin has quit IRC[05:42:29] *** pauldachz has joined ##OpenGL[05:44:43] *** BreadProduct has joined ##OpenGL[05:49:24] *** Alina-malina has joined ##OpenGL[05:52:30] *** RyanPridgeon has quit IRC[05:55:08] *** staylor has quit IRC[06:01:50] *** james4k has quit IRC[06:12:57] *** kivutar has quit IRC[06:15:03] *** kivutar has joined ##OpenGL[06:23:34] *** SleekoNiko has quit IRC[06:25:53] *** Zeioth has quit IRC[06:30:43] *** Zupo has joined ##OpenGL[06:32:00] *** Textmode has joined ##OpenGL[06:34:42] *** Zupo2 has quit IRC[06:44:52] *** Smilex has quit IRC[06:53:29] *** BitPuffin has quit IRC[06:54:14] *** Gamecubic has quit IRC[07:01:14] *** james4k has joined ##OpenGL[07:02:27] *** Keniyal has quit IRC[07:03:50] *** jhuntley has quit IRC[07:05:58] *** Zupo2 has joined ##OpenGL[07:06:21] *** linuxuz3r has quit IRC[07:07:27] *** Zupo has quit IRC[07:11:57] *** sam has quit IRC[07:13:03] *** MLM has quit IRC[07:13:26] *** anivemin has joined ##OpenGL[07:14:46] *** Burga has joined ##OpenGL[07:16:16] *** jhuntley has joined ##OpenGL[07:18:05] *** anivemin has quit IRC[07:19:13] *** Twinklebear has quit IRC[07:19:47] *** slime has quit IRC[07:21:13] *** slime has joined ##OpenGL[07:22:18] *** doomlord_1 has joined ##OpenGL[07:25:18] *** ozette has joined ##OpenGL[07:30:34] *** foreignFunction has joined ##OpenGL[07:32:25] *** sam has joined ##OpenGL[07:36:03] *** shintah has joined ##OpenGL[07:36:47] *** Dark_Confidant|m has joined ##OpenGL[07:36:47] *** Dark_Confidant has quit IRC[07:38:01] *** sam has quit IRC[07:39:38] *** foreignFunction has quit IRC[07:42:52] *** sam has joined ##OpenGL[07:46:04] *** ikrima has quit IRC[07:49:27] *** Demon_Fox has quit IRC[07:50:51] *** Demon_Fox has joined ##OpenGL[07:51:32] *** Waynes has joined ##OpenGL[07:53:51] *** zoraj_ has joined ##OpenGL[07:57:10] *** slidercrank has joined ##OpenGL[07:57:30] *** zoraj__ has quit IRC[07:57:53] *** ozette has quit IRC[08:02:22] *** CainJacobi has quit IRC[08:07:05] *** Majiet has quit IRC[08:11:04] *** TyrfingMjolnir has joined ##OpenGL[08:11:50] *** TyrfingMjolnir has quit IRC[08:13:26] *** TyrfingMjolnir has joined ##OpenGL[08:15:56] *** Domx has joined ##OpenGL[08:19:16] *** robot-beethoven has joined ##OpenGL[08:24:23] *** Beetny has joined ##OpenGL[08:25:48] *** ikrima has joined ##OpenGL[08:27:26] *** TyrfingMjolnir has quit IRC[08:27:37] *** Majiet has joined ##OpenGL[08:28:13] *** TyrfingMjolnir has joined ##OpenGL[08:29:47] *** SugarCube has quit IRC[08:31:39] *** ville has quit IRC[08:32:04] *** Zupo2 has quit IRC[08:32:07] *** glYoda has quit IRC[08:32:19] *** glYoda has joined ##OpenGL[08:33:57] *** ville has joined ##OpenGL[08:34:01] *** Garner has joined ##OpenGL[08:41:18] *** SugarCube has joined ##OpenGL[08:42:19] <Demon_Fox> Anyone know of a free book for modern OpenGL?[08:42:26] <Demon_Fox> A good free book[08:43:27] *** puerum has quit IRC[08:43:36] <chrisf> Demon_Fox: start with open.gl[08:43:37] *** MINIMAN10000 has quit IRC[08:44:13] *** anivemin has joined ##OpenGL[08:48:43] <Demon_Fox> Thanks[08:48:49] *** anivemin has quit IRC[08:49:39] <chrisf> Demon_Fox: but really, get the superbible[08:50:28] <Demon_Fox> chrisf, I think it is kind of sad that we don't have the books like OpenGL 1.x did[08:50:43] *** Lemml has joined ##OpenGL[08:50:48] <chrisf> there's a modern version of the red book[08:51:03] <Demon_Fox> Really?[08:51:19] <Demon_Fox> I need to search hard then[08:51:19] <Bloodust> indeed![08:51:25] <Demon_Fox> hi Bloodust[08:51:28] <Bloodust> 8th version of redbook[08:51:54] <Bloodust> http://it-ebooks.info/book/2138/[08:52:00] <Bloodust> looks free'ish[08:52:35] <Demon_Fox> thanks[08:52:43] *** Textmode has quit IRC[08:54:04] <Demon_Fox> and it is only 986 pages long[08:54:22] <Demon_Fox> That is better than the Intel asm books[08:54:50] <chrisf> if you dont like reading, you're in the wrong game[08:55:50] <Demon_Fox> No, I'm just saying it is shorter[08:55:59] <Demon_Fox> by 400 pages[08:56:04] <chrisf> heh[08:57:13] <Demon_Fox> The intel manual is 40% longer[08:57:25] <Demon_Fox> So this is a light read[08:58:02] *** pazul has joined ##OpenGL[08:59:40] <chrisf> Demon_Fox: the instruction set manual is small; the ivybridge gpu manual is 2437 ;)[09:00:29] <Demon_Fox> It is rather redundant anyways[09:00:40] <Demon_Fox> I mean some of the Intel stuff drags on[09:00:47] <Demon_Fox> but it is precise[09:04:41] *** samrat has quit IRC[09:04:55] <Demon_Fox> This book is rather good[09:05:01] <Demon_Fox> I'm on page 52[09:05:24] <Demon_Fox> There was a lot of starter stuff though[09:05:47] <Bloodust> the book covers everything gl related[09:06:14] *** devbug has quit IRC[09:07:19] *** kuldeepdhaka has quit IRC[09:09:13] *** madjestic has joined ##OpenGL[09:10:04] <Demon_Fox> Thanks Bloodust[09:10:48] <Demon_Fox> I think it will be useful if I translate the book code to use SDL stuff instead of Glut or glew[09:10:52] <Demon_Fox> I might learn a bit more[09:11:05] <Demon_Fox> But I'm going to bed[09:11:06] <Demon_Fox> Night[09:11:10] *** Demon_Fox has quit IRC[09:11:22] *** madjestic has quit IRC[09:12:56] *** zzuegg has joined ##OpenGL[09:16:32] *** Majiet_ has joined ##OpenGL[09:19:16] *** Majiet has quit IRC[09:19:41] *** Madsy has quit IRC[09:19:42] *** kuldeepdhaka has joined ##OpenGL[09:21:49] *** madsy has joined ##OpenGL[09:25:02] *** Majiet has joined ##OpenGL[09:27:59] *** Majiet_ has quit IRC[09:28:29] *** l3dx has joined ##OpenGL[09:30:55] *** jubei has joined ##OpenGL[09:32:05] *** samrat has joined ##OpenGL[09:32:19] *** stoopdapoop has joined ##OpenGL[09:32:59] *** BlackPhoenix has quit IRC[09:33:16] *** BlackFox has joined ##OpenGL[09:35:25] *** Majiet_ has joined ##OpenGL[09:37:56] *** Majiet has quit IRC[09:41:25] *** Folkol has joined ##OpenGL[09:42:16] *** anivemin has joined ##OpenGL[09:42:49] <jubei> does anybody understand how glm::rotate works?:)[09:42:49] <jubei> and how is one supposed to pass the angle as radians?[09:43:04] <jubei> i have two vectors v1 and v2 .I do[09:43:25] <jubei> float angle = glm::acos(glm::dot(v1,v2)); //dot product and acos to find the angle[09:43:52] <jubei> that “angle” variable, do I pass it as it is to glm::rotate?[09:44:01] <jubei> or do I need to do glm::radians(angle)[09:44:42] *** karab44 has joined ##OpenGL[09:46:07] *** zajfy has joined ##OpenGL[09:47:06] *** tkeemon has joined ##OpenGL[09:47:45] *** qrlpx has joined ##OpenGL[09:51:36] <Bloodust> well you should check the documentation :D[09:53:03] *** anivemin has quit IRC[09:53:04] <Bloodust> >Rotation angle expressed in radians if GLM_FORCE_RADIANS is define or degrees otherwise.[09:56:11] *** charlie5 has joined ##OpenGL[10:00:16] <jubei> GLM_FORCE_RADIANS is defined[10:00:29] <jubei> the question is.. what does glm::acos return … radians?[10:01:17] <Bloodust> :D[10:02:36] *** agorecki has quit IRC[10:02:38] <jubei> Bloodust: btw, GLM has documentation? since when?[10:02:49] <Bloodust> since always[10:02:53] *** stoopdapoop has quit IRC[10:04:54] *** anivemin has joined ##OpenGL[10:11:55] *** doev has joined ##OpenGL[10:13:55] *** Hadrien has joined ##OpenGL[10:15:03] *** japro has quit IRC[10:26:41] *** bjz has joined ##OpenGL[10:30:45] *** centrinia has quit IRC[10:31:20] *** asido has joined ##OpenGL[10:32:09] *** Burga has quit IRC[10:39:48] *** samrat has quit IRC[10:44:20] *** doev has quit IRC[10:49:46] *** losh has joined ##OpenGL[10:50:32] *** Crehl has joined ##OpenGL[10:51:04] <chrisf> it has doxygen auto awfulness[10:52:28] *** anivemin has quit IRC[10:55:00] *** xishem has quit IRC[11:02:05] *** redeemed has joined ##OpenGL[11:02:21] *** qrlpx has quit IRC[11:05:22] *** Ryp has joined ##OpenGL[11:06:00] *** karab44 has quit IRC[11:09:33] *** Ryp has quit IRC[11:10:49] *** Ryp has joined ##OpenGL[11:11:12] *** Burga has joined ##OpenGL[11:11:38] *** Ryp has quit IRC[11:12:08] *** indefini has quit IRC[11:12:20] *** [1]asido has joined ##OpenGL[11:12:32] *** Ryp has joined ##OpenGL[11:14:24] *** asido has quit IRC[11:17:17] *** Ryp has quit IRC[11:20:49] <Bloodust> looks fine to me http://glm.g-truc.net/0.9.5/api/a00176.html#ga61e65a3bb227c267d1a15113d1056fb1[11:22:32] *** snakenerd has joined ##OpenGL[11:27:58] *** [1]asido has quit IRC[11:28:27] *** hdon has quit IRC[11:29:27] <jubei> chrisf: agreed[11:29:44] <jubei> Bloodust: GLM_FUNC_DECL detail::tmat4x4<T,P>[11:29:59] <jubei> awesome return type :)[11:30:34] <jubei> The problem is that GLM is heavy on C++ templates[11:30:41] *** Ryp has joined ##OpenGL[11:30:46] <jubei> And as a result the auto-generated doxygen is horrible[11:31:12] <Bloodust> well yeah but it does list the possible T types[11:34:22] *** james4k has quit IRC[11:37:19] *** snakenerd has quit IRC[11:38:09] *** robot-beethoven has quit IRC[11:40:09] *** Hadrien has quit IRC[11:47:42] *** hdon has joined ##OpenGL[11:48:40] *** nemesit|znc has joined ##OpenGL[11:52:15] *** tkeemon has quit IRC[11:57:10] *** emperiz has joined ##OpenGL[12:03:40] *** Ryp1 has joined ##OpenGL[12:03:50] *** kuldeepdhaka has quit IRC[12:04:05] *** Ryp has quit IRC[12:06:31] *** loesh has joined ##OpenGL[12:06:38] *** emperiz has quit IRC[12:06:59] *** emperiz has joined ##OpenGL[12:07:31] *** emperiz has quit IRC[12:09:45] *** Khlorghaal has joined ##OpenGL[12:11:48] *** aethersis has joined ##OpenGL[12:12:19] *** Smilex has joined ##OpenGL[12:14:02] *** jdolan has quit IRC[12:16:34] *** jdolan has joined ##OpenGL[12:17:18] *** zoraj_ has quit IRC[12:18:35] *** paperManu_ has joined ##OpenGL[12:18:37] *** Crehl has quit IRC[12:19:13] *** _Cid has joined ##OpenGL[12:20:51] *** TyrfingMjolnir has quit IRC[12:27:30] *** Majiet has joined ##OpenGL[12:29:58] *** Majiet_ has quit IRC[12:30:50] *** jdolan has quit IRC[12:32:19] *** nemesit|znc has quit IRC[12:32:41] *** jdolan has joined ##OpenGL[12:33:08] *** nemesit|znc has joined ##OpenGL[12:34:53] *** ragecryx has joined ##OpenGL[12:35:05] <dawik> I use linmath.h instead of glm, it works quite well[12:35:15] *** Folkol has quit IRC[12:35:15] <dawik> none of that C++ mumbo jumbo[12:35:51] *** Folkol has joined ##OpenGL[12:43:22] *** samrat has joined ##OpenGL[12:45:50] *** bjz has quit IRC[12:48:00] *** aethersis is now known as dreamminder[12:49:10] *** erhan_ has joined ##OpenGL[12:49:45] *** bjz has joined ##OpenGL[12:49:53] <dreamminder> dawik if you decide to use glm then why not to use it for all maths :P[12:51:29] *** Ryp1 has quit IRC[12:53:15] *** samrat has quit IRC[12:53:33] *** jdolan has quit IRC[12:55:00] <dawik> dreamminder: C++ is not how i roll :P if I did, then glm would be viable. it was too nested with templates and iffy features like that to port it to C, for my needs linmath is fine ;)[12:55:46] *** xish has joined ##OpenGL[12:56:10] *** ville has quit IRC[12:56:33] *** jdolan has joined ##OpenGL[12:56:47] <dreamminder> I see[12:57:17] <dreamminder> why do you use C?[13:01:01] <dawik> many reasons, but mainly because I knwo it well. C++ offers a lot more, but nothing I feel is a necessity[13:01:42] <dreamminder> I often use it for the same reason[13:01:50] <dreamminder> what are you making?[13:02:23] <dawik> I have some stuffs, currently working on integrating oculus rift in my particle physics simulation[13:02:26] <BtbN> Smartpointers and complex objects on the stack(together with the deterministic destruction of them) makes C++ very worth it. Even if you only use it like a more feature-rich C.[13:05:33] <dawik> BtbN: maybe, I prefer functions to objects. to me that is more pure :)[13:06:01] <dawik> there are many higher languages I prefer, none that are strictly object-oriented[13:06:10] <dreamminder> JavaScript? :D[13:06:16] <dawik> for instance[13:06:27] <dawik> prototype objects are neat[13:06:38] *** ville_ has joined ##OpenGL[13:06:54] *** jdolan has quit IRC[13:06:56] <dreamminder> I almost got schizophrenia from coding in JS[13:07:52] <dawik> yeah, but once you learn the faults (BUGS) of the language, it is a quite expressive and ok language :)[13:08:39] <dawik> and doing webstuffs there is not much else to chose from, though I read about something called jisp, this morning, which is exactly what you would think[13:09:05] <dawik> a lisp-style language that transpiles to javascript :)[13:10:23] *** samrat has joined ##OpenGL[13:10:24] *** cden has joined ##OpenGL[13:11:13] *** karab44 has joined ##OpenGL[13:11:50] *** paperManu_ has quit IRC[13:15:45] *** ville_ has quit IRC[13:17:30] *** Ryp has joined ##OpenGL[13:23:08] *** hexagoxel has joined ##OpenGL[13:25:10] *** Doxin has joined ##OpenGL[13:25:36] *** Majiet has quit IRC[13:26:27] *** Beetny has quit IRC[13:26:28] *** ^Bzzt^Ploink^ has left ##OpenGL[13:26:45] <Doxin> so I've got this code: http://paste.pound-python.org/show/6Xx7AjsbK2oAm7oRwUUk/ . how would I go about having more than one vertex buffer? or more than one shader? do I need to re-do the whole buffer binding dance every time I switch shader?[13:26:49] *** BzztPloink has joined ##OpenGL[13:27:09] *** BzztPloink has left ##OpenGL[13:28:51] <Bloodust> your shaders probably wont compile[13:29:01] <Doxin> they did[13:29:15] <Doxin> Bloodust: what I just linked is a working program that shows a nice rainbow[13:29:17] *** Ryp has quit IRC[13:29:26] <Bloodust> well thats unexcepted[13:29:29] *** thilp has joined ##OpenGL[13:29:32] <Bloodust> I expected compiler error[13:29:34] <Doxin> what did I do wrong this time?[13:29:51] <Bloodust> attribute and varying no longer exist[13:29:55] <Bloodust> or gl_FragColor[13:30:05] <Doxin> oh[13:30:08] <Doxin> well[13:30:15] <Bloodust> attribute and varying were replaced by in/out[13:30:23] *** jdolan has joined ##OpenGL[13:30:25] <Bloodust> and gl_FragColor by custom out output variable[13:30:32] <Bloodust> such as, "out vec4 color_out;"[13:30:51] <Doxin> so what would thos shaders look like if they were correct?[13:31:26] <Bloodust> something like "in vec3 position; in vec4 color; out vec4 v_color;"[13:31:34] <Doxin> and the fragment shader?[13:31:56] <Bloodust> and in frag shader "in vec4 v_color; out vec4 color_out; void main(){ color_out = v_color; }"[13:32:30] <Bloodust> and Id use layouts for the vertex inputs[13:32:48] <Doxin> one thing at a time[13:32:56] *** snakenerd has joined ##OpenGL[13:33:21] <Doxin> right, shaders fixed.[13:33:27] <Doxin> Bloodust: why would you use layouts?[13:34:06] <Bloodust> well Ive used them so long I dont even remember anymore[13:34:11] <Doxin> lol[13:34:13] <Doxin> well[13:34:18] <Bloodust> but IIRC it cut out some extra opengl calls[13:34:28] <Doxin> oh[13:34:31] <Doxin> eh[13:34:50] <Doxin> sounds like optimisation, lets get this stuff working properly first :P[13:35:07] <Bloodust> its cleaner, but you can worrya bout that later[13:35:11] <Bloodust> so back to your original problem[13:35:12] <Doxin> exactly[13:35:13] *** jdolan has quit IRC[13:35:37] *** RyanPridgeon has joined ##OpenGL[13:35:43] <Bloodust> right, you can avoid this step oc=gl.glGetAttribLocation(shader_program,"color")[13:35:47] <Bloodust> loc*[13:36:44] <Bloodust> so if you want to use another vbo, you have to redo the whole buffer binding dance every time you switch shader or buffer[13:36:54] <Bloodust> unless the attriblocations are the same[13:37:06] <Doxin> I see[13:37:20] <Bloodust> with layouts they are if you set them to be[13:37:25] <Doxin> yeah I get it[13:37:49] <Doxin> no way to avoid the dance if the locations are different?[13:37:52] *** thilp has left ##OpenGL[13:38:03] <Bloodust> VAOs help[13:38:19] <Doxin> what-Os?[13:38:22] <Bloodust> but you'll probably need two VAOs if the locations are different[13:38:24] <Bloodust> vertex array object[13:38:35] <Bloodust> it encapsulates all the binding dances[13:38:39] <Doxin> oh right[13:40:28] <Bloodust> so step 1) layouts and step 2) VAOs[13:40:44] <Doxin> do you absolutely require layouts to use VAOs?[13:40:48] <Bloodust> no[13:41:02] *** reduzio has joined ##OpenGL[13:41:06] <Doxin> then I fail to see the point, if the vao is going to wrap that?[13:41:13] *** reduzio has left ##OpenGL[13:41:18] *** anivemin has joined ##OpenGL[13:41:37] <Bloodust> yeah but if two shaders use different locations for some reason, you need VAO for each shader[13:41:38] *** jdolan has joined ##OpenGL[13:41:53] *** reduz has joined ##OpenGL[13:41:54] <Doxin> Bloodust: well, yes.[13:42:18] <Bloodust> I must, I would like to know how stable the attribute locations are by default[13:42:19] <Doxin> Bloodust: I intend on implementing machinery to automate setting up and binding shaders anyhow, so that's not a big problem as far as I can see[13:42:26] *** xissburg has joined ##OpenGL[13:42:40] <Bloodust> most likely the standard says "dont care, let drivers decide"[13:42:47] <Doxin> pretty likely[13:43:05] <Doxin> also pretty likely implementations are either a) random, or b) in order of definition[13:43:06] <Bloodust> well you might not see it as a problem but it requires bigger memory footprint and more opengl calls[13:43:15] <Doxin> right[13:43:17] *** urraka has joined ##OpenGL[13:43:22] <Doxin> I can always do that later though[13:43:28] <Bloodust> so I see no reason not use layouts[13:43:32] <Doxin> get it working first, and do that if/when it becomes a problem[13:43:42] <Bloodust> they unify your shader interfaces and decreases cpu workload[13:44:04] <Doxin> not all shaders are going to have the same interface. that'd be silly.[13:44:08] *** Ryp has joined ##OpenGL[13:44:14] <Bloodust> mine have[13:44:22] <reduz> hi guys, any idea why glTexImage2D( GL_TEXTURE_2D, 0,GL_SRGB_ALPHA, width, height, 0,GL_SRGB_ALPHA, GL_UNSIGNED_BYTE, data); does not work and results in an invisible texture? doing the same with GL_RGBA instead as format works fine.[13:44:27] <Bloodust> vertex position is always at 0, tex coord at 1, normal at 2 etc.[13:44:58] <Bloodust> reduz is GL_SRGB_ALPHA a valid input format type?[13:45:21] <Doxin> Bloodust: it doesn't make sense for e.g. effect shaders to have normals though[13:45:36] <Bloodust> Doxin then you just leave them out[13:45:48] *** anivemin has quit IRC[13:45:53] <Doxin> humm[13:45:57] *** jdolan has quit IRC[13:46:09] <Doxin> Bloodust: that's more efficient than changing those bindings around?[13:46:37] <reduz> Bloodust, oh i just checked, in OpenGL it has to be supplied only in internalformat, while in OpenGL ES is for both format and internalformat[13:47:06] *** zzuegg has quit IRC[13:47:07] <reduz> so format should just be GL_RGBA ?[13:47:10] <Bloodust> Doxin well yeah[13:47:17] <Doxin> huh[13:47:17] <Bloodust> redeemed probably[13:47:24] <Doxin> well okay then[13:47:43] <Bloodust> on one hand you have 1) change bindings around and on the other hand you have 2) do nothing[13:48:03] <Doxin> Bloodust: on the other hand you have 2) pass more data to the GPU[13:48:09] <Bloodust> mmm no[13:48:09] <Doxin> so depends on your vertex count I guess[13:48:26] *** zzuegg has joined ##OpenGL[13:49:09] <Bloodust> Im pretty sure gl doesnt feed the extra data to the shader even if your attribute pointers are set up to give it more than it takes[13:49:27] <Doxin> Bloodust: your array needs to contain null values though doesn't it?[13:49:35] <Bloodust> what.. no[13:49:53] <Bloodust> you seem to be totally misunderstanding what layouts do :D[13:50:00] <Doxin> hows that?[13:50:19] <Bloodust> because your guestions seem so out of this world :D[13:50:36] *** shingshang has quit IRC[13:50:47] <Doxin> well currently I pass an array to openGL containing all in values, yes?[13:51:11] <Bloodust> when you draw you pass a pointer to opengl where you data is yes[13:51:29] <Doxin> so how do I do that when I e.g. don't need to pass color?[13:51:48] <derhass_> then you don't pass color[13:52:00] <Doxin> derhass_: that's not applicable to an array[13:52:11] <Bloodust> opengl will look at your shader and your input and think "hes giving me color at location 1 but the shader doesnt take anything in that location, ill just ignore it"[13:52:22] <Doxin> oh[13:52:37] <Doxin> but how does that work with the array strides/offsets etc?[13:52:51] <derhass_> Doxin: why is that not applicable to an array?[13:52:53] <Bloodust> I dont see how it wouldnt[13:53:04] <derhass_> Doxin: what you talk about does not really make sense at all[13:53:09] <Doxin> derhass_: because an array is by definition contiguous?[13:53:25] <Bloodust> do you know what the stride parameter does?[13:53:33] <Doxin> veeeery roughly[13:53:38] <derhass_> Doxin: there is an array per attribute[13:53:40] <derhass_> always[13:53:47] <Doxin> uh[13:53:51] <derhass_> so if you don't pass an attribute, you just don't need that array[13:54:11] <Doxin> derhass_: except that that's not quite true. at least not the way I'm doing shit[13:54:16] <derhass_> interleavinging them into some composed attribute is of course possible[13:54:29] <derhass_> Doxin: it is always true. it is how the GL api works[13:54:39] <Doxin> let me type for a sec[13:55:13] <Doxin> derhass_: okay so in http://paste.pound-python.org/show/44B00jyQM0oCtXx1zsi2/ line 81. theoretically, what would I do if I didn't want to pass color? if I leave it out of the array definition won't the offset be calculated wrongly?[13:55:44] <Bloodust> just ignore it in vertex shader[13:55:50] <Bloodust> or dont set glVertexAttribPointer for it[13:56:05] *** Biliogadafr has joined ##OpenGL[13:56:17] <derhass_> Doxin: you must tell the GL about your data layout in any case[13:56:27] <Doxin> derhass_: obviously[13:56:47] <Doxin> so I'll /still/ need to do the whole binding dance if the arguments I pass change?[13:57:15] * Doxin confused[13:57:52] <derhass_> that is what the whole "binding dance" is about: telling the GL where to find what data[13:57:58] <Doxin> well yes[13:58:08] <Doxin> but Bloodust promised me I could avoid that[13:58:12] <Bloodust> with layouts and vaos, your rendering will look like this: shader1.bind(); vao1.bind(); glDraw(..); vao2.bind(); glDraw(...); shader2.bind(); vao3.bind(); glDraw(...);[13:58:33] <Doxin> Bloodust: I dont see how, if the layout of the array has to change[13:58:37] <Bloodust> well, even without layouts[13:59:02] <Bloodust> layout of the array doesnt change[13:59:16] <Bloodust> you just ignore the input in the shader[13:59:39] <Doxin> but then I need null values in my array to pad it so the array layout doesn't change[13:59:43] <Bloodust> instead of "in vec3 pos; in vec3 color;" you just change it to "in vec3 pos;" and forget the whole color input[13:59:49] <Bloodust> no you dont[13:59:52] <Bloodust> the stride doesnt change[14:00:00] <Doxin> wait[14:00:23] <Doxin> opengl is doing something more clever here than I expect, isn't it?[14:00:31] <Bloodust> not really[14:00:35] <Bloodust> this is pretty straightforward[14:00:42] <Bloodust> this really doesnt get any more simpler than this is[14:00:57] <urraka> in fact, GL is not calculating any offsets like you mentioned, you give it all it needs to know[14:00:59] <Doxin> nothing has been simple with opengl so far, so maybe that's tripping me up[14:01:05] *** Ryp has quit IRC[14:01:49] <Doxin> so what about the offset=ctypes.c_void_p(vertex_data.dtype["position"].itemsize) bit, what if position isn't...[14:01:49] <Doxin> oh[14:01:52] <Doxin> I think I see[14:01:56] <Doxin> no I dont[14:02:01] <Doxin> what if position isn't defined?[14:02:04] <Doxin> what then?[14:02:10] <Doxin> the offset for it is still passed to opengl[14:02:10] <urraka> defined where?[14:02:43] <Doxin> I ment not present in the array[14:02:57] <urraka> you're supposed to know what you have in your data[14:03:03] <Doxin> I am aware[14:03:27] <Doxin> but I've been told that I only need to setup the buffer offsets etc once. I dont see how that works with optional inputs[14:03:47] <urraka> you do that with VAOs[14:03:53] <Doxin> so I've been told[14:03:57] <Bloodust> thats correct[14:04:00] <Doxin> but how do you do that using a single vao?[14:04:00] <Bloodust> you set them once[14:04:04] * Doxin confused harder[14:04:08] <urraka> you use as many as needed[14:04:40] <urraka> every time you draw from a different array or your layout changes you will need a different VAO[14:04:41] *** Ryp has joined ##OpenGL[14:04:58] <Bloodust> you set VAO once and thats enough, UNLESS the data structure/format in your VBO changes or shader input locations are not the same for all shaders you use[14:05:15] <Doxin> right[14:05:15] <Doxin> so[14:05:16] <derhass_> Doxin: it is totally unclear what your scenario is[14:05:29] <Doxin> derhass_: that's because I'm writing pretty generic code[14:05:31] <Doxin> just[14:05:33] <Doxin> gimme a sec[14:05:44] <Doxin> Bloodust: so you're telling me I need a vao per argument set?[14:05:51] <derhass_> maybe you over-thinking and over-abstracting things here[14:06:07] <Doxin> probably[14:06:26] *** Folkol has quit IRC[14:06:28] <Doxin> derhass_: I just know I dont understand something, and I'd rather not write code based on a misunderstanding[14:06:32] <Bloodust> one VAO is enough, unless what I said before[14:06:45] <Doxin> Bloodust: one is enough, unless when[14:06:54] <Bloodust> <Bloodust> you set VAO once and thats enough, UNLESS the data structure/format in your VBO changes or shader input locations are not the same for all shaders you use[14:07:02] <Bloodust> unless ^[14:07:05] *** h3r3tic_ has quit IRC[14:07:22] <Doxin> Bloodust: right, the format in my vbo changes because the amount of arguments I want to pass changes. correct?[14:07:33] <Bloodust> no[14:07:39] <Doxin> ;_;[14:07:41] <Bloodust> you dont have to change it[14:08:07] <Bloodust> your dataformat is vvv,cccc,[14:08:09] <Doxin> Bloodust: how do I not? if I dont put e.g. position in my array, my array is going to be shorter than opengl expects, right?[14:08:18] *** h3r3tic has joined ##OpenGL[14:08:28] <Doxin> Bloodust: my data format seems to be vcvcvc as far as I can tell[14:08:46] <urraka> changing the array is not the same as just changing the amount of attributes the sahder expects[14:09:10] <Doxin> I am aware[14:09:16] <Doxin> which is entirely why I dont understand[14:09:18] <Bloodust> Doxin right, I mean vvv is vec3 and cccc is vec4[14:09:29] <Bloodust> and it repeats so its interleaved[14:09:29] <urraka> if you change the array with a different layout you will need to set the pointers again[14:09:58] <urraka> but if you want to draw with the same array just ignoring color you dont have to change anything[14:10:04] <Doxin> urraka: people keep telling me I dont need to change the layout[14:10:14] <Doxin> urraka: but I dont see how, without padding it with 0 values[14:10:32] <Bloodust> I really wish I had a drawing that showed you how the data moves in opengl[14:10:35] <urraka> if you dont change the array the padding will still be there with the colors[14:10:40] <Bloodust> im too lazy to type it out[14:10:41] <urraka> garbage data[14:11:26] <Doxin> Bloodust: so say the layout is like [pos,col,pos,col,pos,col,...], and I don't pass col. only way I see how to do that without changing the layout is [pos,nil,pos,nil,pos,nil,...], because passing [pos,pos,pos,...] would be a different layout[14:12:06] <Bloodust> mmm no[14:12:13] <Bloodust> this is where the stride parameter kicks in[14:12:28] <urraka> is your definition of "pass" stuff uploading a whole new ARRAY_BUFFER?[14:12:45] <Doxin> urraka: yes?[14:12:58] <urraka> well.. new buffer, new pointers[14:13:37] <Bloodust> for both arrays [pos,col,pos,col,pos,col,...] and [pos,nil,pos,nil,pos,nil,...] the glVertexAttributePointer for pos is the same, stride jumps over the color and nil in both cases[14:14:21] <Doxin> Bloodust: except there is no color to jump over in [pos,pos,pos,...] so it'd skip positions[14:14:40] <Bloodust> yeah but the point is[14:14:45] <Bloodust> you dont have to change your data to that[14:14:57] <Bloodust> if you dont want to use the color values, then just dont use them[14:15:05] <Bloodust> ignore them completely[14:15:06] <Doxin> there is no "just dont use em"[14:15:09] <Bloodust> forget they ever existed[14:15:12] <Doxin> I leave em out or set them to some nonce[14:15:16] <Doxin> I cannot ignore them[14:15:25] <Bloodust> sure you can[14:15:47] <Doxin> no[14:15:48] <Doxin> look[14:15:52] <urraka> if you create a new array buffer you have to set all the pointers again, even if your layout is the same...[14:15:53] <Doxin> Bloodust: I have two options here[14:16:00] <Doxin> Bloodust: I either put the color in the array or I dont[14:16:02] <Doxin> Bloodust: which is it[14:16:25] <Bloodust> opengl doesnt care which one you do[14:16:34] <Bloodust> sure if you pack the positions tightly your interface changes[14:16:38] <Doxin> derp[14:16:43] <Bloodust> but if you just ignore the colors, you can use the same shader interface[14:16:44] <Doxin> Bloodust: is what urraka says true?[14:17:00] <Bloodust> well yeah[14:17:13] <Doxin> ._.[14:17:18] <Doxin> well that's the info I wanted[14:17:26] <Doxin> Bloodust: so I'll need a vao per vbo?[14:17:48] <Bloodust> usually[14:17:53] <urraka> you could reuse the buffers you already have though[14:18:02] <Doxin> Bloodust: that explains it[14:18:34] <Bloodust> I hope it does but Im not holding my breath[14:19:27] <Doxin> lol[14:19:38] <Bloodust> I hope you dont create two VBOs just because you want to use the same data for two different things[14:19:47] <Doxin> Bloodust: essentially, the point that caused confusion was "1 vao ever" vs "1vao per vbo"[14:20:08] <Doxin> Bloodust: I wasn't even contemplating using the same vbo with different shaders[14:20:42] <Doxin> anyways thanks for the halp, I'll be afk for a bit[14:20:54] *** zoraj has joined ##OpenGL[14:21:17] <Bloodust> when you've done the changes, repaste and link it and we'll check it over again[14:21:33] <Bloodust> I really want to you understand this[14:21:57] <Bloodust> also, if you dont understand how the data moves from your VBO to the shader, I suggest you think about it[14:22:02] <Bloodust> pen and paper helps[14:22:23] *** ShiroiKuma has quit IRC[14:23:45] *** jdolan has joined ##OpenGL[14:23:47] *** centrinia has joined ##OpenGL[14:23:53] *** Ryp has quit IRC[14:28:04] *** gaganjyot has joined ##OpenGL[14:29:18] *** tehrain has joined ##OpenGL[14:29:26] *** hdon has quit IRC[14:37:46] *** erhan_ has quit IRC[14:47:25] *** dreamminder has quit IRC[14:57:01] *** viggo has joined ##OpenGL[14:57:15] *** anivemin has joined ##OpenGL[14:59:24] *** Burga has quit IRC[14:59:29] *** Biliogadafr has quit IRC[14:59:43] *** RyanPridgeon has quit IRC[15:02:18] *** anivemin has quit IRC[15:02:44] *** Biliogadafr has joined ##OpenGL[15:07:45] *** xissburg has quit IRC[15:08:29] *** Zeioth has joined ##OpenGL[15:10:09] *** xissburg has joined ##OpenGL[15:14:59] *** tm604 has left ##OpenGL[15:17:58] *** MLM has joined ##OpenGL[15:19:30] *** gaganjyot has quit IRC[15:23:00] *** Biliogadafr has quit IRC[15:30:50] *** gaganjyot has joined ##OpenGL[15:31:43] *** ExpiredPopsicle has quit IRC[15:34:50] *** gaganjyot has quit IRC[15:35:29] *** gaganjyot has joined ##OpenGL[15:36:40] *** gaganjyot has quit IRC[15:36:57] *** xissburg has quit IRC[15:37:25] *** gaganjyot has joined ##OpenGL[15:40:28] *** xissburg has joined ##OpenGL[15:43:59] *** ExpiredPopsicle has joined ##OpenGL[15:45:16] *** BitPuffin has joined ##OpenGL[15:45:35] *** jubei has quit IRC[15:46:48] *** TheFinal has joined ##OpenGL[15:47:25] *** ville_ has joined ##OpenGL[15:48:12] <TheFinal> i'm looking for a 3D engine that would allow me to realize a cad application. i suppose that unreal and unity are not the best ones, i need LOT of bezier lines and 3D surfaces with a HUGE amount of points (basically i need to render something that can scale up to 12000x6500 vertex[15:50:10] <Yaniel> good luck with that[15:51:21] <Yaniel> I don't think even current commercial cad applications work well with that many vertices[15:51:30] *** _Cid has quit IRC[15:53:33] *** Gamecubic has joined ##OpenGL[15:54:26] *** ExpiredPopsicle has quit IRC[15:56:12] *** razieliyo has joined ##OpenGL[15:57:20] *** Zupo has joined ##OpenGL[15:57:23] *** centrinia has quit IRC[16:00:01] <Bloodust> they probably dont[16:00:11] <Doxin> TheFinal: I'm guessing you don't actually need that. what's your use-case?[16:01:53] *** japro has joined ##OpenGL[16:02:29] <TheFinal> well no let me explain better... i need lot of bezier lines that are for the geometries, and at the end i need to render this superdetailed map (sort of terrain mapping, more or less) with this definition[16:02:47] <Doxin> TheFinal: sounds like you don't need it to run in realtime then[16:02:51] <Yaniel> you don't really need to[16:02:57] *** Ad1_RnR has joined ##OpenGL[16:03:13] <Doxin> TheFinal: and it sounds like you're working on either a resolution or a scale that's insane[16:03:27] <TheFinal> no, this is a 3d surface cad for a milling machine, realtime not needed[16:03:32] <Yaniel> or if you do, may I recommend disney's latest renderer[16:03:35] <Doxin> TheFinal: divide the terrain up into manageable chunks and work on them one by one[16:03:50] <Bloodust> if realtime is not needed, you can have ALL the vertices you want[16:04:34] <TheFinal> but what do you suggest as a base just to not reinvent the wheel?... can unreal/unity/whathever be the right choice?[16:04:58] <Yaniel> still no idea[16:05:02] <Doxin> TheFinal: sounds like you don't actually want to do a 3d render at all to me[16:05:12] <Doxin> TheFinal: is the end result a mesh or an image or what?[16:06:26] <TheFinal> just a secondo, i want to give you an exact idea...[16:07:15] *** MINIMAN10000 has joined ##OpenGL[16:07:48] <TheFinal> https://www.youtube.com/watch?v=I-njQZlz6oI[16:08:00] <TheFinal> ok this video is about me using a software called artcam[16:08:38] <Doxin> TheFinal: so you need to create a depth map from a mesh?[16:08:41] <TheFinal> it is quite a good software BUT is it strictly linked to internet explorer, yes you have read it right, a cad/cam linked to a browser, and has too much tools for my customers[16:09:36] <TheFinal> i need to create, modify, edit a high density mesh and to use lot of bezier lines to edit/modify/create this mesh (you can use geometries and apply special cross section to these to create the 3d surface)[16:09:47] <Doxin> right[16:10:09] <Doxin> TheFinal: I'm not sure there's any software that exists that does exactly what you want though[16:10:41] <TheFinal> i alread have experience of programming of course, but i need to speed up my development so i need an engine that can handle this kind of situation[16:11:14] <Doxin> without some heavy heavy optimization, nothing can[16:11:45] <Yaniel> where heavy practically means rewrite from scratch[16:11:51] <TheFinal> but the weird thing is that i'm more scaried by bezier lines than 3d mesh[16:12:00] <TheFinal> oh...[16:12:56] <TheFinal> just to show you, starting from 6:30 you can see that i'm drawing a spline and then later i use this to do mesh operations[16:12:56] <Yaniel> you probably end up making meshes from the bezier lines anyway[16:13:34] <Doxin> TheFinal: that's not that complex of a thing, but it seems you're wanting to use a tiny tiny tiny resolution for it[16:14:02] <TheFinal> i was thinking also to use just "bitmaps" and then applying this as a depth map to a simple surface[16:14:30] <TheFinal> this for the visualization of course, for the cam calculation it is another thing[16:14:54] <Doxin> if that works for your purposes[16:14:57] <Doxin> sure, why not[16:15:10] <Doxin> TheFinal: sampling the bitmap in realtime to do a rough render shouldn't be too hard either[16:15:19] <TheFinal> but really i am more scared for the "2D" part of the cad[16:15:22] <Yaniel> tons of LOD streaming and the visualisation should not be an issue[16:18:56] <TheFinal> yes[16:19:25] <TheFinal> some engine to suggest? the one that allow me to do the smallest changes possible?[16:19:34] <TheFinal> do i have to start my 3d engine (sob)[16:19:39] <TheFinal> (&sigh)[16:19:56] <Doxin> TheFinal: I'd go with just using openGL. should be easy enough to get what you need implemented[16:20:12] *** TyrfingMjolnir has joined ##OpenGL[16:21:29] *** ExpiredPopsicle has joined ##OpenGL[16:21:30] <TheFinal> ok so lets say that i use opengl, consider that in a normal project i have something like 10k small vectors, can i handle these (bezier) without problems? i would like to use the latest implementation of opengl so to stick with shaders[16:21:35] <TheFinal> would this be a problem?[16:21:55] <Doxin> TheFinal: having 10k vectors isn't a problem until you start doing stuff with it[16:22:07] <Doxin> TheFinal: you basically want to make sure to render as little as possible[16:22:47] *** roboman2444 has quit IRC[16:23:51] <TheFinal> ok so my dreams to use something already made vanish...[16:23:54] <TheFinal> (sob)[16:24:46] <TheFinal> unreal was not bad, i would have use it also to be cross platform[16:26:36] *** roboman2444 has joined ##OpenGL[16:26:42] *** doomlord_1 has joined ##OpenGL[16:28:00] *** anivemin has joined ##OpenGL[16:28:17] <Doxin> TheFinal: you can totally do this[16:28:31] <Doxin> TheFinal: holding vertices in memory is essentially free until you get to absurd numbers[16:28:43] <Doxin> TheFinal: the key is to make sure to not try and draw all of those vertices[16:30:13] *** erhan_ has joined ##OpenGL[16:32:58] *** anivemin has quit IRC[16:33:12] *** roboman2444 has quit IRC[16:33:53] *** Kido_SoraKi has joined ##OpenGL[16:39:12] *** Sos has quit IRC[16:42:35] *** Orion] has joined ##OpenGL[16:42:58] *** shingshang has joined ##OpenGL[16:44:58] *** roboman2444 has joined ##OpenGL[16:45:02] *** ughman has joined ##OpenGL[16:46:23] *** TheFinal has left ##OpenGL[16:47:02] *** neure has joined ##OpenGL[16:47:04] <neure> hi[16:47:31] <neure> how should i set light color and intensity?[16:47:39] <neure> in physically based rendering[16:48:14] <neure> i can simply multiply color with intensity[16:48:44] <neure> but then color could be dark or bright red for example[16:49:08] <neure> and that is kind of wrong to say intensity would be some specific physical value[16:49:17] <neure> i suppose the color should be normalized?[16:50:45] *** _Cid has joined ##OpenGL[16:51:14] <_Cid> can anyone explain glDrawElements and how it contrasts from glDrawArrays[16:51:22] <Bloodust> drawelements uses indices[16:51:24] <_Cid> I've been reading and reading, but I'm a little lost on the indices part[16:51:25] <Bloodust> drawarrays doesnt[16:51:35] <ughman> I'm confused as to what constitutes non-uniform flow control[16:52:04] *** ManDay has joined ##OpenGL[16:52:15] <neure> branches that can take different paths per fragment?[16:52:22] <Bloodust> _Cid normally you access an array from beginning to end[16:52:39] <Bloodust> so indices would be 0,1,2,3,4,5[16:52:44] <ughman> so if the branch is decided based only on a uniform variable it's fine?[16:52:48] *** ManDay has quit IRC[16:52:57] <_Cid> ah so it's just if you have to do an "out of order" array?[16:53:18] <Bloodust> yeah[16:53:23] <neure> typically reuse is the key[16:53:25] <Bloodust> or save memory[16:53:26] <_Cid> jeez that just sounds like overcomplicating things[16:53:37] <_Cid> hm[16:53:55] <neure> say you have a sphere which is made from 1000 triangles[16:53:56] <_Cid> could you clarify saving memory?[16:53:59] <_Cid> okay[16:54:34] <neure> each triangle shares three edges with other triangles[16:54:52] <neure> by using indices can reuse vertex attribute data[16:54:52] <_Cid> hm[16:55:10] <neure> otherwise you'd have to repeat each vertex for each triangle it is used in[16:55:16] <_Cid> okay[16:55:32] <_Cid> so there's much less than 1000 vertices[16:55:47] *** staylor has joined ##OpenGL[16:55:50] <_Cid> makes sense[16:55:53] <Bloodust> much less than 3k vertices[16:56:09] <_Cid> er yes[16:56:12] <neure> if you use noe indices, you would need 1000 * 3 vertices[16:56:14] <_Cid> yeah lol[16:56:29] <neure> and you'd have a lot of duplicate vertices[16:56:34] <_Cid> yeah[16:56:41] <_Cid> hmm[16:56:55] <neure> it is not uncommon for a vertex to be reused in 3 to 6 triangles[16:57:14] <_Cid> I've been trying to fix this damn error for 2 days now[16:57:46] <_Cid> I create a game object and render it[16:57:51] <_Cid> and all goes smoothly[16:58:07] <_Cid> if I create a second object, which should get subsequently rendered after the first[16:58:22] <_Cid> my window doesn't redraw so it's invisible[16:58:24] <_Cid> and I get[16:58:24] *** hahuang65 has joined ##OpenGL[16:58:48] <_Cid> *** Error in `<path>': malloc(): memory corruption: 0x0000000002786f20[16:59:03] <_Cid> replaced pathname with <path>[16:59:15] <neure> memory corruption[16:59:16] <_Cid> yeah[16:59:23] <_Cid> everywhere says it's bad memory handling[16:59:31] <neure> it is[16:59:32] <_Cid> but idk what it is I'm doing[16:59:38] <_Cid> I thought maybe passing this[16:59:41] <_Cid> to a function[16:59:45] <_Cid> so I got rid of that[16:59:47] <ughman> this is one of the harder things to debug because it could be a problem anywhere[16:59:49] <_Cid> but it still happens[16:59:55] <Bloodust> ughman did you read this https://www.opengl.org/wiki/Sampler_%28GLSL%29#Non-uniform_flow_control[16:59:57] <neure> remove stuff[17:00:06] <neure> remove bits of your program until it doesnt crash[17:00:11] <_Cid> indeed I have[17:00:14] <_Cid> been at it for days[17:00:16] <ughman> I did[17:00:18] <neure> my guess it is your vertex buffer or index buffer[17:00:34] <neure> so remove any writing to memory related to vbo / ibo[17:00:35] <_Cid> yes[17:00:39] *** Waynes1 has joined ##OpenGL[17:00:41] <_Cid> I assume[17:00:44] <_Cid> I am just doing things wrong[17:00:53] <_Cid> how should one handle vertex/index buffers[17:01:17] <_Cid> as in when should one be doing glgenbuffers[17:01:17] <_Cid> etc[17:01:23] <Bloodust> one for each[17:01:29] <_Cid> how often[17:01:34] <Bloodust> index buffers are GL_ELEMENT_ARRAY_BUFFER or something like tha[17:01:44] <_Cid> I'm using glDrawArrays[17:01:46] <neure> you call glgen* only at load time[17:01:55] <neure> not in per frame[17:01:56] <_Cid> what about glGenVertexArrays[17:02:04] <neure> included in glgen*[17:02:05] <Bloodust> thats VAO[17:02:08] <_Cid> yeah[17:02:16] <neure> you dont gen stuff in per frame code[17:02:22] <neure> you gen stuff at load time[17:02:29] <_Cid> k[17:02:29] <Bloodust> its common to have vbo+index buffer + vao bunbled[17:02:30] *** Waynes has quit IRC[17:02:34] <_Cid> is vao[17:02:34] <neure> also, strictly speaking glGen does not create objects[17:02:47] <_Cid> yeah I've read all about it[17:02:58] <neure> first bind after gen actually creates the object[17:03:00] <_Cid> I had them in my load[17:03:05] <_Cid> yeah[17:03:06] <neure> sounds good[17:03:10] <_Cid> its[17:03:11] <_Cid> glGenVertexArrays(1, &vao);[17:03:11] <_Cid> glBindVertexArray (vao);[17:03:13] <_Cid> those two[17:03:17] <_Cid> I had in render :s[17:03:18] <_Cid> not sure why[17:03:27] <_Cid> but I read that[17:03:31] <_Cid> since glgenbuffers[17:03:35] <_Cid> only finds an unused name[17:03:44] <_Cid> it's not that consuming[17:03:56] <_Cid> anyway, the vao[17:04:03] <_Cid> should I have one or multiple?[17:04:28] *** Plasmastar has joined ##OpenGL[17:05:04] <neure> you can have fewer VBO/IBO and more VAO[17:05:46] <_Cid> okay right now I have one of each for every sprite[17:06:08] <Bloodust> sprite? quad?[17:06:19] <_Cid> yes[17:07:00] <Bloodust> yeaah ujmm[17:07:19] <Bloodust> if its just a quad, you probably dont need more than 1 vbo/ibo/vao[17:07:25] <AbigailBuccaneer> _Cid, typically you should have one VAO for each vertex buffer[17:07:33] <Bloodust> you can easily scale it and move it with uniforms[17:07:41] <AbigailBuccaneer> and if you're rendering lots of sprites then those should probably be in one VBO[17:08:01] *** gareppa has joined ##OpenGL[17:08:03] <_Cid> okay so I should batch them all into one buffer[17:08:19] <_Cid> then have one draw call[17:08:20] <Bloodust> or instance them[17:08:22] <_Cid> per frame[17:08:34] <_Cid> right now they all have render frames and each calls glDrawArrays[17:08:39] <Bloodust> or generate them on the gpu![17:08:44] <_Cid> :\[17:08:58] *** hahuang65 has quit IRC[17:09:12] *** hahuang65 has joined ##OpenGL[17:10:39] *** redeemed has quit IRC[17:14:27] *** doomlord_1 has quit IRC[17:16:04] *** Zupo has quit IRC[17:16:22] *** razieliyo has quit IRC[17:17:58] *** gaganjyot has quit IRC[17:19:12] *** hahuang65 has quit IRC[17:24:44] *** stoopdapoop has joined ##OpenGL[17:30:05] *** hahuang65 has joined ##OpenGL[17:31:16] *** hahuang65 has quit IRC[17:31:25] *** hahuang65 has joined ##OpenGL[17:32:38] *** mukunda_ has quit IRC[17:34:24] *** Yaniel has quit IRC[17:35:03] *** Yaniel has joined ##OpenGL[17:38:09] *** CainJacobi has joined ##OpenGL[17:38:22] *** hahuang65 has quit IRC[17:43:46] *** anivemin has joined ##OpenGL[17:44:12] *** hahuang65 has joined ##OpenGL[17:44:14] <_Cid> when using glDrawArraysInstanced how does one pass multiple textures[17:46:20] <Yaniel> what do you mean multiple textures[17:46:27] *** TyrfingMjolnir has quit IRC[17:48:35] *** unreal_ is now known as unreal[17:49:02] *** anivemin has quit IRC[17:49:39] <_Cid> well I attach the texture with glActiveTexture, glBindTexture then glUniform[17:50:12] <Yaniel> multiple active textures[17:50:30] <Yaniel> or rather, bind textures to multiple texture units[17:50:31] <_Cid> I want to draw a bunch of 2D quads[17:50:39] <_Cid> with different textures I load[17:50:47] <Yaniel> or use texture arrays[17:50:49] <Yaniel> or samplers[17:50:52] <_Cid> samplers[17:50:56] <Yaniel> texture arrays are probably the best[17:51:01] <_Cid> how so?[17:51:15] <_Cid> like, do you still bind it the same way or[17:51:29] <slime> https://www.opengl.org/wiki/Array_Texture[17:51:32] <_Cid> thanks[17:52:12] *** hahuang65 has quit IRC[17:52:12] <Yaniel> basically it is like a 3d texture without interpolation between layers[17:52:22] *** hahuang65 has joined ##OpenGL[17:52:48] <_Cid> should I have one texture array with all my textures loaded in it?[17:53:08] *** hahuang65 has quit IRC[17:53:15] <_Cid> I guess so[17:53:25] <Yaniel> if that suits your purpose[17:53:37] <Yaniel> in case of sprites it usually does[17:53:41] <_Cid> yeah[17:53:53] *** hahuang65 has joined ##OpenGL[17:53:54] <_Cid> thanks[17:53:56] *** centrinia has joined ##OpenGL[17:58:41] *** gareppa has quit IRC[18:08:03] *** samrat has quit IRC[18:10:54] *** samrat has joined ##OpenGL[18:11:53] *** Zupo2 has joined ##OpenGL[18:15:05] *** Slion has joined ##OpenGL[18:20:53] <_Cid> http://i.imgur.com/omTNFOs.gif[18:21:03] <_Cid> oops didn't mean to paste that there, heheh[18:22:32] *** slidercrank has quit IRC[18:24:47] *** slidercrank has joined ##OpenGL[18:26:35] *** sacrebleu has joined ##OpenGL[18:26:48] <sacrebleu> Seeking full-time C++ / OpenGL programmers, pm me with a link to your resume and a good time to call[18:27:54] *** MiniCow has joined ##OpenGL[18:29:53] *** RyanPridgeon has joined ##OpenGL[18:33:28] *** drtaglia has joined ##OpenGL[18:37:31] *** Sos has joined ##OpenGL[18:37:55] *** gaganjyot has joined ##OpenGL[18:38:08] *** Lucretia has quit IRC[18:38:24] *** stefkos has joined ##OpenGL[18:38:24] *** Lucretia has joined ##OpenGL[18:38:47] *** AbigailBuccaneer has quit IRC[18:39:32] *** h3r3tic has quit IRC[18:41:26] *** ShadowIce has joined ##OpenGL[18:41:39] *** stoopdapoop has quit IRC[18:41:39] *** erhan_ has quit IRC[18:41:42] *** h3r3tic has joined ##OpenGL[18:46:41] *** samrat has quit IRC[18:49:58] *** samrat has joined ##OpenGL[18:53:33] *** konom has quit IRC[18:56:09] *** drtaglia has quit IRC[18:57:31] *** tkeemon has joined ##OpenGL[18:58:27] *** Ryp has joined ##OpenGL[19:06:04] *** foreignFunction has joined ##OpenGL[19:16:07] *** linuxuz3r has joined ##OpenGL[19:20:35] *** komsomol has quit IRC[19:22:36] *** hahuang65 has quit IRC[19:23:53] *** clincher has quit IRC[19:28:58] *** samrat has quit IRC[19:29:12] *** TheBunnyZOS has joined ##OpenGL[19:29:32] *** anivemin has joined ##OpenGL[19:32:31] *** stoopdapoop has joined ##OpenGL[19:33:24] *** samrat has joined ##OpenGL[19:34:13] *** anivemin has quit IRC[19:34:49] *** Alina-malina has quit IRC[19:35:52] *** Alina-malina has joined ##OpenGL[19:35:52] *** Alina-malina has quit IRC[19:35:53] *** Alina-malina has joined ##OpenGL[19:37:28] *** Dark_Confidant has joined ##OpenGL[19:37:54] *** clincher has joined ##OpenGL[19:40:10] *** Dark_Confidant|m has quit IRC[19:43:31] *** PasNox has joined ##OpenGL[19:46:09] *** Jeanne-Kamikaze has joined ##OpenGL[19:49:05] *** hexagoxel has quit IRC[19:50:52] *** anivemin has joined ##OpenGL[19:52:04] *** centrinia has quit IRC[19:53:48] *** chirpsalot has quit IRC[19:55:53] *** samrat has quit IRC[19:59:36] *** Keniyal_ has joined ##OpenGL[20:05:17] *** Ryp has quit IRC[20:05:19] *** Crehl has joined ##OpenGL[20:05:57] *** hexagoxel has joined ##OpenGL[20:06:12] *** jdolan has quit IRC[20:06:51] *** Ryp has joined ##OpenGL[20:08:19] *** gareppa has joined ##OpenGL[20:09:30] *** shingshang has quit IRC[20:10:12] *** chirpsalot has joined ##OpenGL[20:18:34] *** neure has quit IRC[20:25:05] *** pazul has quit IRC[20:32:12] *** Doxin has left ##OpenGL[20:33:37] *** maxton has quit IRC[20:34:09] *** james4k has joined ##OpenGL[20:37:16] *** pazul has joined ##OpenGL[20:38:37] *** james4k has quit IRC[20:40:38] <AbleBacon> so... this might sound silly, but do large triangles take longer to draw than small ones?[20:41:53] *** BitPuffin has quit IRC[20:41:54] *** ikrima has quit IRC[20:42:14] *** Syzygy_ has joined ##OpenGL[20:42:23] <AbleBacon> i'm drawing a multi-colored grid using openGL and i have each square in the grid as two triangles, but it occurred to me that i could attempt to draw each square with one triangle, overlapping previous triangles all the way to the edge of the screen to achieve the grid effect[20:42:42] *** Kalic has joined ##OpenGL[20:42:55] *** elveni has joined ##OpenGL[20:43:36] <derhass_> AbleBacon: don't do that[20:43:58] <AbleBacon> why not?[20:44:54] <derhass_> because you are going to force an insane amount of useless fragments[20:45:15] <Stragus> That's a lot of overdraw. Think of the work you are asking from the GPU[20:45:32] <AbleBacon> but this technique would halve the amount of triangles (fragments you call them?) that i draw[20:46:05] *** Syzygy has quit IRC[20:46:15] <AbleBacon> i already have it working where i draw the two triangles for each square, btw so if you're telling me not to draw a grid using triangles, it's too late[20:46:50] <derhass_> AbleBacon: i meant the overdraw thing[20:46:57] <derhass_> drawing a grid with triangles is fine[20:48:08] <AbleBacon> oh okay overdraw isn't what i thought it was[20:48:21] <elveni> any recommendations for a rather straightforward(hopefully not mega bloated) opengl rendering engine that can render some static models so that i can hook up a physics engine to it and do some university level math & physics simulations?[20:48:39] <Stragus> Overdraw: rendering over a fragment/pixel that was already rendered by a different triangle[20:48:52] <AbleBacon> why is that necessarily bad, Stragus?[20:49:22] <Stragus> It's not necessarily bad if properly used, it's just more work for the GPU[20:49:36] <elveni> I'm on a windoze machine, but got debian too, C++ / C would be my languages I do most of the code work in. Mainly asking here since I tried Ogre3D(cool, but bloated like a fat pig) and Irrlicht(very lightweight but 1990's rendering quality).[20:50:28] *** Beetny has joined ##OpenGL[20:50:39] <AbleBacon> okay tell me if this correct or not: the way it works is that the GPU wants to draw a triangle, so it goes in with it's little proverbial paint brush and paints each pixel the color that it needs to be... but if you overdraw, it has to go back and do the work of painting over some pixels that it has already painted?[20:51:19] <AbleBacon> elveni: i have a project kind of like that. i'm writing a version of "asteroids" that does realistic 2D phsyics :D[20:51:31] <AbleBacon> i'd suggest writing the engine yourself, but that's because that kind of thing is fun for me[20:51:59] <elveni> i've written one opengl engine in immediate mode long time ago, but the texture mapping part got to my nerves :P[20:52:20] <AbleBacon> yeah i tried to put textures on my asteroids a couple of times but it never seems to work out[20:52:29] <elveni> and i think i'm too old due to working every day to have that kind of time to create a proper rendering engine :([20:52:48] <elveni> yeah texture mapping sucks, 3d math is simple, texture mapping is hard D:[20:53:02] *** tkeemon has quit IRC[20:53:10] <AbleBacon> i tend to struggle with the math parts, but i get the physics stuff[20:53:29] <derhass_> AbleBacon: your model of the process is justextremely unspecific[20:53:32] <elveni> well math is simple after practice[20:53:38] <elveni> anyone can do it[20:53:47] <AbleBacon> but it's that sort of what's going on, derhass_? in layman's terms?[20:53:49] <derhass_> elveni: what is so hard about texture mapping?[20:54:29] <AbleBacon> derhass_: in my case, i have asteroids with randomly generated shapes and mapping a texture to fit those random shapes it kind of tough for me (even though it's in 2D)[20:54:29] <derhass_> AbleBacon: it is way too unspecific to be of any explanatory use[20:54:46] <AbleBacon> but does it explain why overdrawing is inefficient?[20:55:08] *** tkeemon has joined ##OpenGL[20:55:15] <derhass_> AbleBacon: not really[20:55:19] <derhass_> AbleBacon: it might hint at it[20:55:24] <AbleBacon> okay[20:56:11] <AbleBacon> i think i'm gonna do it anyway... lol[20:56:15] <AbleBacon> just to see what happens[20:56:30] <AbleBacon> got my nifty FPS counter working[20:57:55] <AbleBacon> ah... shit. i forgot that i use multithreading to fill the arrays... not sure if i can fill it in the right order hmmm[20:59:53] *** tkeemon has quit IRC[21:00:15] *** Phroh|orca has joined ##OpenGL[21:01:17] <Phroh|orca> Hi all. What would be the best/most efficient way to set raw pixel byte color values for a texture?[21:01:45] *** tehrain has quit IRC[21:02:14] <Yaniel> make an array of your desired values and upload that with glTexImage[21:02:24] <AbleBacon> yeah--i just use glTexImage2D[21:02:31] <Yaniel> or potentially glTexSubImage if you want to update an existing one[21:02:54] <AbleBacon> this guy has a decent texture loader for beginners: http://www.opengl-tutorial.org/[21:03:11] <AbleBacon> errrr if you're using C++ that is[21:03:32] <Yaniel> the opengl part is hardly different in other languages[21:03:51] <Yaniel> so as long as you know enough c++ to see what is going on you shouldn't have problems[21:03:52] <Phroh|orca> C# eventually but I figured I'd start in C[21:04:05] <Phroh|orca> Yaniel, AbleBacon awesome thanks guys[21:04:14] <Yaniel> most tutorials use C++ though[21:04:25] *** Demon_Fox has joined ##OpenGL[21:04:35] <AbleBacon> yeah, that tutorial that i linked to is pretty good[21:04:48] <Yaniel> I think all modern gl tutorials I know use C++[21:05:31] <Phroh|orca> C++ translates pretty easily so I should be able to figure it out.[21:06:37] *** stoopdapoop has quit IRC[21:08:40] *** gaganjyot has quit IRC[21:08:41] *** stoopdapoop has joined ##OpenGL[21:10:24] *** sherief has joined ##OpenGL[21:11:20] <elveni> derhass_: everything :p its probably easier nowadays though :f hopefully atleast :D[21:12:23] <Phroh|orca> The size of the array will just be the number of px in the image/texture, right?[21:13:10] *** Garner has quit IRC[21:13:22] *** karab44 has quit IRC[21:14:02] <Yaniel> the size of the array should be at least the number of bytes you intend to upload[21:14:20] <Yaniel> which depends on the size of your texture, the format and the data type you use[21:16:01] <Demon_Fox> Just wondering, but is OpenGL 3.0 supported by most graphics cards in the last 6 years?[21:16:02] <Phroh|orca> Ah, right[21:16:05] <Phroh|orca> Thanks again[21:17:13] <Yaniel> Demon_Fox: yes[21:17:33] <Demon_Fox> Would that also apply to low end nvidia stuff also?[21:18:30] <Demon_Fox> ^ that might be a question for google though[21:19:25] <Yaniel> anything worth caring about does[21:20:13] <slime> Demon_Fox: for nvidia, the geforce 8000-series (2008) and newer supports GL3.x[21:20:39] <Demon_Fox> neat[21:20:45] <Demon_Fox> My free graphics card supports it[21:21:36] <foobaz> the last widely-used chipset to not support GL3 was intel arrandale, released in 2010[21:21:57] <Demon_Fox> Intel has crappy GPUs anyways[21:22:05] <foobaz> it was the original "intel hd graphics", paired with the first core i chip[21:22:05] <Demon_Fox> but thanks for the input[21:22:19] <Demon_Fox> I wanted to know if my current computers would support it[21:22:24] <Yaniel> the latest intel gpus are pretty decent actually[21:22:42] <Demon_Fox> When did they finally get the drivers working right[21:23:06] <foobaz> on linux, about a year ago[21:23:28] <foobaz> mesa jumped from opengl 2.1 support to opengl 3.3 support real fast[21:24:24] *** anivemin has quit IRC[21:24:30] <Demon_Fox> Not sure how I missed that[21:24:34] *** CapsAdmin has joined ##OpenGL[21:24:35] *** kuldeepdhaka has joined ##OpenGL[21:24:46] <Demon_Fox> but perhaps it is because I have not used a decent distro in a while[21:24:57] *** sacrebleu has quit IRC[21:25:15] <slime> foobaz: it had core GL3.1 support for a while, before core GL3.3[21:25:35] *** Phroh|orca has left ##OpenGL[21:25:41] <slime> http://www.mesa3d.org/relnotes/9.0.html[21:25:41] *** Ryp has quit IRC[21:25:54] <slime> (and mesa 8 implemented GL3.0)[21:27:42] *** Syzygy_ has quit IRC[21:29:57] <Demon_Fox> Thanks for all the info[21:31:37] *** indefini has joined ##OpenGL[21:34:53] *** xish has quit IRC[21:42:54] *** katlogic_ has joined ##OpenGL[21:44:11] *** meoblast001 has joined ##OpenGL[21:45:04] *** mukunda_ has joined ##OpenGL[21:46:15] *** katlogic has quit IRC[21:50:20] *** james4k has joined ##OpenGL[21:50:29] *** anivemin has joined ##OpenGL[21:54:47] *** karswell has joined ##OpenGL[21:54:51] <AbleBacon> if you have three vertices, how do you tell what direction the triangle that they create will face by default?[21:54:53] *** Syzygy has joined ##OpenGL[21:55:57] <Yaniel> take the cross product of two edge vectors[21:56:21] <AbleBacon> but i can create three vectors with my three points[21:56:28] <AbleBacon> how do i know which two of them are edge vectors?[21:57:10] <Yaniel> any vector on the edge of a polygon is[21:57:21] *** snakenerd has quit IRC[21:57:27] *** jdolan has joined ##OpenGL[21:57:29] <Yaniel> but IIRC you should be using a->b and a->c[21:57:43] <AbleBacon> well, i've had cases where, when i switch the order of two vertices, the triangle faces the opposite direction[21:58:00] <japro> that should happen in all cases :)[21:58:39] <AbleBacon> { {1, 1, 0}, {0, 1, 0}, {1, 0, 0} } for example[21:59:02] <derhass_> japro: hehehe[21:59:16] <AbleBacon> so is that { a, b, c }[21:59:23] <AbleBacon> ?[21:59:25] <japro> cross(a,b) = -cross(b,a)[21:59:38] <japro> also cross(-a,b) = -cross(a,b)[21:59:46] <derhass_> AbleBacon: depends on what a, b and c are[21:59:58] <AbleBacon> okay exactly[22:00:05] <AbleBacon> so i'm asking how to tell which one is which in the eyes of opengl[22:00:07] <derhass_> that is totally up to you[22:00:43] <AbleBacon> let's say i want that example above to be { a, b, c }. in what order would i pass that to openGL for it to render?[22:00:47] *** PasNox has quit IRC[22:00:49] <Yaniel> on a higher level, if the vertices end up on screen in a <insert current winding order> order, the triangle faces towards the screen[22:01:01] <derhass_> AbleBacon: opengl's orienation rules are just the winding order as seen from the camera[22:01:26] <AbleBacon> ah--okay[22:01:29] <AbleBacon> so you can just set a winding ordre?[22:01:54] <Yaniel> yes. the default is counter-clockwise[22:01:59] <AbleBacon> void glFrontFace(GLenum mode);[22:02:01] <AbleBacon> got it[22:02:09] <AbleBacon> okay--thanks! that's what i wanted to know... that clears things up a lot[22:05:45] <AbleBacon> what do you guys use to create shapes to render? i'm just doing rudimentary 2D shapes[22:06:09] <AbleBacon> i end up drawing them out on a grid and manually figuring out how to split them up into triangles[22:06:57] <japro> fairydust (and sometimes blender if i run out of fairies to grind up)[22:08:08] <AbleBacon> i tried blender and i haaaated it[22:08:20] *** jdolan has quit IRC[22:08:31] <AbleBacon> i did stuff with solidworks and proE in college and those were great[22:08:44] <AbleBacon> they had datum lines, the ability to set precise dimensions...[22:08:53] <AbleBacon> good luck making something symmetrical in blender ~_~[22:09:06] <japro> add a symmetry modifier :p[22:09:42] <japro> it isn't exactly intuitive admittedly (but as far as i can tell no general purpose 3d editing software is)[22:10:13] <AbleBacon> i'm sure i tried that at some point[22:10:47] <AbleBacon> i liked in solidworks you could say "this line... and this other line... are the same length"[22:11:07] *** losh has quit IRC[22:11:11] <AbleBacon> and if you changed one line or caused it to be changed indirectly, the other one would retain the constraint of equilinearity[22:11:43] *** dsodman_ has quit IRC[22:11:54] <AbleBacon> i guess that's not a word, but you get what i mean probably[22:14:44] *** qeed has joined ##OpenGL[22:14:58] <paperManu> you can't really compare a CAD software with something like Blender anyway, their don't have the same goal[22:16:44] <Stragus> To make something symmetrical in Blender, copy geometry, scale by X||Y||Z by -1.0, done[22:17:06] <Stragus> Blender is quite powerful, if you know how to use it[22:17:55] <paperManu> and if you want to do CAD in blender, you can try sverchok (a plugin)[22:18:44] *** Majiet has joined ##OpenGL[22:23:31] *** SleekoNiko has joined ##OpenGL[22:26:03] *** Portals has joined ##OpenGL[22:26:04] *** anivemin has quit IRC[22:26:30] *** Garner has joined ##OpenGL[22:27:05] *** anivemin has joined ##OpenGL[22:27:57] *** TunnelCat has joined ##OpenGL[22:28:42] <AbleBacon> yeah, but what if you want to change it after you've copied it? more copying![22:29:36] *** Majiet has quit IRC[22:30:08] <paperManu> not the same goal again ... try doing anything organic with solidworks ;)[22:30:24] <AbleBacon> well, okay that's true[22:31:32] <Demon_Fox> I'm guessing shaders do opacity settings[22:31:46] *** anivemin has quit IRC[22:35:45] <Yaniel> ...opacity settings?[22:35:55] <Portals> Is there any tool to find opengl errors?[22:36:46] <Demon_Fox> Yaniel, Setting opacity[22:36:51] <Portals> Nvm.[22:36:58] <Demon_Fox> Like an opacity filter, but on the fly[22:38:02] *** kuldeepdhaka has quit IRC[22:41:19] *** kuldeepdhaka has joined ##OpenGL[22:42:17] <foobaz> in GLSL, are variables automatically initialized to zero?[22:42:22] *** zzuegg has quit IRC[22:42:45] <foobaz> if i declare "float x;" is x 0.0 or undefined?[22:43:55] *** cden has quit IRC[22:45:16] *** TheBunnyZOS has quit IRC[22:47:34] *** Portals has quit IRC[22:53:12] *** paperManu has quit IRC[22:55:25] <Demon_Fox> I wonder if OpenGL 3/4 are faster than 1/2 because they don't flood the GPU with function calls[22:57:25] *** Portals has joined ##OpenGL[22:57:59] *** ville_ is now known as ville[22:58:00] *** tkeemon has joined ##OpenGL[23:05:03] <Stragus> Demon_Fox, that's handled by the drivers, it's all the same to the GPU[23:05:27] *** b4b has joined ##OpenGL[23:05:46] <Demon_Fox> Perhaps the delays in just the flood of function calls verses one with a big buffer[23:06:06] <Demon_Fox> I gots to go[23:06:11] <Stragus> The function calls and extra processing may demand more CPU time, yes[23:06:25] <Demon_Fox> Thanks for answering my question Stragus[23:06:49] <Stragus> Also... VBOs are much faster than immediate mode since the data can be stored in GPU memory, if that was your question[23:07:17] *** jdolan has joined ##OpenGL[23:08:44] *** tcsc has joined ##OpenGL[23:09:07] *** meoblast001 has quit IRC[23:10:03] *** anivemin has joined ##OpenGL[23:10:46] *** Ryp has joined ##OpenGL[23:10:46] *** anivemin has quit IRC[23:12:12] *** Suchorski has joined ##OpenGL[23:12:44] *** Ryp has quit IRC[23:14:30] *** foreignFunction has quit IRC[23:16:30] *** staylor has quit IRC[23:16:44] *** pazul has quit IRC[23:16:57] *** Lemml has quit IRC[23:27:21] *** Majiet has joined ##OpenGL[23:29:11] <Bloodust> possibly[23:29:58] *** metredigm has joined ##OpenGL[23:29:58] *** metredigm has joined ##OpenGL[23:29:59] *** metredigm has left ##OpenGL[23:30:57] *** Cabanossi has quit IRC[23:31:57] *** radr has quit IRC[23:32:07] *** Cabanossi has joined ##OpenGL[23:32:17] *** ShadowIce has quit IRC[23:34:30] *** TechEffigy has joined ##OpenGL[23:35:18] <Portals> Bloodust, should I set the viewport before or after I bind a framebuffer?[23:35:36] <Portals> It should be before right?[23:35:44] <Portals> Because I'm setting the viewport of my screen[23:36:01] <Portals> If I do it after, I will set the viewport of my framebuffer. Right?[23:36:57] <derhass_> nope[23:37:04] <derhass_> the viewport is a global state[23:37:08] <derhass_> not a per-framebuffer one[23:37:57] <Portals> Thanks![23:43:31] *** centrinia has joined ##OpenGL[23:47:03] *** bb010g has quit IRC[23:48:05] *** hdon has joined ##OpenGL[23:48:49] *** puerum has joined ##OpenGL[23:50:02] *** ClarusCogitatio has quit IRC[23:50:43] *** Match has joined ##OpenGL[23:53:43] <Match> hi all, I'm going to implement large terrain. NVidia Gems is a good point to start from or something else better ? (NVidia Gems2 . Terrain Rendering using GPU Geometry Clipmaps)[23:56:09] <TechEffigy> octrees and shaders for the height map[23:56:18] <TechEffigy> and blending[23:56:20] *** centrinia is now known as Samhain[23:56:54] <Match> thx TechEffigy , what you mean exactly ?[23:57:09] <Match> have you a link ?[23:57:09] <TechEffigy> lookup octrees[23:58:16] *** agorecki has joined ##OpenGL[23:58:38] <TechEffigy> http://www.gametutorials.com/tutorial/height-map/[23:58:44] <TechEffigy> terrain on there[23:59:02] *** japro has quit IRC[23:59:48] *** gareppa has quit IRC