November 3, 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 | >
November 3, 2014 [00:03:10] *** paperManu has joined ##OpenGL[00:06:18] *** centrinia has quit IRC[00:08:00] *** s0s has joined ##OpenGL[00:10:50] *** xdrone has joined ##OpenGL[00:10:53] *** Sos has quit IRC[00:15:38] *** ShadowIce has quit IRC[00:24:44] *** losh has quit IRC[00:25:52] *** petervaro has joined ##OpenGL[00:27:23] *** sreich has joined ##OpenGL[00:28:00] *** realz has joined ##OpenGL[00:29:25] *** Alina-malina has quit IRC[00:29:57] *** Lemml has quit IRC[00:30:05] *** Alina-malina has joined ##OpenGL[00:30:05] *** Alina-malina has joined ##OpenGL[00:32:48] *** centrinia has joined ##OpenGL[00:33:52] *** Misu has quit IRC[00:34:18] *** Misu has joined ##OpenGL[00:38:53] *** Misu has quit IRC[00:42:21] *** razieliyo_ is now known as razieliyo[00:42:30] *** razieliyo has joined ##OpenGL[00:44:53] *** petervaro has quit IRC[00:46:45] *** shintah has quit IRC[00:55:10] *** MiniCow has quit IRC[01:00:45] *** tcsc has joined ##OpenGL[01:01:01] *** Jubb has joined ##OpenGL[01:03:32] *** oberstein has quit IRC[01:17:11] *** hexagoxel_ has quit IRC[01:21:56] *** SleekoNiko has quit IRC[01:23:19] *** SleekoNiko has joined ##OpenGL[01:25:10] *** derhass has quit IRC[01:26:12] *** skoskav has quit IRC[01:26:34] *** skoskav has joined ##OpenGL[01:28:41] *** pazul has quit IRC[01:32:22] *** Crehl__ has joined ##OpenGL[01:35:55] *** Crehl_ has quit IRC[01:37:28] *** Alina-malina has quit IRC[01:38:15] <Khlorghaal> will if( uniform ) not incur the perf hit of executing the block regardless of the condition?[01:38:30] <Khlorghaal> i would use #ifdefs but that would be inconvenient[01:38:36] <Spark> no[01:38:44] *** Motig has quit IRC[01:38:52] <Spark> it is the same for every fragment / vertex so it should not[01:39:01] <Spark> you may pay the price for the actual test[01:39:04] <Spark> or maybe not even that[01:39:05] <Khlorghaal> ah so even if its not uniform[01:39:14] *** Motig has joined ##OpenGL[01:39:42] *** TheLorax has joined ##OpenGL[01:40:05] *** furor has joined ##OpenGL[01:40:06] <Khlorghaal> i have a paranoid distrust of optimizers :V[01:40:07] <Stragus> Use the preprocessor[01:40:18] <Stragus> Yes, and wisely so[01:40:41] <TheLorax> do I _HAVE_ to put texture coords into the same buffer object as my normals and vertex positions in opengl 3+?[01:40:47] *** Alina-malina has joined ##OpenGL[01:40:54] <Spark> you can do some tricks like if (FOO) then #define FOO to be true instead of my_uniform[01:40:59] <Spark> or false, rather[01:41:05] <Stragus> No, TheLorax, you can use multiple VBOs if you want[01:41:13] <Khlorghaal> im doing two passes with the shader, but on second pass it does chained texture fetch[01:41:25] <Spark> use 2 shaders for that[01:41:39] <Spark> what does it save you in complexity to use 1 shader?[01:41:51] <TheLorax> Stragus, if they are in seperate buffer objects, then what do I bind them to? There is only one ARRAY_BUFFER bind target.[01:41:58] <Khlorghaal> well id have to copypaste it then[01:42:02] <Khlorghaal> and i may change stuff later[01:42:23] <Spark> you should be able to abstract code into 2 shaders[01:42:28] <Khlorghaal> ideally id have a better environment so i could avoid that[01:42:41] <Spark> *out of 2 shaders[01:42:59] <Khlorghaal> TheLorax: you seem no not understand what buffer objects are for, they store arbitrary data[01:43:22] <Stragus> TheLorax, glBindBuffer(), glVertexAttribPointer(), bind a different buffer, set a new attrib, etc.[01:43:30] *** Slion has quit IRC[01:43:59] <TheLorax> Stragus, ohhh, ok. I thought that once you bound a different buffer the attribpointer effect stopped.[01:45:19] *** oberstein has joined ##OpenGL[01:45:54] *** narcan has joined ##OpenGL[01:46:12] <glYoda> "will if( uniform ) not incur the perf hit of executing the block regardless of the condition?" …while the control flow itself isn't divergent (i.e. all invocations will execute the same condition) you will pay for the conditional test itself[01:46:49] <Khlorghaal> im doing 2-3 texture fetches so a bool check is completely negligible[01:47:17] <glYoda> you can eliminate that step by conditionalizing the relevant logic via the preprocessor[01:47:52] <Khlorghaal> for sake of lazyness how bad would it be to just use a uniform?[01:47:54] <glYoda> of course you'll pay the cost of a shader recompile along with additional API calls to enable that particular program object[01:47:57] <Stragus> Khlorghaal, build two different shaders, there's no sense performing that branch millions of times when once will do[01:48:11] <glYoda> Stragus like I just said[01:48:29] *** furor has quit IRC[01:48:43] * Stragus beats the lazyness out of Khlorghaal[01:49:04] <Khlorghaal> and ill probably never have to do this again in my engine :/[01:52:54] <Spark> do what you like, we can only give you best practices[01:53:09] <Spark> which are established by people doing complicated things and needing good results every time[01:54:28] <dahlia> not best practices: https://www.shadertoy.com/view/ldjGzt[01:55:03] <Khlorghaal> hrm if i used layout locations it wouldnt be a problem at all to use two seperate programs.... although ive so far been able to keep to 3.2 with a few extensions[01:55:06] *** Alina-malina has quit IRC[01:55:26] *** meoblast001 has joined ##OpenGL[01:55:34] <Stragus> Fix your code to allow multiple shader programs[01:55:39] <Stragus> You'll really need that[01:55:58] <Khlorghaal> no the reason i dont want to duplicate is incase i change it[01:56:12] <Khlorghaal> i need the two to be identical except for two blocks[01:56:13] <glYoda> "which are established by people doing complicated things and needing good results every time" <-- this.[01:56:14] <Stragus> You can recompile the same shader twice with different #if stuff then[01:56:24] <Stragus> Okay, use the preprocessor[01:56:39] <Khlorghaal> oh subconscious derp[01:57:12] <Khlorghaal> the reason i implicitly coudlnt do that is because i have my shader containers such that i can refresh them without restarting the program[01:57:28] *** samrat has joined ##OpenGL[01:57:33] <Khlorghaal> well that and id have to track uniform locations in both[01:58:18] *** xdrone has quit IRC[01:58:18] <Khlorghaal> and the way the refreshing system works would need a bunch of work to allow alternating #defs[01:58:23] <japro> here is a philosophical question... if you have thousands of cores but way less actual schedulers... do you "execute" the branch per core or per scheduler :o)[01:59:08] *** bjz has joined ##OpenGL[02:00:53] *** xdrone has joined ##OpenGL[02:03:48] *** DolpheenDream has joined ##OpenGL[02:04:00] *** paperManu has quit IRC[02:04:46] *** b4b has joined ##OpenGL[02:06:23] *** samrat has quit IRC[02:09:34] *** samrat has joined ##OpenGL[02:10:13] *** Demon_Fox has joined ##OpenGL[02:15:29] *** DolpheenDream has quit IRC[02:16:30] *** samrat has quit IRC[02:17:00] *** Alina-malina has joined ##OpenGL[02:21:30] *** metredigm has joined ##OpenGL[02:22:01] *** DolpheenDream has joined ##OpenGL[02:22:19] *** TyrfingMjolnir has quit IRC[02:29:20] *** samrat has joined ##OpenGL[02:29:55] *** Xgamerz has joined ##OpenGL[02:31:33] *** Smilex has quit IRC[02:33:59] *** samrat has quit IRC[02:35:51] *** DolpheenDream has quit IRC[02:36:05] *** samrat has joined ##OpenGL[02:37:11] *** narcan has quit IRC[02:38:37] *** narcan has joined ##OpenGL[02:38:39] *** BreadProduct has quit IRC[02:39:11] *** Xgamerz has left ##OpenGL[02:40:28] *** thetourist has joined ##OpenGL[02:40:53] *** Bigpet_ has joined ##OpenGL[02:42:46] *** xissburg has quit IRC[02:43:07] *** xissburg has joined ##OpenGL[02:43:10] *** samrat has quit IRC[02:45:24] *** jhuntley has joined ##OpenGL[02:45:55] *** DolpheenDream has joined ##OpenGL[02:48:13] *** samrat has joined ##OpenGL[02:48:45] *** thetourist has quit IRC[02:50:17] *** ra4king has quit IRC[02:50:46] *** ra4king has joined ##OpenGL[02:52:50] *** samrat has quit IRC[02:53:12] *** Garner has quit IRC[02:59:11] *** charlie5 has joined ##OpenGL[03:03:04] *** MLM has quit IRC[03:10:38] *** MiniCow has joined ##OpenGL[03:14:03] *** metredigm has quit IRC[03:15:24] *** mat^2 has quit IRC[03:22:06] *** linuxuz3r has joined ##OpenGL[03:23:37] *** paperManu_ has quit IRC[03:28:08] *** TyrfingMjolnir has joined ##OpenGL[03:28:34] *** linuxuz3r has quit IRC[03:29:48] *** petervaro has joined ##OpenGL[03:33:37] *** DrBenway has joined ##OpenGL[03:34:47] *** Orion] has quit IRC[03:35:51] *** PortaLu has joined ##OpenGL[03:35:54] *** Lucretia has quit IRC[03:39:03] <glYoda> heh welcome to the world of static scheduling[03:40:07] *** b4b has quit IRC[03:40:59] *** samrat has joined ##OpenGL[03:41:05] *** MiniCow has quit IRC[03:41:46] *** TunnelCat has joined ##OpenGL[03:45:42] <Spark> i will never forgive nvidia for confusing the term "core"[03:45:57] <dahlia> or intel?[03:46:04] <glYoda> Spark heh[03:47:44] *** xdrone has left ##OpenGL[03:47:53] *** samrat has quit IRC[03:48:42] <yaakuro> Spark: And what is confusing?[03:48:53] *** HuntsMan has joined ##OpenGL[03:50:43] <dahlia> Nvidia uses the term "Cuda cores" but I have no idea how that relates to OpenGL[03:51:10] <LeelooMinai> THose are little processing units - shaders in OpenGL world[03:51:29] <dahlia> vertex shaders? fragment shaders? either?[03:51:50] <bkc_> dahlia: they're unified in modern hardware[03:51:54] <LeelooMinai> ALl of them - OpenGL compute shaders, geometry, etc.[03:51:57] *** Hunts2 has quit IRC[03:52:29] <LeelooMinai> The power of GPUs comes mostly from ability to have, say, 1000 of those and running them in parallel.[03:54:51] *** TyrfingMjolnir has quit IRC[03:54:55] *** DolpheenDream has joined ##OpenGL[03:56:09] *** shirt has quit IRC[03:57:10] *** TyrfingMjolnir has joined ##OpenGL[04:06:35] <Spark> the classical meaning of core was essentially several versions of a whole cpu, on the same die[04:06:48] <Spark> the trend was for more cores per die[04:07:37] <Spark> So nvidia decided to redefine the term core to mean something far smaller and more fundamental, something closer to a functional unit or a vector lane on a conventional CPU. Many of these would exist in a conventional core, e.g. x86, but that didn't stop nvidia.[04:08:09] <Spark> So that's why nvidia GPUs have hundreds / thousands of cores.[04:08:37] *** hdon has joined ##OpenGL[04:08:48] <Spark> If you applied a similar standard to x86, you'd find that CPUs also have hundreds of cores. A few factors behind GPUs of course, but not the orders of magnitude claimed by nvidia.[04:08:52] <Spark> </rant>[04:09:37] <LeelooMinai> cores/processing units/shaders - they are just identical pieces of processing hardware:)[04:10:44] * dahlia blames nvidia's marketing department[04:12:21] <Spark> I don't mind being a bit flexible, with evolution of language and all that. But if your "core" doesn't have its own instruction decoder, it's probably not a core.[04:12:42] *** TyrfingMjolnir has quit IRC[04:12:47] *** DolpheenDream has quit IRC[04:12:58] *** shintahW2 has joined ##OpenGL[04:15:46] *** bjz has quit IRC[04:15:57] *** kuldeepdhaka has quit IRC[04:17:41] *** shintahW has quit IRC[04:17:42] *** shintahW2 is now known as shintahW[04:18:11] *** kuldeepdhaka has joined ##OpenGL[04:19:38] *** TyrfingMjolnir has joined ##OpenGL[04:20:41] *** Madsy has quit IRC[04:23:43] *** TheLorax has quit IRC[04:30:45] <Khlorghaal> arent rasterizers a seperate set of processors?[04:31:40] *** urraka has quit IRC[04:33:50] <roboman2444> ....maybe?[04:33:58] <roboman2444> really depends on the card[04:35:34] <glYoda> "arent rasterizers a seperate set of processors?" …nothing I'd consider to be a "processor"[04:35:48] <glYoda> rasterizers are still primarily fixed function logic[04:41:52] *** bjz has joined ##OpenGL[04:46:52] *** TyrfingMjolnir has quit IRC[04:51:57] *** Cabanossi has quit IRC[04:54:49] *** Cabanossi has joined ##OpenGL[04:56:37] *** Dark_Confidant|m has joined ##OpenGL[04:56:37] *** Dark_Confidant has quit IRC[04:59:45] *** TyrfingMjolnir has joined ##OpenGL[05:01:50] *** xish has joined ##OpenGL[05:02:31] *** ragecryx has quit IRC[05:06:17] <ra4king> holy crap[05:06:28] <ra4king> glBufferStorage took 2 minutes to implement.... and the speed boost is enormous[05:06:54] <ra4king> modifying the VBO data is instant now[05:08:34] *** Keniyal_ has quit IRC[05:09:59] *** zajfy has quit IRC[05:13:07] *** kidnapped_robot has quit IRC[05:17:09] *** Nach0z is now known as NachOz[05:17:19] *** NachOz is now known as Nach0z[05:17:57] <ra4king> hmm, only parts of the buffer need to be modified[05:18:19] <ra4king> at sparse times. therefore implementing a rotating buffer would be a waste and slower[05:18:47] <ra4king> is it ok to edit the same data that is rendered? I'm doing that and it's not causing issues but I do believe that breaks the contract[05:19:45] *** TyrfingMjolnir has quit IRC[05:23:08] <glYoda> is it OK? …no[05:23:46] <ra4king> there we go, implemented fence sync[05:23:55] <ra4king> put in glFenceSync right after the draw call[05:24:01] <glYoda> as per the spec you'll need to handle synchronization explicitly on the client side[05:24:04] <ra4king> then I call glWaitSync right before the mapped buffer update[05:24:21] <ra4king> glYoda: right, that's what I thought. thanks[05:24:34] <glYoda> otherwise you'll have no control over when the GPU might actively source from a store you're actively modifying via the CPU[05:24:34] <ra4king> is my solution correct? testing it, it works fine and the framerate is the same[05:27:37] *** JoshSyn has joined ##OpenGL[05:27:42] <ra4king> glYoda: what does the flag "GL_SYNC_FLUSH_COMMANDS_BIT" for ClientWaitSync signify?[05:30:39] *** slidercrank has quit IRC[05:35:19] <ra4king> sweet, at 200 FPS, the ClientWaitSync call only costs me 0.029ms per frame[05:35:52] <ra4king> ~0.6% of the time it takes to render a frame[05:35:56] <ra4king> hooray \o/[05:40:01] *** xissburg has quit IRC[05:47:03] *** bb010g has quit IRC[05:50:51] *** JoshSyn has quit IRC[05:53:17] *** HunterD has joined ##OpenGL[05:54:16] *** Khlorghaal has quit IRC[05:59:52] *** TyrfingMjolnir has joined ##OpenGL[06:00:42] *** TunnelCat has quit IRC[06:00:46] *** petervaro has quit IRC[06:06:22] *** shingshang has joined ##OpenGL[06:06:29] <Budd> Once I call glProgramUniform*, does the uniform remain set if I use another program then return to the first one?[06:08:02] *** Zeioth has quit IRC[06:08:31] *** narcan has quit IRC[06:10:52] *** samrat has joined ##OpenGL[06:13:16] *** bb010g has joined ##OpenGL[06:17:02] *** Zupo has joined ##OpenGL[06:17:12] *** Zupo2 has quit IRC[06:20:04] *** hahuang65 has quit IRC[06:23:42] *** tcsc has quit IRC[06:25:17] *** HunterD has quit IRC[06:25:22] *** RyanPridgeon has quit IRC[06:25:35] *** HunterD has joined ##OpenGL[06:31:57] *** Zupo has quit IRC[06:38:49] <ra4king> this is very strange, I attach a bunch of textures to an FBO, 3 to color attachments and 1 for depth[06:38:57] <ra4king> reading back these textures gives me all 0's except for the depth[06:39:02] <ra4king> the depth texture is filled properly[06:47:19] *** meoblast001 has quit IRC[06:47:43] *** slidercrank has joined ##OpenGL[06:50:56] *** hahuang65 has joined ##OpenGL[06:53:46] *** mat^2 has joined ##OpenGL[06:53:49] *** HunterD has quit IRC[06:54:57] *** Garner has joined ##OpenGL[06:59:02] *** foreignFunction has joined ##OpenGL[07:02:43] *** Bigpet_ has quit IRC[07:07:15] *** Burga has joined ##OpenGL[07:24:04] *** shadowdaemon has quit IRC[07:26:00] *** shintah has joined ##OpenGL[07:29:00] *** HunterD has joined ##OpenGL[07:29:44] *** shadowdaemon has joined ##OpenGL[07:37:51] *** Dark_Confidant has joined ##OpenGL[07:40:52] *** Dark_Confidant|m has quit IRC[07:40:55] <ra4king> this is so frustrating[07:41:04] <ra4king> I created a project from scratch and made FBO's work fine[07:41:22] <ra4king> now in this original project, none of my color attachments are rendered to, only the depth attachment is filled properly[07:43:59] *** Nach0z has quit IRC[07:44:48] *** Nach0z has joined ##OpenGL[07:44:48] *** Nach0z has joined ##OpenGL[07:45:14] *** razieliyo has quit IRC[07:48:32] *** CainJacobi has quit IRC[07:50:25] *** Twinklebear has quit IRC[08:02:41] *** CainJacobi has joined ##OpenGL[08:04:35] *** BitPuffin has quit IRC[08:04:50] *** anivemin has joined ##OpenGL[08:05:41] *** damir__ has quit IRC[08:05:57] *** CainJacobi has quit IRC[08:07:57] *** Gamecubic has quit IRC[08:08:06] *** mm765 has joined ##OpenGL[08:21:11] *** maxton has joined ##OpenGL[08:22:47] *** kuldeepdhaka has quit IRC[08:30:24] *** kuldeepdhaka has joined ##OpenGL[08:30:57] *** robot-beethoven has joined ##OpenGL[08:32:06] <ra4king> very strange, it looks like glClear is clearing all the attached textures with the ClearColor properly but the fragment outputs are not put in the textures at all[08:35:10] *** centrinia has quit IRC[08:36:34] *** zoraj_ has joined ##OpenGL[08:39:49] *** zoraj__ has quit IRC[08:41:58] *** Tag_ has joined ##OpenGL[08:46:45] <Bloodust> hum[08:50:27] *** Jack_ has joined ##OpenGL[08:50:28] <Tag_> good morning![08:53:17] *** damir__ has joined ##OpenGL[08:53:17] *** Tag_ has quit IRC[08:54:28] *** Tag_ has joined ##OpenGL[08:57:46] *** ikrima has joined ##OpenGL[09:00:34] <newguise1234> guys, I'm having a problem with glEnableVertexAttribArray not being declared when I include <GL/glew.h>, I am including glew.h before anything else.[09:01:03] <newguise1234> well nvm, I spelled it wrong in my code[09:01:21] <newguise1234> Have been searching for whats wrong for too long TT____TT[09:05:18] <ra4king> and in the end it's because of 1 small state that caused me so much anguish[09:05:29] *** foobaz has quit IRC[09:05:45] <ra4king> blending was enabled, thus since all my output values had a=0, none were written to the textures[09:05:46] <ra4king> wow[09:06:01] <ra4king> 1 line: glDisable(GL_BLEND) was all I needed to fix my issue..... several months of headache[09:06:38] *** foobaz has joined ##OpenGL[09:07:04] <newguise1234> lol TT___TT[09:08:02] <newguise1234> haha, this may not be a great idea, but there is a person called bunnie huang, who with some others used a "fuzzer" to reverse engineer the pin interaction with an undocumented arm processor[09:08:10] <Bloodust> bahah[09:08:30] <newguise1234> you could write an OpenGL state "fuzzer" that would just run until you found something that worked for you :p[09:08:33] <Bloodust> lesson learned, dont have blending on all the time :D[09:09:36] *** Waynes has joined ##OpenGL[09:17:03] *** bb010g has quit IRC[09:22:52] *** moser has quit IRC[09:25:07] *** hdon has quit IRC[09:25:25] *** hdon has joined ##OpenGL[09:29:53] *** PasNox has joined ##OpenGL[09:32:36] *** Waynes has quit IRC[09:33:43] *** hdon has quit IRC[09:34:54] *** kuldeepdhaka has quit IRC[09:36:06] *** hdon has joined ##OpenGL[09:38:11] *** groton has joined ##OpenGL[09:40:05] *** moser has joined ##OpenGL[09:40:20] *** kuldeepdhaka has joined ##OpenGL[09:40:43] *** SurgeMedic has quit IRC[09:46:17] *** anivemin has quit IRC[09:47:35] *** erhan_ has joined ##OpenGL[09:50:46] *** robot-beethoven has quit IRC[09:54:03] *** Match has joined ##OpenGL[09:54:15] *** centrinia has joined ##OpenGL[09:56:33] *** telex has quit IRC[09:58:43] *** telex has joined ##OpenGL[09:59:34] *** anivemin has joined ##OpenGL[10:05:16] *** oberstein has quit IRC[10:05:55] *** Jack_ has quit IRC[10:07:51] *** HunterD has quit IRC[10:10:16] *** Madsy has joined ##OpenGL[10:10:16] *** Madsy has joined ##OpenGL[10:17:11] *** konom has joined ##OpenGL[10:17:28] *** redeemed has joined ##OpenGL[10:20:56] *** Beetny has joined ##OpenGL[10:26:18] *** groton has quit IRC[10:26:48] *** agorecki has quit IRC[10:32:06] *** Lemml has joined ##OpenGL[10:32:15] *** anivemin has quit IRC[10:32:22] *** HunterD has joined ##OpenGL[10:34:05] *** groton has joined ##OpenGL[10:35:54] *** groton has quit IRC[10:37:44] *** viggo2 has joined ##OpenGL[10:39:04] *** devbug has quit IRC[10:40:13] *** viggo has quit IRC[10:40:13] *** slidercrank has quit IRC[10:42:23] <_Cid> If I make a texture atlas for my sprite sheet[10:42:34] <_Cid> is there any real dimension restrictions to the atlas[10:43:04] *** s0s has quit IRC[10:43:20] <_Cid> or could it be one huge column of images[10:43:30] <Bloodust> there is[10:43:36] *** s0s has joined ##OpenGL[10:43:36] <Bloodust> but why atlas, why not array texture?[10:43:46] <_Cid> no texture switching[10:43:56] <_Cid> I made a program[10:44:00] <Bloodust> theres no texture switching in array texture[10:44:09] <_Cid> oh[10:44:11] <_Cid> but[10:44:16] <_Cid> they all have to be the same size[10:44:23] <Bloodust> thats true[10:44:33] <_Cid> this allows for variable size[10:44:47] <_Cid> I made a program to compile all the pictures in a directory into a single file[10:44:57] <_Cid> and saving one large header containing information[10:45:07] <_Cid> this way it'll save space and keep things less cluttered[10:45:23] <_Cid> (and easy to secure/validate contents)[10:45:24] <Bloodust> have you solved the filtering issues?[10:45:30] <_Cid> hm[10:45:36] <_Cid> I probably haven't run in to them yet[10:45:48] <_Cid> what are the filtering issues?[10:46:22] <Bloodust> texture borders sample nearby textures[10:46:27] *** kilon has joined ##OpenGL[10:46:27] *** kilon has joined ##OpenGL[10:46:36] <_Cid> hm[10:46:43] <_Cid> so they blend?[10:46:58] <_Cid> together I guess[10:47:04] <Bloodust> yeah[10:47:06] <_Cid> what do you do about this?[10:47:45] <Bloodust> dunno, tis the reason I use array textures[10:47:59] <_Cid> explain how it's different[10:48:06] <_Cid> why doesn't it occur with array textures[10:48:18] <Bloodust> array texture is like 3d texture[10:48:21] <_Cid> yes[10:48:24] <Bloodust> but it doesnt sample between texture layers[10:48:27] <Bloodust> unlike 3d texture[10:48:30] <_Cid> yes I've read about them[10:48:43] <_Cid> continue[10:48:49] <Bloodust> well thats it[10:49:00] <Bloodust> mipmapping works normally for array textures[10:49:10] <_Cid> this is a 2d sprite engine[10:49:25] <Bloodust> and filtering obv[10:49:41] <_Cid> So you're saying two sprites next to one another[10:49:47] <_Cid> will have a blended border[10:49:52] <_Cid> if I use a texture atlas[10:49:53] *** HuntsMan has quit IRC[10:50:23] *** oberstein has joined ##OpenGL[10:50:24] <_Cid> I don't see how a texture atlas will behave different from a texture array in this manner[10:50:25] <Bloodust> http://gamedev.stackexchange.com/questions/46963/how-to-avoid-texture-bleeding-in-a-texture-atlas[10:50:33] <Bloodust> texture atlas is a single 2d texture[10:50:49] <Bloodust> array texture is an array of 2d textures (in this case)[10:50:57] <Bloodust> filtering is applied to single textures in the array[10:51:19] <_Cid> ah[10:51:47] <Bloodust> anyway[10:51:49] <_Cid> well of course that will occur with 3d rendering[10:51:57] <_Cid> in a distance[10:52:00] <Bloodust> yeah its possible you wont have any issue with 2d[10:52:03] <_Cid> not in a 2d sprite environment[10:52:16] <_Cid> there wont be any transformations of that kind[10:52:17] <mathias__> _Cid: Depends if you can zoom out far enough or not[10:52:18] <_Cid> done to the sprites[10:52:23] <_Cid> exactly[10:52:42] <_Cid> thanks for the heads up though[10:54:56] <_Cid> yeah, you can definitely just add a padding around each sprite in your atlas to prevent bleeding into other textures[10:55:17] <_Cid> you may have to texture the padding too[10:55:24] <_Cid> if it's a seamless texture[10:55:46] <_Cid> anyway[10:57:10] *** Madsy has quit IRC[10:57:57] *** prophile has joined ##OpenGL[11:02:35] <newguise1234> guys, I've a base system set up and my initial render function is using vaos with GL_TRIANGLES[11:02:36] *** erhan_ has quit IRC[11:02:57] <newguise1234> to import a wavefront object file, it describes shapes in faces, could rendering this be as simple as changing GL_TRIANGLES to GL_QUAD to display it?[11:03:15] <mathias__> Could be![11:03:22] <newguise1234> thanks lol[11:03:40] <mathias__> no problem, happy to help.[11:03:50] *** centrinia has quit IRC[11:04:25] *** Demon_Fox has quit IRC[11:10:35] *** seangrove has quit IRC[11:10:36] *** seangrove has joined ##OpenGL[11:10:45] <ra4king> Bloodust: this is why I love doing this stuff myself[11:10:48] <ra4king> look how much I've learned![11:10:55] <ra4king> anyway... 5 am.... school is going to suck tomorrow[11:10:56] <ra4king> goodnight[11:22:08] *** Crehl has joined ##OpenGL[11:32:26] *** erhan_ has joined ##OpenGL[11:33:20] *** anivemin has joined ##OpenGL[11:33:53] *** ikrima has quit IRC[11:34:07] *** snakenerd has joined ##OpenGL[11:36:15] *** shintahW2 has joined ##OpenGL[11:37:47] *** anivemin has quit IRC[11:38:40] *** Burga has quit IRC[11:39:27] *** shintahW has quit IRC[11:39:27] *** shintahW2 is now known as shintahW[11:48:01] *** Madsy has joined ##OpenGL[11:48:36] *** snakenerd has quit IRC[11:56:13] *** PasNox has quit IRC[12:00:22] *** Crehl has quit IRC[12:03:52] *** TyrfingMjolnir has quit IRC[12:04:27] *** PasNox has joined ##OpenGL[12:09:08] *** Portals has joined ##OpenGL[12:09:32] *** centrinia has joined ##OpenGL[12:09:34] <Portals> Bloodust, you there?[12:09:43] <Bloodust> ye[12:10:29] *** PasNox has quit IRC[12:10:56] *** PasNox has joined ##OpenGL[12:12:07] <Portals> Raged quit yesterday, only had one texture rendered that was some reason rendered across the whole screen..Today, it was the normal size. Do you have to restart your computer sometimes to "reset" opengl? å[12:12:20] <Bloodust> nope[12:12:50] <Portals> Multiple textures work. wut[12:13:07] <Portals> It, it works[12:13:45] <Portals> My framebuffer works[12:13:58] <Portals> \o/[12:16:04] <Bloodust> who's manufactured your gpu?[12:16:38] <Portals> Sapphire[12:16:42] <Portals> 6870 hd[12:16:58] <Portals> Got two. But only one is running as of right now[12:17:40] <Portals> I had this program on two different computers, didn't work on either before. Works on one now. Going to test the other[12:17:56] *** _Cid has quit IRC[12:18:29] *** _Cid has joined ##OpenGL[12:24:58] *** gravitation has joined ##OpenGL[12:25:10] <gravitation> This seemingly simple OpenGL program fails to do anything: http://codepad.org/WakQRaEI[12:25:40] <gravitation> I get a blank blue screen, so I know the windowing system is correctly displaying OpenGL’s framebuffer. But my lines aren’t being drawn.[12:25:53] <gravitation> Also, changing glDrawArrays(GL_LINES, 0, 6); to use GL_TRIANGLE_FAN fails as well[12:26:26] <gravitation> the shaders are here: http://codepad.org/djIjjJ9L and here: http://codepad.org/nLwPZ2h6[12:26:43] <Bloodust> umm, objective C?[12:27:06] <gravitation> Yeah, but it’s mostly just straight C. You can ignore the Objective-C bits.[12:27:18] <Adrinael> Is something flipping buffers?[12:27:32] <Adrinael> Are you supposed to do that yourself?[12:27:32] <gravitation> It is, flushBuffer does the flip.[12:27:35] <Adrinael> Right[12:28:07] <gravitation> Dunno why they call it “flushBuffer,” when it’s really a buffer swap, but that’s just how it is :-p [been using that function for years, and it’s always worked][12:28:26] <gravitation> This is the first time I’m using 4.1 though, and this is a new machine, so I figure I have some 4.1-specific thing set up wrong.[12:28:52] <gravitation> glBindFragDataLocation(prog->programID, 0, "colorOut"); maybe?[12:28:53] <Bloodust> why are you normalizing your vertex data[12:29:03] <Bloodust> 36 to 38[12:29:16] <gravitation> because I had GL_FALSE there before, and changed it to GL_TRUE in a vain attempt to get it to draw :-p[12:29:16] *** s0s has quit IRC[12:29:22] <gravitation> I’ll flip it back[12:29:44] <gravitation> yeah, no change[12:29:58] <Bloodust> as long as dept test is off, I see no reason why this wouldnt work[12:30:01] <Bloodust> depth*[12:30:13] *** Portals has quit IRC[12:31:19] *** hdon has quit IRC[12:31:31] <gravitation> Bloodust: I just disabled it expicilty to make sure, and it still fails.[12:31:47] <gravitation> The weirdest thing is that the glGetError() doesn’t even report that anything is wrong. It just doesn’t draw.[12:33:10] *** kuldeepdhaka has quit IRC[12:34:47] <gravitation> ARRRRGG! :([12:36:33] *** Portals has joined ##OpenGL[12:38:16] *** HunterD has quit IRC[12:40:05] *** ManDay has joined ##OpenGL[12:40:24] *** moser has quit IRC[12:40:43] *** Portals has quit IRC[12:42:02] *** hdon has joined ##OpenGL[12:43:38] <gravitation> Nobody? :([12:45:45] <Bloodust> looks good[12:46:15] <gravitation> but it draws nothing but a blank blue screen :-/[12:46:55] <Bloodust> try disabling culling[12:47:26] <gravitation> I did[12:47:34] *** CrizMobius has joined ##OpenGL[12:51:36] *** HunterD has joined ##OpenGL[12:55:46] *** Portals has joined ##OpenGL[13:03:35] *** snakenerd has joined ##OpenGL[13:03:38] *** Beetny has quit IRC[13:04:04] *** anivemin has joined ##OpenGL[13:05:25] *** james4k has quit IRC[13:08:52] *** anivemin has quit IRC[13:09:07] *** PasNox has quit IRC[13:09:08] *** Jack has joined ##OpenGL[13:09:30] *** PasNox has joined ##OpenGL[13:09:32] *** Jack is now known as Guest90495[13:12:57] *** paperManu_ has joined ##OpenGL[13:14:17] *** tz has quit IRC[13:15:34] *** samrat has quit IRC[13:16:23] *** tz has joined ##OpenGL[13:16:57] *** PasNox has quit IRC[13:17:25] *** PasNox has joined ##OpenGL[13:17:33] *** Woomla has joined ##OpenGL[13:18:50] <ikarus> not quite an OpenGL question, but shadows from directional light sources, do people really just construct a orthographic camera that covers the clipspace ? and how on earth do people handle pointlights that cast shadows, decompose into several spotlights and hope you can do proper edge blending ?[13:21:10] *** tz has quit IRC[13:22:47] <Bloodust> yes. cubemaps I think.[13:22:53] *** tz has joined ##OpenGL[13:23:31] <ikarus> Bloodust: my poor head hurts when I think of the edge blending and precision issues with that....[13:24:37] <ikarus> I've been tempted to just tell artists nope[13:24:41] *** PasNox has quit IRC[13:25:02] *** PasNox has joined ##OpenGL[13:25:55] *** doev has joined ##OpenGL[13:26:09] *** hexagoxel has joined ##OpenGL[13:26:46] *** BitPuffin has joined ##OpenGL[13:27:46] <ikarus> considering doing a polar unwrap of the world in two halves (to make sure I can overlap the edges and stitch) but I know the operations for that are slow and the accuracy will suffer....[13:28:17] *** maxton has quit IRC[13:29:41] *** tz has quit IRC[13:31:25] *** tz has joined ##OpenGL[13:32:17] *** PasNox has quit IRC[13:32:39] *** PasNox has joined ##OpenGL[13:34:05] *** ManDay has quit IRC[13:37:39] *** moser has joined ##OpenGL[13:38:33] *** tz has quit IRC[13:39:27] *** tz has joined ##OpenGL[13:40:14] *** jdolan has quit IRC[13:40:48] *** jdolan has joined ##OpenGL[13:42:38] *** jdolan has quit IRC[13:43:11] *** jdolan has joined ##OpenGL[13:44:14] *** groton has joined ##OpenGL[13:46:23] *** roboman2444 has quit IRC[13:46:56] *** roboman2444 has joined ##OpenGL[13:47:40] *** jdolan has quit IRC[13:48:04] *** jdolan has joined ##OpenGL[13:49:08] *** tz has quit IRC[13:49:57] *** tz has joined ##OpenGL[13:51:09] <Woomla> I want to draw a cube with some colors and a rectangle with a texture, but the cube is black as soon as I draw the rectangle. Without the rectangle the cube has color. I use glBindTexture before drawing the rectangle. Should I unbind it?[13:52:45] <ikarus> in modern OpenGL, most of the musts in that depend on your shaders[13:54:13] *** tz has quit IRC[13:55:04] *** qeed has quit IRC[13:55:24] <gravitation> Bloodust: mother$%^&*(, I accidentally had the w coordinate set to 0 in my vert shader, that was it.[13:56:17] *** xissburg has joined ##OpenGL[13:56:32] <Woomla> It seems that after glTexImage2D it seems I cannot draw a cube with colors[13:56:53] <ikarus> Woomla: is this 1.2 or 2.1 fixed pipeline ?[13:56:56] *** tz has joined ##OpenGL[13:57:02] <ikarus> Woomla: because it sounds like it[13:58:11] *** jdolan has quit IRC[14:00:33] *** jorj has joined ##OpenGL[14:01:25] *** tz has quit IRC[14:01:50] <Bloodust> gravitation oh haha[14:02:03] <Bloodust> yeah we should have seen that :D[14:02:27] *** tz has joined ##OpenGL[14:03:38] *** paperManu_ has quit IRC[14:05:08] <Bloodust> Woomla so wheres the code?[14:05:39] *** HunterD has quit IRC[14:08:02] <Portals> Bloodust. When I just play around. I notice that my framebuffer doens't work when depth test is enabled[14:08:39] <Bloodust> but your fbo has depth buffer, right?[14:08:54] <Portals> Yep[14:09:18] <Bloodust> wicked[14:09:26] *** tz has quit IRC[14:10:27] *** tz has joined ##OpenGL[14:11:06] <Portals> The weird thing is. When depth test is disabled. Multiple textures gets rendered. though they get rendered in the opposite y coord.[14:12:24] <Portals> I don't know.[14:12:31] <Portals> Well, gonna keep testing[14:14:32] <newguise1234> no mathias__ ! GL_QUAD was not declared in this scope! lol[14:14:50] <newguise1234> guess I'm just doing a index expansion to turn them into triangles[14:14:57] *** tz has quit IRC[14:15:08] *** TheBix has joined ##OpenGL[14:15:29] <Bloodust> newguise1234 GL_QUADs is no longer part of core opengl[14:15:58] *** tz has joined ##OpenGL[14:17:14] <mathias__> newguise1234: Convert the faces into triangles and use gl_triangle_strip, or something[14:17:21] <mathias__> newguise1234: Use primtive restart if you have to[14:18:05] <Bloodust> no need to use strips or primitive restart if they are normal quads[14:18:23] <newguise1234> I'm pulling them from a wavefront object file, so I just have another for loop that makes a second triangle from the face indices[14:18:49] <Woomla> ikarus: I'm not that familiar with opengl :([14:19:06] <Bloodust> why not run the model through modeling software and let that triangulate it[14:19:23] <Bloodust> Woomla are you using shaders?[14:19:23] *** alllex229 has joined ##OpenGL[14:19:57] <Woomla> ikarus: but I've seem to find the solution. To use glDisable(GL_TEXTURE_2D) before drawing rectangles etc and enable it when drawing textures.[14:20:12] <Portals> Bloodust, how it looks right now : http://imgur.com/zdSIZTi[14:20:15] <Bloodust> so you are not using shaders[14:20:15] <Woomla> Bloodust: No, I'm not there yet[14:20:29] <Portals> If I switch the tex coords. it looks like this :[14:20:30] <ikarus> Woomla: sounds like old fashioned fixed pipeline, run away from that as soon as you can[14:20:33] *** tz has quit IRC[14:20:33] <Bloodust> Woomla shaders is the first thing you should learn when learning opengl[14:21:19] <Woomla> Bloodust: I'm now following nehe tutorials.[14:21:27] <newguise1234> Woomla: I'm pretty brand spanking new at this, but the arcsynthesis tutorial in the topic really helped[14:21:47] <Portals> http://imgur.com/U7KFn8T[14:22:00] <Bloodust> Woomla stop[14:22:04] <Bloodust> do not follow nehe tutorials[14:22:25] <newguise1234> You will hug people on the sidewalk after reading arcsynthesis tutorials[14:22:28] *** tz has joined ##OpenGL[14:23:51] <newguise1234> Bloodust: I downloaded blender and didn't see any easy options right there to output to a wavefront object file using triangle instead of quad faces[14:24:12] *** alllex229 is now known as alllex229_[14:24:18] <newguise1234> I just downloaded it so I could work on importing models into my program, and I should probably just use tinyobj or something like that[14:24:20] <Woomla> Ok, I did already looked at arcsynthesis. In the past I had fast results using nehe tutorials so...[14:24:52] <Bloodust> Woomla theres also https://open.gl/ and http://www.opengl-tutorial.org/[14:24:59] <Bloodust> they should be as fast as NeHe to start with[14:25:36] *** groton has quit IRC[14:25:47] <gravitation> I’m new to modern GLSL, the last time I played with it was back in 2.1[14:26:05] <Bloodust> its not much different[14:26:05] <gravitation> Why is that “attribute” is no now longer accepted in my vert shaders? It seems I have to use “in” instead.[14:26:17] <Bloodust> thats one of the changes[14:26:28] <Bloodust> attribute and varying got replaced with in/out[14:27:51] <Bloodust> newguise1234 dunno about blender but 3ds max exports triangles just fine[14:28:49] <japro> newguise1234, the obj exporter has a "triangulate faces" option[14:29:23] <newguise1234> thanks[14:30:01] *** alllex229_ has quit IRC[14:30:08] *** tz has quit IRC[14:30:48] *** Viata has joined ##OpenGL[14:31:58] *** tz has joined ##OpenGL[14:32:41] <Woomla> Bloodust: cool, thanks.[14:33:02] *** jdolan has joined ##OpenGL[14:34:08] *** moser has quit IRC[14:34:09] *** oberstein has quit IRC[14:34:44] *** moser has joined ##OpenGL[14:36:20] *** paperManu has joined ##OpenGL[14:36:42] *** tz has quit IRC[14:36:56] *** urraka has joined ##OpenGL[14:37:28] *** tz has joined ##OpenGL[14:42:22] *** tz has quit IRC[14:42:30] *** Zupo2 has joined ##OpenGL[14:42:58] *** tz has joined ##OpenGL[14:44:42] *** paperManu has quit IRC[14:45:36] <Portals> Bloodust, the problem seems to be that I flush incorrectly. å[14:46:02] <Bloodust> dont flush :/[14:47:28] *** tz has quit IRC[14:48:54] <Portals> I tried with multiple texture so I forced my spritebatch to flush after every texture. Got it to work correctly. If I had two or more of the same texture, I started to render a downscaled version of my framebuffer instead of the actually texture. Bloodust[14:48:59] *** tz has joined ##OpenGL[14:49:58] <Bloodust> you have silly problems[14:50:27] *** sam has quit IRC[14:51:32] <Portals> I do :)[14:52:52] *** anivemin has joined ##OpenGL[14:53:25] *** dreamminder has joined ##OpenGL[14:57:15] *** anivemin has quit IRC[14:57:16] *** sam has joined ##OpenGL[14:58:47] *** paperManu has joined ##OpenGL[15:01:09] *** tz has quit IRC[15:02:00] *** tz has joined ##OpenGL[15:02:59] *** Zeioth has joined ##OpenGL[15:03:03] *** samrat has joined ##OpenGL[15:05:37] *** Bigpet_ has joined ##OpenGL[15:06:45] *** tz has quit IRC[15:07:28] *** tehrain has joined ##OpenGL[15:07:29] *** tehrain has joined ##OpenGL[15:08:30] *** tz has joined ##OpenGL[15:10:49] *** Ryp has joined ##OpenGL[15:12:35] *** Folkol has joined ##OpenGL[15:17:09] <Portals> It's so weird, it's like my framebuffer can't handle 8 vertices on the same texture.[15:18:57] *** tz has quit IRC[15:18:57] <Portals> My spritebatch can render to the screen no problem. But when it tries to render to the framebuffer. Somethings happens.[15:18:58] *** pazul has joined ##OpenGL[15:20:31] *** tz has joined ##OpenGL[15:22:21] *** TyrfingMjolnir has joined ##OpenGL[15:25:07] *** razieliyo has joined ##OpenGL[15:25:22] *** HunterD has joined ##OpenGL[15:25:23] *** tz has quit IRC[15:26:41] *** centrinia has quit IRC[15:27:01] *** tz has joined ##OpenGL[15:28:41] *** alllex229_ has joined ##OpenGL[15:31:46] *** Alina-malina has quit IRC[15:31:52] *** Tag_ has quit IRC[15:32:27] *** Alina-malina has joined ##OpenGL[15:32:28] *** Alina-malina has quit IRC[15:32:28] *** Alina-malina has joined ##OpenGL[15:33:36] *** BitPuffin has quit IRC[15:33:49] *** tz has quit IRC[15:34:33] *** tz has joined ##OpenGL[15:36:03] *** raptop has joined ##OpenGL[15:37:17] <raptop> Hello , i am going to implement a CHC++ algorithm on my opengl renderer, i am wondering if there is any recommendation for a fast kdtree library[15:37:59] *** reiny_day has joined ##OpenGL[15:38:16] <japro> i'd like to say, obj file indexing starting at 1 is annoying... thanks for listening[15:38:20] *** BitPuffin has joined ##OpenGL[15:40:39] *** Alina-malina has quit IRC[15:41:53] *** Ryp has quit IRC[15:44:14] *** gravitation has quit IRC[15:44:17] *** t4nk038 has joined ##OpenGL[15:46:28] *** Alina-malina has joined ##OpenGL[15:46:29] *** Alina-malina has quit IRC[15:46:29] *** Alina-malina has joined ##OpenGL[15:47:03] *** slidercrank has joined ##OpenGL[15:48:03] *** doomlord_1 has joined ##OpenGL[15:48:55] *** doomlord_1 has joined ##OpenGL[15:49:36] *** kilon has quit IRC[15:50:09] *** Orion] has joined ##OpenGL[15:51:49] *** tz has quit IRC[15:52:32] *** tz has joined ##OpenGL[15:53:38] *** anivemin has joined ##OpenGL[15:55:45] *** maxton has joined ##OpenGL[15:56:40] *** tz has quit IRC[15:57:34] *** Gamecubic has joined ##OpenGL[15:58:09] *** anivemin has quit IRC[15:59:02] *** tz has joined ##OpenGL[15:59:20] <Yaniel> oh so you noticed[16:01:06] *** HuntsMan has joined ##OpenGL[16:01:30] *** DrSkyLizard has joined ##OpenGL[16:03:08] *** Ryp has joined ##OpenGL[16:03:56] *** Khlorghaal has joined ##OpenGL[16:05:12] *** TheBix has quit IRC[16:07:05] *** damir__ has quit IRC[16:09:19] *** Portals has quit IRC[16:09:53] *** dusted has joined ##OpenGL[16:10:45] *** tz has quit IRC[16:11:08] *** bb010g has joined ##OpenGL[16:11:32] *** tz has joined ##OpenGL[16:11:41] *** Folkol has quit IRC[16:13:15] *** AbigailBuccaneer has joined ##OpenGL[16:14:47] <t4nk038> hello, i know its not and opengl question but i think is a related top[16:15:29] *** petervaro has joined ##OpenGL[16:15:35] <t4nk038> im currently calculating smooth normals by getting each vertex/normal and iterate for each normal through all vertices and check which face vertices are connected to the "current" vertex and than interpolate the normals[16:15:51] <t4nk038> after that i divide this interpolated normals vector through the number of sums and normalize them[16:15:58] <t4nk038> works fine, but is slow[16:16:24] <t4nk038> i have a binary format, where everything triangle is stored seperately[16:16:32] *** tz has quit IRC[16:16:40] <t4nk038> without smooth normal calc it takes about 12ms to load the mesh with animations[16:16:52] <t4nk038> with my smooth normal calculations it takes about 1 second[16:17:02] *** tz has joined ##OpenGL[16:17:13] <t4nk038> because i iterate through each vertex (10000) about 10.000 times :)[16:17:43] <AbigailBuccaneer> t4nk038, is this for loading static assets? it's much more normal to do normal smoothing at export time than load time[16:18:16] <t4nk038> its an vertex animated mesh[16:18:20] <t4nk038> kinda like the md2 format[16:18:35] <t4nk038> for static assets i use the obj format with exported normals[16:18:47] <t4nk038> for animations i have written a binary format with vertices and uv coordinates[16:19:43] *** Zupo2 has quit IRC[16:20:02] *** Zupo2 has joined ##OpenGL[16:20:05] <AbigailBuccaneer> fair enough. if you're iterating over each vertex once for each other vertex, you need to get some more appropriate data structures :P[16:21:35] <t4nk038> well the reason i use a binary format is to get the mesh directly into memory :)[16:21:36] *** tz has quit IRC[16:21:49] <japro> iterate over triangles, and add th normal to all the vertices. then do a second pass over all vertices normalizing again[16:22:15] <t4nk038> th normal?[16:22:32] <AbigailBuccaneer> presumably a typo of "the normal"[16:23:00] *** DolpheenDream has joined ##OpenGL[16:23:02] *** tz has joined ##OpenGL[16:23:21] <AbigailBuccaneer> presumably "the normal" here means the face normal, which you can get by taking a cross product of two of the edge vectors of your triangle[16:23:26] <AbigailBuccaneer> and is sufficient to give you unsmoothed normals[16:23:32] <t4nk038> i do that already[16:23:42] <t4nk038> i do this while loading the mesh from binary[16:23:44] <japro> that gives you smoothed normals (assuming you use indexed dat)[16:23:56] <japro> but my algorithm isn't n^2 :)[16:24:00] *** RyanPridgeon has joined ##OpenGL[16:24:32] <t4nk038> japro, currently my order is load vertices and uvs for each triangle from binary, calculate (flat) normals and store them[16:24:49] <t4nk038> after all data is loaded from file, i smooth them[16:25:03] <t4nk038> but for this i need to find the adjutant vertices for every vertex[16:25:24] <AbigailBuccaneer> the smoothed normal of a vertex should just be the average of each flat face normal that the vertex is a part of, right?[16:25:29] <japro> nah, just iterate over the trianges and add to their respective vertex normals[16:26:29] <t4nk038> so just the sum of all 3 vertex normals?[16:26:38] <t4nk038> sumNormals /= 3[16:26:40] <t4nk038> and then normalize?[16:27:40] <japro> just normalize[16:27:44] *** tz has quit IRC[16:27:46] *** puerum has quit IRC[16:27:52] <japro> since scaling the vector doesn't change the direction anyway[16:28:01] *** groton has joined ##OpenGL[16:29:02] *** tz has joined ##OpenGL[16:29:15] <japro> actually why 3 vertex normals?[16:29:28] *** theripper93 has joined ##OpenGL[16:29:52] <japro> smoothing means you are calculating vertex normals by averaging the normals of the triangles, not the other way around[16:30:46] <AbigailBuccaneer> japro, i think t4nk038's data already has vertex normals - which might just be derived from face normals earlier in the export pipeline?[16:31:07] <t4nk038> no, i calculate my normals from the triangles vertices[16:31:11] <AbigailBuccaneer> but yeah the usual thing to do is to calculate the normal of a face by doing some math to calculate the vector perpendicular to the triangle plane[16:31:58] <AbigailBuccaneer> t4nk038, what exactly does this per-vertex normal data you already have look like?[16:32:34] <t4nk038> like flat shading[16:32:56] <AbigailBuccaneer> so they exactly match what the face normals would be (and presumably you have lots of duplicated vertices to achieve this)?[16:33:49] *** newguise1234 has quit IRC[16:33:51] <t4nk038> well maybe this code explains more than my words: http://codepaste.net/iuhycr[16:34:44] <japro> all i'm saying is you don't have to iterate over the vertices and find all the adjacent ones, just iterate over the trianges instead and "scatter" the normals instead of "gathering" them[16:34:51] <japro> which gives you a faster algorithm[16:35:05] <enleeten> echo $STY[16:36:15] <t4nk038> i get what you mean, but i just dont get how i should implement this[16:37:17] *** Nickeeh has quit IRC[16:37:29] <japro> for(triangles) for(i=0:2)vertex_normal[i] += triangle_normal;[16:37:38] <japro> for(vertices) normalize(vertex)[16:38:06] <AbigailBuccaneer> t4nk038, part of the problem is that your format involves no sharing of normals[16:38:16] <japro> do we know that?[16:38:23] *** icedev has quit IRC[16:38:26] <t4nk038> yes, each triangle is stored as is[16:38:29] <AbigailBuccaneer> *no sharing of vertices[16:38:54] <AbigailBuccaneer> ie. if two triangles share an edge, then that's six vertices, and two of them happen to be in the same position as two other vertices[16:38:57] *** james4k has joined ##OpenGL[16:39:39] <AbigailBuccaneer> and so there's multiple copies of each vertex that you presumably want to be identical[16:39:54] <japro> if the data is not indexed you are pretty much screwed yes :D[16:39:56] *** foreignFunction has quit IRC[16:39:57] <t4nk038> well i think ill implement normal calculation in my blender export script[16:40:00] <t4nk038> :)[16:40:02] *** Nickeeh has joined ##OpenGL[16:40:03] <t4nk038> that will be easier[16:40:11] <AbigailBuccaneer> if you can, switching to indexed rendering (ie. with a GL_ELEMENT_ARRAY_BUFFER and shared vertices) would be vastly preferable[16:42:09] <japro> if the vertices are exactly the same you can kinda calculate indices efficiently by sorting them lexically and then numbering them according to that[16:42:23] *** tm604 has joined ##OpenGL[16:42:28] *** haasn has quit IRC[16:42:56] *** tm604 has quit IRC[16:42:56] *** tm604 has joined ##OpenGL[16:42:58] *** alllex229_ has quit IRC[16:43:06] *** theripper93 has quit IRC[16:43:20] *** james4k has quit IRC[16:43:25] <AbigailBuccaneer> japro, smoothing normals should be done at export time rather than load time, but exporting indexed data should *really really* be done at export time :P[16:43:58] <japro> pfft :) why make it easy when you can do it the hard way[16:49:41] *** haasn has joined ##OpenGL[16:49:45] <t4nk038> ok ok i will export indices and create the mesh from that :D[16:49:52] *** tz has quit IRC[16:50:32] *** tz has joined ##OpenGL[16:56:42] *** farhad has joined ##OpenGL[16:56:58] *** Madsy has quit IRC[16:57:22] *** staylor has joined ##OpenGL[17:01:01] *** RyanPridgeon has quit IRC[17:02:17] *** Ryp has quit IRC[17:02:48] *** gareppa has joined ##OpenGL[17:05:43] *** Ryp has joined ##OpenGL[17:05:50] *** zajfy has joined ##OpenGL[17:06:02] *** harha_ has joined ##OpenGL[17:06:30] <harha_> Been writing a cook-torrance shader, does this look right at all? :P http://i.imgur.com/id1LSXb.png[17:06:41] *** tz has quit IRC[17:09:23] *** ragecryx has joined ##OpenGL[17:09:27] *** Alina-malina has quit IRC[17:09:31] *** Ryp has quit IRC[17:09:32] *** anivemin has joined ##OpenGL[17:09:32] *** tz has joined ##OpenGL[17:09:33] *** Ryp1 has joined ##OpenGL[17:10:18] <harha_> http://i.imgur.com/yt6VjwG.png <-- Improved it a bit since that last screenshot.[17:11:38] <Bloodust> thats a mighty specular highlight[17:12:10] <Bloodust> although I dont think that its correct[17:12:28] *** MLM has joined ##OpenGL[17:14:10] *** anivemin has quit IRC[17:14:14] *** tz has quit IRC[17:15:33] *** tz has joined ##OpenGL[17:15:56] <harha_> Well the surface material info is fixed atm with really shiny properties. I'm not sure either about my calculations, the specular could be wrong somehow and probably is..[17:16:06] *** DrSkyLizard has quit IRC[17:17:22] *** pazul has quit IRC[17:17:22] *** pazul has joined ##OpenGL[17:18:37] *** Madsy has joined ##OpenGL[17:19:32] <Stragus> harha_, that doesn't look quite right, and the black spots on the geometry are worrying. Are these shadows or the symptom of a bug?[17:20:58] *** Zupoman has joined ##OpenGL[17:21:01] <harha_> symptoms of a bug[17:21:34] <harha_> Well good to hear that it doesn't look right at all, I was quite unsure myself.[17:21:58] *** doev has quit IRC[17:22:48] *** timsche has joined ##OpenGL[17:24:14] *** roboman2444 has quit IRC[17:24:48] *** reiny_day has quit IRC[17:31:05] *** DrBenway has quit IRC[17:32:30] *** tz has quit IRC[17:32:46] *** BitPuffin has quit IRC[17:33:34] *** tz has joined ##OpenGL[17:34:38] *** anivemin has joined ##OpenGL[17:39:11] *** anivemin has quit IRC[17:42:06] *** Woomla has quit IRC[17:44:21] *** roboman2444 has joined ##OpenGL[17:44:31] *** raptop has quit IRC[17:44:32] *** roboman2444 has quit IRC[17:44:32] *** roboman2444 has joined ##OpenGL[17:47:19] *** radr has joined ##OpenGL[17:47:37] *** Alina-malina has joined ##OpenGL[17:47:37] *** Alina-malina has quit IRC[17:47:37] *** Alina-malina has joined ##OpenGL[17:49:06] *** alllex229_ has joined ##OpenGL[17:51:29] *** Ryp1 has quit IRC[17:52:37] *** redeemed has quit IRC[17:52:48] *** tz has quit IRC[17:54:43] *** stefkos has joined ##OpenGL[17:54:50] *** Alina-malina has quit IRC[17:55:05] *** tz has joined ##OpenGL[17:55:40] *** harha_ has quit IRC[17:58:33] *** samrat has quit IRC[18:00:20] *** telex has quit IRC[18:02:47] *** telex has joined ##OpenGL[18:04:24] *** tz has quit IRC[18:06:04] *** tz has joined ##OpenGL[18:07:01] *** samrat has joined ##OpenGL[18:07:19] *** Ryp has joined ##OpenGL[18:08:44] *** HunterD has quit IRC[18:09:46] *** newguise1234 has joined ##OpenGL[18:10:10] <newguise1234> can anyone try to join #intel-gfx and see if they are banned? I've never been there and I do have a registered nickname[18:12:06] *** Ad1 has joined ##OpenGL[18:13:48] <AbigailBuccaneer> newguise1234, i can join just fine[18:16:31] *** samrat has quit IRC[18:17:37] *** tz has quit IRC[18:18:45] <t4nk038> AbigailBuccaneer, i rewrote my exporter and i now use indices and glDrawElements[18:18:48] <t4nk038> holy shit is that awesome[18:18:58] <t4nk038> loading time went down from 14ms to 0.5 ms[18:19:06] *** CrizMobius has quit IRC[18:19:07] <newguise1234> AbigailBuccaneer: thanks for checking, it looks like the webclient is banned on their list :/[18:19:12] <t4nk038> file size for the base mesh from 1,7mb to 66kb :D[18:19:31] <AbigailBuccaneer> t4nk038, nice! such big wins always feel great :D[18:19:34] *** tz has joined ##OpenGL[18:19:39] <t4nk038> yes thanks a lot[18:21:00] *** samrat has joined ##OpenGL[18:24:15] *** rawtass has joined ##OpenGL[18:27:08] *** neurre has joined ##OpenGL[18:28:32] <neurre> anyone know a program that could generete cubemap noise textures?[18:29:28] *** hahuang65 has quit IRC[18:31:32] *** samrat has quit IRC[18:31:41] *** stoopdapoop is now known as stoopdaschool[18:31:53] *** ClarusCogitatio has joined ##OpenGL[18:32:05] *** stoopdaschool is now known as stoopdapoop[18:33:49] *** tz has quit IRC[18:34:13] *** karab44 has joined ##OpenGL[18:35:00] *** samrat has joined ##OpenGL[18:35:07] <newguise1234> neurre: glm has some noise functions, I dont know if thats what you're looking for[18:35:26] <neurre> no, i need a texture map[18:36:05] *** tz has joined ##OpenGL[18:38:38] <newguise1234> neurre: could you just generate 2 dimensions of noise and cut out a cubemap shape? or is that inane[18:38:42] *** petervaro has quit IRC[18:39:00] *** erhan_ has quit IRC[18:39:06] <neurre> i know i could get this done myself[18:39:13] <neurre> but im just seeing if there are shortcust[18:39:16] <newguise1234> got it[18:39:16] <neurre> cuts[18:40:29] *** tz has quit IRC[18:42:06] *** tz has joined ##OpenGL[18:43:10] *** SHLV has joined ##OpenGL[18:43:36] *** Waynes has joined ##OpenGL[18:44:02] *** SHLV has quit IRC[18:44:46] *** dusted has quit IRC[18:46:21] *** Viata has quit IRC[18:47:10] *** TheBunnyZOS has joined ##OpenGL[18:49:02] *** Match has quit IRC[18:51:26] *** Madsy has quit IRC[18:51:48] *** TyrfingMjolnir has quit IRC[18:52:33] *** groton has quit IRC[18:53:04] *** Madsy has joined ##OpenGL[18:53:04] *** Madsy has joined ##OpenGL[18:59:40] *** hdon has quit IRC[18:59:58] *** pizthewiz has joined ##OpenGL[19:02:17] *** FrodoTheHobbit has quit IRC[19:02:51] *** FrodoTheHobbit has joined ##OpenGL[19:03:52] *** CainJacobi has joined ##OpenGL[19:03:53] *** Cain_Jacobi has joined ##OpenGL[19:03:54] *** damir__ has joined ##OpenGL[19:03:57] *** Cain_Jacobi has quit IRC[19:07:08] *** dreamminder has quit IRC[19:08:24] *** PasNox has quit IRC[19:08:31] *** groton has joined ##OpenGL[19:08:59] *** CainJacobi has quit IRC[19:09:01] *** BreadProduct has joined ##OpenGL[19:09:30] *** CainJacobi has joined ##OpenGL[19:09:30] *** Misu has joined ##OpenGL[19:09:46] *** katlogic has quit IRC[19:09:53] *** katlogic_ has joined ##OpenGL[19:11:45] *** aethersis has joined ##OpenGL[19:12:06] *** tz has quit IRC[19:12:09] *** aethersis is now known as dreamminder[19:12:36] *** tz has joined ##OpenGL[19:12:42] *** BitPuffin has joined ##OpenGL[19:13:08] *** Ad1_RN has joined ##OpenGL[19:14:36] *** hdon has joined ##OpenGL[19:15:19] *** hahuang65 has joined ##OpenGL[19:15:39] *** hahuang65 has joined ##OpenGL[19:17:05] *** ShadowIce has joined ##OpenGL[19:17:05] *** Ad1_RnR has quit IRC[19:22:06] *** samrat has quit IRC[19:22:39] *** fmardini has joined ##OpenGL[19:22:42] *** shingshang has quit IRC[19:24:09] *** gareppa has quit IRC[19:25:18] <fmardini> Hi, I am using OpenGL ES and I want to something like gl_vertexid in my shaders. I am drawing using draw[19:25:40] <fmardini> elements and thus send an buffer with indices[19:26:08] <fmardini> do I need to switch to drawarray and send index along, or is there a trick i'm missing[19:28:02] *** RyanPridgeon has joined ##OpenGL[19:28:14] *** samrat has joined ##OpenGL[19:29:16] <roboman2444> so i know how to make voronoi using the depth buffer and rendering cones... how would i generate actual geometry off of it?[19:30:01] <roboman2444> im sure there is an actual algorithm to do so, but in the mean time i was thinking run a marching cubes-like algorithm on a voronoi texture[19:31:05] *** hexagoxel has quit IRC[19:31:51] <Madsy> fmardini: Pretty sure there is no support for gl_VertexID on OpenGL ES. Extensions have support for gl_InstanceID, glVertexAttribDivisor and glDrawArraysInstanced though.[19:32:26] <Madsy> roboman2444: What do you mean with "generate actual geometry" ? A voronoi tesselation is already geometry, no?[19:32:58] <roboman2444> Madsy, the way i know of how to do voronoi images are render cones and abuse the depth buffer[19:33:04] *** groton has quit IRC[19:33:20] <roboman2444> i was wondering if there was some resources on how to actually generate meshes[19:33:47] <fmardini> Madsy: Yes there is no support. I was thinking of sending extra info along, but that doesn't work since I draw using drawelements and index should update each time a vertex is referenced[19:33:53] <Madsy> I'm not sure what you're trying to achieve[19:35:43] *** Crehl has joined ##OpenGL[19:36:36] *** samrat has quit IRC[19:37:08] <fmardini> Madsy: I want to experiment with having the barycentric coordinates in the fragment shader, my idea was to send (1,0,0) (0,1,0) (0,0,1) along each vertex and those will get interpolated in the fragment shader, so i wanted to get the index, mod it by 3, and and along[19:37:40] *** Dark_Confidant|m has joined ##OpenGL[19:37:40] *** Dark_Confidant has quit IRC[19:41:50] *** foreignFunction has joined ##OpenGL[19:44:56] *** fmardini has quit IRC[19:45:26] *** neurre has quit IRC[19:45:35] *** RoestVrijStaal has joined ##OpenGL[19:45:39] <t4nk038> is there an benefit if using glDrawElements if using a texture mesh?[19:46:02] <t4nk038> it looks like i need to duplicate nearly every vertex[19:46:26] <t4nk038> not two vertices have the same texture coordinates[19:46:58] <newguise1234> do ibo indices start at 0 or 1?[19:47:37] <Bloodust> 0[19:47:47] *** hexagoxel has joined ##OpenGL[19:48:09] <Bloodust> t4nk038 depends on mesh[19:48:09] *** rawtass has quit IRC[19:48:46] <t4nk038> well i can imagine its useful on walls, with repeating uv coordinates and vertex positions[19:51:22] *** Slion has joined ##OpenGL[19:52:03] <Bloodust> and spherical shapes[19:53:18] <t4nk038> hm and its a pain to write an exporter that converts vertex indices and uv indices into one index buffer :D[19:53:52] *** Alina-malina has joined ##OpenGL[19:54:37] <Bloodust> well its not fun I can tell you that[19:54:47] <Bloodust> my fbx exporter is pretty heavy[19:58:23] <t4nk038> well i think ill sacrifice file size to my mental health[19:58:43] *** cr`nge has joined ##OpenGL[20:01:30] *** karab44 has quit IRC[20:01:41] *** tz has quit IRC[20:02:09] *** BitPuffin has quit IRC[20:02:45] *** derhass has joined ##OpenGL[20:04:02] <newguise1234> does it mean anything besides the fact that my shaders aren't operating properly[20:04:07] *** tz has joined ##OpenGL[20:04:18] <newguise1234> if when I glDrawArrays(GL_POINTS) I end up with a single point in the middle of the screen?[20:05:05] <t4nk038> well gl_points takes every vertex coordinate, well, as a point[20:05:07] <newguise1234> thats about all my dunceness can get to show up right now and it won't move around based on static offsets added to vertexCoord and set to gl_Position[20:05:10] <t4nk038> so maybe something is wrong with your buffer[20:05:39] <t4nk038> so you try to modify the point position in the vertex shader?[20:05:39] <newguise1234> right, I should be passing in 5 points minimum and 8 points maximum[20:05:48] <newguise1234> yes and nothing changes[20:05:55] <newguise1234> but the fragment shader will change the color[20:06:11] <t4nk038> well fragment can work even if your vertex shader has errors, i think[20:06:24] <t4nk038> but dont take me for granted[20:07:11] <krnlyng> hi, have an application where i am writing a plugin for. the application segfaults if i add glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, 0, colors); but not actually there, somewhere else, what possible reasons could that be?[20:07:41] <t4nk038> do you print shader status?[20:08:06] <t4nk038> krnlyng, which profile?[20:08:12] <t4nk038> version?[20:08:13] <newguise1234> t4nk038: I'm not sure how to do that[20:08:17] *** tz has quit IRC[20:08:21] <krnlyng> t4nk038: GLES 2.0[20:08:23] <newguise1234> oh sorry[20:08:34] <krnlyng> t4nk038: shader status?[20:08:50] <t4nk038> https://www.opengl.org/wiki/Shader_Compilation[20:08:56] <t4nk038> newguise1234[20:09:37] *** tz has joined ##OpenGL[20:09:53] <t4nk038> krnlyng the last parameter is offset[20:09:57] <t4nk038> what is colors supposed to be?[20:10:05] *** Alina-malina has quit IRC[20:10:09] *** lasserix has joined ##OpenGL[20:10:33] <t4nk038> its something like (GLvoid*)(sizeof(float)*3 // 3 floats offset[20:10:52] *** hdon has quit IRC[20:11:06] <krnlyng> t4nk038: https://www.opengl.org/sdk/docs/man/html/glVertexAttribPointer.xhtml says its the pointer to the data?[20:11:21] <newguise1234> the shaders are compiling, I finally got that working lol. Uniform Locations have been gotten and supposedly the uniform variables have been set[20:11:26] <krnlyng> t4nk038: colors is GLfloat colors[4*NUM];[20:11:57] <t4nk038> krnlyng, read the description below[20:12:05] <newguise1234> using glMapBuffer, I've printfd the data and it matches what I wrote to it, I guess maybe my attribute may be off, but I thought about it pretty thoroughly when I wrote that section of code[20:12:18] <newguise1234> I guess if I did it right I wouldn't be having problems though lol[20:12:22] <t4nk038> krnlyng, the parameter description[20:13:15] <dreamminder> fluid simulation! https://www.youtube.com/watch?v=Zl0_FSi0Kno[20:13:22] *** gareppa has joined ##OpenGL[20:13:54] <krnlyng> t4nk038: and how would i specify the data if this is only an offset? i am confused (sorry, new to opengl(es))[20:14:20] <t4nk038> the vertex array object only defines how the data from the vertex buffer object is used krnlyng[20:14:33] <t4nk038> it knows nothing about the data[20:14:48] <dawik> krnlyng: you would bind and upload the data to a vertex buffer object first[20:15:53] <krnlyng> dawik, t4nk038: ah thanks[20:16:06] <krnlyng> do you know any good examples for this?[20:16:22] <krnlyng> now i am wondering why the code worked on my previous device...[20:17:07] <t4nk038> well maybe you are lucky and you got the right offset from your color :D[20:17:11] <t4nk038> but dont do that[20:17:37] <dawik> the sequence of things are important since you opengl is implemented as a state machine.. https://open.gl/drawing <- i think this example is good, but you have to adjust some function calls to their ES-counterparts, but he lesson is the same[20:18:44] <Budd> where can I get a list of predefined shader variables (e.g. gl_ModelViewProjectionMatrix)?[20:19:20] <t4nk038> Budd, what?[20:19:20] *** cr`nge has quit IRC[20:19:42] <t4nk038> well that depends on your version[20:19:51] <t4nk038> you have to use deprecated opengl to get that[20:20:09] <t4nk038> for recent/modern opengl versions, you need to write your own matrices[20:20:23] <Budd> really? I'm behind the times. I thought the docs were incomplete :)[20:21:04] <t4nk038> yes, well its a overhead in the beginning, but really simplifies everything once you have a framework[20:21:31] <Budd> So everything down to the transform matrices is manual now, yes? So glTranslate and friends are presumably obsolete as well, since I won't be using their matrices.[20:21:39] <t4nk038> exactly[20:22:01] <t4nk038> well you can still create an opengl 2.0 context :)[20:22:09] <dawik> you could basically just assign your Native Device Coordinates directly with gl_Position :)[20:22:12] <t4nk038> but the driver just wraps vbos around that stuff, inefficiently[20:22:28] <dawik> and not bother with matrices[20:22:43] *** snakenerd has quit IRC[20:22:51] <t4nk038> if you dont want to do any matrices/vectors stuff, use glm[20:22:56] <t4nk038> if you use c++[20:23:03] <dawik> or linmath.h if you are cool, and code C :D[20:23:11] <Bloodust> bahahah[20:23:53] <dreamminder> *faints*[20:23:56] <t4nk038> xD[20:24:15] <t4nk038> well there is a reason why Unity Engine is popular nowadays[20:24:24] <dreamminder> to hell with linmath! math.h ftw xD[20:24:34] <t4nk038> just look at tigsource, noone is writing an own engine anymore[20:24:40] <stoopdapoop> glm? more like DirectXMath[20:24:43] * stoopdapoop runs for the hills[20:31:54] *** snakenerd has joined ##OpenGL[20:32:24] <dreamminder> do oyu have any cool projects you can show? :D[20:33:05] *** cr`nge has joined ##OpenGL[20:37:07] <dreamminder> t4nk038, I think that writing one's own engine doesn't make much sense any more[20:37:19] <dreamminder> unless you need it for something very very specialized[20:37:50] <t4nk038> well i think it does if you want to understand how an engine works and if you want to optimize[20:38:17] <t4nk038> every game needs different implementations, i dont think an engine, that does everything, can handle this right[20:39:03] <krnlyng> dawik, t4nk038: is this correct now? https://bpaste.net/show/312076b5556a i get a black screen.. (at first it renders the octagons, but they disappear after some time) could this be because of this code or should i look somewhere else?[20:39:22] *** snakenerd has quit IRC[20:39:31] <t4nk038> krnlyng, why do you bind the shader?[20:39:38] <t4nk038> you bind the shader program before you draw the object[20:40:03] <t4nk038> and if in your draw function, you bind the vertex array object[20:40:15] <t4nk038> then draw with glDrawElements/glDrawArrays[20:40:56] <t4nk038> and the way you setup the buffer size looks wrong to me[20:41:46] <t4nk038> ah well no it could be right, you only have one "color"[20:42:15] <t4nk038> please dont create buffers in the main loop[20:42:25] <t4nk038> all you do there is binding the shader program, and draw the object[20:42:31] <krnlyng> t4nk038: erm so the correct flow would be?[20:42:54] <Bloodust> 1) initialize 2) use[20:43:32] <t4nk038> init phase -> create vertex buffer objects, create vertex array objects "game loop" -> bind shader, bind vertex array object of the mesh -> draw mesh[20:44:26] <timsche> just think about output performance when you create buffers in a thight renderer loop[20:44:38] <t4nk038> dat memory leaks[20:45:21] <Bloodust> mm[20:45:42] *** ClarusCogitatio has quit IRC[20:48:05] <t4nk038> krnlyng, i would recommend you to create a struct that holds the vertex buffer objects data[20:48:09] <t4nk038> call it vertexData[20:48:29] <t4nk038> and put float vertex[3]; float normal[3]; float uv[2]; in there[20:48:34] *** BlackFox has quit IRC[20:48:46] <t4nk038> so you can use sizeof(vertexData) * numberOfVertices to create the buffer[20:48:59] <t4nk038> i think this helps to keep your code clean and helps you understand it[20:50:05] *** ClarusCogitatio has joined ##OpenGL[20:51:28] *** BlackFox has joined ##OpenGL[20:54:09] <newguise1234> can you use vaos, vbos and ibos with opengl 2.1?[20:54:23] *** Madsy has quit IRC[20:54:59] <japro> vaos are available via extensions, the rest is there anyway[20:55:38] <Bloodust> vbos and (maybe ibos) were added in opengl 1.5[20:55:57] *** Madsy has joined ##OpenGL[20:55:57] *** Madsy has joined ##OpenGL[20:56:13] *** snakenerd has joined ##OpenGL[20:56:24] <newguise1234> k, how do yall start approaching a problem w/ opengl when you have no clue where to look?[20:57:14] <t4nk038> there are tons of tutorials out there, just be careful which version they use[20:57:59] <t4nk038> is there a reason why you use 2.1?[20:58:14] <derhass> newguise1234: depends on the kind of problem[20:58:17] <newguise1234> my intel gfx card in my laptop doesn't go higher[20:58:37] <krnlyng> okay thanks t4nk038 i will try that[20:58:37] <newguise1234> I had been excited about being able to clearly follow and use 3.3 tutorials until I came upon this fact lol[20:58:53] <krnlyng> whats normal and uv for? t4nk038[20:59:11] <t4nk038> well normal is the vertex normal and uv are the texture coordinates[20:59:18] <t4nk038> krnlyng, do you have a projection matrix and stuff?[20:59:24] <t4nk038> else you wont see anything :)[21:01:06] *** ManDay has joined ##OpenGL[21:01:40] <krnlyng> t4nk038: erm no[21:02:16] <t4nk038> newguise1234 that depends on your matrices[21:02:41] <t4nk038> you can set it like you want[21:02:52] <t4nk038> you can make -x forward and z up[21:09:12] <newguise1234> say I were to just set all vertices to a single vector, what should I make this so it would show up on the screen?[21:09:21] <newguise1234> via the vertex shader[21:09:51] <japro> are there intel cards that are clean 2.1? i thought the old gmas were 1.4 and the HD ones did 3+[21:10:33] *** lasserix_ has joined ##OpenGL[21:10:33] <newguise1234> oh, well glxinfo says OpenGL:2.1[21:10:47] <derhass> japro: there is also the driver factor[21:11:22] <newguise1234> japro: I read a similar thing while trying to figure out what to do earlier[21:12:57] *** __zoot__ has joined ##OpenGL[21:13:19] *** lasserix has quit IRC[21:16:48] *** konom has quit IRC[21:17:46] *** alllex229_ has left ##OpenGL[21:21:01] <derhass> " Im Zentrum steht die Geschichte der Freundschaft zwischen dem Ich-Erzähler und Alexis Sorbas, zwischen einem von Selbstzweifeln geplagten, intellektuellen Verstandesmenschen und einem Lebenskünstler, der seinen Gefühlen und Instinkten vertraut und in völligem Einklang mit sich und der Welt lebt."[21:21:14] <derhass> nix liegt mir ferne akls "von Selbstzweifeln geplagten,[21:21:24] <derhass> verdammt[21:21:50] <derhass> nix liegt mir ferner als "intellektuelle verstandesmenschen" und "volligem einklang mit sich und der welt"[21:21:57] <derhass> +e[21:22:18] <derhass> hmpf.[21:22:19] <Yaniel> okay[21:22:29] <derhass> please ignore that[21:22:37] <derhass> me irssi is confused, and so am I[21:23:38] <japro> ARB_literary_criticism?[21:23:55] <Yaniel> yes[21:24:23] <derhass> i don't hintk that reached ARB approval already[21:24:48] <Yaniel> well, DE_literary_criticism then[21:24:54] <newguise1234> If I glDisable(GL_CULL_FACE); should I be able to see the back side of rendered triangles?[21:25:02] <dreamminder> Yaniel https://www.youtube.com/watch?v=Zl0_FSi0Kno[21:26:06] <Yaniel> newguise1234: you should see triangles that are facing away from the camera[21:26:17] <japro> Yaniel, i'm looking forward to DE_nietzsche and DE_kafka[21:26:30] <japro> th second one probably being more confusing to use[21:27:18] <Yaniel> dreamminder: video looks corrupted[21:27:26] <dreamminder> corrupted?[21:27:27] <dreamminder> what do you mean[21:28:41] <Yaniel> looks like when you forget to set the correct pack/unpack alignment for textures[21:29:03] <japro> maybe we should call the grand inquisitor to purge the corruption and bring the heretics to justice?[21:29:27] <derhass> we should call the secret gl police[21:29:36] <Yaniel> like.. sheared[21:29:48] <Yaniel> or is it just the browser on my phone[21:30:17] <japro> derhass, you blew it... now it isn't secret anymore *throws up stack of paper*[21:30:34] <derhass> japro: it is secret by definition[21:31:13] <japro> secret in plain sight! genius![21:31:44] <Yaniel> you just need the spec to definw it so[21:31:44] <dreamminder> Yaniel, there are no textures[21:31:53] <Yaniel> dreamminder: I mean the video[21:32:00] <japro> no spoons either[21:32:04] <dreamminder> it is not sheared[21:32:18] <newguise1234> will matrix multiplications work in glsl 120? or do I have to use functions such as glTransformf[21:32:29] <Yaniel> looks a bit like it was missing stuff from the end of each line[21:32:37] <derhass> newguise1234: of course glsl 120 has matrix operations[21:32:38] <dreamminder> weird[21:32:40] <Yaniel> and wraps the next line there instead[21:32:42] *** Textmode has joined ##OpenGL[21:32:45] <dreamminder> can anyone watch it too and tell me if it is sheared?[21:32:51] <Yaniel> probably a bug on my end[21:32:53] <japro> looked fine to me[21:32:55] <dreamminder> https://www.youtube.com/watch?v=Zl0_FSi0Kno[21:32:58] <dreamminder> oh[21:33:08] <dreamminder> now I must rewrite it to 3d[21:33:13] <dreamminder> it will be pain in my ass xD[21:33:38] <Bloodust> oh yes[21:33:43] <Bloodust> yes it will be[21:34:46] <dreamminder> my brain is not working :<[21:35:58] *** PortaLu is now known as Lucretia[21:36:00] *** rdgawdzi_ has joined ##OpenGL[21:36:07] *** Lucretia has quit IRC[21:36:07] *** Lucretia has joined ##OpenGL[21:36:38] *** RavenWorks has joined ##OpenGL[21:36:42] <Lucretia> does anyone here know the status of glnext?[21:36:50] <Lucretia> apart from "not yet"[21:37:08] <Yaniel> it is being worked on apparently[21:37:27] <Yaniel> I hear there is some activity regarding it on the khronos cvs[21:37:49] <Yaniel> alas, I don't have access to that[21:38:03] <Lucretia> still can't believe they're using cvs[21:38:03] <derhass> do they still use cvs?[21:38:08] <derhass> lol[21:38:09] <Lucretia> but anyways[21:38:25] <Lucretia> any idea if it's being based on this mantle thing?[21:38:36] <Lucretia> whether it'll be a C or C++ API?[21:38:45] <Yaniel> probably C[21:39:12] <Lucretia> easier to bind to[21:39:12] *** snakenerd has quit IRC[21:39:15] <Yaniel> and I doubt it will differ much from swift/mantle[21:39:30] <RavenWorks> Is there anything that needs to be done to resize a FBO besides using glTexImage2D to resize its only attachment?[21:39:45] <japro> adjusting the viewport?[21:40:29] <RavenWorks> would that change the values returned by glGetRenderbufferParameteriv(GL_RENDERBUFFER, GL_RENDERBUFFER_WIDTH.. ?[21:40:37] <Lucretia> you mean metal? (which is Swift)[21:40:45] <Yaniel> yes, sory[21:40:51] <derhass> RavenWorks: nope[21:41:00] <derhass> RavenWorks: a texture isn't a renderbuffer[21:41:37] <Lucretia> well, let's hope it's not in Swift[21:41:42] <Lucretia> Obj-C's bad enough[21:41:58] <RavenWorks> right, but I thought I saw somewhere in the docs that a renderbuffer's size is the smallest of all its attachments?[21:42:11] <slime> RavenWorks: a Renderbuffer isn't a Framebuffer Object[21:42:21] <Yaniel> you are confusing terms now, RavenWorks[21:42:24] <RavenWorks> oh, crap, right[21:42:24] <slime> (nor is it the FBO's viewport)[21:43:14] <derhass> nor do FBOs have a viewport[21:43:16] <Yaniel> Lucretia: I think we are safe in that regard[21:44:20] *** centrinia has joined ##OpenGL[21:45:33] <RavenWorks> wow, yeah, glViewport fixed it :( I was so hung up on the answer I was getting from glGetRenderbufferParameteriv that I didn't even try that[21:45:53] <RavenWorks> Sorry about that! Thank you![21:47:10] *** RavenWorks has quit IRC[21:47:21] *** slime has quit IRC[21:47:30] *** dreamminder has left ##OpenGL[21:48:55] *** slime has joined ##OpenGL[21:49:43] *** fmardini has joined ##OpenGL[21:50:01] * Textmode huggles slime :3[21:51:08] *** rdgawdzi__ has joined ##OpenGL[21:51:13] *** ManDay has quit IRC[21:53:23] *** rdgawdzi_ has quit IRC[21:58:23] <roboman2444> so.... does anyone have any ideas on how to generate voronoi geometry?[21:59:50] *** jdolan_ has joined ##OpenGL[21:59:50] *** jdolan has quit IRC[22:02:56] *** rawtass has joined ##OpenGL[22:05:28] *** konom has joined ##OpenGL[22:08:47] *** rdgawdzi__ has quit IRC[22:08:48] <newguise1234> everywhere it says gDEBugger supports 32-bit linux, but I can't find an actual link for software, any input?[22:10:10] *** t4nk038 has quit IRC[22:10:17] <derhass> look at amd's developer site[22:10:41] *** Defaultti has quit IRC[22:12:56] <newguise1234> thanks, would you recommend gdebugger or bugle?[22:14:04] <derhass> newguise1234: don't ask me that[22:14:11] <derhass> newguise1234: I'd recommend neither[22:14:12] <newguise1234> haha, aight[22:14:34] <derhass> my personal experience with that tools is just not really positive[22:14:42] <derhass> but others have different experiences[22:15:35] <Bloodust> ditto[22:15:39] <Bloodust> I never got any of those to work properly[22:15:59] *** Biliogadafr has joined ##OpenGL[22:16:01] <Bloodust> they either didnt show what I wanted to see or they crashed[22:16:03] <Bloodust> usually both[22:16:09] <derhass> Bloodust: i got them to work with simple gl code. but they all failed for the cases where I needed them[22:16:17] <derhass> maybe my code is just too broken[22:18:23] *** Slion has quit IRC[22:20:45] *** pazul has quit IRC[22:21:07] *** Defaultti has joined ##OpenGL[22:23:18] *** rdgawdzi__ has joined ##OpenGL[22:26:44] *** DolpheenDream has quit IRC[22:28:42] *** Biliogadafr has quit IRC[22:28:59] *** Waynes has quit IRC[22:29:27] *** Biliogadafr has joined ##OpenGL[22:32:51] *** pazul has joined ##OpenGL[22:33:53] *** void256 has joined ##OpenGL[22:37:25] *** Khlorghaal has quit IRC[22:38:24] *** james4k has joined ##OpenGL[22:42:08] *** charlie5 has quit IRC[22:44:23] *** timsche has quit IRC[22:45:42] *** rawtass has quit IRC[22:46:37] *** yaakuro has quit IRC[22:47:29] *** Zupoman has quit IRC[22:49:47] *** qeed has joined ##OpenGL[22:52:29] *** damir__ has quit IRC[22:54:10] *** Khlorghaal has joined ##OpenGL[22:58:09] *** tehrain has quit IRC[23:01:15] *** Syzygy_ has joined ##OpenGL[23:02:30] *** gareppa has quit IRC[23:03:09] *** Lemml has quit IRC[23:06:03] *** jdolan_ has quit IRC[23:06:22] *** petervaro has joined ##OpenGL[23:07:57] *** SHLV has joined ##OpenGL[23:08:35] *** narcan has joined ##OpenGL[23:17:11] *** TunnelCat has joined ##OpenGL[23:21:00] *** prophile has quit IRC[23:24:47] *** foreignFunction has quit IRC[23:25:45] *** tz has quit IRC[23:26:12] *** prophile has joined ##OpenGL[23:26:42] *** tz has joined ##OpenGL[23:28:55] *** Ad1 has quit IRC[23:33:57] *** rdgawdzi__ has quit IRC[23:35:25] *** pazul has quit IRC[23:36:52] *** hdon has joined ##OpenGL[23:38:28] *** kuldeepdhaka has joined ##OpenGL[23:42:08] *** stefkos has quit IRC[23:42:35] *** jdolan has joined ##OpenGL[23:43:19] *** narcan has quit IRC[23:47:19] *** pazul has joined ##OpenGL[23:51:07] *** void256 has quit IRC[23:52:18] *** telex has quit IRC[23:54:46] *** telex has joined ##OpenGL