November 20, 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 20, 2014 [00:00:34] <metredigm> sweet, that fixed everything[00:00:40] <metredigm> including my knowledge[00:00:43] <metredigm> thanks[00:06:45] *** Ad1_RnR has quit IRC[00:07:53] *** ville has quit IRC[00:07:59] *** b4b has joined ##OpenGL[00:15:35] *** freespace has quit IRC[00:16:14] *** Zupoman has quit IRC[00:17:06] *** Zupo has joined ##OpenGL[00:17:53] *** Misu has quit IRC[00:18:53] *** BreadProduct_ has joined ##OpenGL[00:19:37] *** BreadProduct has quit IRC[00:19:42] *** BreadProduct_ is now known as BreadProduct[00:24:39] *** BreadProduct has quit IRC[00:24:44] *** ville has joined ##OpenGL[00:26:01] *** void256 has quit IRC[00:27:48] *** roboman2444 has joined ##OpenGL[00:31:23] *** Codex_ has quit IRC[00:33:08] *** ShadowIce has quit IRC[00:33:25] *** shintah has quit IRC[00:35:23] *** TheTeapot has joined ##OpenGL[00:36:47] *** bkre_ has joined ##OpenGL[00:38:53] *** bkre has quit IRC[00:39:02] *** Thrzsh has quit IRC[00:41:58] *** TheBunnyZOS has quit IRC[00:44:26] *** fatalhalt has joined ##OpenGL[00:47:47] *** TunnelCat has joined ##OpenGL[00:48:35] *** bkre_ has quit IRC[00:48:35] *** Ad1 has quit IRC[00:50:01] *** konradsurf has joined ##OpenGL[00:53:12] *** kmnt has quit IRC[00:53:22] *** Alina-malina has quit IRC[00:53:46] *** Alina-malina has joined ##OpenGL[00:55:47] *** telex has quit IRC[00:56:37] *** telex has joined ##OpenGL[00:57:29] *** freespace has joined ##OpenGL[00:59:18] *** Crehl has quit IRC[01:00:31] *** Alina-malina has quit IRC[01:01:24] *** paul424 has quit IRC[01:02:49] *** freespace has quit IRC[01:08:03] *** linuxuz3r has joined ##OpenGL[01:15:49] *** edwardjohn has joined ##OpenGL[01:18:43] *** paperManu_ has joined ##OpenGL[01:19:36] *** BreadProduct has joined ##OpenGL[01:21:23] *** derhass has quit IRC[01:24:49] *** hexagoxel_ has joined ##OpenGL[01:25:15] *** freespace has joined ##OpenGL[01:25:45] *** DolphinDream has joined ##OpenGL[01:27:08] *** Ad1 has joined ##OpenGL[01:27:45] *** Alina-malina has joined ##OpenGL[01:27:46] *** Alina-malina has quit IRC[01:27:46] *** Alina-malina has joined ##OpenGL[01:28:42] *** hexagoxel has quit IRC[01:31:42] *** indefini has quit IRC[01:33:46] *** devbug has quit IRC[01:40:45] *** BitPuffin has joined ##OpenGL[01:45:48] *** TheChubu has joined ##OpenGL[01:46:37] *** kmnt has joined ##OpenGL[01:47:54] *** bjz_ has quit IRC[01:50:25] *** bjz has joined ##OpenGL[01:51:16] *** Demon_Fox has joined ##OpenGL[01:52:11] *** Madsy has quit IRC[01:52:29] *** Madsy has joined ##OpenGL[01:52:30] *** Madsy has joined ##OpenGL[01:54:45] *** BreadProduct has quit IRC[01:55:06] *** bjz has quit IRC[01:59:38] *** indefini has joined ##OpenGL[02:01:55] *** wutata has joined ##OpenGL[02:06:22] *** mayankmadan__ has joined ##OpenGL[02:07:28] *** tcsc has joined ##OpenGL[02:08:20] <mayankmadan__> is it better to create a 4x4 modelView matrix or to just get it by glMatrixMode(GL_MODELVIEW_MATRIX) ?[02:09:06] <bob_twinkles> what do you mean create a 4x4 modelview matrix?[02:09:08] *** centrinia has joined ##OpenGL[02:09:08] *** hahuang61 has quit IRC[02:09:23] <bob_twinkles> in any case the matrix stack stuff is depricated[02:09:32] <mayankmadan__> GLfloat matrix[16];[02:09:38] <mayankmadan__> and then put values[02:09:53] *** mayankmadan_ has quit IRC[02:09:57] <bob_twinkles> I would personally recommend finding a library that does that for you, unless you really want to learn the math =P[02:16:08] <TheChubu> download glm + use core profile[02:16:42] *** hexagoxel_ has quit IRC[02:17:28] <TheChubu> or if you use a language in which all math libraries are either made by braindead people or tuned for working with 2000x2000 matrices of doubles[02:17:32] <TheChubu> do everything on your own[02:19:26] *** wutata has quit IRC[02:20:30] <Domx> Why are my UV reversed and from bottom to top on iOS?[02:21:33] <TheChubu> DO NOT QUESTION APPLE'S GENIUS[02:21:58] <TheChubu> that, or maybe top left corner / bottom left corner convention switch[02:22:17] <Domx> it's fucking annoying my animation sprite sheets are top to bottom with white space in the last few frames if it doesn't complete the row[02:22:58] <Domx> which in apples uv system the frame on the bottom left is 0, 0[02:23:29] <slime> apple doesn't have a uv system[02:23:53] *** Twinklebear has joined ##OpenGL[02:24:09] <Domx> well[02:24:19] <Domx> obviously[02:24:28] <slime> gl / gles have conventions for treating rows in textures and screen coordinates though[02:24:42] <slime> but there's nothing special about iOS or apple there[02:24:52] <Domx> the way they have implemented it[02:25:07] <slime> they stick to the gles spec for their gles implementation[02:25:17] <Domx> okay[02:25:48] <slime> (which, in this case, is the same as the desktop gl2 spec)[02:25:51] <Domx> maybe im wrong and libpng doesn't flip the image or something like other image loading libaries do?[02:26:07] <Domx> sounds more realistiv[02:26:12] <Domx> sorry for rant[02:27:06] *** Khlorghaal has quit IRC[02:27:56] *** slidercrank has quit IRC[02:29:18] *** Thrzsh has joined ##OpenGL[02:33:23] *** glYoda has quit IRC[02:33:35] *** glYoda has joined ##OpenGL[02:35:44] <edwardjohn> Can an app written for gles run on a desktop? Or does there need to be a software emulation step?[02:36:37] <cmr> edwardjohn: there's various GLES compatability extensions for desktop gl[02:36:51] <cmr> so you can run without modification, except possibly context creation[02:37:22] <slime> gles2 is already mostly a subset of gl2, as well[02:39:30] <edwardjohn> Okay, thanks.[02:46:59] *** Madsy^ has joined ##OpenGL[02:47:42] *** Madsy is now known as Guest23688[02:49:05] *** Madsy^ is now known as Madsy[02:49:11] *** warchild has joined ##OpenGL[02:49:25] *** Madsy has quit IRC[02:49:26] *** Madsy has joined ##OpenGL[02:49:33] *** Guest23688 has quit IRC[02:51:32] *** SleekoNiko has joined ##OpenGL[02:52:05] *** karab44 has quit IRC[03:00:25] *** zajfy has quit IRC[03:07:28] *** manny- has quit IRC[03:10:20] *** Alina-malina has quit IRC[03:12:28] *** puerum has joined ##OpenGL[03:17:20] *** manny- has joined ##OpenGL[03:18:23] *** staylor has quit IRC[03:21:07] *** jbud has joined ##OpenGL[03:24:42] *** Alina-malina has joined ##OpenGL[03:29:44] *** asfdfdfd has quit IRC[03:31:11] *** SleekoNiko has quit IRC[03:31:11] *** Lucretia has quit IRC[03:31:28] *** Lucretia has joined ##OpenGL[03:40:03] *** b4b has quit IRC[03:42:02] *** zoktar has quit IRC[03:43:12] *** Gamecubic has quit IRC[03:43:12] *** BitPuffin has quit IRC[03:44:32] *** Gamecubic has joined ##OpenGL[03:44:37] *** zoktar has joined ##OpenGL[03:44:40] *** TyrfingMjolnir has joined ##OpenGL[03:48:28] *** fatalhalt has quit IRC[03:48:45] *** SleekoNiko has joined ##OpenGL[03:49:41] *** Hunts has joined ##OpenGL[03:52:01] *** kmnt has quit IRC[03:52:42] *** TheTeapot has quit IRC[03:52:44] *** HuntsMan has quit IRC[03:56:49] *** robot-beethoven has joined ##OpenGL[03:59:34] *** TyrfingMjolnir has quit IRC[04:00:22] *** TyrfingMjolnir has joined ##OpenGL[04:02:43] *** TyrfingMjolnir has quit IRC[04:03:13] *** Garner has quit IRC[04:05:04] *** Thrzsh has quit IRC[04:05:56] *** doomlord_1 has joined ##OpenGL[04:07:49] *** urraka has quit IRC[04:09:13] *** staylor has joined ##OpenGL[04:09:31] *** Keniyal has joined ##OpenGL[04:09:45] *** staylor has quit IRC[04:09:51] *** ex172000 has joined ##OpenGL[04:10:55] *** konradsurf has quit IRC[04:11:29] *** kmnt has joined ##OpenGL[04:12:35] *** TyrfingMjolnir has joined ##OpenGL[04:14:42] *** ex172000 has quit IRC[04:16:23] *** DolphinDream has quit IRC[04:17:23] *** newguise1234 has quit IRC[04:19:02] *** TheTeapot has joined ##OpenGL[04:19:19] *** Thrzsh has joined ##OpenGL[04:20:32] *** konom has quit IRC[04:21:23] *** Ephemeral has quit IRC[04:23:07] *** Ephemeral has joined ##OpenGL[04:23:07] *** edwardjohn has quit IRC[04:24:36] *** edwardjohn has joined ##OpenGL[04:26:24] *** captainmack_ has quit IRC[04:26:56] *** captainmack_ has joined ##OpenGL[04:31:21] *** Orion] has quit IRC[04:31:29] *** captainmack_ has quit IRC[04:31:48] *** newguise1234 has joined ##OpenGL[04:33:26] <metredigm> valgrind is a tool of gods[04:33:29] <metredigm> why had i never head of this[04:33:39] <warchild> jup[04:34:15] <warchild> it reports gl library leaks pretty much always though[04:36:10] *** newguise1234 has quit IRC[04:36:10] *** newguise1234 has joined ##OpenGL[04:37:52] *** luxigo has joined ##OpenGL[04:41:54] *** samrat has joined ##OpenGL[04:42:45] *** Bigpet_ has quit IRC[04:45:55] *** Gamecubic has quit IRC[04:46:20] *** Gamecubic has joined ##OpenGL[04:50:23] *** paperManu_ has quit IRC[04:51:16] *** clincher has quit IRC[04:52:44] *** clincher has joined ##OpenGL[04:54:07] *** luxigo has quit IRC[04:56:51] *** Cabanossi has quit IRC[04:58:08] *** Cabanossi has joined ##OpenGL[05:01:38] *** samrat has quit IRC[05:07:28] *** CainJacobi has quit IRC[05:08:08] *** centrinia has quit IRC[05:11:54] *** shintahW2 has joined ##OpenGL[05:13:24] *** samrat has joined ##OpenGL[05:13:34] *** luxigo has joined ##OpenGL[05:14:55] *** CainJacobi has joined ##OpenGL[05:16:06] *** shintahW has quit IRC[05:16:06] *** shintahW2 is now known as shintahW[05:18:11] *** akaWolf has quit IRC[05:22:15] *** mayankmadan__ has quit IRC[05:24:19] *** TheChubu has quit IRC[05:26:00] *** slidercrank has joined ##OpenGL[05:30:13] *** edwardjohn has quit IRC[05:38:21] *** malko has joined ##OpenGL[05:41:57] *** samrat has quit IRC[05:44:38] *** captainmack_ has joined ##OpenGL[05:44:42] *** TunnelCat has quit IRC[05:51:28] *** SleekoNiko has quit IRC[05:52:15] *** Thrzsh has quit IRC[05:53:51] *** TheBix has joined ##OpenGL[05:54:25] *** doomlor__ has joined ##OpenGL[05:55:15] *** doomlord_1 has quit IRC[05:57:27] *** BreadProduct has joined ##OpenGL[06:00:49] *** hahuang61 has joined ##OpenGL[06:05:24] *** hahuang61 has quit IRC[06:07:51] <Domx> sooooo the iOS simulator uses software rendering for opengl[06:08:14] <Domx> before when i was using sdl with it the frame rate was 60fps[06:08:26] *** karswell has quit IRC[06:08:34] <Domx> why can't i get that with a native app?[06:09:10] *** karswell has joined ##OpenGL[06:09:17] <bob_twinkles> because as powerful as the iphone is it's not on the level of your dev machine?[06:09:25] *** jbud has quit IRC[06:09:25] <bob_twinkles> are you talking about performance on the device versus the simulator?[06:09:35] *** slidercrank has quit IRC[06:09:51] <Domx> perf on the device is better then the simulator because the simulator uses software rendering[06:10:11] <bob_twinkles> wait so what's the problem then?[06:10:29] <slime> it only uses software rendering if you make it fall back to it[06:10:31] <Domx> its impossible to test[06:10:35] <slime> (i.e. it's a slow path, not the only path)[06:10:59] <Domx> slime: link to docs where i can set it up?[06:11:07] <slime> there's nothing to set up[06:11:24] <Domx> then why is the simulator so slow when not using SDL[06:11:27] <slime> it just falls back to software rendering if you aren't on a fast path, AFAIK[06:11:42] <slime> perhaps you're setting up your context using different parameters[06:11:44] * slime shrugs[06:12:12] <Domx> slime: im using GLKViewController[06:12:14] <bob_twinkles> it also probably falls back if you do something the simulator doesn't expect[06:12:21] <Domx> i don't really set up the context[06:12:23] <slime> Domx: I've never used that[06:12:36] <Domx> you just inherit from that[06:12:42] <Domx> and that is your context[06:13:07] <glYoda> "why can't i get that with a native app?" …you can -- run it natively on the device[06:13:41] <glYoda> which you should be doing anyway[06:14:22] <Domx> glYoda: i don't have a device :s is prototype for work. I will get hardware when prototype is approved[06:14:34] <glYoda> if you don't have a device then you're doing it wrong[06:14:47] <Domx> glYoda: tell that to the company[06:14:53] <glYoda> you cannot adequately verify correctness OR performance without testing on the target[06:14:57] <Domx> i had to bring in my own mac too[06:15:05] <glYoda> that that isn't the Mac you've written the SW on :P[06:15:10] <glYoda> (or whatever else)[06:15:17] *** kmnt has quit IRC[06:15:26] <Domx> glYoda: im not having perf issues[06:15:34] <Domx> ive seen it before with other apps i[06:15:35] <glYoda> note exactly what I said[06:15:39] <Domx> written[06:15:40] <glYoda> every word[06:16:10] <Domx> I jsut want the simulator to run at an acceptable speed :([06:16:16] <Domx> so i can test[06:16:17] <glYoda> attempting to write a GL acceleratedf application using the simulator is an exercise in failure AFAIC[06:16:31] <glYoda> it really is that simple[06:16:57] <glYoda> the simulator is a CPU based immediate mode renderer[06:16:58] <Domx> glYoda: yes, but the simulator isn't a VM[06:17:05] <glYoda> it isn't a HW accelerated TBDR[06:17:17] <Domx> i know[06:17:42] <glYoda> the performance / feature set / precision etc. requirements and the API limits are vastly different between the two[06:17:48] <Domx> but when i was using SDL with the app it was running at 60fps the only thing to change is the context creation[06:17:58] *** SleekoNiko has joined ##OpenGL[06:18:05] <Domx> 60 fps in the simulator[06:18:08] <glYoda> again I fail to see how any of that matters[06:18:20] <glYoda> performance within the SWR is irrelevant[06:18:48] <Domx> it relevant when you don't want to test on the device[06:19:07] <glYoda> and as I said earlier if you can't test on the device you've failed[06:19:14] <Domx> it irrelevent to releasing and how the app will actually perform, sure.[06:19:20] *** kmnt has joined ##OpenGL[06:19:22] <Domx> but to the SDLC it's very relevent[06:19:29] <glYoda> and I would never want to run the app you've written without physical (target based) testing :P[06:19:45] <Domx> it would get to that stage[06:19:46] <glYoda> nor would anyone else for that matter[06:19:48] <foobaz> more like "if you can't test on the shitty real-world drivers your vendor ships, you've failed"[06:19:58] <Domx> that testing will exist[06:20:25] <foobaz> not to disparage your own driver, it is one of the best ones out there[06:20:45] <Domx> just at this point i want to write my app using the simulator. arguing against that is arguing against the purpose of having a simulator in the first place[06:21:17] <slime> the purpose of the simulator isn't really so you can write your entire app with no device..[06:21:24] <glYoda> "that testing will exist" …great then you've just admitted that you don't need the simulator to begin with[06:21:38] <glYoda> so problem solved hehe[06:22:27] <Domx> okay do you write any software testing on all target platforms as you write it?[06:22:27] <glYoda> I'm sorry to be the one to tell you this but really… if you need to develop under Apple's SWR without testing on a target (at that point) then something is very wrong[06:22:40] <glYoda> Domx yes it's expected of me[06:22:47] <Domx> of you[06:22:48] <glYoda> and it's a critical requirement for my job[06:22:54] <Domx> your job[06:23:04] <glYoda> I damn well better test upon every-fucking-thing I target :)[06:23:26] <glYoda> and guess what? …I do the same for SW I've written for personal use[06:23:30] <Domx> so every time you build you run every piece of hardware?[06:23:39] <Domx> put in a semicolon[06:23:45] <glYoda> it's really not difficult to restrict the targets to targets which you can directly test against[06:23:47] <Domx> better test against everything[06:24:07] <foobaz> what, no more rage128? :([06:24:24] <slime> Domx: that's kind of a weird comparison that you're building, since he's telling you to test with something rather than everything[06:24:40] <glYoda> Domx yes I'd expect any "non trivial" project to involve some level of distributed testing[06:24:46] <slime> (although everything is a good idea too)[06:24:49] <glYoda> that is well… "world of duh" AFAIC[06:25:00] <glYoda> for larget projects[06:25:00] <Domx> slime: what im making will work it's not very complicated its just a slot game (ie quads and textures)[06:25:04] <glYoda> *larger[06:25:45] <glYoda> in any case you know the feature set / API version etc. you've targeted and that should tell you what you'll want to test against[06:25:55] <glYoda> at least at this point in the development process[06:26:18] <Domx> either way it doesn't matter, my boss isn't going to go and get me every target device because we're not even sure if we're going to do it[06:26:33] <glYoda> at a minimum that means *some* physical target (i.e. iPhone, iPad, … whatever)[06:26:41] <glYoda> and not just the SW renderer[06:26:55] <Domx> im not targetting the SW renderer[06:27:00] <Domx> its all i have[06:27:08] *** AndroUser466 has joined ##OpenGL[06:27:19] <glYoda> actually yes you are if that is what you've been writing the app against :P[06:27:27] <Domx> when SDL creates it's context it seems to do something that enables HW accell[06:27:28] <glYoda> hence the problem[06:27:55] *** samrat has joined ##OpenGL[06:28:09] <Domx> glYoda: I'm writing my app against a lot of target platforms... the iOs simulator is just the easiest one to test in.[06:28:14] <glYoda> and that problem doesn't change if you suddenly target an accelerated IMR on the desktop… since none of these are the TBDRs Apple is shipping in the various iOS platforms[06:28:19] <Domx> emscripten takes too long to build[06:28:22] *** Zupo2 has joined ##OpenGL[06:28:28] <Domx> and i haven't created my android build yet[06:28:44] *** xissburg has quit IRC[06:29:35] <glYoda> meh as I've said… get a physical device and test against that[06:31:51] *** Zupo has quit IRC[06:32:54] *** shingshang has joined ##OpenGL[06:34:52] <Domx> nvm figured it out[10:45:10] *** echelog has joined ##OpenGL[10:46:10] *** bjz_ has quit IRC[10:46:45] *** DrSkyLizard has joined ##OpenGL[10:49:57] *** Folkol has joined ##OpenGL[10:52:01] *** hexagoxel_ has joined ##OpenGL[10:54:22] *** luxigo has quit IRC[10:56:21] *** centrinia has joined ##OpenGL[11:05:09] *** Serus has joined ##OpenGL[11:08:53] *** samrat has quit IRC[11:09:38] *** HuntsMan has joined ##OpenGL[11:11:04] *** samrat has joined ##OpenGL[11:18:00] *** Demon_Fox has quit IRC[11:23:11] *** kuldeepdhaka has joined ##OpenGL[11:25:38] *** erhan_ has joined ##OpenGL[11:30:28] *** Clair has quit IRC[11:37:33] *** indefini has quit IRC[11:39:33] *** TheTeapot has joined ##OpenGL[11:40:06] *** hexagoxel_ has quit IRC[11:40:36] *** CrizMobius has joined ##OpenGL[11:41:35] *** MiniCow has joined ##OpenGL[11:41:46] *** aethersis has joined ##OpenGL[11:42:51] <aethersis> wooo, I finally have a data flow chart for my program![11:44:57] *** TheTeapot has quit IRC[11:49:12] *** HuntsMan has quit IRC[11:50:55] *** HuntsMan has joined ##OpenGL[11:51:50] <Bloodust> pfft[11:51:56] <Bloodust> just code[11:52:21] *** ManDay has joined ##OpenGL[12:00:37] *** DaGardner has quit IRC[12:01:32] *** clauswitt has quit IRC[12:01:39] *** robot-beethoven has quit IRC[12:02:49] *** DrSkyLizard has quit IRC[12:04:22] *** hexagoxel has joined ##OpenGL[12:09:03] *** Khlorghaal has joined ##OpenGL[12:14:09] *** captainmack_ has joined ##OpenGL[12:17:59] <aethersis> no I can't code it straightforward[12:18:31] *** captainmack_ has quit IRC[12:18:43] <aethersis> http://postimg.org/image/7s3ppabgv/full/[12:18:47] <aethersis> just look how big it is![12:20:11] <aethersis> I prefer to have the diagram debugged before I start debugging code xD[12:20:17] *** clauswitt has joined ##OpenGL[12:20:31] *** bjz has joined ##OpenGL[12:20:48] <Bloodust> well as long as you understand what that grah is about :P[12:20:54] <aethersis> I do[12:21:02] <aethersis> but it's too complex to code it straight from mind[12:21:08] <aethersis> I could but I'm afraid I'd make way too many errors[12:22:48] <aethersis> each thing that looks like class there is actually a shader xD[12:22:52] *** ripper93 has joined ##OpenGL[12:27:17] *** huntercool has quit IRC[12:30:53] *** ripper93 has quit IRC[12:33:11] *** Syzygy_ is now known as Syzygy[12:35:03] <AbigailBuccaneer> diagrams? here in JOCK CODER COLLEGE your fancy diagrams will get you shoved in a locker[12:36:44] <dahlia> diagram? *googles*[12:37:32] <Bloodust> diaphram*[12:38:11] <Bloodust> diaphragm*[12:39:11] <dahlia> diefragmentdie[12:40:22] <neure> dielectric[12:41:25] <dahlia> enough of this meaningless diatribe[12:43:25] *** huntercool has joined ##OpenGL[12:44:53] <danhedron> let me just digest that[12:44:54] *** cr`nge has joined ##OpenGL[12:50:33] *** ManDay has quit IRC[12:53:37] *** Khlorghaal has quit IRC[12:54:23] <aethersis> ther's no big code without big diagrams![12:54:41] *** bjz has quit IRC[13:01:42] *** kuldeepdhaka has quit IRC[13:03:14] *** Cooler has joined ##OpenGL[13:08:09] *** samrat has quit IRC[13:08:25] *** kuldeepdhaka has joined ##OpenGL[13:09:57] <Cooler> do i need shaders for just drawing a quad?[13:10:04] *** Codex_ has joined ##OpenGL[13:10:12] <Cooler> with a texture[13:10:15] <Bloodust> yes[13:10:21] <Bloodust> you need shader if you want to draw anything[13:10:22] <AbigailBuccaneer> Cooler, yes -- all drawing goes via shaders[13:11:12] <Cooler> well to draw a solid color you can just do glcolorf[13:11:22] <Bloodust> nope, not part of core opengl[13:11:31] <Cooler> its not?[13:11:33] <neure> glColor is deprecated[13:11:35] <neure> dont use[13:11:38] <Bloodust> removed from core[13:11:41] <Cooler> oh yeah vbo[13:11:51] <neure> you still need a shader[13:11:59] *** bjz has joined ##OpenGL[13:12:11] <Cooler> well then you don't have to specify or write a shader[13:12:19] <Bloodust> theres no reason to avoid using shaders[13:12:45] <neure> uniform vec3 Color; void main(void){ gl_FragColor.rgb = Color; }[13:14:57] <Cooler> well to use vbos you can just pass in the color buffer without shaders[13:18:30] *** karab44 has joined ##OpenGL[13:22:05] *** edwardjohn has joined ##OpenGL[13:22:36] *** paperManu_ has joined ##OpenGL[13:23:24] *** zajfy has joined ##OpenGL[13:28:12] *** HuntsMan has quit IRC[13:29:17] *** centrinia has quit IRC[13:32:09] *** cr`nge has quit IRC[13:34:33] *** konom has joined ##OpenGL[13:35:15] <AbigailBuccaneer> Cooler, if you're using a version of OpenGL where glColor etc. is still available, then you don't need to use shaders to draw. on the other hand, your code will be deprecated before it's even finished being written, and you're unlikely to receive much support for it here[13:36:11] <Cooler> AbigailBuccaneer: color buffers for vbos don't use shaders?[13:37:18] <AbigailBuccaneer> modern opengl doesn't have any concept of "color buffers" etc. - your VBOs contain generic data, which you access in a shader as vertex attributes. there's no fixed "this buffer is for colors" etc[13:38:19] <Cooler> yeah but you don't have to pass in a shader program and compile it[13:38:30] *** mat^2 has joined ##OpenGL[13:39:27] *** Khlorghaal has joined ##OpenGL[13:39:44] *** MiniCow has quit IRC[13:40:11] <dahlia> I think some nvidia drivers have some minimal built-in shader thingie[13:40:28] <AbigailBuccaneer> either you're in a world of glColor3f etc., or you're in a world of shaders and glVertexAttribPointer[13:40:33] <dahlia> can't say I know how to use it tho[13:40:54] <Bloodust> dahlia, the default FFP shader?[13:41:28] <dahlia> Bloodust: all I know is somehow I enabled it once and someone told me about it[13:41:50] *** Match has joined ##OpenGL[13:42:29] <dahlia> it might be FFP but I would think my vbo would need to match the one somehow?[13:42:40] <dahlia> the FFP one[13:43:31] *** asido has quit IRC[13:43:37] *** Beetny has quit IRC[13:44:46] *** akaWolf has quit IRC[13:45:01] *** mat^2 has quit IRC[13:48:14] <Bloodust> dahlia apparently the default gl_Vertex location is bound to vertex attribute location 0[13:48:43] <Cooler> Is there a good tutorial on shaders for java?[13:49:12] <Bloodust> dunno[13:49:24] *** wutata- has joined ##OpenGL[13:50:04] *** mat^2 has joined ##OpenGL[13:51:01] <dahlia> Bloodust: ok maybe it would work then[13:52:21] *** mat^2 has quit IRC[13:52:48] *** wutata has quit IRC[13:57:35] *** mat^2 has joined ##OpenGL[14:01:08] *** BitPuffin has joined ##OpenGL[14:08:00] *** edwardjohn has quit IRC[14:08:28] *** samrat has joined ##OpenGL[14:15:52] *** kidnapped_robot has quit IRC[14:16:48] *** centrinia has joined ##OpenGL[14:17:18] <Cooler> Creating a shader for a 2d game seems pointless[14:17:26] *** paperManu_ has quit IRC[14:17:37] <Cooler> all it needs to do is draw the sprite texture on screen[14:18:13] *** orangeppop has joined ##OpenGL[14:18:35] <ville> glsl it self won't change whether you use java or something else[14:18:53] *** karswell has quit IRC[14:23:44] <enleeten> Cooler: what do you think "draws" on the screen? shaders[14:24:14] *** moser has quit IRC[14:24:41] <orangeppop> I'm using old style OpenGL 2.1, and trying to get my head around VBOs. I'm copying across to the VBO from a C++ vector of GLfloats, with x, y , z co-ordinates stored sequentially. I use glDrawArrays to draw it all. As I understand it, the last argument, "count" should be the number of vertices I'm drawing - so vector::size()/3 in my case. This draws bonkers stuff all over the place, and a quarter of the actual line strip I'm trying to draw. If I use[14:24:41] <orangeppop> vector::size()/12, it draws a quarter of the line strip and no crazy stuff... Where am I going wrong? Presumably I'm misunderstanding how vectors work? Thanks.[14:25:21] <Bloodust> orangeppop pastebin?[14:25:39] <orangeppop> Sure, give me a second[14:26:06] <Cooler> enleeten: i know i just can't find a good tutorial on shaders[14:26:25] <Cooler> for java[14:26:46] <Bloodust> not much java code on shaders[14:28:19] <orangeppop> Bloodust, http://hastebin.com/uniyugezey.cpp[14:29:24] <orangeppop> vecSin.size()/12 is the weird hacky bit to stop it drawing crazy shit[14:29:27] <Bloodust> wrong parameter to bufferdata[14:29:45] <Bloodust> size should be in bytes[14:29:57] <Bloodust> so vecSin.size()*sizeof(float)[14:30:00] <Cooler> i dn't mean GLSL, i mean the inital setup load, compile,et[14:30:03] <Bloodust> or double[14:30:04] <Cooler> c[14:30:12] <Bloodust> whatever it is[14:30:42] <orangeppop> pretty sure I tried that once but I'll give it another go[14:30:44] <orangeppop> thanks[14:30:56] <Bloodust> and the /3 for drawArrays is correct[14:31:08] <Bloodust> but I can see how /12 seems to work[14:32:13] <enleeten> Cooler: what java binding are you using?[14:32:15] <orangeppop> That worked great... could have sworn I'd tried that before, thanks! Have only spent the past day fighting with it... thanks again[14:32:31] <enleeten> lwjgl.org has some docs, there's also a port of the arcsynthesis tuts to java out there[14:32:40] <Bloodust> orangeppop next step, start using shaders[14:32:42] <Cooler> enleeten: lwjgl[14:34:29] <orangeppop> Bloodust, heh, another day, have been taught the old way and don't have the time to invest for this mini project :)[14:36:56] *** snakenerd has joined ##OpenGL[14:37:02] *** forests has quit IRC[14:37:26] *** kmnt has joined ##OpenGL[14:37:45] *** forests has joined ##OpenGL[14:39:18] *** akaWolf has joined ##OpenGL[14:39:44] *** urraka has joined ##OpenGL[14:41:23] *** DrBenway has quit IRC[14:41:29] *** moser has joined ##OpenGL[14:45:02] *** abs25 has joined ##OpenGL[14:46:40] *** jdolan has quit IRC[14:48:15] *** roxlu has quit IRC[14:49:35] *** snakenerd has quit IRC[14:50:27] *** roxlu has joined ##OpenGL[14:51:14] *** metredigm_ has joined ##OpenGL[14:51:36] *** roxlu has joined ##OpenGL[14:52:47] *** roxlu has joined ##OpenGL[14:52:59] *** aethersis has quit IRC[14:55:22] *** roxlu has joined ##OpenGL[14:57:56] *** roxlu has joined ##OpenGL[14:59:31] *** xissburg has joined ##OpenGL[15:02:27] *** snakenerd has joined ##OpenGL[15:02:53] *** samrat has quit IRC[15:04:03] *** Gamecubic has joined ##OpenGL[15:04:11] *** snakenerd has quit IRC[15:04:17] *** Cooler has quit IRC[15:04:50] *** snakenerd has joined ##OpenGL[15:06:20] *** samrat has joined ##OpenGL[15:09:51] *** tehrain has joined ##OpenGL[15:09:51] *** tehrain has joined ##OpenGL[15:10:34] *** Zupo2 has joined ##OpenGL[15:11:28] *** onatto has joined ##OpenGL[15:16:00] *** onatto has quit IRC[15:16:01] *** ClarusCogitatio has joined ##OpenGL[15:16:28] *** kuldeepdhaka has quit IRC[15:17:38] *** onatto has joined ##OpenGL[15:17:43] <onatto> ;2[15:18:06] *** onatto has quit IRC[15:19:05] *** Gamecubic has quit IRC[15:19:31] *** Gamecubic has joined ##OpenGL[15:21:14] *** ClarusCogitatio has quit IRC[15:25:04] *** ClarusCogitatio has joined ##OpenGL[15:27:16] *** TheBix has quit IRC[15:27:42] *** mayankmadan has joined ##OpenGL[15:28:50] *** jdolan has joined ##OpenGL[15:30:36] *** kuldeepdhaka has joined ##OpenGL[15:31:14] *** ClarusCogitatio has quit IRC[15:31:16] *** Tag_ has quit IRC[15:32:14] *** nmschulte has joined ##OpenGL[15:39:33] *** ClarusCogitatio has joined ##OpenGL[15:42:18] *** DolphinDream has joined ##OpenGL[15:42:27] *** DolphinDream has quit IRC[15:43:05] *** xissburg has quit IRC[15:43:07] *** kuldeepdhaka has quit IRC[15:43:12] *** xissburg has joined ##OpenGL[15:43:57] *** Lemml has quit IRC[15:48:52] *** wutata- has quit IRC[15:48:57] *** HuntsMan has joined ##OpenGL[15:49:18] *** wutata- has joined ##OpenGL[15:49:18] *** MLM has joined ##OpenGL[15:51:07] *** Zupo has joined ##OpenGL[15:51:38] *** Zupo2 has quit IRC[15:52:30] *** ClarusCogitatio has quit IRC[15:53:12] *** orangeppop has quit IRC[15:54:11] *** indefini has joined ##OpenGL[15:54:33] *** SleekoNiko has quit IRC[15:54:43] *** clauswitt has quit IRC[15:55:44] *** metredigm_ has quit IRC[15:58:18] *** metredigm_ has joined ##OpenGL[15:58:33] *** Zupo2 has joined ##OpenGL[15:58:57] *** Zupo has quit IRC[15:59:04] *** ClarusCogitatio has joined ##OpenGL[15:59:28] *** kuldeepdhaka has joined ##OpenGL[16:03:32] *** aethersis has joined ##OpenGL[16:03:43] <aethersis> hi[16:03:57] <aethersis> is there some easy way to draw something into texture2D ?[16:04:12] <aethersis> I want to do it from the level of GUI[16:04:28] <aethersis> without passing anything to shader. Just to alter the texture2D data so that it's saved there[16:04:58] <aethersis> and just THEN it's passed to shader to be processed or displayed[16:05:08] <HuntsMan> call glTexImage2D again or glTexSubImage2D?[16:05:29] <HuntsMan> but what kind of drawing?[16:05:33] <aethersis> yeah but how do I create the GLVoid* pixels ?[16:05:46] <aethersis> like in mspaint. per pixel drawing[16:06:45] *** ClarusCogitatio has quit IRC[16:06:56] <HuntsMan> maybe it is easier just to do it with render to texture (FBOs)[16:07:09] <aethersis> how about glDrawPixels?[16:07:45] *** ClarusCogitatio has joined ##OpenGL[16:07:57] <aethersis> but still it needs this horrible pixel data thing[16:08:47] <HuntsMan> "horrible"[16:09:12] <aethersis> I think the glDrawPixels would be the most useful function for me[16:09:16] <damir__> allocate your memory for the RGB[A] image, set it manually pixel by pixel, then upload to texture[16:09:22] <HuntsMan> yeah but it will be slow[16:09:26] <aethersis> but how do I create the pixel data[16:09:27] <HuntsMan> specially per-pixel[16:09:30] <damir__> then do it with GPU[16:09:36] <damir__> if you want it to be fast[16:09:40] <HuntsMan> aethersis: is just an array of numbers[16:09:50] <aethersis> yeah but it must have some clearly specified format or something[16:09:56] <aethersis> I don't know how it's defined[16:10:00] <damir__> char* image=malloc(width*height*depth);[16:10:02] <damir__> tadaa[16:10:14] <aethersis> what's depth[16:10:20] <aethersis> bit depth?[16:10:26] <aethersis> but there are 3 channels[16:10:39] <damir__> 3 channels -> your depth is 3[16:10:44] <damir__> since 1 byte per channel[16:10:46] <aethersis> 3*8bit[16:10:50] <aethersis> I see[16:10:53] <aethersis> humphf[16:10:57] <aethersis> ugh...[16:12:02] <aethersis> if I have a 2d matrix stored as 1d then if I want to access i,j point, I do this: #define IX(i,j) ((i)+(N)*(j))[16:12:12] <aethersis> how'd it be for 3d?[16:13:01] <HuntsMan> why do you need it for 3D?[16:13:01] <aethersis> IX(i,j,k) (i+N*j+M*k) ???[16:13:08] <aethersis> because it is kinda 3d[16:13:20] <aethersis> it's [width][height][depth] right?[16:13:26] <HuntsMan> but texture data is 2D (for 2D textures of course)[16:13:32] <aethersis> yes[16:13:48] <aethersis> but I need some idea how to access each channel at each pixel[16:13:54] <aethersis> something like macro[16:14:50] <urraka> pixel(x,y) -> data[(y * width + x) * channels][16:15:04] <urraka> then you have pixel[0] pixel[1] pixel[2] for RGB or something[16:15:08] <aethersis> there we go![16:15:09] <aethersis> <3[16:15:29] *** ClarusCogitatio has quit IRC[16:16:15] <aethersis> so that'd be #define R(x,y) (y*width+x)*1) ?[16:16:29] <aethersis> then G would be *2 and B * 3?[16:16:29] *** metredigm_ has quit IRC[16:16:35] <urraka> no[16:16:53] <aethersis> how'd it be then[16:17:06] *** ClarusCogitatio has joined ##OpenGL[16:17:14] <urraka> uint8_t *pixel = data[(y * width + x) * channels];[16:17:19] <urraka> pixel[0] -> R[16:17:23] <urraka> pixel[1] -> G[16:17:24] <urraka> etc[16:17:38] <aethersis> I see[16:17:41] <aethersis> thank you so much :3[16:18:13] *** doev has quit IRC[16:20:17] *** damir__ has quit IRC[16:21:43] *** ClarusCogitatio has quit IRC[16:23:40] *** captainmack_ has joined ##OpenGL[16:24:06] *** ClarusCogitatio has joined ##OpenGL[16:29:27] *** centrinia has quit IRC[16:29:50] *** OutofControl_ has joined ##OpenGL[16:30:19] *** mayankmadan has quit IRC[16:32:36] *** pazul has joined ##OpenGL[16:34:21] *** Zupo3 has joined ##OpenGL[16:36:30] *** Zupo2 has quit IRC[16:36:30] *** DrSkyLizard has joined ##OpenGL[16:36:36] *** neure has quit IRC[16:40:23] *** samrat has quit IRC[16:41:57] *** samrat has joined ##OpenGL[16:45:35] *** mayankmadan has joined ##OpenGL[16:52:45] *** MiniCow has joined ##OpenGL[16:52:51] *** Thrzsh has joined ##OpenGL[16:53:53] *** wutata- has quit IRC[17:01:29] *** cr`nge has joined ##OpenGL[17:04:36] *** damir__ has joined ##OpenGL[17:04:58] *** Malediction_ has quit IRC[17:07:12] *** Keniyal has quit IRC[17:09:18] *** Malediction has joined ##OpenGL[17:11:23] *** TheBunnyZOS has joined ##OpenGL[17:11:45] *** Thrzsh has quit IRC[17:12:24] *** Zerflag has joined ##OpenGL[17:14:17] *** MiniCow has quit IRC[17:14:53] *** MiniCow has joined ##OpenGL[17:22:36] *** japro has joined ##OpenGL[17:23:32] *** seangrove has joined ##OpenGL[17:24:19] *** stefkos has joined ##OpenGL[17:25:54] <aethersis> I think there's a better way of doing this drawing thing. I will simply let pixel to be drawn put into shader as uniform value[17:26:06] *** serengeor has quit IRC[17:26:28] <aethersis> this will save me the headache[17:26:36] <aethersis> *from the headache[17:27:19] <japro> the draw pixel shader? :D$[17:27:34] <japro> glDrawArrays(GL_POINT, 0, 1); ?[17:27:38] <aethersis> yeah that's what I'm going to do xD[17:27:44] <aethersis> no not like that[17:27:47] <aethersis> it's supposed to draw on texture[17:27:59] <japro> if you really want to draw single pixels just set them in a big ass array and upload that as texture every frame[17:27:59] <aethersis> I have fbo already attached and being swapped continuously for effects like progressive blur[17:28:10] <aethersis> yeh that's another possibility[17:28:20] *** DaGardner has joined ##OpenGL[17:28:25] <japro> using gl draws to set single pixels is utter overkil[17:28:34] <japro> (probably even detrimental)[17:28:49] <aethersis> http://postimg.org/image/dmh6j32s1/[17:29:02] *** Zerflag has quit IRC[17:29:14] *** mayankmadan has quit IRC[17:33:36] *** redeemed has quit IRC[17:33:58] *** ManDay has joined ##OpenGL[17:34:40] *** DrSkyLizard has quit IRC[17:41:00] *** japro has quit IRC[17:42:08] *** Orion] has joined ##OpenGL[17:42:28] *** samrat has quit IRC[17:42:42] *** staylor has joined ##OpenGL[17:42:45] *** Bigpet_ has quit IRC[17:44:44] *** samrat has joined ##OpenGL[17:45:49] *** PasNox has quit IRC[17:47:57] *** pazul has quit IRC[17:51:57] *** Waynes has joined ##OpenGL[17:53:07] *** MLM has quit IRC[17:54:54] *** Shadda has quit IRC[17:55:30] *** Codex_ has quit IRC[17:56:32] *** staylor has quit IRC[17:57:07] *** Shadda has joined ##OpenGL[17:59:38] *** pazul has joined ##OpenGL[18:00:11] *** mayankmadan has joined ##OpenGL[18:01:21] *** telex has quit IRC[18:02:39] *** telex has joined ##OpenGL[18:02:52] *** tkeemon has joined ##OpenGL[18:04:01] *** FrodoTheHobbit has joined ##OpenGL[18:04:26] *** slidercrank has joined ##OpenGL[18:09:41] *** CrizMobius has quit IRC[18:14:19] *** Cooler has joined ##OpenGL[18:16:06] *** hexagoxel has quit IRC[18:18:30] *** jdolan has quit IRC[18:18:56] *** bookmark has joined ##OpenGL[18:19:09] <aethersis> hey guys[18:19:13] <aethersis> GLubyte* pData = (GLubyte*)malloc(WIDTH*HEIGHT*3); it doesn't seem to work[18:19:26] <bookmark> hi too[18:19:26] <aethersis> when I was doing it with SOIL, loading an actual image, it was working[18:19:27] <aethersis> now it is not[18:19:48] <aethersis> texture is set like this: glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, texture_width, texture_height, 0, GL_RGB, GL_UNSIGNED_BYTE, pData);[18:20:08] <bookmark> what file format?[18:20:21] <aethersis> no format[18:20:25] <bookmark> oh[18:20:33] <aethersis> soil was working, but now i want to create the data manually[18:20:42] <bookmark> i mean do you load your images from a certain format?[18:20:43] <bookmark> oh[18:20:47] <bookmark> never done that[18:20:50] <aethersis> same[18:21:12] <bookmark> except with renderbuffer stuff[18:21:17] <bookmark> like mirrors[18:21:23] <ClaudiusMaximus> define "not working"[18:21:50] <bookmark> could you just use the .data() from a vector?[18:21:56] <bookmark> why not just use a vector?[18:22:14] <bookmark> it mallocs(or something) automatically[18:22:47] <bookmark> i think i have about 2 pointers in my entire program[18:23:05] <aethersis> when I try to bind the texture it gives me glGetError == 0 assertion failed[18:23:46] <bookmark> i gave my advice ;)[18:23:47] <aethersis> glBindTexture(GL_TEXTURE_2D, front);[18:23:48] <aethersis> there[18:24:14] <Stragus> You didn't share any code or information to actually see the problem[18:24:57] <aethersis> the code was working before my futile attempt to allocate the data manually[18:25:16] <aethersis> if you tell me how to allocate data properly for glTexture2D it will solve the problem xD[18:25:25] <aethersis> the rest of the code is irrelevant[18:25:40] <Stragus> Ah, that must be OpenGL's default row packing aligned on 4 bytes[18:26:19] <aethersis> now that's something! I beg you tell me how to allocate the data properly[18:27:05] <Stragus> glPixelStorei( GL_UNPACK_ALIGNMENT, 1 );[18:27:16] <Stragus> Keep your allocation the way it is[18:28:01] <aethersis> wait what's that glPixelStorei and where am I supposed to call it[18:29:12] <Stragus> Before your glTexImage2D() call[18:29:32] <aethersis> every time?[18:29:36] <aethersis> I have 3 textures[18:29:39] <aethersis> ther are going to be 8[18:29:51] <Stragus> Just once if you want, it's a state global to the context[18:30:01] *** Codex_ has joined ##OpenGL[18:30:10] *** goliath has joined ##OpenGL[18:31:00] <aethersis> it's still not working[18:32:45] *** kuldeepdhaka has quit IRC[18:33:20] <Cooler> how do you translate when using VBOs?[18:33:34] <Cooler> cause gltranslate doesn't seem to do anything[18:34:08] <bookmark> usually by means of giving a matrix to glsl[18:34:35] <bookmark> I never got VBOs working without getting glsl working[18:34:56] <bookmark> i mean its kind of like they work together[18:35:32] <Cooler> so the vertex shader has to do something?[18:37:07] <bookmark> see you get the matrix from c++ and send it into glsl as a uniform i think it is( i can give you specifics if you want ), then you issue a draw call, then the vertex shader manipulates the attributes using the matrix cuz you program it to do that, then the fragment shader shades the whole thing :)[18:37:17] <bookmark> c++ or whatever language[18:37:55] <Cooler> java[18:38:03] <bookmark> attributes being the vert coords, UVs and texture coords[18:38:36] <bookmark> http://www.andrews3d.com/images/GLSL4/[18:38:45] <bookmark> oh well here is some c++ source sorry[18:39:05] *** erhan_ has quit IRC[18:39:09] <bookmark> thats all i work in[18:40:03] <aethersis> I know what was the error, stragus - it was improperly defined texture size lmao[18:40:53] <bookmark> anyone know how to get the view matrix inside of Autodesk maya?[18:41:18] <bookmark> i want to project UVs[18:43:11] *** hexagoxel has joined ##OpenGL[18:48:17] *** jdolan has joined ##OpenGL[18:51:15] <Cooler> is there a good glsl 4 tutorial?[18:51:40] *** MiniCow has quit IRC[18:51:48] <Cooler> what is uniform mat4 Proj4x4;?[18:52:04] <bookmark> you mean in my code?[18:52:17] *** Syzygy__ has joined ##OpenGL[18:52:32] <Cooler> does it have to be binded somehow to the projection matrix?[18:52:39] <Cooler> yeah[18:53:18] <bookmark> yeah see the reshape function in mod.cpp[18:53:38] <bookmark> i'm sorry that i don't have a working java version for you[18:53:53] *** samrat has quit IRC[18:54:32] <Cooler> need a good tutorial for glsl[18:54:54] *** hdon has joined ##OpenGL[18:55:54] *** samrat has joined ##OpenGL[18:56:04] <bookmark> the fragment and shader stuff in glsl is fairly simple, its the stuff you have to hand it from c or java that is hard to find[18:56:18] *** Syzygy has quit IRC[18:56:33] <bookmark> i recommend just finding some basic example that already works[18:56:36] <bookmark> thats what i did[18:56:51] <bookmark> i found a program that compiled and rendered a triangle[18:57:01] <bookmark> and from there i added textures[18:57:03] <bookmark> and what not[18:57:25] <Cooler> i am trying to translate[18:57:32] *** doomlord_1 has joined ##OpenGL[18:58:02] <bookmark> does your program render something and do you have a fragment shader?[18:58:24] *** tcsc has joined ##OpenGL[18:58:25] *** jdolan has quit IRC[18:58:26] <bookmark> i mean does your program[18:58:36] *** jdolan has joined ##OpenGL[19:01:17] *** Misu has joined ##OpenGL[19:01:18] *** jdolan has quit IRC[19:01:25] *** jdolan has joined ##OpenGL[19:01:33] <bookmark> java is slow anyway ;P[19:02:54] *** samrat has quit IRC[19:05:33] <Codex_> rendering a triangle is the easy part. You end up problems once you need to move the triangle's corners.[19:06:45] <bookmark> ive never really had much problem moving stuff[19:06:59] <Cooler> Well apparently its as easy as multiplying the gl_ModelViewProjectionMatrix to input pos[19:07:22] *** samrat has joined ##OpenGL[19:07:30] <Codex_> they're just cpu operations which are slower than hell. Or if you go to shaders route, you have plenty of unexpected limitations.[19:07:33] <bookmark> not sure about the order there but its something similar[19:07:52] <bookmark> actually matrix manipulation is fast[19:08:11] <Codex_> matrix operations cannot move the triangle's corners[19:08:13] <bookmark> its the multiplication operation thats slow by each vert[19:08:41] <bookmark> codex you can just add a value to the coordinate and rebuffer[19:09:33] <bookmark> ive actually rotated objects using their vertices[19:09:35] *** staylor has joined ##OpenGL[19:09:40] <bookmark> its not that hard either[19:10:04] <bookmark> in terms of speed matrices speed things up[19:11:11] *** ShadowIce has joined ##OpenGL[19:11:12] *** Match has quit IRC[19:11:12] *** Ad1_RnR has joined ##OpenGL[19:11:18] <Codex_> but moving stuff in opengl is tricky business[19:11:21] <Cooler> damn it now the translate is working[19:11:31] <bookmark> just moving?[19:12:23] *** pazul has quit IRC[19:12:37] <Codex_> vertex pointer -swapping trick is probably the best one for moving, even though it eats lots of memory[19:12:40] <bookmark> i mean i guess there is some ambiuity in that there are multiple ways to accomplish it[19:12:56] <bookmark> ambiguity[19:14:08] <bookmark> to move something just use a matrix[19:14:15] <bookmark> its super fast[19:15:14] <bookmark> plus it simplifies[19:15:34] *** Cooler has quit IRC[19:16:51] *** shingshang has quit IRC[19:17:06] *** snakenerd has joined ##OpenGL[19:17:43] <aethersis> lmao[19:17:50] <aethersis> I have a working paint app in OpenGL[19:17:59] <aethersis> the approach is so ugly it can't be worse I guess lol[19:18:00] *** snakenerd has quit IRC[19:18:22] <Bloodust> oh god Codex_ has spoken again[19:18:29] <aethersis> I have fbo which is back buffer, texture which is front buffer and texture which is image to be drawn to fbo[19:18:47] <aethersis> so it's like back buffer = front buffer + texture with pixel data[19:18:53] <aethersis> and then swap buffers and do it again and again[19:19:04] <aethersis> is that acceptable?[19:19:27] <aethersis> I have to clear the texture data everytime the mouse is clicked and rebind the texture :/[19:19:43] *** jjs_ has joined ##OpenGL[19:19:51] *** snakenerd has joined ##OpenGL[19:20:05] *** jjs_ has quit IRC[19:20:42] <Codex_> bloodust: sounds like you have more ways how to move objects in opengl?[19:21:02] <Codex_> bloodust: if the already mentioned ones are not good enough[19:24:46] *** Folkol has quit IRC[19:24:47] <Bloodust> moving objects? a transformation matrix[19:25:09] *** snakenerd has quit IRC[19:25:11] <Codex_> that's only per-object basis movement. You usually want something more.[19:25:17] *** pazul has joined ##OpenGL[19:25:52] <Bloodust> like what?[19:25:56] <Bloodust> and does bookmark want more than that?[19:25:57] <bookmark> what i usually do is just animate at that point[19:26:03] <Codex_> like move vertices inside an object[19:26:15] <bookmark> i just swap objects[19:26:45] <bookmark> i have a hidden object that i get a matrix from[19:27:01] <bookmark> and i just have the other n objects use that matrix[19:27:09] <bookmark> and this defines an animation[19:28:00] <Bloodust> umm[19:28:10] <bookmark> ive done it other ways[19:28:17] *** bkre_ has joined ##OpenGL[19:28:32] <bookmark> i actually do in my current code base for hit boxes[19:28:55] *** ManDay has quit IRC[19:29:05] <bookmark> because the collision detection on a hit box needs real values[19:29:46] <Bloodust> so you have a group of objects and you move them all at once?[19:29:49] <Bloodust> Im missing something here[19:30:02] <bookmark> i custom designed rotate function[19:30:05] *** Zupoman has joined ##OpenGL[19:30:06] <bookmark> translate function[19:30:15] <bookmark> for my hit boxes[19:30:43] <bookmark> but i'm pretty sure you could just mult the vertex coordinates by the modelview matrix[19:30:52] <bookmark> to get those values for doing something like that[19:31:05] <bookmark> i just chose to be better safe than sorry[19:31:12] *** pazul has quit IRC[19:31:54] <bookmark> i should put examples of that someplace[19:32:59] <bookmark> and you have to rebuffer[19:33:28] <bookmark> which is time consuming[19:35:53] <Bloodust> mkay[19:36:45] <Codex_> bookmark: rebuffer means glBufferData calls?[19:37:08] <Codex_> bookmark: I mean, if you know the positions beforehand, you can avoid those calls.[19:37:56] <bookmark> well yeah thats what i do when i switch objects in an animation[19:41:14] <aethersis> heee I made laser painting app xD[19:41:25] <aethersis> it's like you have fluorescent paint that reacts on light[19:41:42] <aethersis> you paint somehing with light and then it glows after a while[19:41:52] <aethersis> opengl is so cool![19:42:13] *** PortaLu has joined ##OpenGL[19:42:13] *** PortaLu has joined ##OpenGL[19:42:26] *** Lucretia has quit IRC[19:42:28] *** PortaLu is now known as Lucretia[19:42:55] *** pazul has joined ##OpenGL[19:45:35] *** ragecryx has joined ##OpenGL[19:45:53] *** tcsc has quit IRC[19:47:15] *** foreignFunction has joined ##OpenGL[19:48:56] *** snakenerd has joined ##OpenGL[19:49:32] *** RyanPridgeon has joined ##OpenGL[19:50:43] *** forests has quit IRC[19:53:36] *** hahuang61 has joined ##OpenGL[19:54:19] *** forests has joined ##OpenGL[19:59:21] *** DrBoneStrong has joined ##OpenGL[20:00:22] *** Thrzsh has joined ##OpenGL[20:02:02] *** CainJacobi has joined ##OpenGL[20:02:06] *** ManDay has joined ##OpenGL[20:08:25] *** pizthewiz has joined ##OpenGL[20:11:15] *** magicthing has joined ##OpenGL[20:13:04] <magicthing> hiya, can anyone point me to a C or C++ opengl renderer that is simple yet uses modern opengl(not too modern) that can render basic shapes such as boxes, spheres, etc. ? Ogre3D seems very big for this purpose and irrlicht seems very outdated.[20:13:27] *** fille has joined ##OpenGL[20:13:34] *** Spkka has joined ##OpenGL[20:13:55] <fille> hell wondering how i can convert a mat4 to mat3[20:13:58] <fille> in glsl[20:14:26] <Bloodust> fille mat3 m3 = mat3(m4); doesnt work?[20:14:28] <BtbN> irrlicht seems outdated?[20:14:46] <Bloodust> or mat3 m3 = (mat3)m4;[20:14:52] <Bloodust> I dont remember the casting syntax[20:14:56] <fille> i think i tried that[20:15:16] <fille> ohh i thought mat3 m3 = mat3(mat4=[20:15:24] <fille> mat4)*[20:15:32] <Codex_> magicthing: http://sivut.koti.soon.fi/~terop/GameApi.html this one is simple, but its mostly for minigames....[20:16:10] *** ClarusCogitatio has quit IRC[20:16:17] <magicthing> cool thanks Codex_[20:16:28] <bookmark> http://codepad.org/DLty88IO[20:16:31] <Spkka> Hey, I am trying to render truetype fonts, using SDL_ttf by packing the individual glyphs into a OpenGL texture atlas. This all works fine and I get my font rendered through a shader but for some reason the background of the text doesn't contain any alpha. When I check the texture in gDebugger the values all seem to be correct. Yes blending is enabled and the blendfunc is set. How could I possibly lose my alpha channel?[20:16:44] <Bloodust> magicthing tread very lightly[20:17:27] *** doomlord_1 has quit IRC[20:17:34] <bookmark> Spkka, couldn't the image itsself be used as an alpha of sorts?[20:17:47] <bookmark> maybe one of the channels[20:17:54] <fille> GLES20.glEnable(GLES20.GL_BLEND);?[20:18:41] <bookmark> im just going to render fonts using geometry[20:18:47] *** lenarhoyt has joined ##OpenGL[20:18:50] *** ClarusCogitatio has joined ##OpenGL[20:19:04] <Spkka> The texture in gDebugger shows alpha values ranging from 0 to 255, and all text is white. The shader itself simply samples from the texture and multiplies by the vertex color.[20:19:36] <bookmark> so all your seeing is white blocks?[20:19:39] <Codex_> spkka: have you done glEnable(GL_BLEND); ?[20:19:48] <Spkka> nah, colored text with a black background[20:19:58] <Spkka> where the black should transparent[20:20:11] <bookmark> hmm[20:20:31] <bookmark> i would just contrast the shit out of it and then use it as its own alpha[20:20:33] <Spkka> Codex_: yes, and blendfunc is set to src_alpha, one_minus_alpha[20:21:10] <Spkka> bookmark: yeah I don't say this is the best way, I am just really confused why there is blending going on[20:21:17] <Spkka> no blending*[20:21:37] *** snakenerd has quit IRC[20:21:54] <bookmark> render order[20:22:06] <Codex_> spkka: and your colours really have alpha channel?[20:22:16] <bookmark> and do you have depth enabled?[20:23:13] <Codex_> maybe the shader ignores the alpha channel?[20:23:15] <bookmark> if they are drawn first but depth isn't enabled, you'd still see them but they would have no transparency[20:23:35] <Spkka> what bookmark makes sense I think, should look into that[20:23:44] <Spkka> however I have depth testing enabled[20:23:49] *** dusted has quit IRC[20:23:53] <bookmark> hmm[20:24:12] <Spkka> my sprites are rendered using the same shader btw, these show alpha as expected[20:24:16] <bookmark> i think you'd get the same result if they are closer to the camera?[20:24:48] <bookmark> yes but when are they called?, in a loop? in sequence?[20:25:10] <bookmark> the draw call i mean[20:25:10] <Spkka> mh well let me look into the depth thing, I recently added depth testing and changed my transform to 3d coordinates[20:25:30] <Spkka> rendering loop, before rendering spritebatches[20:25:46] <bookmark> they should come after their background[20:25:57] <bookmark> (the stuff you see in the transparency)[20:26:45] *** BreadProduct has joined ##OpenGL[20:27:07] <Spkka> the rendering call to the font should come after the background rendering using depth testing you mean?[20:27:43] <bookmark> not sure[20:27:56] <bookmark> i barely have transpancies working myself[20:28:12] <bookmark> kind of bleeding edge to me[20:28:36] <bookmark> i just know that you have to draw backgrounds first[20:28:48] *** Syzygy__ has quit IRC[20:28:55] <bookmark> not sure about depth testing[20:28:57] <Spkka> I was a bit confused because sdl_ttf actually returns a 32bit, argb surface, but it seems to be all fine in gDebugger, must be my code somewhere :)[20:29:18] *** faty has quit IRC[20:29:25] *** DapperPixpy has joined ##OpenGL[20:29:35] <bookmark> i suspect your draw order[20:29:50] <Spkka> well background is drawn before ui elements[20:29:59] <bookmark> hmm[20:30:09] <Spkka> however they are at the same depth[20:30:37] <bookmark> then i would try with depth turned off for the text or move the text closer to the camera[20:31:16] *** Waynes1 has joined ##OpenGL[20:34:31] *** Waynes has quit IRC[20:35:10] <Spkka> alright, neither seem to help but thank you for your input! I will play around a bit :)[20:35:50] <bookmark> sorry man :([20:40:31] *** mayankmadan has quit IRC[20:42:37] *** CainJacobi has quit IRC[20:43:04] *** CainJacobi has joined ##OpenGL[20:45:01] *** fille_ has joined ##OpenGL[20:45:15] *** ManDay has quit IRC[20:45:23] <fille_> hi wondering if i can rotate a gl_point[20:46:05] *** MLM has joined ##OpenGL[20:47:41] <Stragus> A point is rendered from a single vertex, and you can transform any vertex by a matrix that "rotates", so yes[20:48:51] <fille_> okej, strange im using the same modelMatrix[20:49:34] <fille_> every elere[20:49:37] <fille_> else*[20:50:32] *** aphorisme has joined ##OpenGL[20:51:56] *** tkeemon has quit IRC[20:52:44] *** paul424 has joined ##OpenGL[20:52:45] <aphorisme> Does anyone know about a reference where one can see quick which states goes into which objects? Like what is stored in a VAO, VBO, ... ?[20:53:27] *** derhass has joined ##OpenGL[20:54:29] *** Syzygy__ has joined ##OpenGL[20:55:00] *** Syzygy__ is now known as Syzygy[20:56:35] *** Crehl has joined ##OpenGL[20:57:25] *** japro has joined ##OpenGL[20:58:58] *** Dudi has joined ##OpenGL[21:08:48] <japro> http://i.imgur.com/I0raWvZ.png?1 now i have to figure out a lazy way to so some (probably baked) gi[21:09:49] <Bloodust> what are you making?[21:10:07] <japro> uh, stuff[21:10:27] <japro> was sort of thinking of having a plane dogfighting game over a cityscape[21:10:27] <fille_> bloodlust do u know why i cant rotate a glPoint[21:10:37] *** DaGardner has quit IRC[21:10:41] <fille_> i can rotate everything else[21:10:41] <japro> what would rotating a point do?[21:10:59] <Bloodust> fille rotating in place or around something ? :D[21:11:01] <japro> well i guess around a center that is not the point[21:11:05] <fille_> im using glPointsize to make it bigger[21:11:14] <fille_> then i use glpoint cord for texture[21:11:33] <fille_> it should rotate around its point[21:11:36] <fille_> :D[21:11:46] <Bloodust> why not just use triangles[21:12:07] <japro> well, you could rotate the gl_PointCoords[21:12:15] <fille_> true,[21:13:46] <fille_> never mind then[21:19:07] <japro> i'm kinda too lazy to somehow generate texcoords to bake lightmaps for this :([21:19:26] <japro> maybe i could just tessellate them a bit and calculate occlusion values per vertex?[21:19:38] <roboman2444> kinda[21:19:46] <roboman2444> some demoscene demos do this[21:19:57] <japro> leaves the issue of having to tessellate the floor in a way that fits the buildings on it[21:20:56] *** samrat has quit IRC[21:21:23] *** mockillo has quit IRC[21:22:40] *** newguise1234 has quit IRC[21:23:33] *** pazul has quit IRC[21:29:30] *** doomlord_1 has joined ##OpenGL[21:33:13] *** Garner has quit IRC[21:36:09] *** newguise1234 has joined ##OpenGL[21:42:21] *** CainJacobi has quit IRC[21:42:25] *** newguise1234 has quit IRC[21:42:25] *** newguise1234 has joined ##OpenGL[21:42:47] *** CainJacobi has joined ##OpenGL[21:43:33] <aethersis> holy shit[21:43:39] <aethersis> I have recurence in shader :/[21:43:46] <aethersis> tricky stuff to be done :<[21:44:24] <japro> recurrence?[21:46:26] <aethersis> yes[21:46:39] <aethersis> new state news data from current state[21:46:49] <aethersis> plus data from old state lol[21:47:16] <aethersis> furthermore it needs a few iterations like that[21:47:37] <aethersis> so i will have to run the shader a few times and swap states on fbo from CPU[21:47:42] <aethersis> Im too tired to touch it now[21:48:43] *** mockillo has joined ##OpenGL[21:49:32] <aphorisme> does the VAO remember which attributes are enabled?[21:49:58] *** devbug has joined ##OpenGL[21:50:50] <aethersis> I think it does[21:53:12] <japro> that is pretty much the point of having one :D[21:53:27] <aphorisme> ^.^. Okay.[21:53:51] <japro> you could also iterate on a image object or maybe use compute shaders + ssbos if that is an option[21:54:10] <japro> (or just ssbos. but i guess if you have those you also have CS most likely)[21:54:47] <bookmark> if you're using glsl you have to pass them in manually[21:56:21] *** tkeemon has joined ##OpenGL[21:56:49] *** devbug_ has joined ##OpenGL[21:58:39] *** Shogun has joined ##OpenGL[21:58:42] *** tehrain has quit IRC[21:59:09] *** cr`nge has quit IRC[22:01:18] *** devbug has quit IRC[22:04:16] *** fille_ has quit IRC[22:11:32] *** Jeanne-Kamikaze has joined ##OpenGL[22:11:45] *** Keniyal has joined ##OpenGL[22:11:49] *** Spkka has quit IRC[22:12:45] <japro> hmm, does someone have the inverse frustum matrix at hand? :D[22:12:54] <aethersis> use matlab xD[22:14:09] *** DaGardner has joined ##OpenGL[22:15:16] *** aphorisme has quit IRC[22:16:30] *** DrBoneStrong1 has joined ##OpenGL[22:16:37] <bookmark> does anyone know a way to create a 3d orthagonal camera?[22:16:41] *** karab44 has quit IRC[22:16:48] *** Garner has joined ##OpenGL[22:16:57] <bookmark> you can do it in maya, but i was wondering how they do it[22:17:21] <japro> put 3 orthogonal matrices in the upper 3x3 part of the matrix[22:17:25] <japro> add translation :D[22:17:37] <japro> 3 orthogonal vectors i mean[22:18:09] <bookmark> hmm[22:19:04] <japro> so look up ortho projections i guess[22:19:40] *** DrBoneStrong has quit IRC[22:20:26] *** ShadowIce has quit IRC[22:23:56] *** Lemml has joined ##OpenGL[22:30:07] <metredigm> it seems like if i don't bind to GL_ARRAY_BUFFER before i call VertexAttribArray/Pointer then the buffer data is somewhat corrupted[22:30:48] <HuntsMan> metredigm: on which GL version and profile?[22:30:58] *** Jeanne-Kamikaze has quit IRC[22:31:19] <slime> glVertexAttribPointer uses the GL_ARRAY_BUFFER binding that is bound at the time of the VertexAttribPointer call[22:31:33] <foobaz> the GL_ARRAY_BUFFER binding affects how the last parameter of glVertexAttribPointer, the pointer, is interpreted[22:31:45] <derhass> metredigm: we had that same discussion yesterday[22:31:48] <foobaz> https://www.opengl.org/wiki/GLAPI/glVertexAttribPointer[22:31:59] <metredigm> oh jeez. sorry, hit some arrow keys by accident.[22:32:08] <metredigm> yeah that problem was already solved, heh[22:32:26] <derhass> lol[22:33:23] <HuntsMan> lol[22:33:32] *** qeed has joined ##OpenGL[22:35:19] <metredigm> on an unrelated note, does anyone know if cairo renders vector fonts with cairo_show_text()?[22:35:33] <metredigm> i'm using it right now and it looks great, i'm just curious if it's vector-based rendering[22:37:54] *** razieliyo has joined ##OpenGL[22:38:09] *** ShadowIce` has joined ##OpenGL[22:38:15] *** zgreg has quit IRC[22:38:24] *** apoc has quit IRC[22:38:31] *** apoc has joined ##OpenGL[22:38:57] *** devbug has joined ##OpenGL[22:42:06] *** aethersis has quit IRC[22:42:44] *** zgreg has joined ##OpenGL[22:43:05] *** ClarusCogitatio has quit IRC[22:43:13] *** devbug_ has quit IRC[22:44:31] *** goliath has quit IRC[22:45:11] *** ClarusCogitatio has joined ##OpenGL[22:51:31] *** fille has quit IRC[22:52:10] *** ShadowIce has joined ##OpenGL[22:52:34] *** d_aniel has joined ##OpenGL[22:53:01] <d_aniel> hi guys[22:53:13] *** ShadowIce` has quit IRC[22:53:36] <d_aniel> is it possible to use glGenerateMipmap to generate downsampled versions of a texture and then access each level of downsampling to store to disk?[22:54:26] *** abs25 has quit IRC[22:54:37] <HuntsMan> sure[22:54:42] <HuntsMan> glGetTexImage[22:58:12] *** jdolan has quit IRC[22:58:40] *** jdolan has joined ##OpenGL[22:58:57] <d_aniel> HuntsMan: great, thx![22:59:11] *** ClarusCogitatio has quit IRC[22:59:22] *** Burga has joined ##OpenGL[23:00:42] *** Shogun has quit IRC[23:01:03] *** andyc has joined ##OpenGL[23:01:20] *** aphorisme has joined ##OpenGL[23:02:12] *** ClarusCogitatio has joined ##OpenGL[23:04:40] *** foreignFunction has quit IRC[23:05:23] *** ShadowIce has quit IRC[23:05:36] <andyc> Hi all, sorry if this is a daft question - if I have a mesh organised like this: http://ideone.com/K4k5Mo where the vector of vertices is my mesh, how can I buffer it with openGL? I can only work out how to do this if I hold separate vectors for pos, colour etc separately[23:05:53] *** ShadowIce has joined ##OpenGL[23:05:59] *** roxlu has left ##OpenGL[23:06:58] <derhass> andyc: interleaved vertex arrays[23:07:02] <andyc> I thought maybe if I knew how my struct was organised I might be able to buffer with some kind of stride[23:07:08] <derhass> andyc: the stride parameter is your friend[23:07:30] <andyc> derhass, Ah that's what I'm looking for but I couldn't find anything - I'll google interleaving[23:07:38] <derhass> andyc: https://www-user.tu-chemnitz.de/~heinm/tmp/va_ptr.pdf[23:08:05] *** mizux has joined ##OpenGL[23:09:36] *** japro has quit IRC[23:10:14] <andyc> derhass, That's exactly what I'm after thanks a lot[23:13:37] *** aethersis has joined ##OpenGL[23:13:44] <aethersis> I have a very hard nut to crack[23:13:55] <aethersis> maybe someone of you has an idea[23:14:02] <derhass> use a nut cracker[23:14:06] <aethersis> there's such the formula x[IX(i,j)] = (x0[IX(i,j)] + a*(x[IX(i-1,j)]+x[IX(i+1,j)]+x[IX(i,j-1)]+x[IX(i,j+1)]) )/c;[23:14:16] <aethersis> a and c are constants[23:14:40] <aethersis> but as you can see x depends on its neighbours and there is a reccurence[23:14:50] <aethersis> is there any way to rewrite it to fragment shader?[23:14:56] *** TunnelCat has joined ##OpenGL[23:15:01] <bob_twinkles> not directly[23:15:12] <foobaz> use two textures, render the one into the other, then render the other into the one[23:15:20] <bob_twinkles> you'd have to render to an FBO and then draw that FBO on a full screen textured quad[23:15:26] <bob_twinkles> ninja'd[23:15:40] <aethersis> but you can't use fbo texture as both input and output[23:15:57] <bob_twinkles> so either use 2 FBOs or use the backbuffer as the final surface[23:16:05] <bob_twinkles> (bind FBO 0 for the second render)[23:16:12] *** Alina-malina has quit IRC[23:16:17] <aethersis> let's say x is a vector instead of vector field[23:16:17] <foobaz> you can if the input and output are different textures[23:16:32] <aethersis> or scalar for simplification[23:16:38] <aethersis> yeah but it alters itself[23:16:45] <aethersis> it won't work like what you are saying[23:16:58] <aethersis> let's say it's only 1 dimensional[23:17:27] <derhass> you can't do sequential calculations in parallel[23:17:30] <aethersis> x[1] = x0[1] + a*(x[0]+x[2])/c[23:17:52] <bob_twinkles> that doesn't have a closed form solution[23:17:55] <aethersis> then x[2] = x0[2] + a*(x[1] + x[3])/c[23:18:02] <aethersis> x[2] was altered in previous state[23:18:08] <aethersis> it's immediately required[23:18:16] *** ShadowIce has quit IRC[23:18:18] <aethersis> that's it :/ FUCK[23:18:32] <foobaz> you're doing it wrong, you don't want to use the results of this frame in this frame[23:18:32] <aethersis> so there's no way? I need a different algorithm?[23:18:47] <bob_twinkles> it's likely not what you want anyway[23:18:49] <bob_twinkles> what are you doing?[23:19:00] <foobaz> it is mathematically impossible for each pixel to depend on its surrounding pixels[23:19:02] <aethersis> I'm calculating a velocity gradient field[23:19:04] <foobaz> you need a one frame delay[23:19:19] <aethersis> it's a spatial derivative[23:19:28] *** stefkos has quit IRC[23:19:36] <bob_twinkles> yeah but that doesn't depend on it's output...[23:20:08] <aethersis> I guess it's impossible to implement it on fragment shader[23:20:35] <foobaz> if you modified the current buffer, then pixels would use the new value for pixels to the left and up, but the old value for pixels down and to the right, you don't want that[23:20:57] *** edwardjohn has joined ##OpenGL[23:21:00] <derhass> foobaz: there are special cases where one wants that[23:21:00] <bob_twinkles> or possibly something even more screwy depending on how the hardware works[23:21:03] <foobaz> it's true that it's impossible to implement on fragment shader, but that ignores the important fact that it is mathematically the wrong way to do it[23:21:16] <foobaz> you want to be using the old values[23:21:27] <metredigm> you'd need two FBOs (or two textures)[23:21:29] <aethersis> no, the algorithm is correct[23:21:36] <aethersis> it is working properly on CPU[23:21:53] <aethersis> it's called gaussian relaxation[23:22:48] <foobaz> it's not possible for each pixel to depend on the current values of all its neighbors, it is a recursive dependency[23:22:49] <bob_twinkles> if I'm reading http://pauli.uni-muenster.de/~lemm/papers/dens/node87.html correctly that's still wrong[23:22:55] <foobaz> pixel a needs pixel b, but pixel b needs pixel a[23:23:00] *** garFF has joined ##OpenGL[23:23:19] <foobaz> so you can either use a mixture of old values and new values, or you can use all old values[23:23:30] <foobaz> using all old values produces more consistent results[23:23:31] <aethersis> http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html[23:23:35] <foobaz> and that is how everyone else does this[23:23:36] <aethersis> I must read how they implemented it here[23:23:52] <aethersis> it is a mixture[23:23:56] <aethersis> note the x0[23:24:05] *** tcsc has joined ##OpenGL[23:24:13] *** Waynes1 has quit IRC[23:25:00] <foobaz> is x0 one step older than x?[23:25:06] *** Codex_ has quit IRC[23:25:08] <aethersis> yes[23:25:14] <foobaz> ok, in that case you need three framebuffers[23:25:23] *** garFF has quit IRC[23:25:24] <foobaz> one old, one current, and the new one you're writing into[23:25:36] *** garFF has joined ##OpenGL[23:25:48] <foobaz> rotate them every frame[23:25:53] <bob_twinkles> aethersis: you're implementing equation 16 correct?[23:26:10] <aethersis> apparently yes, because I got it from working code made by Jos Stam[23:26:24] <bob_twinkles> take a look at EQ16[23:26:28] <aethersis> holy shit 3 FBOs[23:26:34] <bob_twinkles> you should be using x0 for all the stuff on the right[23:26:35] *** Ad1_RN has joined ##OpenGL[23:27:27] <bob_twinkles> then you only need 2 FBOs and just swap them back and forth[23:27:43] <foobaz> he needs to read from two different textures while writing into a new one[23:28:02] <foobaz> because he has x0 and x[23:28:59] <bob_twinkles> the xs on the right of his equation should be x0s if I'm reading this right though[23:29:53] *** Ad1 has quit IRC[23:29:55] <aethersis> x0 is like my b[23:30:20] <bob_twinkles> that's constant then[23:30:45] <bob_twinkles> and all the xs on the right are the Xs from the previous frame[23:30:47] <aethersis> yes, it doesnt' change[23:31:06] <bob_twinkles> so you only need 2 FBOs[23:31:07] <aethersis> yes but this method has this stupid recurrence[23:31:14] <bob_twinkles> ?[23:31:17] *** kmnt has quit IRC[23:31:17] <aethersis> that there's x on both sides of equation[23:31:18] <bob_twinkles> it's an iterative solver[23:31:29] <aethersis> x[IX(i,j)] = (x0[IX(i,j)] + a*(x[IX(i-1,j)]+x[IX(i+1,j)]+x[IX(i,j-1)]+x[IX(i,j+1)]) )/c;[23:31:30] <bob_twinkles> so... render(); swap_fbos(); goto: start[23:31:34] <aethersis> this formula is right and I am sure of it[23:31:51] <bob_twinkles> while (counter < solve_iterations)[23:31:55] <derhass> that notation is just horrible[23:31:57] *** metredigm has quit IRC[23:32:18] *** BreadProduct has quit IRC[23:32:26] *** ClarusCogitatio has quit IRC[23:33:21] <aethersis> IX is a macro[23:33:24] <bob_twinkles> aethersis: can you pastebin some context for where you're using that equation?[23:33:33] <aethersis> I don't need to[23:33:44] <aethersis> https://github.com/aethersis/fluid-solver/blob/master/solver.cpp[23:33:47] <aethersis> ^^[23:33:57] <aethersis> because it's already on git[23:34:10] <aethersis> I'm basically rewriting all this stuff into GLSL[23:34:15] *** ClarusCogitatio has joined ##OpenGL[23:34:16] <aethersis> if you need a data flow diagram, look here[23:34:27] <aethersis> uhh where 's it[23:34:28] <bob_twinkles> ah, yeah that's what's happening[23:34:38] <bob_twinkles> so that equation isn't actually correct[23:34:48] <bob_twinkles> it's just that since it's an iterative solver anyway, the errors get sort of hidden[23:35:02] <bob_twinkles> and you end up with lower quality results instead of something entierly incorrect[23:35:11] <aethersis> http://postimg.org/image/d9y3ozqqb/[23:35:25] <aethersis> REALLY?[23:35:37] <aethersis> how can it be improved![23:35:41] <aethersis> I beg you tell me[23:35:42] *** Gamecubic has quit IRC[23:35:48] <bob_twinkles> try double buffering x[23:35:51] <aethersis> I wasted so many sleepless nights on it[23:36:05] <aethersis> like how[23:36:08] <aethersis> memcpy?[23:36:09] <bob_twinkles> so like you initialize one buffer, solve into another[23:36:09] *** jdolan has quit IRC[23:36:11] *** Gamecubic has joined ##OpenGL[23:36:12] <bob_twinkles> and then swap the pointers[23:36:15] <bob_twinkles> no need to memcpy[23:36:26] <aethersis> write it exactly as you think it should be[23:37:04] <aethersis> it seemed weird to me as well. I'm sure he made this error on purpose to make other people's programs work worse :D[23:37:48] *** mayankmadan has joined ##OpenGL[23:38:40] *** ClarusCogitatio has quit IRC[23:38:58] <bob_twinkles> http://pastebin.com/BRDbfWuu[23:39:22] <bob_twinkles> heh[23:39:34] <bob_twinkles> obviously I left some important bits out but that's the general idea[23:40:10] <bob_twinkles> aethersis: ^[23:40:40] *** AbleBacon has quit IRC[23:41:16] <aethersis> yes i did it like this[23:41:19] <aethersis> holy fucking christ[23:41:19] *** kmnt has joined ##OpenGL[23:41:20] *** ClarusCogitatio has joined ##OpenGL[23:41:23] <aethersis> it[23:41:25] <aethersis> it is amazing[23:41:30] <aethersis> how could I not see it?![23:41:31] <bob_twinkles> the reason he did it the way he did is probably because this way you need to allocate a second buffer somewhere and he didn't feel like managing that[23:41:36] <aethersis> I can't believe it[23:42:29] <aethersis> or wait[23:42:35] <aethersis> no, it's not working as expected XD[23:42:43] *** Dudi has quit IRC[23:42:44] <bob_twinkles> and this approach translates almost directly to GLSL code, just instead of swapping pointers you swap FBO bindings and have the gpu "render" a textured quad with the shader using texture lookups to do the [IX(ii,jj)] stuff[23:42:50] <bob_twinkles> how so?[23:43:46] *** Demon_Fox has joined ##OpenGL[23:44:03] <aethersis> I don't get this buffer stuff[23:44:07] <aethersis> how's it realted to x and x0[23:44:30] <bob_twinkles> x0 is still whatever it was before since that's constant[23:44:55] <bob_twinkles> it's just you replace the x on the left with buffer_2 and the x on the right with buffer_1[23:45:11] <bob_twinkles> where buffer_1 is initialized to the parameter that gets passed in[23:45:16] <aethersis> without memcpy?[23:45:43] <aethersis> have you noticed that x and x0 are being continuously swapped in the code?[23:47:27] <bob_twinkles> hmm[23:47:42] <bob_twinkles> no they aren't?[23:47:51] <bob_twinkles> there's that swap at the end of set_bnd[23:48:14] <bob_twinkles> but that doesn't do anything 'cause it just exchanges the parameter values which doesn't change anything when the function returns[23:48:24] *** BreadProduct has joined ##OpenGL[23:49:01] <bob_twinkles> unless that's supposed to be before the END_FOR on line 65[23:49:30] <aethersis> see the whole code[23:49:39] <aethersis> apparently it must be recursive, this thing[23:49:58] <aethersis> http://pastebin.com/FRUd8bjZ[23:50:04] <aethersis> I did it like this and it's not working correctly[23:50:07] <aethersis> there must be the recursion[23:50:26] *** ClarusCogitatio has quit IRC[23:50:45] <bob_twinkles> you've still got an x on the right hand side[23:50:49] <bob_twinkles> on the i-1,j term[23:51:08] *** metredigm has joined ##OpenGL[23:51:23] <bob_twinkles> and you need to swap x and x_prev inside the loop over k[23:51:35] <bob_twinkles> the more I look at this code the more lost I'm getting though =P[23:51:53] *** metredigm has left ##OpenGL[23:52:00] *** void256 has joined ##OpenGL[23:52:48] *** metredigm has joined ##OpenGL[23:53:01] <aethersis> yeah I fixed it with the missing x_prev[23:53:15] *** ClarusCogitatio has joined ##OpenGL[23:56:18] <aethersis> eep[23:56:22] <aethersis> I think it's starting to work![23:57:00] <bob_twinkles> awesome[23:57:24] <aethersis> hoooly shit[23:57:43] <aethersis> it works for density fields[23:57:47] <aethersis> but it may be just an illusion[23:57:52] <aethersis> now I will try it in velocity fields[23:58:00] <bob_twinkles> one thing you should think about is figuring out how to move that malloc() somewhere it isn't done per frame, where it is now that malloc/free pair is gonna cost you a lot of CPU time[23:58:01] <bob_twinkles> =D[23:58:07] *** hahuang61 has quit IRC[23:58:26] *** hahuang65 has joined ##OpenGL[23:59:14] <bob_twinkles> same with the mallocs on lines 112/113 (of the github version of the code)