[00:00:29] *** TheLorax has quit IRC
[00:00:37] *** Alina-malina has joined ##OpenGL
[00:02:36] *** FrodoTheHobbit has joined ##OpenGL
[00:02:36] *** ttvdsfx has quit IRC
[00:02:46] *** ttvdsfx has joined ##OpenGL
[00:03:35] *** mat^2 has quit IRC
[00:03:49] *** asdf has joined ##OpenGL
[00:03:52] *** mat^2 has joined ##OpenGL
[00:05:45] *** FrodoTheHobbit1 has quit IRC
[00:06:01] *** shintah has quit IRC
[00:06:11] *** shintah has joined ##OpenGL
[00:06:48] *** Defaultti has quit IRC
[00:07:09] *** TheTeapot has quit IRC
[00:08:06] *** Ad1 has quit IRC
[00:10:57] *** timsche has quit IRC
[00:13:06] *** Defaultti has joined ##OpenGL
[00:15:10] *** stefkos has quit IRC
[00:18:48] *** shintah has quit IRC
[00:19:33] *** agorecki has joined ##OpenGL
[00:20:56] *** TheTeapot has joined ##OpenGL
[00:23:41] <XMPPwocky> is it OK to delete VBOs immediately after creating a VAO using them, so they stay around only as long as the VAO does?
[00:24:26] <bob_twinkles> I think that might cause undefined behavior
[00:24:37] <bob_twinkles> read: the driver either glerrs or crashes
[00:25:02] <bob_twinkles> you'd probably have to read the spec to be sure though
[00:25:05] *** japro has quit IRC
[00:25:25] <XMPPwocky> yeah, i was wondering if somebody else had read the spec :P
[00:25:36] <bob_twinkles> "glDeleteBuffers deletes n buffer objects named by the elements of the array buffers. After a buffer object is deleted, it has no contents, and its name is free for reuse (for example by glGenBuffers). If a buffer object that is currently bound is deleted, the binding reverts to 0 (the absence of any buffer object). "
[00:25:38] <bob_twinkles> so... don't do that
[00:26:50] *** zajfy has joined ##OpenGL
[00:27:17] <bob_twinkles> XMPPwocky: ^
[00:27:37] <XMPPwocky> darn
[00:29:06] <derhass> bob_twinkles: that is not the whole story
[00:29:19] <derhass> XMPPwocky: what you try to do is pefectly allowed by the spec
[00:29:49] <derhass> bob_twinkles: the binding is totally irrelevant here. what matters is that the buffer is attached to the VAO, hence, still in use
[00:30:58] <bob_twinkles> so the driver actually walks the list of VAOs when deleting buffers to make sure it doesn't delete one a VAO is using?
[00:31:03] *** sreich has joined ##OpenGL
[00:31:07] <XMPPwocky> well presumably it's refcounting
[00:31:29] <derhass> bob_twinkles: read section 5.1 of the gl 4.5 spec
[00:31:37] <bob_twinkles> that would probably be the smart way to do it
[00:31:44] *** Pyuruku has joined ##OpenGL
[00:32:03] <derhass> especially 5.1.3 Deleted Object and Object Name Lifetime
[00:32:52] *** Zupo2 has joined ##OpenGL
[00:32:56] <Pyuruku> Hi there, I'm implementing transparency in my software based renderer, and im seeing overlapping lines when triangles meet, http://i.imgur.com/IRLxLi3.png I'm using the standard scanline fill algorithm for rasterization, and was wondering if there were any tips/tricks on how to get rid of the overlap :o
[00:33:23] *** Zupoman has quit IRC
[00:34:05] <Pyuruku> I thought that I could just combine all fragments per model to eliminate overlap
[00:34:16] <Pyuruku> but then I dont know how I would interpolate with shading :o
[00:34:22] *** YarnFive8 has quit IRC
[00:34:24] *** PortaLu has joined ##OpenGL
[00:34:32] <Pyuruku> outside of detecting which fragment I'm currently in...
[00:35:43] <derhass> Pyuruku: you might want to read that classic article: http://chrishecker.com/images/9/97/Gdmtex2.pdf
[00:36:11] *** srjil has quit IRC
[00:36:24] *** Lucretia has quit IRC
[00:36:35] *** PortaLu is now known as Lucretia
[00:36:42] *** Lucretia has quit IRC
[00:36:42] *** Lucretia has joined ##OpenGL
[00:37:23] *** TheTeapot has quit IRC
[00:38:30] <bob_twinkles> derhass: so when I delete a buffer object, _I_ can no longer bind it, but implicit bindings through stuff like binding a VAO that uses the buffer still works because the underlying id/memory hasn't been deallocated?
[00:38:52] <derhass> bob_twinkles: yes
[00:40:01] *** TheTeapot has joined ##OpenGL
[00:40:59] <bob_twinkles> it seems like it's still a bad idea though, just 'cause it makes debugging harder
[00:41:34] *** bjz has quit IRC
[00:41:51] *** hahuang65 has quit IRC
[00:42:29] *** Misu has quit IRC
[00:42:30] <bob_twinkles> since you can end up in situations sort of like what happens when you have a dangling pointer in C/C++
[00:42:47] <derhass> bob_twinkles: how?
[00:43:50] <bob_twinkles> well, after you delete the object the GL is allowed to give you the same buffer name back, but referring to different storage
[00:44:38] <bob_twinkles> I guess it's only an issue if you confuse object names with pointers
[00:45:19] <bob_twinkles> and you don't clean up your own state properly
[00:46:13] *** ChrisUK has quit IRC
[00:46:56] *** ChrisUK has joined ##OpenGL
[00:46:56] *** TheTeapot has quit IRC
[00:47:02] *** Shogun_ has quit IRC
[00:47:20] *** yuung has joined ##OpenGL
[00:47:43] <Pyuruku> derhass: The pdf you linked seems to have some display issues http://i.imgur.com/lejtyR4.png, are you seeing this on your end?
[00:48:05] *** Shogun has joined ##OpenGL
[00:48:26] <yuung> I'm using OpenGLES with android, and i'm wondering what determines the x, y, and z axes' viewport values - for example, what determines that -1 is the left edge of the screen, the frustum?
[00:48:34] <yuung> (openGL and 3d graphics noob obviously)
[00:48:37] *** b4b has joined ##OpenGL
[00:49:21] <Pyuruku> yuung Have you looked into the basic rendering pipeline?
[00:49:34] *** Viata has joined ##OpenGL
[00:49:43] <yuung> Pyuruku, yes but it was a while ago
[00:49:48] <Pyuruku> look up NDC to see why -1 is the left edge
[00:49:57] <Pyuruku> normalized device coordinates
[00:49:58] <derhass> Pyuruku: hmm, yes, seems a bit broken at the formulas
[00:50:08] <yuung> Pyuruku, ah okay
[00:50:36] <Pyuruku> derhass do you know of an alternate source? :o a quick google didnt bring up anything
[00:50:44] <yuung> Pyuruku, however can't I programatically set it to be a value other than -1?
[00:50:49] <bob_twinkles> yes
[00:50:54] <derhass> Pyuruku: nope, unfortunalely not
[00:51:08] <Pyuruku> afaik ndc is strictly -1 - 1
[00:51:13] <yuung> i see
[00:51:17] <yuung> for all coordinates or just x?
[00:51:22] <Pyuruku> however i dont think you're asking about ndc, but something else
[00:51:27] <Pyuruku> all coordinates
[00:51:54] <Pyuruku> "for example, what determines that -1 is the left edge of the screen," depends on the coordinate space youre in
[00:51:58] <derhass> yuung: for all
[00:52:11] <Pyuruku> im guessing youre talking about ndc because -1 == left edge
[00:52:19] <Pyuruku> but you need to figure out what space youre in
[00:53:56] <yuung> Pyuruku, what do you mean by 'coordinate space'?
[00:54:01] <yuung> you mean world space, model space, etc?
[00:54:07] <Pyuruku> this is why you need to read up on the rendering pipeline :)
[00:54:12] <yuung> lol
[00:54:12] *** SHLV has joined ##OpenGL
[00:54:15] <yuung> doing so right now :p
[00:54:48] *** Crehl has joined ##OpenGL
[00:57:25] *** Biliogadafr has quit IRC
[00:57:44] *** Viata has quit IRC
[01:04:03] <yuung> i'm reading about the basic rendering pipeline, however i still have a question: when i print out the xyz coords, they will go past (-1, 1).  is this a result of the camera projection matrix?
[01:04:27] <Pyuruku> what space are you printing out the coordinates?
[01:04:33] <yuung> world space
[01:04:36] <yuung> i believe :3
[01:04:37] <Pyuruku> im assuming you're talking about world space?
[01:04:42] <Pyuruku> yeah
[01:04:58] <Pyuruku> so once all of the transformations and projections are applied
[01:05:10] <Pyuruku> you divide by the perspective to get normalized device coordinates
[01:05:10] <yuung> mhm
[01:05:16] <Pyuruku> which are -1 to 1 in all axes
[01:05:31] <Pyuruku> which are then converted to screen space via a simple function
[01:05:37] <yuung> ah, i see
[01:05:46] <yuung> is there a name for that function/matrix?
[01:05:47] <Pyuruku> screen space being a 2d representation of varying size
[01:05:50] <yuung> right
[01:06:11] <Pyuruku> well, I have a project open that has that code, here's what I do
[01:06:12] <Pyuruku> (x * 0.5f + 0.5f) * mRenderWindow->width() * mRenderWindow->devicePixelRatio()
[01:06:25] <Pyuruku> same for y, just switch to height
[01:06:42] <yuung> ah! so there's not necessarily a standardized function/matrix for it
[01:06:48] <yuung> probably because it's relatively simple
[01:06:48] <yuung> ?
[01:06:51] <Pyuruku> yeah
[01:06:55] <yuung> gotcha
[01:07:00] <Pyuruku> its up to you to decide how you map NDC to your screen
[01:07:01] *** newguise1234 has quit IRC
[01:07:03] <Pyuruku> the screen is arbitrary
[01:07:07] <yuung> right
[01:07:08] <Pyuruku> think of the oculus and stuff
[01:07:10] <Pyuruku> or a circle display
[01:07:13] *** tm604 has quit IRC
[01:07:16] <yuung> makes sense
[01:07:18] *** Ryp has joined ##OpenGL
[01:07:32] <yuung> awesome!  now i will go back to reading about the basic rendering pipeline.
[01:07:35] <bob_twinkles> usually it's a rectangle specified by glViewport() though
[01:08:18] *** newguise1234 has joined ##OpenGL
[01:08:36] *** Ryp has quit IRC
[01:09:37] *** Ryp has joined ##OpenGL
[01:10:16] *** tm604 has joined ##OpenGL
[01:13:59] *** tm604 has quit IRC
[01:13:59] *** tm604 has joined ##OpenGL
[01:15:20] *** b4b has quit IRC
[01:16:05] *** hexagoxel has quit IRC
[01:21:31] *** yuung has quit IRC
[01:23:29] *** indefini has quit IRC
[01:24:00] *** asdf has quit IRC
[01:26:29] *** Madsy has quit IRC
[01:26:50] *** Madsy has joined ##OpenGL
[01:29:04] *** Textmode has joined ##OpenGL
[01:31:34] <Textmode> how can I confirm that I actually have a stencil buffer?
[01:35:04] <bob_twinkles> what OpenGL[ES] version?
[01:35:11] *** bkre_ has quit IRC
[01:35:32] <Textmode> legacyGL, 2
[01:36:41] <bob_twinkles> glGet with argument GL_STENCIL_BITS should tell you the number of bits the stencil buffer has
[01:37:32] *** pestle has joined ##OpenGL
[01:37:44] *** tcsc has quit IRC
[01:40:52] *** asdf has joined ##OpenGL
[01:41:26] <Textmode> okay, that leave me with two questions; Why don't I have a stencil (even though I requested one) and why did it appear to work before?
[01:43:30] <Hunts> we cannot guess
[01:43:49] <bob_twinkles> check ALL the return values!
[01:44:14] <bob_twinkles> and call glGetError a bunch, that could help
[01:48:12] *** YarnFive8 has joined ##OpenGL
[01:49:34] *** asdf has quit IRC
[01:53:12] *** slime has joined ##OpenGL
[01:55:03] <Textmode> …no errors, apprently.
[01:55:44] <bob_twinkles> how are you getting a context?
[01:57:22] *** RyanPridgeon_ has quit IRC
[01:58:02] <Textmode> Through SDL2, and yes I'm setting SDL_GL_STENCIL_SIZE before creating the window and context.
[01:58:41] <bob_twinkles> and SDL says it's all OK?
[01:58:52] <bob_twinkles> I'm not that familiar with SDL, sorry
[02:01:04] *** charlie5 has quit IRC
[02:01:19] *** SHLV has quit IRC
[02:01:41] *** Ryp has quit IRC
[02:02:42] *** SorajSM has joined ##OpenGL
[02:06:13] <Textmode> somehow I was managing to use SDL to create a window and GL context without actually initialising the video subsystem. but that apprently wasn't the problem.
[02:07:04] *** konom has quit IRC
[02:07:38] <urraka> are you checking SDL_GetError?
[02:08:34] <Textmode> urraka: I am now. and nothing interesting other than the aforementioned.
[02:08:38] <slime> SDL_GetError isn't like glGetError, its output is only valid if a function returned with a definite error value (null pointer for functions that return pointers, or -1 for functions that return integers)
[02:09:13] <urraka> i see, i wasnt sure about that
[02:09:17] <Majiet> so, i am looking at the matrix for perspective camera, and is wondering if left and Top is suppose to be 0 or.
[02:09:54] <Majiet> Otho*
[02:10:05] <Majiet> ortho *
[02:10:29] *** meoblast001 has joined ##OpenGL
[02:12:12] *** Keniyal_ has quit IRC
[02:14:38] *** indefini has joined ##OpenGL
[02:15:07] *** Crehl has quit IRC
[02:17:00] <Textmode> I'm half-tempted to just use the depth buffer instead; I *know* i have one of those.
[02:17:07] <Textmode> and I have no other need of it…
[02:21:03] *** konom has joined ##OpenGL
[02:23:11] *** Garner has quit IRC
[02:25:09] <Textmode> ah, got it.
[02:25:33] <Textmode> er... "stencil bits: 11134"
[02:25:43] <Textmode> well, it works. but that number seems unlikely.
[02:26:27] <Textmode> oh, right. I moved the line that actually sets that variable.
[02:26:53] <Textmode> so everything looks good now.
[02:27:47] <bob_twinkles> what was wrong?
[02:29:26] <Dom__> Majiet: which way is up to you
[02:29:32] <Textmode> bob_twinkles: order of events, basically.
[02:29:41] <Dom__> 0, 0  can be your top left
[02:29:57] <Dom__> usually is either top or bottom left
[02:30:07] <bob_twinkles> Textmode: ah, ic
[02:32:16] <Dom__> anyone else get to work on monday, look at your tasks for the week and then proceed to procrastinate till wednesday?
[02:34:21] *** Majiet has quit IRC
[02:34:56] <bob_twinkles> s/wednesday/the last possible minute/
[02:35:02] <bob_twinkles> well, school work anyway
[02:38:28] <bob_twinkles> it's a really bad habit actually
[02:41:17] <Dom__> heh
[02:41:33] <Dom__> i did that all through school
[02:50:07] *** charlie5 has joined ##OpenGL
[02:50:08] *** charlie5 has left ##OpenGL
[02:55:43] *** cr`nge has quit IRC
[03:04:34] *** jdolan has quit IRC
[03:05:02] *** jdolan has joined ##OpenGL
[03:05:37] *** b4b has joined ##OpenGL
[03:08:36] *** jdolan has quit IRC
[03:08:56] *** hahuang65 has joined ##OpenGL
[03:10:32] *** jdolan has joined ##OpenGL
[03:10:51] *** kuldeepdhaka has joined ##OpenGL
[03:10:55] *** roboman2444 has quit IRC
[03:12:23] *** derhass_ has joined ##OpenGL
[03:15:22] *** derhass has quit IRC
[03:26:44] *** slidercrank has quit IRC
[03:27:43] *** mmnumbp has quit IRC
[03:29:41] *** mmnumbp has joined ##OpenGL
[03:32:04] *** DMJC has joined ##OpenGL
[03:32:11] *** qeed has quit IRC
[03:35:59] *** centrinia has joined ##OpenGL
[03:39:50] *** DapperPixpy has joined ##OpenGL
[03:42:02] <jbud> Hey #opengl guys, I'm trying to implement a crazy little idea in my app. I'd like to have a single static mesh represent water in my scene, however the mesh will always be centered to the camera. ie. if I fly forwards forever, it will look like the water goes on forever. I'm using a water texture, and in my frag shader I'm simply passing the camera XZ position and adding that to the texture coordinate to make it look like I'm actually moving
[03:43:33] <Stragus> Remember to reset eventually :). Or floats will lose accuracy with a large exponents
[03:43:41] <jbud> Hey Stragus  :)
[03:43:46] *** asdf has joined ##OpenGL
[03:43:54] <jbud> I'm running into issues with this technique though, I feel like I'm overlooking something
[03:44:04] <XMPPwocky> jbud: what issues
[03:44:04] <bob_twinkles> the other thing you can do is just not do the position transform when rendering water
[03:44:50] <jbud> eg. little ponds should look like the water is perfectly still as my camera flies over that pond. However I can actually see the textures shifting as I'm flying towards the pond
[03:45:02] <jbud> As if the water itself is moving
[03:45:21] <jbud> I can put together a little video clip if that sounds confusing
[03:45:44] *** jdolan has quit IRC
[03:46:05] *** jdolan has joined ##OpenGL
[03:48:44] *** HuntsMan2 has joined ##OpenGL
[03:49:03] <jbud> bob_twinkles: right now I'm doing  gl_Position = perspective * view * cameraPos * vert ... you're recommending  removing cameraPos?
[03:49:29] <bob_twinkles> how are you getting the vert position?
[03:49:45] <jbud> Its static, never changes
[03:50:13] <jbud> There's only 4 verts for the horizontal water plane
[03:50:28] *** asdf has quit IRC
[03:51:08] <bob_twinkles> I was recomending removing any transform to/from world space
[03:51:27] <bob_twinkles> but it seems like you've already done that
[03:51:39] <bob_twinkles> maybe the video would help?
[03:51:50] <jbud> gimme a few mins :)
[03:52:41] *** Hunts has quit IRC
[03:59:36] *** jdolan has quit IRC
[04:00:16] <jbud> https://www.youtube.com/watch?v=q71ga-U4tiU    My water rendering issue
[04:00:45] <jbud> It sort of looks like the water is really far away, and that there's a hole in the terrain, but that's not the case at all
[04:01:37] *** t4nk100 has joined ##OpenGL
[04:02:40] *** t4nk100 has left ##OpenGL
[04:03:05] *** jdolan has joined ##OpenGL
[04:03:10] *** hdon has joined ##OpenGL
[04:03:23] *** pauldachz has quit IRC
[04:03:39] *** asdf has joined ##OpenGL
[04:04:37] *** james4k has joined ##OpenGL
[04:06:49] *** tonytonychpr has joined ##OpenGL
[04:08:31] *** wiky has joined ##OpenGL
[04:13:57] *** pauldachz has joined ##OpenGL
[04:14:38] *** jdolan has quit IRC
[04:15:17] *** meoblast001 has quit IRC
[04:15:33] *** jdolan has joined ##OpenGL
[04:16:50] *** Orion] has quit IRC
[04:17:57] *** TyrfingMjolnir has quit IRC
[04:18:40] <bob_twinkles> try not adding the camera position?
[04:20:33] *** urraka has quit IRC
[04:25:19] <XMPPwocky> i mean, the camera position is also not a matrix
[04:25:57] *** TyrfingMjolnir has joined ##OpenGL
[04:26:37] <jbud> I actually get some weirder effects by not including the camera position
[04:27:13] <jbud> Some surprising effects actually, the water itself doesn't seem to shift at a consistent angle
[04:27:43] <jbud> Like the XZ texture shifting varies depending on which way the camera is facing
[04:28:16] *** tonytonychpr has quit IRC
[04:28:25] *** jdolan has quit IRC
[04:33:11] *** BreadProduct has quit IRC
[04:37:13] *** jdolan has joined ##OpenGL
[04:37:19] *** kidnapped_robot has quit IRC
[04:41:36] *** omererden has joined ##OpenGL
[04:43:53] *** Cabanossi has quit IRC
[04:46:09] *** Cabanossi has joined ##OpenGL
[04:51:04] *** TunnelCat has quit IRC
[04:51:23] *** omererden has left ##OpenGL
[04:56:53] *** Pyuruku has quit IRC
[04:57:52] *** pauldachz has quit IRC
[04:59:22] *** tapout has joined ##OpenGL
[04:59:37] *** xissburg has quit IRC
[05:06:32] *** telex has quit IRC
[05:08:48] *** telex has joined ##OpenGL
[05:08:50] *** pauldachz has joined ##OpenGL
[05:10:12] *** shingshang has joined ##OpenGL
[05:12:55] *** SleekoNiko has quit IRC
[05:19:44] *** asdf has quit IRC
[05:20:44] *** omererden has joined ##OpenGL
[05:20:56] *** omererden has left ##OpenGL
[05:22:22] *** pestle has quit IRC
[05:29:34] *** SleekoNiko has joined ##OpenGL
[05:30:53] *** pauldachz has quit IRC
[05:32:07] *** pauldachz has joined ##OpenGL
[05:42:44] *** Bigpet_ has quit IRC
[05:46:05] *** NinjaPreez has joined ##OpenGL
[05:47:04] <NinjaPreez> Heyo! Anyone mind if I ask some very beginner questions? I'm following every tut I've found to the letter, and not getting correct results.
[05:50:04] *** centrinia has quit IRC
[05:50:37] <cmr> NinjaPreez: what's up?
[05:52:24] <NinjaPreez> I'm using lwjgl and slick2D in Java to build a game, and when I draw an image to the screen using the dimensions of the Display object, I'm seeing the image at a lower resolution.
[05:53:54] <NinjaPreez> Absolutely every line in the code relating to the size of the viewport or display size checks out. I even made it print the values to make sure they didn't change somehow. So I'm thinking maybe I'm doing something wrong with my ortho call?
[05:54:22] *** DapperPixpy has quit IRC
[05:55:02] *** metredigm has joined ##OpenGL
[05:55:13] <bob_twinkles> code helps
[05:56:54] *** iRoBut has joined ##OpenGL
[06:04:10] *** centrinia has joined ##OpenGL
[06:04:58] *** iRoBut is now known as eyeRoBut
[06:05:17] *** tapout has quit IRC
[06:05:47] *** tapout has joined ##OpenGL
[06:06:13] *** eyeRoBut has quit IRC
[06:09:11] *** tapout has quit IRC
[06:09:47] *** tapout has joined ##OpenGL
[06:10:39] <NinjaPreez> Sorry, google coma. Found the issue. Apparently, Slick2D requires texture sizes to be powers of 2.
[06:12:40] <slime> I'd recommend libgdx rather than slick2d, if you're going to be using Java
[06:12:48] *** BreadProduct has joined ##OpenGL
[06:15:25] <NinjaPreez> Will definitely look into it. Seems like a silly restriction to me.
[06:20:42] *** b4b has quit IRC
[06:21:03] *** edwardk has joined ##OpenGL
[06:26:34] *** hahuang61 has joined ##OpenGL
[06:27:49] *** hahuang65 has quit IRC
[06:30:24] <jbud> Hey guys! I finally got it to work :) I still used the same method from before (offsetting the texture fetch based off my camera pos), but it turns out I needed to scale my offset by 0.012
[06:30:47] <jbud> Wanna know how I got that precise number? Trial and error over the passed 2 hours X_x
[06:40:55] <Stragus> You should try to find where that number comes from
[06:42:01] *** samrat has joined ##OpenGL
[06:42:39] <NinjaPreez> From non OpenGL experience: patchwerk fixes always come back to bite you in the ass
[06:46:52] *** plash has quit IRC
[06:47:17] *** krnlyng has quit IRC
[06:49:04] *** plash has joined ##OpenGL
[06:49:37] *** krnlyng has joined ##OpenGL
[06:51:45] *** clauswit_ has quit IRC
[06:53:05] *** MLM has quit IRC
[06:53:09] *** SorajSM has quit IRC
[06:53:50] *** asdf has joined ##OpenGL
[06:54:04] *** CainJacobi has quit IRC
[06:54:57] <Dom__> still haven't started work
[06:55:05] <Dom__> work day finishes in 1hr
[06:55:08] <Dom__> awww yeah
[06:55:50] *** clauswitt has joined ##OpenGL
[06:57:44] *** clauswitt has quit IRC
[06:58:25] *** clauswitt has joined ##OpenGL
[06:59:15] *** asdf has quit IRC
[06:59:22] *** Zeioth has quit IRC
[06:59:35] *** asdf has joined ##OpenGL
[07:09:41] *** Dark_Confidant has quit IRC
[07:09:41] *** Dark_Confidant|m has joined ##OpenGL
[07:13:33] *** SleekoNiko has quit IRC
[07:14:32] *** b4b has joined ##OpenGL
[07:14:49] *** Lypho has quit IRC
[07:15:10] *** Lypho has joined ##OpenGL
[07:21:52] *** shintah has joined ##OpenGL
[07:24:42] *** bjz has joined ##OpenGL
[07:25:03] *** Gamecubic has quit IRC
[07:27:17] *** plash has quit IRC
[07:27:52] *** pauldachz has quit IRC
[07:29:18] *** b4b has quit IRC
[07:29:58] *** foreignFunction has joined ##OpenGL
[07:30:29] *** pauldachz has joined ##OpenGL
[07:31:00] *** foreignFunction has quit IRC
[07:33:38] *** asdf has quit IRC
[07:34:12] *** plash has joined ##OpenGL
[07:35:45] *** Zupo has joined ##OpenGL
[07:36:55] *** Zupo2 has quit IRC
[07:42:01] *** Ad1_RnR has quit IRC
[07:43:05] *** BitPuffin has quit IRC
[07:45:24] *** Ad1_RnR has joined ##OpenGL
[07:47:15] *** bsomers has quit IRC
[07:52:17] *** damir__ has quit IRC
[07:52:32] *** Stragus has quit IRC
[07:55:00] *** Zupo has quit IRC
[07:55:46] *** clauswitt has quit IRC
[07:59:06] *** b4b has joined ##OpenGL
[08:00:04] *** Waynes has joined ##OpenGL
[08:05:34] *** suppahsrv has quit IRC
[08:08:32] *** jbud has quit IRC
[08:10:56] *** DrSkyLizard has joined ##OpenGL
[08:12:12] *** Twinklebear has quit IRC
[08:14:14] *** Burga has joined ##OpenGL
[08:15:09] *** Waynes has quit IRC
[08:15:27] *** plash has quit IRC
[08:15:27] *** plash has joined ##OpenGL
[08:17:03] *** Textmode has quit IRC
[08:21:03] *** neure has joined ##OpenGL
[08:24:11] *** neure has quit IRC
[08:27:03] *** maxton has joined ##OpenGL
[08:32:25] *** b4b has quit IRC
[08:35:37] *** Biliogadafr has joined ##OpenGL
[08:37:33] *** hexagoxel has joined ##OpenGL
[08:39:23] *** Burga has quit IRC
[08:41:53] *** dinamic has quit IRC
[08:41:54] *** xorox90 has joined ##OpenGL
[08:42:01] *** dinamic has joined ##OpenGL
[08:43:43] *** Lemml has joined ##OpenGL
[08:44:35] *** damir__ has joined ##OpenGL
[08:48:40] *** puerum has quit IRC
[08:50:42] *** robot-beethoven has joined ##OpenGL
[08:53:17] *** hexagoxel has quit IRC
[08:55:01] *** Garner has joined ##OpenGL
[08:55:51] *** konom has quit IRC
[08:58:38] *** Biliogadafr has quit IRC
[09:00:15] *** devbug has quit IRC
[09:07:00] *** konom has joined ##OpenGL
[09:08:29] *** shintahW has joined ##OpenGL
[09:13:17] *** clauswitt has joined ##OpenGL
[09:16:47] *** derhass has joined ##OpenGL
[09:18:01] *** clauswitt has quit IRC
[09:19:48] *** derhass_ has quit IRC
[09:27:59] *** losh has joined ##OpenGL
[09:29:38] *** TyrfingMjolnir has quit IRC
[09:37:01] *** james4k has quit IRC
[09:38:22] *** suppahsrv has joined ##OpenGL
[09:41:58] *** Folkol has joined ##OpenGL
[09:44:26] *** PasNox has joined ##OpenGL
[09:46:25] *** clauswitt has joined ##OpenGL
[09:49:01] *** clauswitt has quit IRC
[09:49:24] *** Stragus has joined ##OpenGL
[09:49:34] *** NinjaPreez has quit IRC
[09:50:10] *** clauswitt has joined ##OpenGL
[09:51:47] *** kuldeepdhaka has quit IRC
[09:51:49] *** BreadProduct has quit IRC
[09:52:16] *** clauswitt has quit IRC
[09:52:59] *** clauswitt has joined ##OpenGL
[09:54:35] *** clauswitt has quit IRC
[09:55:10] *** HunterD has joined ##OpenGL
[09:55:21] *** petervaro has quit IRC
[09:55:40] *** petervaro has joined ##OpenGL
[09:56:44] *** clauswitt has joined ##OpenGL
[09:58:49] *** clauswitt has quit IRC
[09:59:42] *** clauswitt has joined ##OpenGL
[10:05:42] *** japro has joined ##OpenGL
[10:14:52] *** robot-beethoven has quit IRC
[10:16:23] *** clauswit_ has joined ##OpenGL
[10:17:47] *** clauswitt has quit IRC
[10:23:24] *** petervaro has quit IRC
[10:24:24] *** petervaro has joined ##OpenGL
[10:28:44] *** Ryp has joined ##OpenGL
[10:33:52] *** HunterD has quit IRC
[10:36:38] *** HuntsMan2 has quit IRC
[10:37:37] *** kuldeepdhaka has joined ##OpenGL
[10:38:02] *** viggo2 has joined ##OpenGL
[10:38:46] *** agorecki has quit IRC
[10:40:38] *** viggo has quit IRC
[10:42:42] *** Dark_Confidant has joined ##OpenGL
[10:43:05] *** PasNox has quit IRC
[10:43:47] *** HunterD has joined ##OpenGL
[10:45:07] *** PasNox has joined ##OpenGL
[10:46:04] *** Dark_Confidant|m has quit IRC
[10:48:00] *** petervaro_ has joined ##OpenGL
[10:50:23] *** petervaro has quit IRC
[10:50:39] *** rdgawdzi__ has joined ##OpenGL
[10:50:46] *** Jack_ has joined ##OpenGL
[10:50:52] *** rdgawdzi__ has quit IRC
[10:51:54] *** centrinia is now known as sho_jitou
[10:52:02] *** sho_jitou is now known as centrinia
[10:52:02] *** Ryp has quit IRC
[10:56:00] *** Demon_Fox has quit IRC
[10:59:37] *** snakenerd has joined ##OpenGL
[11:00:24] *** PasNox has quit IRC
[11:01:07] *** kuldeepdhaka has quit IRC
[11:01:37] *** PasNox has joined ##OpenGL
[11:03:15] *** Ryp has joined ##OpenGL
[11:03:19] *** Majiet has joined ##OpenGL
[11:07:39] *** Crehl has joined ##OpenGL
[11:08:51] *** omererden has joined ##OpenGL
[11:09:00] *** omererden has left ##OpenGL
[11:10:38] *** snakenerd has quit IRC
[11:13:09] *** wiky has quit IRC
[11:15:31] *** petervaro__ has joined ##OpenGL
[11:18:04] *** Beetny has joined ##OpenGL
[11:18:06] *** petervaro_ has quit IRC
[11:19:05] *** Ryp has quit IRC
[11:22:01] *** Ryp has joined ##OpenGL
[11:23:44] *** petervaro__ has quit IRC
[11:25:41] *** centrinia has quit IRC
[11:28:46] *** pazul has joined ##OpenGL
[11:33:09] *** hdon has quit IRC
[11:36:29] *** Ryp has quit IRC
[11:40:08] *** Ryp has joined ##OpenGL
[11:42:13] *** ManDay has joined ##OpenGL
[11:43:11] *** tomnewmann has joined ##OpenGL
[11:44:35] *** tomnewmann has quit IRC
[11:44:51] *** tomnewmann has joined ##OpenGL
[11:46:09] *** tomnewmann has quit IRC
[11:46:29] *** tomnewmann has joined ##OpenGL
[11:47:23] *** timsche has joined ##OpenGL
[11:47:24] *** tomnewmann has quit IRC
[11:47:42] *** tomnewmann has joined ##OpenGL
[11:49:06] *** xorox90 has quit IRC
[11:49:12] *** tomnewmann has quit IRC
[11:49:22] *** hdon has joined ##OpenGL
[11:49:36] *** tomnewmann has joined ##OpenGL
[11:51:26] *** Crehl has quit IRC
[11:51:30] *** tomnewmann has joined ##OpenGL
[11:55:28] *** ManDay has quit IRC
[11:55:57] *** tomnewmann has quit IRC
[11:56:21] *** tomnewmann has joined ##OpenGL
[11:57:44] *** tomnewmann has quit IRC
[11:58:08] *** ManDay has joined ##OpenGL
[11:58:19] *** Bigpet_ has joined ##OpenGL
[11:59:01] *** matpow2 has joined ##OpenGL
[11:59:18] *** tomnewmann has joined ##OpenGL
[12:00:09] *** tomnewma_ has joined ##OpenGL
[12:00:10] *** tomnewmann has quit IRC
[12:00:13] *** matpow2 has quit IRC
[12:00:41] *** Jack_ has quit IRC
[12:00:55] *** soulz has quit IRC
[12:01:26] *** soulz has joined ##OpenGL
[12:02:25] *** suppahsrv has quit IRC
[12:02:40] *** soulz has quit IRC
[12:08:12] *** tomnewma_ has quit IRC
[12:08:12] *** tomnewmann has joined ##OpenGL
[12:09:34] *** indefini has quit IRC
[12:10:25] *** suppahsrv has joined ##OpenGL
[12:13:49] *** ManDay has quit IRC
[12:14:05] *** clauswit_ has quit IRC
[12:14:08] *** tomnewmann has quit IRC
[12:14:26] *** tomnewmann has joined ##OpenGL
[12:14:58] *** ManDay has joined ##OpenGL
[12:15:02] *** ManDay has joined ##OpenGL
[12:15:33] *** tomnewmann has quit IRC
[12:15:52] *** tomnewmann has joined ##OpenGL
[12:16:42] *** tomnewmann has quit IRC
[12:17:22] *** tomnewmann has joined ##OpenGL
[12:19:48] *** tomnewmann has quit IRC
[12:20:06] *** tomnewmann has joined ##OpenGL
[12:20:39] *** tomnewmann has quit IRC
[12:21:35] *** tomnewmann has joined ##OpenGL
[12:24:33] *** kuldeepdhaka has joined ##OpenGL
[12:27:03] *** clauswitt has joined ##OpenGL
[12:27:30] *** tomnewmann has quit IRC
[12:27:46] *** tomnewmann has joined ##OpenGL
[12:27:59] *** soulz has joined ##OpenGL
[12:28:56] *** clauswitt has quit IRC
[12:31:21] *** soulz has quit IRC
[12:31:49] *** prophile has joined ##OpenGL
[12:34:08] *** tomnewmann has quit IRC
[12:35:36] *** tomnewmann has joined ##OpenGL
[12:36:55] *** tomnewmann has joined ##OpenGL
[12:36:57] *** pazul has quit IRC
[12:38:09] *** tomnewmann has quit IRC
[12:38:16] *** tomnewmann has joined ##OpenGL
[12:38:57] *** HunterD has quit IRC
[12:39:31] *** Keniyal has joined ##OpenGL
[12:39:58] *** soulz has joined ##OpenGL
[12:41:36] *** tomnewmann has quit IRC
[12:42:32] *** tomnewmann has joined ##OpenGL
[12:42:43] *** farhad has joined ##OpenGL
[12:43:47] *** soulz has quit IRC
[12:45:18] *** tomnewmann has quit IRC
[12:45:28] *** tomnewmann has joined ##OpenGL
[12:45:57] *** ManDay has quit IRC
[12:46:22] *** TheBeerinator has quit IRC
[12:46:38] *** clauswitt has joined ##OpenGL
[12:47:26] *** PasNox has quit IRC
[12:47:59] *** PasNox has joined ##OpenGL
[12:48:59] *** pazul has joined ##OpenGL
[12:51:29] *** charlie5 has joined ##OpenGL
[12:51:32] *** tomnewmann has quit IRC
[12:53:06] *** tomnewmann has joined ##OpenGL
[12:53:52] *** tomnewmann has quit IRC
[12:54:11] *** tomnewmann has joined ##OpenGL
[12:54:41] *** devPunk has joined ##OpenGL
[12:54:55] *** Madsy has quit IRC
[12:55:04] *** Majiet has quit IRC
[12:56:51] *** indefini has joined ##OpenGL
[12:58:29] *** zajfy has quit IRC
[13:06:07] *** Sos has joined ##OpenGL
[13:07:32] *** DrSkyLizard has quit IRC
[13:07:40] *** tomnewmann has quit IRC
[13:07:45] *** snakenerd has joined ##OpenGL
[13:08:03] *** tomnewmann has joined ##OpenGL
[13:08:23] *** pauldachz has quit IRC
[13:10:07] *** Majiet has joined ##OpenGL
[13:12:21] *** samrat has quit IRC
[13:14:35] *** Khlorghaal has quit IRC
[13:17:28] *** devPunk1 has joined ##OpenGL
[13:17:29] *** devPunk has quit IRC
[13:18:03] *** devPunk has joined ##OpenGL
[13:18:04] *** devPunk1 has quit IRC
[13:19:01] *** tomnewmann has quit IRC
[13:19:18] *** tomnewmann has joined ##OpenGL
[13:19:49] *** farhad has quit IRC
[13:21:33] *** tomnewmann has quit IRC
[13:21:49] *** tomnewmann has joined ##OpenGL
[13:23:30] *** ragecryx has joined ##OpenGL
[13:25:09] *** tomnewmann has quit IRC
[13:27:09] *** Majiet has quit IRC
[13:29:36] *** devPunk has quit IRC
[13:29:57] *** Majiet has joined ##OpenGL
[13:30:57] *** paperManu_ has joined ##OpenGL
[13:31:32] *** Beetny has quit IRC
[13:38:12] *** zzuegg has joined ##OpenGL
[13:38:59] *** Jonatan is now known as Jonatan_
[13:44:48] *** jdolan has quit IRC
[13:45:48] *** jdolan has joined ##OpenGL
[13:48:58] *** hexagoxel has joined ##OpenGL
[13:52:31] *** tomnewmann has joined ##OpenGL
[13:53:43] *** jdolan has quit IRC
[13:54:49] *** BitPuffin has joined ##OpenGL
[13:54:58] *** Sirolf has joined ##OpenGL
[13:55:07] *** tomnewmann has quit IRC
[13:56:59] *** tomnewma_ has joined ##OpenGL
[14:03:31] *** dusted has joined ##OpenGL
[14:03:34] *** lbt has left ##OpenGL
[14:04:48] *** urraka has joined ##OpenGL
[14:05:19] *** xissburg has joined ##OpenGL
[14:09:27] *** kidnapped_robot has joined ##OpenGL
[14:12:37] *** Majiet has quit IRC
[14:13:00] *** samrat has joined ##OpenGL
[14:13:58] *** Grimshaw has joined ##OpenGL
[14:15:14] *** tomnewmann has joined ##OpenGL
[14:15:23] *** tomnewma_ has quit IRC
[14:15:53] *** pazul has quit IRC
[14:17:44] *** erhan_ has joined ##OpenGL
[14:22:42] *** tomnewmann has quit IRC
[14:22:56] *** tomnewmann has joined ##OpenGL
[14:26:44] *** tomnewmann has quit IRC
[14:26:51] *** tomnewmann has joined ##OpenGL
[14:27:40] *** pazul has joined ##OpenGL
[14:28:06] *** tomnewmann has quit IRC
[14:28:14] *** tomnewmann has joined ##OpenGL
[14:29:31] *** tomnewmann has quit IRC
[14:30:03] *** tomnewmann has joined ##OpenGL
[14:33:13] *** kuldeepdhaka_ has joined ##OpenGL
[14:34:10] *** kuldeepdhaka has quit IRC
[14:42:09] *** jdolan has joined ##OpenGL
[14:42:50] *** razieliyo has joined ##OpenGL
[14:43:32] *** soulz has joined ##OpenGL
[14:46:05] *** Ryp has quit IRC
[14:48:09] *** Ryp has joined ##OpenGL
[14:51:01] *** xjiujiu has joined ##OpenGL
[14:51:03] *** tomnewmann has quit IRC
[14:51:38] *** tomnewmann has joined ##OpenGL
[14:53:10] *** tomnewmann has quit IRC
[14:53:45] *** tomnewmann has joined ##OpenGL
[14:58:51] *** tomnewmann has quit IRC
[14:59:13] *** paperManu_ has quit IRC
[14:59:39] *** tomnewmann has joined ##OpenGL
[15:02:06] *** tomnewmann has quit IRC
[15:02:31] *** tomnewmann has joined ##OpenGL
[15:05:45] *** tomnewmann has quit IRC
[15:06:00] *** tomnewmann has joined ##OpenGL
[15:08:02] *** tomnewmann has quit IRC
[15:08:12] *** tomnewmann has joined ##OpenGL
[15:09:16] *** samrat has quit IRC
[15:10:58] *** tomnewmann has quit IRC
[15:11:25] *** tomnewmann has joined ##OpenGL
[15:11:53] *** Ryp has quit IRC
[15:13:17] *** Ryp has joined ##OpenGL
[15:14:23] *** Chunk2 has quit IRC
[15:14:41] *** samrat has joined ##OpenGL
[15:15:32] *** Orion] has joined ##OpenGL
[15:18:41] *** dmlloyd has joined ##OpenGL
[15:20:00] *** tomnewmann has quit IRC
[15:21:35] *** tomnewmann has joined ##OpenGL
[15:22:17] *** luxigo has joined ##OpenGL
[15:22:20] *** garbage has joined ##OpenGL
[15:23:54] *** tomnewmann has quit IRC
[15:23:56] *** tehrain has joined ##OpenGL
[15:23:56] *** tehrain has joined ##OpenGL
[15:24:10] *** tomnewmann has joined ##OpenGL
[15:24:43] *** Chunk2 has joined ##OpenGL
[15:25:44] *** kuldeepdhaka_ is now known as kuldeepdhaka
[15:27:34] *** tomnewmann has quit IRC
[15:27:44] *** prophile has quit IRC
[15:27:46] *** tomnewmann has joined ##OpenGL
[15:29:04] *** tomnewmann has quit IRC
[15:29:09] *** tomnewma_ has joined ##OpenGL
[15:29:51] *** tomnewma_ has quit IRC
[15:30:36] *** telex has quit IRC
[15:30:52] *** tomnewmann has joined ##OpenGL
[15:31:26] *** tomnewmann has quit IRC
[15:31:51] *** tomnewmann has joined ##OpenGL
[15:32:50] *** telex has joined ##OpenGL
[15:33:09] *** tomnewmann has quit IRC
[15:36:40] *** tomnewma_ has joined ##OpenGL
[15:37:15] *** tomnewma_ has quit IRC
[15:37:43] *** tomnewmann has joined ##OpenGL
[15:38:21] *** tomnewmann has quit IRC
[15:38:55] *** xissburg_ has joined ##OpenGL
[15:39:32] *** tomnewma_ has joined ##OpenGL
[15:39:55] *** xissburg has quit IRC
[15:40:49] *** Ryp has quit IRC
[15:41:35] *** Ryp has joined ##OpenGL
[15:48:47] *** tomnewma_ has quit IRC
[15:48:57] *** tomnewmann has joined ##OpenGL
[15:49:48] *** HunterD has joined ##OpenGL
[15:51:28] <ikarus> ugh, writing a "resource manager" for OpenGL operations can be a pain (right, I need the next free texture unit and need to tell the shader that name x refers to it)
[15:53:32] <AbigailBuccaneer> ikarus, i've tried to do things with optimally efficient texture unit switching for minimal sampler uniform changes
[15:53:37] <AbigailBuccaneer> my findings are: it's not really worth it :P
[15:54:00] <ikarus> AbigailBuccaneer: oh, this isn't even to get optimally efficient
[15:54:14] <ikarus> this is just to cut down on the number of things different bits of code need to know about
[15:54:43] *** dlite has joined ##OpenGL
[15:55:00] *** xjiujiu has quit IRC
[15:55:06] *** tomnewmann has quit IRC
[15:55:13] *** tomnewma_ has joined ##OpenGL
[15:55:15] <dlite> I did't understand the PROJECTION matrices ...can anyone please sum it up in one line ?
[15:55:15] *** Twinklebear has joined ##OpenGL
[15:55:37] <ikarus> the projection matrix turns world space into clipspace
[15:56:16] <AbigailBuccaneer> dlite, a projection matrix maps the entire visible world (as defined by a camera frustum) into a unit cube. this takes into account your FoV and the screen's aspect ratio
[15:56:37] *** roboman2444 has joined ##OpenGL
[15:56:39] *** Binero has joined ##OpenGL
[15:56:48] *** tomnewma_ has quit IRC
[15:56:49] <Binero> Hello
[15:56:55] <AbigailBuccaneer> hi Binero
[15:57:03] *** nmschulte has quit IRC
[15:57:07] <Binero> Is it possible there are some errors in the XML opengl specification?
[15:57:30] <dlite> well ... I got your point ... but whatz the seperation again ?? MODEL VIEW and PROJECTION view
[15:57:47] <dlite> I'm thinkin it's related to object and camera thingy
[15:58:08] *** Twinklebear has quit IRC
[15:58:13] <Binero> If I look here: https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml
[15:58:22] <Binero> There is an #endif without a matching #if
[15:59:08] <AbigailBuccaneer> dlite, the model matrix defines the position, orientation and scale of the object. the view matrix defines the position and orientation of the camera. the projection matrix defines the field-of-view etc. of the camera
[16:00:04] <AbigailBuccaneer> the model and view matrices are typically orthonormal - ie. they both consist of a translation and a rotation
[16:00:14] *** clauswitt has quit IRC
[16:00:20] <dlite> AbigailBuccaneer ... got it. So everytime I wanna modify the object.. I use MODEL VIEW
[16:00:45] <dlite> and for VIEW stuff.. we should use PROJECTION VIEW MATRIX
[16:01:06] <AbigailBuccaneer> dlite, there are three matrices - the model matrix, the view matrix and the projection matrix
[16:01:36] <AbigailBuccaneer> legacy OpenGL, if i remember correctly, requires you to specify the "model view" matrix - which is just the composition of the model and view matrices
[16:01:56] <AbigailBuccaneer> the model matrix maps coordinates from object space to world space, and the view matrix maps coordinates from world space to view space
[16:02:09] <AbigailBuccaneer> and so the "model view" matrix maps coordinates from object space directly to view space
[16:02:32] <AbigailBuccaneer> if you're using newer GL - ie. with shaders etc. - then you don't need to think in terms of a "model view" matrix
[16:03:06] <AbigailBuccaneer> so to answer your question directly: the model matrix is defined by the properties of the object, and the view and projection matrices are defined by the properties of the camera
[16:03:41] <AbigailBuccaneer> dlite, for more reading: http://arcsynthesis.org/gltut/Positioning/Tut04%20Perspective%20Projection.html https://open.gl/transformations#TransformationsinOpenGL
[16:04:13] *** tomnewma_ has joined ##OpenGL
[16:04:44] *** tomnewma_ has quit IRC
[16:04:52] <dlite> AbigailBuccaneer ... Thank You :) it helped a lot .... Now i can look into programs ... I've got an exam tomorrow ...
[16:05:02] *** tomnewma_ has joined ##OpenGL
[16:05:15] *** samrat has quit IRC
[16:07:18] <AbigailBuccaneer> Binero, i do vaguely recall hearing mentions of errata in the GL spec - it's not impossible. though i think they were a lot more common before the GL spec was XML
[16:07:32] *** Ryp1 has joined ##OpenGL
[16:07:45] <Binero> right
[16:07:50] <AbigailBuccaneer> Binero, though i also know that these days there are several tools to parse the XML spec and write out header files eg. https://bitbucket.org/alfonse/glloadgen/wiki/Home
[16:08:04] *** tomnewma_ has quit IRC
[16:08:09] <Binero> I'm creates non-c bindings though
[16:08:13] <Binero> *creating
[16:08:35] <AbigailBuccaneer> my point is merely that if there were errors as huge as unmatched preprocessor commands in the current xml spec, you wouldn't be the first to find them :P
[16:08:54] <Binero> Yeah
[16:09:09] <Binero> Still can't figure out where the matching if is though, I've checked 3 times and it's right at the top of the file
[16:09:24] <Binero> "#endif</type>" is the line I'm talking about
[16:09:29] *** Ryp has quit IRC
[16:10:21] <AbigailBuccaneer> is it possible that you missed the preprocessor commands on the very first line of that block? <type name="inttypes">#ifndef GLEXT_64_TYPES_DEFINED
[16:11:00] *** damir__ has quit IRC
[16:11:12] *** HuntsMan has joined ##OpenGL
[16:11:49] <AbigailBuccaneer> Binero, ^ everything seems to balance upon a quick visual inspection when you notice that line :P
[16:12:25] *** samrat has joined ##OpenGL
[16:12:45] *** tomnewmann has joined ##OpenGL
[16:14:40] <Binero> hmm
[16:14:54] *** tomnewmann has quit IRC
[16:14:58] <Binero> I did
[16:15:01] <Binero> thanks
[16:15:09] *** tomnewmann has joined ##OpenGL
[16:15:27] <ikarus> yup, I quit, writing the code to this nicely is just such a headache
[16:15:49] <ikarus> because I could hack it up, but I know that will cause headaches 5 days later
[16:16:48] <AbigailBuccaneer> ikarus, in our engine we have a material system, which allows for various textures to be assigned to various "material slots" eg. normal map, cubemap, self-illumination, etc. etc. - and in our GL renderer we just do the absolute simplest thing and make each one of these material slots correspond to a texture unit
[16:18:31] <AbigailBuccaneer> trying to treat texture units as a resource (as you said, "I need the next free texture unit") is a nice theoretical idea but it's better to take the simpler option of just treating them as a piece of state that each draw can change as necessary
[16:19:08] <AbigailBuccaneer> and then your sampler uniforms don't require changing at draw time, which should simplify matters somewhat
[16:19:47] <ikarus> mhm, these however are in post processing effects
[16:19:54] <ikarus> so slightly less fun
[16:20:44] <AbigailBuccaneer> the post-processing code in our engine is the ugliest part of the renderer by a long way, so maybe i shouldn't be handing out advice about how to architect it :P
[16:22:06] <ikarus> hehehe
[16:23:27] *** tomnewma_ has joined ##OpenGL
[16:23:28] *** tomnewmann has quit IRC
[16:23:33] <AbigailBuccaneer> though in terms of texture unit usage - we have fixed texture units for accessing the depth texture and scene colour, and then for anything else (eg. multi-step post-processing) things just bind whichever textures they want from 0 upwards, making no attempt to not clash with others
[16:26:21] *** tomnewma_ has quit IRC
[16:26:23] *** tomnewmann has joined ##OpenGL
[16:27:42] <dlite> why is it that I always have to RESIZE the window to initiate display in OPENGL program ?
[16:28:10] <AbigailBuccaneer> dlite, because your code is incorrect, and there's something you're doing in a resize callback that you should be doing at initialise too
[16:28:12] <AbigailBuccaneer> :)
[16:29:23] <AbigailBuccaneer> without showing us any code there's not much we can do - it might be a problem with the way you're using a windowing library, or maybe you're not flushing or swapping your buffers, or maybe your code only redraws when you resize the window instead of every frame, or...
[16:31:44] *** slidercrank has joined ##OpenGL
[16:32:35] *** BreadProduct has joined ##OpenGL
[16:35:03] <dlite> AbigailBuccaneer here is the link http://pastebin.com/JJrx5sgm
[16:35:18] <dlite> http://pastebin.com/JJrx5sgm
[16:35:41] <dlite> tell me where I went wrong
[16:37:05] <Binero> am I right in saying the OpenGL XML specification doesn't 100% conform with the C macro language?
[16:37:05] <Binero> Because of the line #endif</type> - macros are supposed to end with a newline
[16:37:31] *** staylor has joined ##OpenGL
[16:38:41] <AbigailBuccaneer> dlite, try adding glFinish() at the end of your display() function
[16:41:17] *** dlite has quit IRC
[16:42:37] *** dlite has joined ##OpenGL
[16:43:34] *** RyanPridgeon has joined ##OpenGL
[16:43:49] *** Zupo has joined ##OpenGL
[16:44:38] *** tomnewmann has quit IRC
[16:45:47] *** tomnewmann has joined ##OpenGL
[16:45:49] *** dlite has quit IRC
[16:48:03] *** james4k has joined ##OpenGL
[16:48:42] *** tomnewmann has quit IRC
[16:49:00] *** tomnewmann has joined ##OpenGL
[16:49:26] *** bjz_ has joined ##OpenGL
[16:49:37] *** bjz has quit IRC
[16:50:20] *** tomnewmann has quit IRC
[16:50:33] *** tomnewmann has joined ##OpenGL
[16:51:16] *** Grimshaw has quit IRC
[16:51:29] *** maxton has quit IRC
[16:53:13] *** james4k has quit IRC
[16:54:31] <Binero> hmm the opengl spec has a huge bias towards C; seems like you can't properly use it without having some sort of c parser
[16:54:47] <Binero> mainly because the imports
[16:55:01] *** garbage has quit IRC
[16:55:18] *** Ad1 has joined ##OpenGL
[16:56:01] *** PasNox has quit IRC
[16:56:16] <Yaniel> well it is designed as a C API
[16:59:27] *** Gamecubic has joined ##OpenGL
[16:59:34] *** bjz_ has quit IRC
[17:00:00] *** bjz has joined ##OpenGL
[17:00:18] *** radr has joined ##OpenGL
[17:00:56] *** tomnewmann has quit IRC
[17:01:03] <Binero> yeah but what's the point of making an XML specification if you don't actually plan for it to make generating external bindings easier
[17:01:14] <Binero> well it does make it easier but
[17:01:19] <Binero> doesn't allow to fully automate it
[17:01:20] *** tomnewmann has joined ##OpenGL
[17:01:41] <Binero> seems like the way to do it is ignore the <types> block and just manually port those
[17:02:46] *** Keniyal has quit IRC
[17:03:45] *** cr`nge has joined ##OpenGL
[17:05:42] *** tomnewmann has quit IRC
[17:05:49] *** tomnewmann has joined ##OpenGL
[17:08:08] *** MLM has joined ##OpenGL
[17:13:47] *** RyanPridgeon has quit IRC
[17:14:18] *** throwthecheese has joined ##OpenGL
[17:14:39] <throwthecheese> What should I use instead of the gl_ values?
[17:15:03] <throwthecheese> I want to write a Cg shader and my default script contains this outdated method
[17:15:05] <Stragus> Your own attributes and varyings
[17:15:34] <throwthecheese> What?
[17:16:27] <Stragus> You can define your own vertex attributes, there's no need to use the legacy predefined ones
[17:16:54] *** SnakeTrailSteve has quit IRC
[17:16:55] <throwthecheese> I need them for lighting
[17:17:28] <throwthecheese> It's gl_LightSource
[17:18:19] <Stragus> You can define your own uniforms, storing whatever light data you want, to replace this
[17:19:42] <throwthecheese> As I'm a noob and my GPU is not powerful, I need this variable
[17:20:47] <Yaniel> you should define it as a uniform
[17:21:10] <throwthecheese> How?
[17:21:28] <Binero> ok I give up on generating safe opengl bindings, I'll just use the unsafe ones that everyone else uses
[17:21:33] <Binero> too much effort
[17:21:34] *** TyrfingMjolnir has joined ##OpenGL
[17:22:51] *** aethersis has joined ##OpenGL
[17:23:30] *** SnakeTrailSteve has joined ##OpenGL
[17:23:56] <aethersis> hi foobaz
[17:24:00] <aethersis> I have a special question for you
[17:24:12] *** RyanPridgeon has joined ##OpenGL
[17:24:17] <aethersis> I saw you watching me on git, so I also watched what you have and this png shrinker thing seems very interesting for me
[17:24:30] <aethersis> could you tell me what it does? PNG is loseless by its nature, so how's that supposed to work?
[17:24:42] <Yaniel> the compression parameters can be tweaked
[17:24:59] <Yaniel> and there is a filter applied to the data before compression, which can be tweaked as well
[17:25:12] <Yaniel> different combinations result in different compressed sizes
[17:25:48] <Yaniel> that is what for example optipng does
[17:26:13] <aethersis> so it's still png that can be opened on any device?!
[17:26:15] <Yaniel> the thing you seem to refer to appears to take the raw image data, simplify it for better compression and compress it again
[17:26:26] <aethersis> can it recompress existing png file?
[17:26:30] <foobaz> yes, my pngs are still regular pngs
[17:26:36] <aethersis> omfg it's ingenious
[17:26:39] <foobaz> it works by changing the color values to be more compressible
[17:26:40] <aethersis> he could make lots of money on it
[17:26:44] <aethersis> incredible
[17:26:45] <foobaz> thanks :)
[17:26:51] <aethersis> foobaz you're a genius
[17:26:56] <aethersis> you just solved a huge problem!
[17:26:58] <Yaniel> I prefer optipng
[17:27:09] <foobaz> this GUI program includes my algorithm: http://pngmini.com/
[17:27:12] <Yaniel> but I suppose in some cases it wouldn't hurt to simplify the image as well
[17:27:24] <aethersis> we make web browser slot games and all sprite atlases are png files because we need alpha
[17:27:29] <aethersis> the greatest problem is large file size
[17:27:42] <Yaniel> well..
[17:27:45] <aethersis> <3<3<3 we are going to use it
[17:27:50] <Yaniel> try: indexed color mode
[17:28:05] <Yaniel> and running it through optipng
[17:28:20] <Yaniel> even without indexing a couple of files I tried shrank by almost 50%
[17:28:44] <foobaz> my algorithm works best on photographic images, it doesn't work well on images with large areas of flat colors, because those are already highly compressible
[17:29:08] <foobaz> and the compression artifacts are more noticeable than JPG because the file format isn't designed for it
[17:30:01] <aethersis> foobaz, do you have a version for linux?
[17:30:02] <aethersis> I
[17:30:06] <aethersis> I;d test it now
[17:30:07] *** Stragus has quit IRC
[17:30:45] <throwthecheese> How do I enable gl_ variables globally?
[17:31:15] <foobaz> yes it runs on linux
[17:32:29] <aethersis> what's that .go thing x
[17:32:29] <aethersis> xD
[17:32:40] <Yaniel> go is a programming language
[17:32:47] <Yaniel> and a board game
[17:33:09] <foobaz> there is a C version in imagealpha at pngmini.com if you prefer
[17:33:14] <throwthecheese> How do I enable gl_ variables globally?
[17:33:42] <Yaniel> throwthecheese: what do you mean by that?
[17:33:53] <Yaniel> you can't just "enable" variables
[17:33:56] <Yaniel> nor uniforms
[17:34:00] <throwthecheese> I can't use gl_LightSource
[17:34:12] <Yaniel> most likely because it is deprecated
[17:34:19] <Yaniel> define your own uniform in its place
[17:34:30] <Yaniel> you can call it for example my_LightSource
[17:34:43] <throwthecheese> Is it a struct?
[17:34:48] <Yaniel> dunno
[17:34:58] <aethersis> foobaz, your program turned out to be super helpful
[17:35:07] <aethersis> it will make everything run few dozen percent faster
[17:35:25] <Yaniel> aethersis: but mah losslessness :(
[17:35:29] <throwthecheese> OK, I have uniform lightsource, how do I continue?
[17:35:38] <aethersis> it's good that it's lossy
[17:35:47] <aethersis> we actually wanted jpeg but it has no alpha
[17:36:10] <Yaniel> just like you would with the gl_ version
[17:36:13] <aethersis> there are some dirty hacks that can kinda enable it but they don't work on every platform and are problematic
[17:36:55] <throwthecheese> I have no experience with GL or CG, just tell me how do I define it
[17:37:14] <aethersis> just read the documentation xD
[17:37:16] <Yaniel> I have never touched CG
[17:39:26] <AbigailBuccaneer> aethersis, i hope you're not planning on using JPG/PNG as compressed texture formats for OpenGL rendering
[17:39:37] <aethersis> no
[17:39:42] <aethersis> it's just css and html5
[17:39:44] <AbigailBuccaneer> phew :P
[17:40:06] *** luxigo has quit IRC
[17:40:50] <aethersis> for opengl I'd rather use JPEG
[17:41:13] <AbigailBuccaneer> noooo! nooooo. trust me you'd rather use a texture format that stays compressed on the GPU
[17:41:26] <throwthecheese> How do I make a light source in Cg?
[17:41:27] <Yaniel> PNG is okay for rendering
[17:41:31] <aethersis> but actually I dunno, anything I do is fully procedural and Im not going to make anything non-procedural
[17:41:37] <Yaniel> just not compressed in GPU memory
[17:41:41] *** Ryp1 has quit IRC
[17:41:48] *** prophile has joined ##OpenGL
[17:42:05] <Yaniel> JPG will cause some artifacts due to its lossiness
[17:42:49] <AbigailBuccaneer> lossiness is fine. being compressed on the GPU is much more important than being lossless when it comes to real-time rendering
[17:42:58] <AbigailBuccaneer> (as long as you're not doing scientific rendering or something, idk)
[17:43:45] <aethersis> I'm doing only scientific shit right now xD
[17:43:55] <aethersis> but I also have a problem I can't overcome because of my lazyness
[17:44:05] <aethersis> I have a working algorithm but I'm too noobish to implement it on glsl
[17:44:25] <Yaniel> throwthecheese: google is your friend on that
[17:45:04] <aethersis> I can't help you with cg, throwthecheese but I can refer yo to doing it in glsl
[17:45:25] <aethersis> there's a book called OpenGL Development Cookbook. It can be downloaded for free from the internet and there are various lighting techniques described
[17:45:36] <aethersis> with nice and simple examples in code without too many uesless wrappers
[17:45:49] <aethersis> the main advantage of this book is that its code is as clean as possible
[17:46:05] <aethersis> much better than the Red Book
[17:46:18] <aethersis> I find red book very overwhelming :<
[17:46:47] <aethersis> In general OpenGL is very hard to begin with for me :( I'd want someone to lead me through it step by step lol
[17:47:13] *** tomnewmann has quit IRC
[17:47:20] *** tomnewmann has joined ##OpenGL
[17:47:32] <AbigailBuccaneer> the thing about learning OpenGL is that people typically learn computer graphics and linear algebra at the same time
[17:48:02] <aethersis> the thing is that I'm already quite familiar with it
[17:48:10] <aethersis> especially with linear algebra and calculus
[17:48:32] <aethersis> sure it helps a lot but the whole OpenGL thing is so huge that I can't see it as a whole yet and I need it to progress
[17:49:25] <aethersis> before I start learning something I like to see all the big blocks it's made of, like there are VAOs, FBOs etc and there are shaders you bind and there's state machine and so on
[17:50:30] <aethersis> what's FBO like? You bind somet texture to it, set this FBO as active, then fragment shader will render to it and then you can reactivate the default framebuffer and display the texture that was previously attached to the FBO?
[17:50:53] <aethersis> does it work like that or I got something wrong?
[17:51:30] <Bloodust> sounds about right
[17:51:35] <AbigailBuccaneer> basically yeah
[17:51:58] <aethersis> phew xD
[17:52:14] <AbigailBuccaneer> i think the shortest definition i can come up with is "a framebuffer specifies the destinations of fragment shader outputs"
[17:52:20] <aethersis> there should be articles that describe things first like that and then go to advanced concepts like how to set them up etc xD
[17:52:28] <aethersis> right
[17:52:35] <aethersis> but you need to bind some texture to FBO, right?
[17:52:48] <aethersis> so when you set this FBO as active, then the image will be rendered to the texture right?
[17:53:07] <AbigailBuccaneer> yes, a framebuffer has textures attached to it, these textures are the fragment shader outputs
[17:53:09] <Yaniel> yes, then the framebuffer specifies that fragment shader output X goes to that textures
[17:53:18] *** tomnewmann has quit IRC
[17:53:29] <aethersis> and once I want to reuse this texture, I need to unbind it and in general I will need 2 textures that will be swapped to for example progressively blur something?
[17:53:32] *** tomnewmann has joined ##OpenGL
[17:54:12] <AbigailBuccaneer> aethersis, you don't need to detach a texture from a framebuffer to sample it in a shader - as long as the framebuffer it's attached to isn't active
[17:54:12] *** tomnewmann has quit IRC
[17:54:25] <aethersis> like this: bind texture A to FBO, render A to B, swap, render B to A, swap, render A to B and so on?
[17:54:27] <AbigailBuccaneer> or, i think, as long as the framebuffer doesn't write to that texture?
[17:54:59] <aethersis> yeah but for blur you need the whole previous state to obtain new state
[17:55:11] <aethersis> and I guess you can't read and write at the same time anyway
[17:56:06] <aethersis> and well, no matter how these FBOs work, I actually need two textures for every value - for previous and current state. That's how my algorithm works
[17:58:10] *** Match has joined ##OpenGL
[18:00:00] *** RyanPridgeon has quit IRC
[18:01:52] <aethersis> can the same texture be bound to two different shader programs?
[18:02:27] *** throwthecheese has quit IRC
[18:02:40] <aethersis> and is FBO related to a single shader or to all active shaders?
[18:03:15] <aethersis> I will explain: I want to make a multipass blur
[18:03:18] <Bloodust> all
[18:03:31] <aethersis> so I'd have to rebind the default framebuffer ?
[18:03:35] <Bloodust> its a global state that is on and affects everything unless you unbind it
[18:03:55] <aethersis> I see
[18:04:20] <aethersis> so I'd have texture A and B and then I bind A to FBO, render, unbind FBO, display, swap and start over?
[18:05:10] <Bloodust> mm m
[18:06:35] <aethersis> awesome! I really start getting it <3
[18:07:14] *** pauldachz has joined ##OpenGL
[18:08:42] <AbigailBuccaneer> aethersis, you should be able to do it with one framebuffer and usage of glDrawBuffers
[18:09:16] <aethersis> you mean one extra and the default one?
[18:09:51] <aethersis> ohwait
[18:09:58] <aethersis> glDrawBuffers just displays content of fbo or what?
[18:10:30] <Bloodust> no
[18:10:31] <AbigailBuccaneer> glDrawBuffers specifies an array of framebuffer attachments that fragment shader outputs will be output to
[18:10:57] <aethersis> oh
[18:11:07] <aethersis> how do I get the current framebuffer? I will need to go back to it xD
[18:11:08] *** TheBunnyZOS has joined ##OpenGL
[18:11:18] <Bloodust> save it on a variable
[18:11:19] <aethersis> and if I lost it, it would be a catastrophe
[18:11:21] <aethersis> how
[18:11:34] <aethersis> is there something like glGetActiveBuffer?
[18:11:43] <Bloodust> what
[18:11:45] *** Biliogadafr has joined ##OpenGL
[18:11:45] <AbigailBuccaneer> for multi-pass blur: you could bind A and B to GL_COLOR_ATTACHMENT0 and GF_COLOR_ATTACHMENT1, use glDrawBuffers to draw only to GL_COLOR_ATTACHMENT0 while you read from texture B and vice versa
[18:11:46] <Bloodust> grr
[18:11:49] <Bloodust> dont use glGets
[18:11:54] <Bloodust> they cause pipelane stall
[18:11:58] <AbigailBuccaneer> and then you don't need to rebind the framebuffer or change the attachments in between passes of the blur
[18:12:22] <aethersis> eee...
[18:12:35] <Bloodust> aethersis whats the command to create a framebuffer object?
[18:12:42] <aethersis> glGenBuffers I guess
[18:12:49] <Bloodust> yeah no
[18:12:55] <Bloodust> glgenframebuffers
[18:13:00] <aethersis> yeah
[18:13:10] <aethersis> Before I start coding I must understand the concept xD
[18:13:11] <Bloodust> see how it takes GLuint* framebuffers as parameter?
[18:13:15] <aethersis> mhm
[18:13:26] <Bloodust> and you call it like GLuint i; glGenFramebuffers(1, &i);
[18:13:35] <Bloodust> the i is where you save the framebuffer
[18:13:48] <Yaniel> the default framebuffer is always framebuffer 0
[18:13:53] <aethersis> ohhhhh thanks yaniel
[18:13:57] <Bloodust> and how do you know which fbo is bound? you look at your damn code
[18:14:02] <aethersis> so this is the one that's bound to screen, right? xD
[18:14:25] <aethersis> oh wait, can I bind any FBO to be displayed to screen?
[18:14:29] <Yaniel> no
[18:14:50] <Yaniel> the default framebuffer is whatever the OS gives you along with your context
[18:14:52] <aethersis> bbl I will read the whole chapter from redbook about textures
[18:14:55] <Yaniel> usually the screen or a window
[18:15:02] <AbigailBuccaneer> as somebody who mainly writes code for iOS, this whole "default framebuffer" business makes me very uncomfortable... :P
[18:15:04] *** CainJacobi has joined ##OpenGL
[18:15:05] <aethersis> it will take about an hour
[18:15:24] <aethersis> otherwise I will kill you with questions xD
[18:15:28] <aethersis> although I think I almost get it
[18:26:17] *** hexagoxel has quit IRC
[18:31:09] *** hahuang61 has quit IRC
[18:32:12] *** cr`nge has quit IRC
[18:33:27] *** erhan_ has quit IRC
[18:36:54] *** realz is now known as pinkie
[18:37:24] *** pinkie is now known as Guest56875
[18:37:30] *** Guest56875 is now known as realz
[18:38:13] *** bjz has quit IRC
[18:38:21] *** bjz has joined ##OpenGL
[18:41:54] *** Misu has joined ##OpenGL
[18:42:37] <AbigailBuccaneer> question: why does glClear use eg. (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT) whereas glInvalidateFramebuffer,glDrawBuffers etc. use eg. { GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1, GL_DEPTH_STENCIL_ATTACHMENT }?
[18:43:34] <AbigailBuccaneer> is that just a historical wrinkle of the API (as glClear existed before framebuffers)?
[18:43:35] <japro> to differentiate the color attachments?
[18:44:02] <AbigailBuccaneer> japro, but why wouldn't i be able to clear one specific attachment instead of all the color attachments?
[18:44:19] <japro> alernatively: cause stuff is weird
[18:44:31] <AbigailBuccaneer> i'm prepared to accept that as the reason
[18:45:03] <japro> well i guess for consistencs glClear should have like GL_COLOR0_BUFFER_BIT etc
[18:45:23] <japro> but i guess they couldn't "fix" that given that Clear is about as old as gl itself?
[18:45:32] <krnlyng> hi, i am working on a touch input plugin for mupen64plus which renders buttons to the screen using GLES, but there is an issue with glide64mk2 (which is one of the graphic plugins for mupen64plus). as soon as i include rendering into my touch plugin glide64mk2 draws only a black screen with nothing on it (the buttons are drawn ontop by my plugin). it works in other plugins like ricevideo. i assume it is because there is some glUseProgram or glBindBuffer or s
[18:45:32] <krnlyng> omething call missing in the draw method of glide64mk2, which functions should i look out for? (i only know very little about GLES, still learning)
[18:46:24] <AbigailBuccaneer> krnlyng, you may have to speak at the level of a graphics developer, not a mupen64plus plugin developer
[18:47:11] <krnlyng> AbigailBuccaneer: sorry i don't quite understand...
[18:47:23] <AbigailBuccaneer> so the graphics plugin... draws the frame to the default framebuffer and then you're expecting to be able to draw straight on top of the existing contents?
[18:47:52] <AbigailBuccaneer> or does it render to a texture which you then render and then render your buttons on top of?
[18:48:03] *** Zupo has quit IRC
[18:48:49] <AbigailBuccaneer> in particular, where does glFinish() / wglSwapBuffers() / whatever get called? do these plugins let you turn v-sync on/off?
[18:49:26] <AbigailBuccaneer> i suspect if a plugin were to be double buffered and you were doing your own drawing after it was finished, you'd end up rendering to the wrong back buffer
[18:50:11] <AbigailBuccaneer> there are tools available that can give a trace of a GL frame - vendor-specific ones from Nvidia and AMD (nsight and CodeXL, i think?) as well as vendor-neutral ones (eg. vogl)
[18:51:36] *** hexagoxel has joined ##OpenGL
[18:51:55] <AbigailBuccaneer> krnlyng, i only just parsed that you're using GLES, in which case presumably the relevant function would be eglSwapBuffers
[18:54:40] *** Zupo has joined ##OpenGL
[18:56:22] *** krnlyng has quit IRC
[18:56:47] *** ShadowIce has joined ##OpenGL
[18:56:58] *** krnlyng has joined ##OpenGL
[18:58:21] <krnlyng> AbigailBuccaneer: i've added a function to the input plugin called RenderCallback which gets called from the core module, right after the callback for on screen text display is called so i suppose i am rendering to the right buffer
[18:58:56] *** aethersis has quit IRC
[18:59:33] <krnlyng> AbigailBuccaneer: the SDL_SwapBuffers function is called from within the graphics plugin
[19:05:45] *** hahuang61 has joined ##OpenGL
[19:09:43] *** Dark_Confidant has quit IRC
[19:09:44] *** Dark_Confidant|m has joined ##OpenGL
[19:13:05] *** MLM has quit IRC
[19:13:45] *** timsche has quit IRC
[19:14:12] *** cr`nge has joined ##OpenGL
[19:15:54] <krnlyng> AbigailBuccaneer: and vsync can be turned on and off via a config file setting, currently i have it turned off
[19:15:55] *** Match has quit IRC
[19:17:19] *** Binero has quit IRC
[19:17:19] *** Sirolf has quit IRC
[19:22:10] *** Alina-malina has quit IRC
[19:23:01] *** BreadProduct_ has joined ##OpenGL
[19:23:09] *** prophile has quit IRC
[19:23:31] *** BreadProduct has quit IRC
[19:23:31] *** BreadProduct_ is now known as BreadProduct
[19:27:05] *** Binero has joined ##OpenGL
[19:29:54] *** shingshang has quit IRC
[19:38:54] *** Alina-malina has joined ##OpenGL
[19:38:55] *** Alina-malina has quit IRC
[19:38:55] *** Alina-malina has joined ##OpenGL
[19:43:08] *** ChrisUK has quit IRC
[19:45:07] *** Madsy has joined ##OpenGL
[19:45:08] *** Madsy has joined ##OpenGL
[19:45:53] *** BreadProduct has quit IRC
[19:47:48] *** Zupoman has joined ##OpenGL
[19:52:21] *** damir__ has joined ##OpenGL
[19:53:41] *** clauswitt has joined ##OpenGL
[19:55:58] *** foreignFunction has joined ##OpenGL
[19:56:58] *** stefkos has joined ##OpenGL
[20:00:51] *** nepgear is now known as shakesoda
[20:03:25] *** TyrfingMjolnir has quit IRC
[20:07:11] *** samrat has quit IRC
[20:09:20] *** samrat has joined ##OpenGL
[20:13:42] *** samrat has quit IRC
[20:14:10] *** Crehl has joined ##OpenGL
[20:16:41] *** bkre_ has joined ##OpenGL
[20:19:37] *** groton has joined ##OpenGL
[20:22:24] *** Misu has quit IRC
[20:22:52] *** Misu has joined ##OpenGL
[20:23:37] *** samrat has joined ##OpenGL
[20:24:43] *** pazul has quit IRC
[20:25:44] *** james4k has joined ##OpenGL
[20:27:40] *** bkre_ has quit IRC
[20:27:46] *** bkre_ has joined ##OpenGL
[20:29:15] *** f0ster has joined ##OpenGL
[20:29:29] <f0ster> Anyone have a recommendation for best way to learn opengl ?
[20:30:25] *** james4k has quit IRC
[20:31:33] *** james4k has joined ##OpenGL
[20:34:14] *** Crehl has quit IRC
[20:34:24] <Bloodust> same as everything else
[20:34:28] <Bloodust> doing it doing it doing it
[20:42:13] *** AbleBacon has joined ##OpenGL
[20:42:21] *** konom has quit IRC
[20:43:43] <AbleBacon> so... i have a whole bunch of triangles and i've mapped all of them to the same triangular piece of texture just to test to see if my texturing works. however, all my triangles appear solid grey (the texture is mostly grey and when i switched it with a mostly red texture, all triangles appeared solid red)
[20:43:58] <AbleBacon> i've tried shrinking down the size of the texture triangle, but they always just appear a solid color
[20:44:45] <AbleBacon> so i guess my question is firstly whether or not it's valid to even do a mapping like that where the geometries might differ significantly, and secondly if there's any obvious mistake i might be making that's causing the solid color
[20:44:56] <AbleBacon> i've tried various kinds of texture filtering like "GL_NEAREST", etc. already
[20:46:48] <f0ster> Bloodust: sounds goo :)
[20:46:58] <derhass> AbleBacon: sounds  like your texcoords don't work
[20:47:13] <f0ster> Bloodust: that's kind of the mantra of life, do work
[20:48:18] <AbleBacon> what do you mean, derhass? i used { {0.0f, 0.0f}, {1.0f, 0.0f}, {1.0f, 1.0f} } to test\
[20:48:45] <AbleBacon> so that's definitely a triangle and, as i understand, even if it's "backwards", the texture should still appear (but backwards)
[20:50:01] <AbleBacon> http://i.imgur.com/LqUEyrF.png
[20:50:22] <derhass> AbleBacon: I mean that there might be something wrong with how those coords end up when the texture is actually sampled
[20:50:41] <AbleBacon> what could cause that?
[20:51:13] <derhass> mistakes when setting up the attribute array, mistakes in forwarding the data to the fragment shader, mistakes in the fragment shader, some invalid state
[20:51:19] <AbleBacon> i have everything in 2D and i've made sure that the vector buffer and UV buffer are always the same size
[20:51:20] <derhass> there are so many possibilities
[20:52:32] <AbleBacon> well, i use the same shader for displaying my FPS counter, so i'm pretty sure at least that part must be correct
[20:53:14] <AbleBacon> but so could "clockwiseness" cause this kind of behavior?
[20:53:25] <derhass> no
[20:53:52] <groton> AbleBacon: show the sources
[20:54:36] <AbleBacon> http://ideone.com/w0OYtK
[20:54:50] <AbleBacon> that's the relevant fragment
[20:55:25] <AbleBacon> i just give every set of 3 vertices the same set of 3 UVs for testing
[20:55:31] *** clauswitt has quit IRC
[20:55:52] <AbleBacon> and i've tried this even with a 4 x 4 pixel texture to make sure it's not just shrinking it down into a solid color or something
[20:57:43] <AbleBacon> it's as though it just takes a single color out of the texture and only uses that
[20:59:25] <Yaniel> tried outputting the uv coords as color yet?
[21:00:12] <groton> AbleBacon: what if you remove your glUseProgram() call?
[21:00:29] *** timsche has joined ##OpenGL
[21:01:03] <AbleBacon> weird... they still appear grey, groton
[21:01:12] <AbleBacon> oh wait nvm
[21:01:20] *** meoblast001 has joined ##OpenGL
[21:01:23] <AbleBacon> yeah, no they're white now
[21:01:31] <AbleBacon> and what do you mean, Yaniel?
[21:01:59] *** petervaro has joined ##OpenGL
[21:02:15] <AbleBacon> this is the fragment shader: http://ideone.com/mI8648
[21:02:41] <groton> AbleBacon: are you calling somewhere: glEnable( GL_TEXTURE_2D ); ?
[21:02:42] <Yaniel> like outColor = vec4(uv.xy, 0.0, 1.0)
[21:03:07] <Yaniel> to verify you aren't getting the same coord for every vertex
[21:03:10] <derhass> groton: don't do that
[21:03:32] <Yaniel> ^ it won't have any effect with shaders and is deprecated anyway
[21:03:40] * groton is ooold :)
[21:03:51] <AbleBacon> how do you read the output from a shader?
[21:04:09] *** Stragus_ has joined ##OpenGL
[21:04:21] *** Stragus_ is now known as Stragus
[21:04:24] <derhass> AbleBacon: you look at the screen
[21:04:33] <derhass> should be very easy in that case
[21:04:52] <AbleBacon> so i give my shader an extra output parameter called "outColor"?
[21:05:03] <derhass> no
[21:05:12] <derhass> you use that with whatever output you have
[21:05:13] <Yaniel> just use whatever your color output is
[21:06:35] <AbleBacon> okay i changed my output to that and the triangles are just white
[21:06:59] <Yaniel> did the shader compile?
[21:07:02] <AbleBacon> yes
[21:07:46] <derhass> AbleBacon: and are you using the program again? you reported white directly before that, for groton's suggestion
[21:07:47] <AbleBacon> i guess i'm just not understanding what that does... instead of outputting a vector of colors i'm outputting a vector of coordinated?
[21:07:49] <AbleBacon> coordinates*
[21:08:12] <derhass> AbleBacon: yes. and it if is all white, it is exactly the problem I mentioned in the beginning
[21:08:19] <derhass> your texcoords are screwed
[21:08:23] <AbleBacon> oh lol i'm a moron
[21:08:26] <AbleBacon> yeah, now they're black
[21:08:38] <derhass> they are still screwed, just differently
[21:09:08] <AbleBacon> so this likely means that it's using the same coordinate all over?
[21:09:19] <urraka> are you using the layout stuff in the shader for the attributes?
[21:09:26] <urraka> i see you hardcoded the locations
[21:09:42] <AbleBacon> i have the texture set as a uniform
[21:10:52] <AbleBacon> oh shit!
[21:10:55] <AbleBacon> i got it working
[21:11:06] <AbleBacon> i disabled the rendering of everything but the asteroids, and now i see the textures
[21:11:13] *** clauswitt has joined ##OpenGL
[21:11:15] <AbleBacon> i guess i used a setting during earlier rendering that screwed it up
[21:11:29] <AbleBacon> heh heh they actually look pretty cool
[21:11:42] *** Ad1_RN has joined ##OpenGL
[21:11:45] <AbleBacon> thanks for the help, guys!!!
[21:11:53] <Bloodust> AbleBacon texture2D function was replaced by texture
[21:12:21] <AbleBacon> in the shader?
[21:12:25] <Bloodust> ye
[21:12:25] <Yaniel> yes
[21:12:27] <AbleBacon> thx
[21:12:33] <Bloodust> it now overloads properly
[21:12:52] *** kuldeepdhaka has quit IRC
[21:13:11] *** Garner has quit IRC
[21:13:41] <AbleBacon> i was rendering the asteroids correctly the whole time... was just rendering something else wrong that was leaving a setting messed up *sigh*
[21:14:56] *** timsche_ has joined ##OpenGL
[21:15:04] *** samrat has quit IRC
[21:15:13] *** timsche_ has quit IRC
[21:15:24] *** timsche_ has joined ##OpenGL
[21:15:35] *** Ad1_RnR has quit IRC
[21:16:05] <AbleBacon> glVertexAttribDivisor() messed it up. hmmm
[21:16:18] *** timsche_ has quit IRC
[21:16:34] <ville> ahh. nothing quite like being screwed over by residual state
[21:16:39] <AbleBacon> setting it back to its proper setting after doing the particles doesn't fix it, though :(
[21:17:15] <AbleBacon> if you enable a vertex attribute, change its divisor, and then disable that vertex attribute, will re-enabling that attribute later but with another attribute pointer... idk what i'm asking
[21:17:38] <Bloodust> AbigailBuccaneer are you not using VAOs ?
[21:17:41] <AbleBacon> i'm using vertex attribute 0 to render some particles... then i disable it and use that same index later (but with different settings) to render other stuff
[21:19:10] *** HunterD has quit IRC
[21:22:22] *** clauswitt has quit IRC
[21:25:47] *** groton has quit IRC
[21:33:12] *** DapperPixpy has joined ##OpenGL
[21:33:25] *** clauswitt has joined ##OpenGL
[21:35:04] *** clauswitt has quit IRC
[21:35:41] *** kuldeepdhaka has joined ##OpenGL
[21:35:45] *** junaidnaseer2 has joined ##OpenGL
[21:36:03] *** clauswitt has joined ##OpenGL
[21:39:33] *** Gamecubic has quit IRC
[21:40:09] *** Gamecubic has joined ##OpenGL
[21:41:27] *** snakenerd has quit IRC
[21:42:22] *** jdolan has quit IRC
[21:42:52] *** jdolan has joined ##OpenGL
[21:43:05] *** MLM has joined ##OpenGL
[21:44:21] *** telex has quit IRC
[21:44:57] *** junaidnaseer2 has quit IRC
[21:46:47] *** telex has joined ##OpenGL
[21:49:29] *** aethersis has joined ##OpenGL
[21:50:32] <aethersis> Does anyone know what mean shift is ?
[21:51:20] <roboman2444> >>:(
[21:51:26] <roboman2444> a mean shift
[21:51:41] <derhass> yeah, it's mean
[21:52:15] <aethersis> mean, liek so cruel
[21:52:16] <aethersis> ?
[21:55:34] <derhass> aethersis: we need more context
[21:55:46] <derhass> aethersis: it might be https://en.wikipedia.org/wiki/Mean-shift
[21:55:50] <aethersis> yes
[21:55:51] <derhass> ore something different
[21:55:59] <aethersis> I need segmentation using mean shift
[21:56:06] <aethersis> actually my friend needs it and I'm trying to help her
[21:57:56] *** Keniyal has joined ##OpenGL
[22:01:39] *** Zeioth has joined ##OpenGL
[22:02:05] *** foreignFunction has quit IRC
[22:04:52] *** centrinia has joined ##OpenGL
[22:05:29] *** linuxuz3r has joined ##OpenGL
[22:08:01] *** konom has joined ##OpenGL
[22:09:26] *** meoblast001 has quit IRC
[22:10:35] *** Garner has joined ##OpenGL
[22:16:00] *** kuldeepdhaka has quit IRC
[22:16:35] *** centrinia has quit IRC
[22:20:26] *** kuldeepdhaka has joined ##OpenGL
[22:26:20] *** jdolan has quit IRC
[22:27:02] *** jdolan has joined ##OpenGL
[22:27:06] *** rosseaux has quit IRC
[22:27:35] *** rosseaux has joined ##OpenGL
[22:28:20] *** rosseaux has quit IRC
[22:28:24] *** Biliogadafr has quit IRC
[22:28:42] *** rosseaux has joined ##OpenGL
[22:31:18] *** martyj-o has joined ##OpenGL
[22:31:27] <martyj-o> Why is there a special "OpenGL ES" branch?
[22:31:33] <martyj-o> How is it different from "main OpenGL"?
[22:31:42] *** jdolan has quit IRC
[22:31:44] <martyj-o> And why does WebGL base itself on this "ES" branch?
[22:32:32] *** rosseaux has quit IRC
[22:33:09] <slime> opengl es exists because embedded GPU hardware typically doesn't have all of the features of desktop GPU hardware, and it also gives a chance to remove some parts of the API that aren't relevant anymore
[22:33:09] <metredigm> AbleBacon: a bit late on the draw, but your VertexAttribPinter calls both use the same pointer offset, when the second one should be (void*) (sizeof(float) * 2)
[22:33:53] <martyj-o> slime: If they aren't relevant, why not just remove it altogether and call it OpenGL <next_version>?
[22:34:12] <metredigm> unless you are doing things with instancing in which case ignore what i just said
[22:34:13] <slime> martyj-o: opengl 3.x did that for a lot of things
[22:34:55] <slime> but the opengl 3.x API also has many features that don't exist on lots of mobile GPUs
[22:35:05] <martyj-o> I have no interest in mobile devices.
[22:35:08] <AbleBacon> i was doing instancing but found that it was screwing up my texturing in a different section
[22:35:13] <slime> martyj-o: then don't use GLES
[22:35:15] <martyj-o> WebGL is used in browsers, though. On real computers.
[22:35:24] <slime> it's also in browsers on mobile devices
[22:35:48] <slime> if you're going to write graphics code meant to run on desktop computers I'd recommend using real OpenGL in a first-class native program
[22:35:49] <martyj-o> So WebGL is intentionally crippled? Can you give an example of something that they chopped off+
[22:35:50] <martyj-o> *?
[22:35:56] <foobaz> geometry shaders
[22:36:00] <metredigm> (compute shaders)
[22:36:13] <foobaz> vertex attribute objects (VAOs)
[22:36:15] <martyj-o> "First-class"?
[22:36:16] <metredigm> tesselation entirely i thank
[22:36:18] <metredigm> *think
[22:36:35] <martyj-o> I used to code C, but never want to do that again. I'm a JavaScript/HTML 5 (Canvas 2D/3D) guy now.
[22:36:37] <slime> martyj-o: yes, a program running in the OS rather than in a browser
[22:36:50] <slime> there are many languages to choose from
[22:36:54] <martyj-o> Will be using this to distribute EXEs: https://github.com/rogerwang/node-webkit
[22:37:03] <foobaz> i write my opengl programs in go
[22:37:11] <metredigm> i write them in brainfuck
[22:37:33] <martyj-o> What is a first-class language?
[22:38:10] <flan3002> Anything outside of a browser could use OpenGL (not ES), provided the correct bindings. Does that qualify?
[22:38:59] *** tehrain has quit IRC
[22:40:37] *** qeed has joined ##OpenGL
[22:41:41] *** Crehl has joined ##OpenGL
[22:43:07] *** RyanPridgeon has joined ##OpenGL
[22:43:46] *** agorecki has joined ##OpenGL
[22:44:23] *** Ad1 has quit IRC
[22:45:08] *** meoblast001 has joined ##OpenGL
[22:45:34] *** bjz has quit IRC
[22:46:23] *** kriskropd has joined ##OpenGL
[22:46:55] *** bjz has joined ##OpenGL
[22:55:54] <AbleBacon> if you guys wanted to draw "thrust" coming out of a rocket in 2D, how would you do it?
[22:56:08] <AbleBacon> or--better example a candle light
[22:56:17] <AbleBacon> like, you know, it flickers and waves around slightly
[22:56:30] <foobaz> particle effects
[22:57:10] <AbleBacon> particle effects still use vertices and UVs, right?
[22:57:25] <AbleBacon> they're just "instanced"
[22:57:33] <foobaz> they still use vertices, but not necessarily UVs or instancing
[22:57:57] <foobaz> you can use procedural colors instead of textures
[22:58:03] <AbleBacon> ah... okay good idea
[22:58:17] <AbleBacon> yes, yes... blue flame in the middle, becoming more red towards the outside
[22:58:24] <foobaz> and while instancing is fast, particle effects were in widespread use before instancing was added to gl
[22:58:34] <bob_twinkles> right, so one of the attributes on the particles could be an age
[22:58:38] <AbleBacon> and then should i just randomly scale it a bit each frame? for the flickering?
[22:58:59] <foobaz> sure that sounds good
[22:59:00] <AbleBacon> would this attribute be stored on the openGL side, or on the C++ side? (since that's what i'm using)
[22:59:13] <bob_twinkles> both
[22:59:25] <AbleBacon> is "age" something i'd pass to the shader?
[22:59:29] <bob_twinkles> yeah
[22:59:40] <bob_twinkles> using glVertexAttribPointer() or something like it probably
[22:59:48] <AbleBacon> hmmmm
[22:59:57] <bob_twinkles> (assuming you're using OpenGL 3.0 and V[AB]Os)
[23:00:31] <bob_twinkles> there are more advanced things you can do like doublebuffering with transform feedback buffers 'n stuff but for a 2d game doing it all on the CPU should be plenty fast enough
[23:01:32] <AbleBacon> yeah--i'm using those
[23:01:46] <AbleBacon> 3.0 and VAOs, that is
[23:02:00] <bob_twinkles> mk, so you should already have most of the code you need
[23:04:04] *** pauldachs has joined ##OpenGL
[23:04:53] *** pauldachz has quit IRC
[23:06:16] *** jophish_ has joined ##OpenGL
[23:06:23] *** pauldachs is now known as pauldachz
[23:06:39] *** jophish_ is now known as Guest80907
[23:06:55] <AbleBacon> now to find a function that defines a candle-light shape
[23:07:54] <foobaz> the hard way would be to model it using fluid dynamics
[23:08:37] <bob_twinkles> you could model it offline and render it with keyframes or something
[23:08:42] <bob_twinkles> that would eat hella memory though
[23:09:01] <bob_twinkles> (well, so would a fullblown fluid dynamics simulation I suppose)
[23:09:18] *** Lemml has quit IRC
[23:10:29] <bob_twinkles> actually, SPH is pretty fast if you feel like spending a bit of time on the implementation =P
[23:11:57] *** zajfy has joined ##OpenGL
[23:12:29] *** Guest80907 has quit IRC
[23:12:38] *** jophish__ has joined ##OpenGL
[23:14:33] <flan3002> Are you talking about 2D fluids?
[23:15:26] <aethersis> WHAT WHER
[23:15:40] <aethersis> ICH BIN FLUID DYNAMICS MEISTER!
[23:16:11] <aethersis> flan3002,
[23:16:16] <aethersis> bob_twinkles,
[23:16:18] <aethersis> what's going on
[23:16:43] <flan3002> aethersis: Meister? Na gut...
[23:16:49] <aethersis> :D
[23:17:29] <bob_twinkles> uh, Able.Bacon wants a flickering candle and foo.baz suggested he could get the particle system to look right by running an online fluid dynamics simulation of the flame particles
[23:17:39] <bob_twinkles> and then I started muttering to myself out loud on the internet
[23:17:53] <aethersis> pfft
[23:17:59] <aethersis> simplest way to make candle is to rig a plane
[23:18:03] <aethersis> make it a sprite
[23:18:06] <aethersis> add some glow shader
[23:18:39] <aethersis> https://www.youtube.com/watch?v=-I8pkm4-ODU&list=UU9JTIEWawv9zzjLqI2JBc9A
[23:18:41] <aethersis> I made this one
[23:19:04] <aethersis> in the way I described, actually it's even simpler, it's specially adjusted random noise
[23:19:14] <aethersis> so that most of it is directed towards top and side
[23:19:23] <aethersis> if you do that smart, it will look very nice
[23:19:31] <aethersis> and more realistic than some particle stuff
[23:19:35] <aethersis> much more realistic
[23:19:56] <aethersis> doing it with CFD is overkill
[23:20:03] *** jophish__ has quit IRC
[23:20:15] *** jophish__ has joined ##OpenGL
[23:21:04] <bob_twinkles> yes, but for a pet project it has the advantage of giving you an opportunity to play with implementing CFD
[23:21:11] *** jophish__ has quit IRC
[23:21:31] <bob_twinkles> though you're right, it's way overkill
[23:22:18] <aethersis> I'm into some crazy realtime CFD now and making candle with it would be really really really stupid
[23:22:25] *** stefkos has quit IRC
[23:22:33] <aethersis> if you do it in a very smart way with the noise animation, it can even handle wind etc
[23:22:59] *** jophish__ has joined ##OpenGL
[23:23:30] *** jophish__ has quit IRC
[23:23:39] *** jophish__ has joined ##OpenGL
[23:25:08] *** anivemin has joined ##OpenGL
[23:25:09] *** snakenerd has joined ##OpenGL
[23:26:45] *** roboman2444 has quit IRC
[23:27:19] *** linuxuz3r has quit IRC
[23:27:30] *** timsche has quit IRC
[23:27:40] <bob_twinkles> I haven't gotten a chance to play with CFD yet unfortunately
[23:27:56] <bob_twinkles> I feel like you could hack wind into an SPH solver though
[23:28:13] <bob_twinkles> of course, it might just destabalize the whole thing
[23:28:37] *** timsche has joined ##OpenGL
[23:32:15] *** snakenerd has quit IRC
[23:34:10] *** razieliyo has quit IRC
[23:34:38] *** Taywee has quit IRC
[23:35:17] <aethersis> no xD
[23:35:23] *** BitPuffin has quit IRC
[23:35:27] *** linuxuz3r has joined ##OpenGL
[23:36:14] <metredigm> pft, he should be using real-time raytracing if he want an on-par effect
[23:36:26] <metredigm> the flames would clearly distort and refract the world behind them
[23:38:48] <bob_twinkles> properly adjusting the index of refraction using an accurate simulation of heat from burning material?
[23:39:15] *** metredigm has quit IRC
[23:40:51] *** Demon_Fox has joined ##OpenGL
[23:41:16] *** roboman2444 has joined ##OpenGL
[23:45:03] *** jdolan has joined ##OpenGL
[23:45:40] *** Zupoman has quit IRC
[23:48:07] *** Binero has quit IRC
[23:49:31] *** zoktar has quit IRC
[23:53:50] *** paperManu has quit IRC
[23:54:43] *** Khlorghaal has joined ##OpenGL
[23:55:29] *** kuldeepdhaka has quit IRC
[23:58:33] *** zoktar has joined ##OpenGL
[23:58:53] *** bjz has quit IRC
[23:59:54] *** losh has quit IRC

   November 10, 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 | >