November 23, 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 23, 2014 [00:00:08] <aethersis> which is the gradient itself[00:01:32] <aethersis> anyone? xD[00:01:36] <aethersis> void256[00:02:42] <void256> I have no idea what you are talking about ... but it looks like calculating an average to me :-)[00:04:03] <aethersis> IT KINDA IS![00:04:11] *** Codex_ has quit IRC[00:04:13] <aethersis> but it's no ordinary average![00:04:56] *** navitsu has quit IRC[00:05:27] *** b4b has joined ##OpenGL[00:05:43] <void256> why not?[00:05:50] <void256> 5 values divided by 5[00:05:53] <void256> :)[00:06:24] <void256> I'm sure you get different blurs by using different filter kernels[00:06:35] <void256> it's like box blur or something?[00:06:39] <derhass> well, you'll get a weighted average than[00:06:39] <aethersis> yes[00:06:44] <aethersis> it's exactly box blurt[00:07:10] <aethersis> gaussian blur is like this (I think) : (2N + 2S + 2W + 2E + NE + NW + SE + SW)/12[00:07:27] <derhass> no[00:07:29] <aethersis> I didn't even understand that until recently[00:07:30] <void256> you could use gauss too - is this maybe used for something else with the same mind blowing potential? =)[00:07:34] <derhass> gaussian blur uses gaussians[00:07:53] <void256> yep, derhass is rigt[00:07:54] <aethersis> I mean the relationship between these matrices and the operation they are actually doing[00:08:12] *** konom has quit IRC[00:08:15] <void256> what you posted is like a very very crude approximation of gauss I think xD[00:08:28] <derhass> depending on the values chosen[00:08:35] <void256> well, actually it even isn't[00:09:11] *** t4nk734 has joined ##OpenGL[00:09:12] *** Tenzin has joined ##OpenGL[00:09:44] <t4nk734> hey can anyone find what's wrong with this vertex shader?[00:09:47] <t4nk734> http://pastebin.com/79ZzueBb[00:09:47] *** RockLee has quit IRC[00:09:52] <void256> http://www.rastergrid.com/blog/wp-content/uploads/2010/09/binomial_coeff2.png[00:10:22] <aethersis> then how come that the kernel matrix I found claimed ot be gaussian blur[00:10:24] <aethersis> hold on[00:10:33] <slime> t4nk734: gl_Position is a vec4[00:10:40] <derhass> void256: pascal would be proud of you[00:10:44] <void256> yes, what slime said[00:10:47] <aethersis> AHAAAAaaaaaaaaaaa!!![00:10:48] <void256> he was too fast[00:10:49] <void256> :>[00:11:13] <aethersis> the matrix is like PDF around the center!!![00:11:15] <aethersis> INGENIOUS!!!![00:11:24] <aethersis> *rubs his eyes*[00:11:28] <void256> aethersis: are you drunk? =)[00:11:32] <aethersis> what the hell am I seeing :o[00:11:38] <aethersis> nono just look![00:11:53] <aethersis> https://en.wikipedia.org/wiki/Gaussian_blur#Sample_Gaussian_matrix[00:12:02] <void256> yep[00:12:07] <void256> doesn't look like your example tho :)[00:12:10] <aethersis> it is two-dimensional probability density function[00:12:16] <void256> >_<[00:12:18] <aethersis> :OOOOOOO[00:12:19] <void256> of course it is[00:12:21] <void256> xD[00:12:21] <aethersis> :OOOOOOO!!!!!!![00:12:25] <aethersis> I UNDERSTAND[00:12:30] <derhass> the whole point of it[00:12:30] <aethersis> IT IS INCREDIBLE[00:12:32] <void256> it's the bell curve thing from mr. gauss[00:12:42] <aethersis> ALL THE MATHEMATICS SPLIT OPEN IN FRONT OF ME[00:12:43] <void256> your mind is blown now?[00:12:45] <void256> ^^[00:12:50] <aethersis> :O[00:12:57] <aethersis> I... I have an enlightenment[00:13:02] <Yaniel> to smithereens, apparently[00:13:04] <aethersis> these convolution matrices... INCREDIBLE[00:13:09] <aethersis> now yes, the integral makes sense[00:13:12] <derhass> void256: seems so. there are all those little brain pieces lying around here[00:13:14] <aethersis> the convolution thing[00:13:15] <aethersis> I SEE IT[00:13:20] <void256> xD @ derhass[00:13:35] <aethersis> it all makes sense~![00:13:47] <void256> do you understand 12 dimensional space time problems now and can visualize them in your brain?[00:13:47] *** jeffroman has quit IRC[00:13:53] <void256> :)[00:14:47] <aethersis> I can[00:14:53] <aethersis> not 12 dimensional[00:14:56] <aethersis> but space-time with ease[00:15:26] <derhass> aethersis: so standard 4d space-time?[00:15:27] <aethersis> all you OpenGL programming guys, you should study maths hard and start describing life with code![00:15:30] <aethersis> yes[00:15:48] <aethersis> one day we will create deus ex machina ![00:15:51] <Yaniel> wait is that fluid simulation essentially a blur pass + a convection pass to move values upwards?[00:15:51] <derhass> aethersis: boooring[00:16:02] <aethersis> Yaniel - kinda[00:16:05] <aethersis> I'm still trying to figure it out[00:16:16] <aethersis> what it does is the del(POSEIDON TRIDENT SYMBOL) xD[00:16:27] <aethersis> scalar field lmao[00:16:29] <aethersis> for diffusion[00:16:38] <aethersis> or for velocity ... what's it called...[00:16:50] <aethersis> yeah for spreading it through viscosity field[00:16:59] <Yaniel> diffusion would indeed make sense to implement as a simple blur[00:17:42] <aethersis> that's what is happening[00:17:44] <t4nk734> slime: why is gl_Position a vec4?[00:17:50] <aethersis> but wtf it's jacobi method, blahblah[00:17:52] <t4nk734> x,y,z and?[00:17:53] <Bloodust> for that .w component[00:17:55] <aethersis> t4nk734, xyzw[00:17:57] <aethersis> quaternion[00:18:02] <t4nk734> what w?[00:18:04] <slime> it's not a quaternion..[00:18:06] <Yaniel> t4nk734: for projection reasons iirc[00:18:07] <Bloodust> haha[00:18:12] <aethersis> xD[00:18:18] <t4nk734> What does w do?[00:18:18] <aethersis> QUATERNION EVIL[00:18:47] <Bloodust> t4nk734 http://stackoverflow.com/questions/2422750/in-opengl-vertex-shaders-what-is-w-and-why-do-i-divide-by-it[00:18:49] <aethersis> who said that quaternions are to complex numbers what complex numbers are for real numbers - I liked it and I think it was someone of you[00:19:01] *** konom has joined ##OpenGL[00:19:37] <foobaz> t4nk734: the w coordinate is complicated, try starting with https://en.wikipedia.org/wiki/Homogeneous_coordinates[00:20:20] <aethersis> foobaz, does it have something to do with vector normalization?[00:20:34] <aethersis> like for affine transformations etc[00:20:46] <foobaz> no, it is for perspective[00:20:48] <aethersis> I've never needed anything 3d in opengl because I've always used it for 2d lmao[00:21:14] <aethersis> but soon I will be hitting 3d very hard and I will die :<[00:21:19] <foobaz> i've written more 2d code too[00:21:21] <derhass> aethersis: well, i need w even for 2d[00:21:31] <foobaz> the math in 3d is a lot harder[00:21:41] <aethersis> the math itself doesn't seem to be a lot harder for me[00:21:46] <t4nk734> um its still not compiling[00:21:50] <aethersis> math is math xD be it 2d , 3d or 4d xD[00:22:03] <slime> t4nk734: what's your new code?[00:22:04] <aethersis> just more to calculate, but what are computers for? xD[00:22:11] <slime> also what does the shader info log say?[00:22:18] <t4nk734> http://pastebin.com/eYKDLjZ3[00:22:38] <aethersis> still, despite my mathematical enlightenment I can't understand this relationship between poisson solver and box blur lol[00:24:11] *** seangrove has quit IRC[00:24:38] <t4nk734> slime?[00:25:11] <foobaz> what does the shader info log say?[00:25:17] <derhass> t4nk734: #version 300 doesn't even exist[00:25:20] <aethersis> *listens to Hallelujah by Handel* xD[00:25:26] <t4nk734> oh[00:25:31] <aethersis> t4nk734, try #version 330 core[00:25:37] <derhass> aethersis: Händel[00:25:50] <aethersis> I don't have this funny a on my keyboard[00:25:56] <aethersis> I know it's HA*&#@$^*#@^4ndel[00:26:27] <aethersis> this stupid thing won't let me sleep[00:26:38] <aethersis> I must revive Jacobi and ask him[00:26:45] <aethersis> WHY DID YOU LEAVE THIS WORLD?![00:27:46] *** staylor_ has quit IRC[00:27:47] <t4nk734> version 330 works[00:27:57] <aethersis> tadaaa! <3[00:27:58] <t4nk734> but the display is just black[00:28:02] <aethersis> oh :([00:28:07] <t4nk734> its not drawing the vbo[00:28:20] <foobaz> aethersis: you don't have to specify core, core is the default[00:28:27] <aethersis> do some gl_getError() or something[00:28:33] *** agorecki has joined ##OpenGL[00:28:38] <aethersis> or gl_checkErrors or what was it called[00:29:10] *** agorecki has quit IRC[00:30:32] <void256> glGetError() is your friend[00:30:53] <Bloodust> not anymore[00:31:03] <aethersis> huh?[00:31:14] <derhass> t4nk734: there are so many things which could lead to a black/empty screen[00:33:47] <bob_twinkles> it's never something entertaining like filling the screen with RGB noise =([00:33:55] <void256> https://www.opengl.org/registry/specs/ARB/debug_output.txt is your friend as well, I guess that was what Bloodust refered to[00:34:02] <bob_twinkles> It's always just black staring at you like "what you expect something to be happening?"[00:34:56] <void256> the death screen of black is one of the most desperate results you can get our of OpenGL, yep :)[00:35:06] <void256> *out[00:35:30] *** DrBenway has quit IRC[00:35:34] <aethersis> have you ever drank beer with tea? xD[00:35:51] <aethersis> void256 no, I got kernel panic once lol[00:36:00] <void256> does that help to understand math and to blow minds? =)[00:36:10] <aethersis> what? teer?[00:36:46] <aethersis> no, it kidna helps me sleep or last longer[00:37:01] <aethersis> for good sleep pure beer is better - porters are the best because they are strong[00:37:14] <aethersis> If I overdo maths, I can't sleep normally so I need some help[00:37:45] <void256> porter & duff?[00:37:47] <void256> =)[00:38:04] <aethersis> what is duff[00:38:10] <aethersis> wait WHAT THE HELL[00:38:15] <aethersis> translate.google.com[00:38:19] <aethersis> lol not this XD[00:38:39] <aethersis> https://en.wikipedia.org/wiki/LU_decomposition THIS! DO YOU SEE IT? IT'S SIERPINSKI'S TRIANGLE USED IN NUMERICAL METHOD![00:39:03] <aethersis> something is haunting me today! First box blur as poisson solver and now sierpinski as matrix determinant! WHAT THE FUCK[00:39:28] <Yaniel> yep[00:39:33] <void256> less beer, more tea[00:39:34] <void256> :>[00:40:11] <Stragus> Someone is doing computational fluid dynamics? :)[00:40:26] *** Lemml has quit IRC[00:40:35] <aethersis> yus[00:40:52] <aethersis> But what the hell? First box blur and poisson solver and now sierpinski's triangle and matrix determinant![00:40:55] <aethersis> THIS IS HAUNTED![00:41:02] <aethersis> Literally![00:41:16] <aethersis> what do these things have in common for gods sake?![00:41:37] <bob_twinkles> solving systems of linear differential equations IIRC[00:41:40] <Stragus> They often "blur" the solution to hide the fact that the linearization to solve numerically creates nasty artefacts[00:42:57] <Stragus> Some well known CFD codes even "blur" whenever pressure or density becomes negative at any point (that is how robust the solution is!)[00:43:39] <aethersis> WHAT THE HELL[00:43:40] <void256> a.k.a. "the gauss conspiracy"[00:43:42] <aethersis> how is th is related?!?!?[00:43:53] <aethersis> what is inside of it ? What fucking devil sits inside?![00:44:06] <aethersis> Give me a hammer and chisel, I want to crack this pandora's box open![00:44:06] *** CainJacobi has joined ##OpenGL[00:44:45] <Stragus> Someone had called Jacobi I believe[00:45:06] <aethersis> I did[00:45:37] <aethersis> I bet that once we break the Riemann's hypothesis it will turn out that there's some algorithm for it based on some blur or fractals or something[00:45:42] <t4nk734> oh man[00:45:47] <Stragus> You should know better than to invoke the deads. He has appeared on IRC for you, who knows what his demands shall be?[00:45:50] <t4nk734> there are no errors[00:45:56] <t4nk734> why is it still black?[00:46:06] <aethersis> WHERE[00:46:10] <aethersis> Jacobi, where are you?[00:46:16] * Stragus points at CainJacobi[00:46:20] <derhass> t4nk734: drawing a black screen doesn't automatically imply gl errors[00:46:24] <aethersis> :OOOOOOOOo[00:46:32] <aethersis> *dies stunned*[00:46:34] <void256> xD[00:46:46] <t4nk734> i am trying to draw a vbo[00:46:57] <bob_twinkles> t4nk734: drivers sometimes just sorta eat errors[00:47:02] <bob_twinkles> do you have a VAO bound?[00:47:03] <t4nk734> do i have to glMatrixMode()?[00:47:09] <t4nk734> yes[00:47:14] <void256> maybe make a glClearColor(1.0, 0.0, 0.0, 1.0) + glClear() before?[00:47:15] <aethersis> cal glGetErrors every line of code xD[00:47:23] <void256> maybe you're rendering black on black :)[00:47:47] <void256> glMatrixMode() good lord? what is this? 18th century? :|[00:47:49] *** DrBenway has joined ##OpenGL[00:48:26] <bob_twinkles> mixing pre-3.0 and 3.0+ code isn't really the greatest thing ever[00:49:03] <Stragus> Maybe his glPolygonStipple() pattern is all blank[00:50:02] *** absof25 has quit IRC[00:51:11] <t4nk734> argh[00:52:06] <void256> black on black?[00:52:08] <void256> =)[00:52:38] *** shintah has quit IRC[00:53:18] <aethersis> https://www.youtube.com/watch?v=pAgnJDJN4VA[00:53:29] <aethersis> back in black![00:53:36] <void256> The uploader has not made this video available in your country.[00:53:42] <aethersis> :<[00:53:51] <t4nk734> no the gl_FragColor is set to white[00:53:59] <aethersis> https://www.youtube.com/watch?v=H8PC1_3fjvs[00:55:44] <bob_twinkles> t4nk734: what sort of values are in your VBO?[00:55:57] <t4nk734> its just 2d vertices[00:56:07] <bob_twinkles> anything outside of NDC range isn't going to get rendered[00:56:07] <t4nk734> no color, texture, normals[00:56:16] <bob_twinkles> (+-1 in x and y)[00:56:26] <bob_twinkles> well it'll get rendered, you just won't see it[00:56:35] <t4nk734> no the vertices are normalized[00:56:45] <t4nk734> floats[00:57:26] <derhass> t4nk734: show your code[00:57:27] <Stragus> printf() all your data to triple-check it really is correct. And verify if you should see it at all with the matrix transformations done[00:57:39] <derhass> t4nk734: it is just guesswork without the code[00:58:24] *** b4b has quit IRC[00:59:25] <t4nk734> this is java[01:00:10] <bob_twinkles> System.out.println() hten[01:00:11] <bob_twinkles> *then[01:00:21] <void256> this[01:00:23] <void256> is[01:00:26] <void256> SPARTAAAAAAAhhh[01:00:26] <t4nk734> http://pastebin.com/eKMjqU50[01:01:37] *** DrBenway has quit IRC[01:01:40] <bob_twinkles> uh, don't hardcode attribute/uniform locations[01:01:49] <aethersis> fuck java[01:01:51] <aethersis> I hate java[01:02:01] <aethersis> java and opengl EWWW[01:02:01] *** snakenerd has joined ##OpenGL[01:02:08] <bob_twinkles> use glGetAttribLocation[01:02:08] <aethersis> DisssGUSTING[01:02:15] <bob_twinkles> java isn't _that_ bad[01:02:49] <derhass> t4nk734: that's not enough[01:02:52] <bob_twinkles> t4nk734: you also need to bind something to GL_ARRAY_BUFFER, not just GL_ELEMENT_ARRAY_BUFFER[01:02:56] <Stragus> True. There's always Brainfuck[01:03:02] <t4nk734> oh[01:03:05] <derhass> bob_twinkles: nope[01:03:22] <bob_twinkles> well ok if you're binding it to the VAO somewhere else you don't[01:03:36] <derhass> t4nk734: the code pasted so far is just inefficient, but not wrong[01:03:41] *** BreadProduct has quit IRC[01:04:07] <derhass> t4nk734: your usage of VAOs is a bit weird. vaos track the attrib enables as well as the element buffer binding[01:05:47] *** Portals has quit IRC[01:06:10] <t4nk734> binding the GL_ARRAY_BUFFER its still black[01:06:57] <Stragus> If you render the *same* geometry with glBegin(), do you see anything?[01:07:07] <Stragus> Just for debugging purposes here...[01:07:22] <t4nk734> you mean immediate mode?[01:07:26] <t4nk734> yeah that works[01:07:55] <t4nk734> derhass: what do you mean weird?[01:08:20] *** Biliogadafr has quit IRC[01:08:31] *** DrBenway has joined ##OpenGL[01:08:34] <derhass> t4nk734: I tried to explain it already[01:08:52] <t4nk734> also why do you have to keep binding and unbinding the arrays and buffers in the loop?[01:09:04] <bob_twinkles> what he's saying is that you don't[01:09:14] <t4nk734> the code is pretty much copied[01:09:25] <Stragus> glEnableVertexAttribArray() should use locations returned by glGetAttribLocation()[01:09:30] <derhass> cargo cult programming for the win![01:09:40] <derhass> Stragus: or the ones assigned[01:10:23] <t4nk734> yeah i am assigning the locations before linking[01:10:28] <t4nk734> the shaders[01:10:36] <Stragus> What's the data type of setupObj.getVboIndexID()? Is it really uint8_t?[01:10:40] <derhass> t4nk734: show the code :)[01:10:41] <Stragus> It's kind of unusual to store indices as 8 bits[01:11:01] <t4nk734> bob_twinkles: so you DON'T have to bind and unbind?[01:11:21] <derhass> t4nk734: gl is a state machine[01:11:24] <Stragus> Whatever was bound stays bound, there is no "unbind"[01:11:40] <derhass> t4nk734: you need to make sure that the correct stuff is bound at the time you need it[01:11:51] *** zzuegg has quit IRC[01:12:14] <t4nk734> unbind meaning bind it to 0[01:12:33] <t4nk734> derhass: which code?[01:12:36] <Stragus> t4nk734, what is the data type of your setupObj.getVboIndexID() pointer?[01:12:39] <derhass> that is a totally useless operation. in core profile at least[01:12:47] <derhass> t4nk734: the vbo and vao setup would be interesting[01:12:58] <derhass> t4nk734: the shader setup also[01:13:42] <t4nk734> i am binding the VAO and the VBO and the indices and enabling the attrib -> drawElements -> bind everything to 0[01:13:52] <derhass> and maybe you have some kind of "gl initialization" function[01:14:21] <derhass> t4nk734: yeah, we have seen that code already[01:14:29] <derhass> t4nk734: it is inefficient, but not wrong[01:14:31] <derhass> per se[01:14:44] *** zzuegg has joined ##OpenGL[01:15:34] <t4nk734> i don't really understand why you have to do that either[01:15:37] *** snakenerd has quit IRC[01:15:46] <t4nk734> i only put that in the loop because most of this code is copied[01:15:58] <Stragus> t4nk734, where is your setupObj code?[01:16:01] <derhass> t4nk734: you don't have to[01:16:20] <t4nk734> i would have thought you just need to bind the buffers once in the init() and unbind and delete them in cleanup()[01:16:46] <Stragus> You would bind a different buffer whenever you want to render something else[01:16:49] *** det has quit IRC[01:17:11] <t4nk734> http://pastebin.com/Gwh09ZJC[01:17:18] *** snakenerd has joined ##OpenGL[01:17:50] <t4nk734> Stragus: yeah i just over simplified[01:18:22] <Stragus> What is the data type of IntBuffer.wrap(objs[0].getSprite().getIndexElements())?[01:18:39] <t4nk734> its a IntBuffer?[01:18:53] <Stragus> "int"? Then why are you specifying GL_UNSIGNED_BYTE to glDrawElements()?[01:19:15] <Stragus> You are telling OpenGL your indices are 8 bits long, uint8_t[01:19:54] <t4nk734> ok so it has to be a bytebuffer?[01:20:18] <Stragus> No, tell OpenGL the proper format for your indices. GL_UNSIGNED_INT would be more like it[01:21:06] <Stragus> No one uses uint8_t to specify vertex indices, a maximum of 256 vertices is... pretty low[01:21:11] *** agorecki has joined ##OpenGL[01:21:22] *** hexagoxel_ has joined ##OpenGL[01:21:23] <t4nk734> i thought i could only be unsigned byte or unsigned short[01:21:34] <Hunts> no[01:21:41] <Stragus> Ah yes, that is true on some (old?) mobile devices[01:21:47] *** Zupoman has quit IRC[01:21:57] *** void256 has quit IRC[01:22:20] *** agorecki has quit IRC[01:23:16] <t4nk734> that didn't do anything[01:23:19] <t4nk734> its still black[01:23:32] <t4nk734> also java only has signed variables[01:24:04] *** aethersis has quit IRC[01:24:39] *** lenarhoyt has joined ##OpenGL[01:24:57] <pink-rg> anyone know what header file glXGetProcAddress() lives in in OSX? the OpenGL framework doesn't seem to have glx.h. Or is there an equivalent function I should be using?[01:25:06] *** hexagoxel has quit IRC[01:25:19] <slime> osx doesn't use X11 or GLX[01:25:20] <Hunts> pink-rg: yeah, you don't use GLX in OS X. GLX is for X11 only[01:25:49] <pink-rg> ok, what function should i be using for retrieving gl extensions then?[01:25:50] <slime> dlopen/dlsym if you really need it, otherwise just link with the framework and use its header[01:26:00] <pink-rg> just static link to library?[01:26:57] <derhass> not really static[01:28:45] <t4nk734> GL_UNSIGNED_INT is not a acceptable arguement for glDrawElements[01:28:50] <t4nk734> https://www.khronos.org/opengles/sdk/docs/man/xhtml/glDrawElements.xml[01:28:53] *** stef has quit IRC[01:29:05] <slime> are you using opengl es?[01:29:06] <Hunts> t4nk734: that's OpenGL ES, it is for OpenGL[01:29:38] *** konom has quit IRC[01:30:34] <t4nk734> no opengl[01:30:48] <Hunts> t4nk734: then you are looking at the wrong documentation[01:30:57] <t4nk734> yeah i just noticed[01:31:01] *** stef has joined ##OpenGL[01:31:30] *** asdtrfygjhknklm1 has joined ##OpenGL[01:32:20] <t4nk734> its still black i cant figure it out[01:33:31] <Stragus> What's the equivalent immediate code that works?[01:33:55] *** seangrove has joined ##OpenGL[01:35:28] *** Zupo has quit IRC[01:35:34] *** Zupo has joined ##OpenGL[01:37:41] *** devbug has joined ##OpenGL[01:38:25] <t4nk734> Stragus: i did manage to get VBO working with this code[01:38:35] <t4nk734> http://wiki.lwjgl.org/index.php?title=The_Quad_textured[01:39:06] <t4nk734> and also this http://www.lwjgl.org/guide[01:39:25] *** TGYoshi has quit IRC[01:39:30] <t4nk734> because the former is a bit outdated its for lwjgl2[01:40:05] <t4nk734> If it would only give some kind of error[01:41:06] *** konom has joined ##OpenGL[01:42:16] *** wreed has joined ##OpenGL[01:47:09] *** BitPuffin has quit IRC[01:49:25] <t4nk734> All this just to draw 2 triangles[01:49:36] <t4nk734> not even textured[01:51:07] *** Mango_Man has joined ##OpenGL[01:53:31] <t4nk734> I can't believe this isn't working[01:54:51] *** asdtrfygjhknklm1 has left ##OpenGL[01:56:05] *** BreadProduct has joined ##OpenGL[01:56:24] *** derhass_ has joined ##OpenGL[01:57:32] <t4nk734> anyone have any ideas what might be wrong?[01:57:45] <slime> I don't see any glUseProgram in your code[01:58:24] <slime> (or where you draw things, for that matter)[01:58:25] *** det has joined ##OpenGL[01:59:32] *** derhass has quit IRC[02:00:59] *** SpicyShibe has joined ##OpenGL[02:02:43] <t4nk734> slime i posted that code somewhere before[02:03:00] <t4nk734> scroll up?[02:03:29] *** seangrove has quit IRC[02:04:18] <t4nk734> slime http://pastebin.com/eKMjqU50[02:05:20] *** telex has quit IRC[02:06:07] <slime> reduce the possibilities for problems by removing your abstractions and unneeded code like the unbinding and the buffer binding after binding the VAO[02:06:40] *** telex has joined ##OpenGL[02:06:47] *** erhan_ has quit IRC[02:08:26] *** wreed has quit IRC[02:09:48] *** hexagoxel_ has quit IRC[02:21:19] *** SleekoNiko has quit IRC[02:23:08] *** MLM has quit IRC[02:27:04] <t4nk734> slime do i have to do glEnableClientState?[02:27:07] *** bb010g has quit IRC[02:27:36] <slime> no, that's the old deprecated equivalent of glEnableVertexAttribArray[02:30:25] *** Burga has joined ##OpenGL[02:30:51] *** bkre_ has quit IRC[02:33:41] *** SleekoNiko has joined ##OpenGL[02:35:16] *** Burga has quit IRC[02:38:21] *** mizux has quit IRC[02:41:58] *** BearishMushroom has joined ##OpenGL[02:47:27] *** BreadProduct_ has joined ##OpenGL[02:48:23] *** BearishMushroom has quit IRC[02:50:04] *** paperManu_ has joined ##OpenGL[02:50:12] *** Ad1 has quit IRC[02:50:30] *** BreadProduct has quit IRC[02:50:44] *** BreadProduct_ is now known as BreadProduct[02:51:24] *** wreed has joined ##OpenGL[03:01:15] *** xissburg has joined ##OpenGL[03:07:28] *** b4b has joined ##OpenGL[03:08:54] *** foreignFunction has quit IRC[03:13:17] *** centrinia has quit IRC[03:14:53] *** Mango_Man has quit IRC[03:18:30] *** Yaniel has quit IRC[03:19:14] *** wreed has quit IRC[03:20:34] *** centrinia has joined ##OpenGL[03:21:30] *** Jubb has quit IRC[03:23:14] *** Garner has quit IRC[03:24:52] *** robot-beethoven has joined ##OpenGL[03:29:39] *** Yaniel has joined ##OpenGL[03:29:54] *** jdolan has joined ##OpenGL[03:32:58] *** Mango_Man has joined ##OpenGL[03:34:24] *** Mango_Man has quit IRC[03:35:06] *** manny- has quit IRC[03:40:19] *** devbug_ has joined ##OpenGL[03:40:42] *** manny- has joined ##OpenGL[03:40:54] *** roboman2444 has joined ##OpenGL[03:43:54] *** devbug has quit IRC[03:48:34] *** Crehl has quit IRC[03:49:17] *** HuntsMan2 has joined ##OpenGL[03:53:05] *** Hunts has quit IRC[03:55:06] *** Misu has quit IRC[04:00:49] *** Jubb has joined ##OpenGL[04:02:19] *** linuxuz3r has joined ##OpenGL[04:07:04] *** jdolan has quit IRC[04:09:54] *** bjz has quit IRC[04:10:07] *** bjz has joined ##OpenGL[04:14:11] *** urraka has quit IRC[04:14:36] *** DolpheenDream has joined ##OpenGL[04:18:25] *** jdolan has joined ##OpenGL[04:22:42] *** LifeBlood has joined ##OpenGL[04:22:53] *** jdolan has quit IRC[04:25:33] *** qeed has quit IRC[04:27:59] *** tcsc has quit IRC[04:37:34] *** shingshang has joined ##OpenGL[04:41:06] *** garFF_ has quit IRC[04:45:05] *** samrat has joined ##OpenGL[04:46:36] *** linuxuz3r has quit IRC[04:57:39] *** Cabanossi has quit IRC[04:58:40] *** Cabanossi has joined ##OpenGL[05:06:31] *** lenarhoyt has quit IRC[05:07:11] *** bb010g has joined ##OpenGL[05:10:42] *** Khlorghaal has quit IRC[05:15:28] *** meoblast001 has joined ##OpenGL[05:19:15] *** jdolan has joined ##OpenGL[05:21:17] *** xissburg_ has joined ##OpenGL[05:23:54] *** jdolan has quit IRC[05:23:54] *** xissburg has quit IRC[05:27:52] *** t4nk734 has quit IRC[05:29:54] *** Demon_Fox has joined ##OpenGL[05:29:58] *** XCVB has quit IRC[05:33:12] *** paperManu_ has quit IRC[05:43:17] *** Alina-malina has quit IRC[05:44:00] *** Alina-malina has joined ##OpenGL[05:44:00] *** Alina-malina has joined ##OpenGL[05:48:05] *** Rifuli has joined ##OpenGL[05:48:26] <Rifuli> I'm having trouble using GLM's extended functionality, in particular glm::linearRand(min,max)[05:48:35] <Rifuli> I can use other extended functionality for matrices and such, but glm/gtc/random.hpp gives me build issues (unresolved external symbols)[05:56:05] *** samrat has quit IRC[06:05:27] *** samrat has joined ##OpenGL[06:12:52] *** Polarina has quit IRC[06:14:38] *** Polarina has joined ##OpenGL[06:15:57] *** Zerflag has joined ##OpenGL[06:24:02] *** b4b has quit IRC[06:29:50] *** garFF has joined ##OpenGL[06:34:44] *** garFF has quit IRC[06:35:29] *** Tenzin has quit IRC[06:50:01] *** DolpheenDream has quit IRC[06:50:27] *** wikiemol has joined ##OpenGL[06:54:11] <wikiemol> Hello. I am relatively new to OpenGL, and I have a question. Is it possible to tell the fragment shader not to draw the fragment if certain conditions are met?[06:55:11] <Rifuli> Yes, use discard.[06:55:14] <cmr> wikiemol: there's the `discard` statement, but I'm not sure how it interacts with divergence rules.[06:55:36] <Rifuli> Also, you want to avoid as much as possible the use of conditional statements in a shader[06:56:06] <wikiemol> Why would I want to avoid using conditional statements in a shader?[06:56:21] <Rifuli> because the GPU doesn't compute them as fast as the CPU can[06:56:35] <wikiemol> Oh thats interesting, thanks[06:56:47] <cmr> wikiemol: http://tangentvector.wordpress.com/2013/04/12/a-digression-on-divergence/[06:56:56] <Rifuli> Think of it like "the GPU wants to process this pixel now, but first it has to work out this statement and while its doing that, its not rendering the pixel"[06:57:06] <Stragus> Small conditional statements are okay, but keep them simple[06:57:13] <Rifuli> ^[06:59:00] <wikiemol> Well doesn't that go for any processor intensive procedure that happens before setting the frag color?[06:59:31] <Stragus> I'm not following the question[07:00:22] <wikiemol> I was referring to what Rifuli said[07:01:18] <Rifuli> It does, if the shader has to wait on it. But I was simply trying to explain it in laymans terms.[07:01:22] *** Wagoo has quit IRC[07:01:51] <Rifuli> I don't actually know the intricacies behind it, I just do what I'm told :P[07:01:57] <Stragus> Real-world example, if you have: if(a){ BigStuff(); } else { OtherBigStuff(); } and fragments can take either path randomly, it's going to be twice as slow as doing any of the two branches[07:02:35] <wikiemol> Oooh I understand[07:03:50] <Stragus> On Nvidia hardware though, if all your fragments in a warp (group of 32) go down the same path, only the path taken will be processed[07:04:15] <wikiemol> So because the GPU waits for all processes to finish, the fragments that will do Biggest stuff will slow down the ones doing the faster stuff?[07:04:38] *** CainJacobi has quit IRC[07:04:46] <Stragus> In a warp (32 threads), the threads not taking a branch wait for the other threads to finish before they can all continue together[07:05:34] <wikiemol> Ah okay that makes sense[07:05:36] <wikiemol> thanks[07:07:44] *** Voidwalkr has joined ##OpenGL[07:08:03] *** linuxuz3r has joined ##OpenGL[07:08:33] *** jdolan has joined ##OpenGL[07:09:52] *** Rifuli has quit IRC[07:12:05] *** xissburg_ has quit IRC[07:14:31] *** jdolan has quit IRC[07:20:00] *** slidercrank has joined ##OpenGL[07:24:28] *** Keniyal has joined ##OpenGL[07:30:26] *** wikiemol has quit IRC[07:31:17] *** meoblast001 has quit IRC[07:45:14] *** Axord has joined ##OpenGL[07:46:18] *** AnAsian has joined ##OpenGL[07:46:26] *** Axord has left ##OpenGL[07:47:52] *** samrat has quit IRC[07:48:32] *** bjz has quit IRC[07:48:39] *** bjz_ has joined ##OpenGL[07:50:24] *** Gamecubic has quit IRC[07:55:40] *** samrat has joined ##OpenGL[08:01:50] *** japro has quit IRC[08:01:51] *** Dragonkeeper has joined ##OpenGL[08:02:01] <Dragonkeeper> hello[08:03:09] *** jbud has quit IRC[08:03:34] *** Zerflag has quit IRC[08:07:53] *** konom has quit IRC[08:09:55] *** Zupo has quit IRC[08:10:18] *** Zupo has joined ##OpenGL[08:10:19] *** Polarina has quit IRC[08:10:31] *** zajfy has joined ##OpenGL[08:12:15] *** Lemml has joined ##OpenGL[08:14:54] *** Zupo has quit IRC[08:15:08] *** Dragonkeeper has left ##OpenGL[08:18:37] *** garFF has joined ##OpenGL[08:22:58] *** garFF has quit IRC[08:23:17] <hdon> hi all :) i'm using OpenGL 3.3.. can i use the old VAOs with the programmable rendering pipeline? IIRC what they do, they contain information specified by the likes of glEnableVertexAttribArray() and glVertexAttribPointer(). am i on the scent?[08:24:18] <hdon> but when i last used them, i was using stuff like glColorPointer() or something like that[08:24:21] <roboman2444> hdon, VAOs were introduced in gl3[08:24:28] <hdon> oh[08:24:31] <roboman2444> it would be weird if you didnt use em[08:26:03] <hdon> i'm not. so i guess it is weird. right now, every time i draw, i UseProgram, then bind my GL_ARRAY_BUFFER, probably also GL_ARRAY_ELEMENT_BUFFER, and then set up a bunch of vertex attributes with glEnableVertexAttribArray() and glVertexAttribPointer()[08:26:20] <hdon> and then end with glDrawArrays() or glDrawElements()[08:26:38] <hdon> can or should i be wrapping up any of this work in a VAO?[08:27:37] <roboman2444> Yeah, all the vertexAttrib stuff and binding buffers is handled by a vao[08:28:20] *** Polarina has joined ##OpenGL[08:28:34] <hdon> hmm... thanks roboman2444[08:32:06] <hdon> hmm... i don't suppose VAOs can inherit attributes from each other...[08:32:33] <cmr> hdon: no, they cannot[08:32:41] <hdon> no way to copy a VAO?[08:32:53] <cmr> no[08:33:03] <roboman2444> why would you?[08:33:43] <hdon> well a lot of info about my models is specific to the class of model, and then only some of it (the actual GL_ARRAY_BUFFER data) is specific to instances of models[08:34:30] <roboman2444> so... make multiple vaos[08:34:34] <hdon> is there any harm in binding a VAO and then changing the GL_ARRAY_BUFFER before drawing? or should i just have a different VAO for each?[08:34:48] <roboman2444> different VAO for each model usually works well, IMO[08:34:53] <hdon> mmm..[08:37:02] <hdon> is shader program also part of VAO state?[08:37:11] <roboman2444> im guessing modern drivers have some optimization for switching between VAOs, rather than manually switching vertex attribs manually[08:37:14] <roboman2444> no[08:37:16] <roboman2444> shader is seperate[08:37:20] <hdon> ah ok[08:37:27] <roboman2444> as well as texture, framebuffer, blending, etc[08:37:34] <hdon> if shader is separate...[08:38:05] <hdon> i mean, you can uniquely identify a vertex attribute with respect to a specific shader program, by the numeric name given to you by GetAttribLocation[08:38:26] <hdon> those attribute locations seem to be part of the VAO state, yet the program is not?[08:38:29] <roboman2444> no[08:38:40] <hdon> no to which part? :)[08:39:02] <roboman2444> you manually set them usually in the shader[08:39:08] <roboman2444> well, in your shader compiling code[08:39:35] <roboman2444> glBindAttribLocation(programid, POSATTRIBLOC, "posattrib"); something like that[08:39:54] <roboman2444> where POSATTRIBLOC is 0[08:40:05] <roboman2444> same as when you do your vertex attrib calls[08:40:28] <hdon> oh[08:40:31] <roboman2444> i have pos data on 0, norm data on 1, texcoord data on 2, etc[08:40:56] <hdon> so instead of asking OpenGL to assign a "location" to my vertex attributes, i specify it myself[08:41:03] <roboman2444> yeah, usually[08:41:14] <hdon> mmm... i haven't been doing that[08:41:19] <roboman2444> then you can manually keep track of things[08:41:30] <roboman2444> good to have a global rule for all your stuff[08:41:39] * hdon nods[08:41:51] <roboman2444> general position data gets put in 0, general surface normal info gets put in 1, general texture info in 2, etc[08:42:08] *** LifeBlood has quit IRC[08:42:13] <hdon> is there any requirement to make these locations contiguous?[08:42:29] <roboman2444> i think there is a limit of number of them[08:42:38] <roboman2444> but i dont think you need to make them contiguous[08:42:45] <hdon> mm.. ok[08:42:46] *** Shockk has joined ##OpenGL[08:42:57] <hdon> thanks for the information roboman2444. i've learned some interesting new things![08:43:07] <roboman2444> (the limit should be over 8 though, so that is 32 total floats of data per vert)[08:43:15] *** linuxuz3r has quit IRC[08:43:54] <roboman2444> you can query that with glGetIntegerv(GL_MAX_VERTEX_ATTRIBS, &SOMEINT);[08:44:01] <hdon> oh... right i think i remember something about this... each location can only be 4 floats?[08:44:05] <roboman2444> apparently on an 8800gtx its 16[08:44:15] <roboman2444> hdon, each location can be up to a vec4[08:44:23] <hdon> and a mat4 requires 4 locations?[08:44:25] <roboman2444> you can shove vec3s, vec2s, etc if you need[08:44:33] <roboman2444> yes, mat4 requires 4 location[08:44:45] <roboman2444> but there is not many times when you need to have a matrix per vertex[08:44:50] * hdon nods[08:44:58] <roboman2444> just use uniforms or uniform buffers for that[08:45:00] <hdon> are uniforms part of VAO state?[08:45:05] <roboman2444> no[08:45:12] <roboman2444> i dont think uniform buffers are either[08:45:16] <roboman2444> although i am unsure[08:45:26] <roboman2444> but uniforms specifically are shader state[08:45:57] <Shockk> hello, I have.. kind of a weird question ; does GLSL have any language semantics, apart from lines beginning with # like #version etc, that would make it impossible to safely strip whitespace from shader source?[08:46:17] <roboman2444> probably not, it is very similar to c syntax[08:46:19] <hdon> Shockk, that would be syntax, not semantics[08:46:32] <Shockk> hdon: ah, apologies[08:46:34] <roboman2444> try it and experiment[08:48:07] *** Burga has joined ##OpenGL[08:48:25] <Shockk> I looked through some shaders I wrote over the last year and couldn't immediately see any cases, just wondered if there might be any edge cases I'd encounter that might rely on whitespace[08:48:26] <hdon> roboman2444, does it matter what order i bind in? BindVertexArray vs. UseProgram?[08:48:41] <roboman2444> no[08:48:44] <roboman2444> they are seperate[08:48:48] <hdon> thanks roboman2444[08:49:26] <roboman2444> you might want to look into making your own state manager[08:49:41] <roboman2444> makes debugging a lot easier and improves performance a bit[08:49:58] <roboman2444> https://github.com/roboman2444/enaengine/blob/master/glstates.c something like this[08:50:10] <roboman2444> (and its accompanying .h file)[08:50:34] *** devbug_ has quit IRC[08:50:52] *** devbug has joined ##OpenGL[08:53:37] <hdon> roboman2444, i believe it is an opengl error condition if i call glVertexAttribPointer() with an attrib location that does not name any vertex attribute in the current shader program.. if that's correct, how does this change with VAOs? does the error wait until i actually draw to show itself? or is it no longer an error condition and silently ignored?[08:54:03] <roboman2444> do you enable the vertex attrib?[08:54:16] <roboman2444> glEnableVertexAttribArray(TANGENTATTRIBLOC);[08:54:18] <edwardk> roboman2444: amused to see that that still is the case. (tuning back into opengl after a ~15 year hiatus)[08:54:21] <hdon> this is from memory... i assume so[08:54:30] <roboman2444> its more likely its throwing an error from that[08:54:34] <hdon> or it's possible that i am wrong here, and what is actually invalid is giving a vertex attrib location of -1[08:54:39] <roboman2444> i dont think it cares about current shader[08:55:25] <hdon> yeah i think it is the -1 that is invalid... it says the VertexAttribPointer 'index' argument is unsigned, and it also says[08:55:27] <hdon> >GL_INVALID_VALUE is generated if index is greater than or equal to GL_MAX_VERTEX_ATTRIBS.[08:55:45] <edwardk> Am i correct in understanding that trying to work with parts of an array of structs as a uniform, not a uniform block is just broken?[08:55:45] <roboman2444> might be[08:56:13] <hdon> so i think what was happening to me in the past was, i was asking opengl to automatically assign a vertex attribute location with glGetAttribLocation() and it was giving me -1[08:56:16] <edwardk> as in no way to ask for the location of the element parts[08:57:13] <hdon> i'm not an expert, but i feel almost competent, and i have no idea what you're talking about edwardk :([08:57:26] <edwardk> hdon: if i make a struct in glsl[08:57:47] <edwardk> e.g. struct Camera { mat4 projection; mat4 modelView; float fovy, aspectRatio, near, far; }[08:57:48] <edwardk> extc[08:57:50] <edwardk> etc[08:57:53] <edwardk> then i go to make[08:58:05] <edwardk> uniform Camera viewportCameras[MAX_CAMERAS];[08:58:22] <edwardk> i do not appear to be able to ask for the uniform location of viewportCameras[0].projection and the like[08:58:44] <hdon> oh, i think i ran into this when writing some lighting shader code...[08:59:02] <edwardk> i can switch to a uniform block i guess, but that means i have to write all that plumbing[08:59:21] <edwardk> i'm currently basically rebuilding all the haskell code for talking to opengl from scratch, so i haven't gotten there yet[08:59:56] <edwardk> i theoretically have raw bindings to the uniform block stuff in http://hackage.haskell.org/package/gl but i don't have a pretty bow on it yet[09:00:20] <hdon> edenist, this page might be useful. https://www.opengl.org/wiki/Layout_Qualifier_%28GLSL%29[09:00:25] <hdon> sorry i meant edwardk ^[09:00:28] <roboman2444> generally its easier to use opengl with C and C derivives[09:00:32] *** jdolan has joined ##OpenGL[09:00:36] <roboman2444> derivatives[09:01:30] <edwardk> roboman2444: sure. i've been there. i pretty much spent all of the 90s writing game engines in the like[09:01:39] <edwardk> but i've moved on to nicer tools these days[09:01:56] <hdon> edwardk, you might be able to, instead of struct Foo { mat4 bar; mat4 baz; } Foo[MAX_FOOS] foos;[09:02:11] <hdon> edwardk, something like Foo { mat4 bar[4]; mat4 baz[4]; Foo foos;[09:02:19] <hdon> edwardk, if your original approach is giving you problems[09:02:36] <hdon> edwardk, that would require a little subscript arithmetic if you needed indexed arrays within your struct to begin with, though[09:02:42] <edwardk> so i spent a couple of weeks fixing up bindings to gl for haskell, got to the point where we have usable sdl2 bindings and have been exploring how to abuse my fragment shaders to do signed distance field tracing[09:02:50] <edwardk> hdon: thats pretty much what i've done[09:03:12] <hdon> edwardk, ooh... further down the page[09:03:23] <edwardk> i'm going to probably revert to the array of structs from the struct of arrays once i get Uniform block stuff in[09:03:57] <hdon> edwardk, it shows an example: struct Thingy { vec4 an_array[3]; int foo; }; layout(locatino=2) uniform Thingy some_thingies[6]; // Each Thingy takes up 4 uniform locations; the first three going to an_array and the fourth going to foo. Thus some_thingies takes up 24 uniform locatinos.[09:03:57] <Shockk> edwardk: sounds interesting, are the usable sdl2 bindings available somewhere?[09:03:57] *** Zerflag has joined ##OpenGL[09:04:17] <edwardk> interesting[09:04:39] *** ShadowIce has joined ##OpenGL[09:04:51] <edwardk> Shockk: http://hackage.haskell.org/package/sdl2 the #haskell-game folks have been rather actively barn-raising improving the status of our tools there[09:05:04] <edwardk> hdon: neat[09:05:08] <Shockk> oh I see, thanks[09:05:57] <edwardk> i have the basic sdf renderer / shader toy harness working, which is pretty boring. https://github.com/ekmett/quine (screen shots are sexy, but they are mostly modified shader toys)[09:06:18] <edwardk> been off working on lots of plumbing for the next stage[09:06:38] *** jdolan has quit IRC[09:07:09] <edwardk> got bored and decided to go stomp around in graphics again[09:07:23] <edwardk> hdon: that may be enough to fix me[09:07:40] <edwardk> i just have to calculate offsets by hand[09:07:51] <hdon> edwardk, i ran into the same problem writing lighting code... i'm curious though, do you actually have a shader program that uses multiple "cameras?"[09:09:02] <edwardk> hdon: i have a vertex shader that does nothing a geometry shader that uses multiple invocations and takes the invocation id to split out to different gl_ViewportIndex selections, each gl_ViewportIndex is associated with a different camera[09:09:46] <edwardk> the primary use is that i'm spheretracing right now, so i'm looking at rendering to two portions of the same frame buffer, basically i'm on a retina display so 2560x1600 is a bit much to raytrace in realtime, but i can do 2x 1280x800 pretty easily[09:09:48] <hdon> edwardk, fascinating... my OpenGL is too old for geometry shaders... are you rendering to multiple displays? or doing stereo vision?[09:09:55] <hdon> ohh i see[09:09:55] <edwardk> so doing two of those buffers stacked on top of each other[09:10:24] <edwardk> then i can build a shader that will do the final compositing of those to get a "low resolution" fringe around a retina core[09:10:35] <hdon> i assume that this approach buys you some performance gain?[09:10:51] <edwardk> that'll give me about half the rays and full retina for a 1280x800 display, with some low resolution peripheral vision[09:10:55] <edwardk> basically a 'fovea' to my retina[09:11:25] <edwardk> and i figure if i need a way to clamp my frame rate, i can foveate again, run 3 screens stacked in the intermediate framebuffer, and foveate a second time[09:11:25] <hdon> i don't really understand what the retina display is, i just figured it was apple hype and new proprietary technology to get devs to invest in their brand more...[09:11:29] <edwardk> pushing a 1/4th of the rays[09:11:40] <edwardk> retina is just 2560x1600[09:11:43] <edwardk> its all[09:11:46] <edwardk> its just a lot of pixels[09:11:46] <hdon> oh, lol[09:11:48] <hdon> ok[09:11:54] <slime> well, it's not a specific number of pixels[09:11:57] <edwardk> and a crappy intel 4000 graphics card to push it[09:11:59] <edwardk> i mean in this case[09:12:00] <hdon> someone told me it had different pixel composition..[09:12:09] <hdon> per color component[09:12:13] <edwardk> its all about exceeding some magic DPI number they like based on view distance, etc.[09:12:16] <hdon> different arrangement or something[09:12:28] <edwardk> but here my concern is that i have too many pixels to raymarch all at once[09:12:32] <hdon> oh, thanks slime[09:12:47] * hdon nods[09:12:49] *** Twinklebear has quit IRC[09:13:34] <edwardk> 'retina' on the iphone was when they doubled the # of pixels to get 300ppi or whatever, and then on the 15" MBP it was 2880xwhatever and on the 13" MBP it was 2560x1600, so in general its 'a lot of pixels compared to the power of the hardware driving it'[09:13:35] <edwardk> =)[09:14:24] <edwardk> when you add all the annoying things apple likes to do to force you into a pipeline to sync with the rest of the desktop i have code that can push at least logically 4200 frames per second on nvidia, that cries trying to get over 50fps on the mac[09:14:27] <hdon> hmm... well i'm sure it works well for hardware video decoders... apple likes selling tv/movies[09:15:14] <hdon> it sounds like GPU vendors will need to make a line of chipsets just for these huge displays that emphasize fill rate...[09:15:29] <hdon> or not, idk[09:15:55] <dahlia> mmmmm moar pixels nom nom nom[09:16:07] <edwardk> the main thing i'm playing with right now is signed distance field rendering, particularly rendering lots of little signed distance fields and coming up with tricks to use pre-sampled grid imposters for them for lighting purposes[09:16:19] <edwardk> so i kinda chose precisely the wrong laptop to prototype on ;)[09:17:10] <dahlia> I'd like to learn how to do SDF. edwardk can you recommend any good web resources?[09:17:27] <edwardk> dahlia: good question, inigo quilez has some excellent tutorials[09:17:41] <dahlia> ah ok ya I was peeking at his site[09:17:43] <slime> edwardk: retina is opt-in for NSOpenGL contexts[09:18:10] *** stefkos has joined ##OpenGL[09:18:40] <edwardk> slime: sure, but even when you don't turn it on, e.g. by not requesting HighDPI through SDL2, the OS compositor winds up blitting up to that nice big screen for you and likes to clamp you even when you try to turn off vsync, etc.[09:18:45] <slime> or rather, for views with opengl surfaces[09:19:03] *** glYoda has quit IRC[09:19:08] <edwardk> slime: i can ask SDL2 to go fullscreen 'for real' rather than at desktop resolution[09:19:14] *** glYoda has joined ##OpenGL[09:19:22] <edwardk> and that makes a rather massive difference in display rate[09:19:49] <edwardk> but then you run into bugs in both glfw-b and sdl2[09:20:12] <edwardk> both screw up and lie to you about the pixel counts on retina displays and then hide the actual native window you need to ask for the real conversion ratio[09:20:34] <edwardk> and worse sdl2 still has a big where you can't 'un-fullscreen' a 'native resolution window[09:20:38] <edwardk> so nobody uses it[09:20:43] <slime> they don't, they report the low-level display mode sizes[09:21:20] <edwardk> slime: exactly, opengl wants all its viewport info in the high resolution display sizes, but SDL2 reports the 'logical pixel size'[09:21:29] <edwardk> so its rather precisely the opposite of that[09:21:52] <slime> it reports the pixel resolutions, rather than resolutions in the 'points' coordinate system, for display modes[09:21:58] <edwardk> SDL2 says 1024x768 for a window that is 2048x1536 physical pixels on a logically scaled 2:1 display[09:22:26] <slime> (note that window widths / heights are in 'points', but display modes are in pixels)[09:22:44] <edwardk> i think you have that precisely backwards[09:22:55] <edwardk> unless my use of the vocabulary is backwards[09:23:17] <edwardk> the numbers SDL2 gives back are half, 1/1.6 whatever of what i have to handle opengl[09:23:23] <edwardk> er hand to[09:23:28] <slime> 2 pixels is 1 point, on a retina display with the display mode set to one that is retina-aware[09:23:51] <edwardk> yes[09:23:52] <slime> 4 pixels rather[09:24:19] <edwardk> what i mean is that i don't have a nice way with sdl2 to get aat the window handle to go call the rectangle conversion functions the mac gives me[09:24:43] <edwardk> at least that i can figure out now[09:24:53] <slime> if you use fullscreen then I believe you can just pick the 1280x800 display mode with the highdpi flag enabled[09:25:12] <slime> then you can use SDL_GL_GetDrawableSize and SDL_GetWindowSize[09:25:28] <edwardk> i usually wind up using the sdl mode that is FullscreenDesktop[09:25:36] <edwardk> that lets me unfullscreen[09:25:44] <slime> right, same thing in that case[09:26:03] <edwardk> if i ask to use Fullscreen, for reals, there is a bug in 2.0.3 that causes it to not let me unfullscreen[09:26:13] <edwardk> so i have to use FullscreenDesktop by default[09:26:44] <edwardk> and i've relegated 'real fullscreen' to an option[09:27:04] <edwardk> which is a shame because it is ridiculously faster[09:27:07] <slime> the display-mode switching fullscreen has always been pretty shitty in OSX, good to not make it the default[09:27:15] <edwardk> oh i agree[09:27:50] <edwardk> its just sad that i can basically add 30% to my framerate, by doing 'sudo defaults write /Library/Preferences/com.apple.windowserver Compositor -dict deferredUpdates 0' and rebooting[09:28:20] <edwardk> and i can't think of a way to turn off deferred updates live in the application otherwise[09:28:57] <edwardk> so i just block randomly and do nothing for large chunks of time when i could run physics[09:29:48] <edwardk> basically wasted the day chasing annoying mac'isms ;)[09:30:11] <slime> does that just disable vsync?[09:30:34] <edwardk> pretty much, even if you tell a mac to disable vsync it just ignores you normally[09:31:01] <slime> I think it ignores you more often on older integrated intel GPUs, which kind of makes sense[09:31:18] <edwardk> how old is older?[09:31:24] <slime> you can use Quartz Debug.app to change it (still system-wide) without rebooting[09:31:33] <slime> well, I consider the HD 4000 old :P[09:31:51] <edwardk> yeah except i can't download the quartz debug app because the site i need to use to register to go pull down is down[09:31:58] <edwardk> which is rather annoying[09:32:05] <edwardk> i can go to the site and log in with an existing login[09:32:10] *** ShadowIce has quit IRC[09:32:12] <edwardk> but going to register on the site goes to a dead link[09:32:16] <edwardk> go apple developer support![09:32:35] <edwardk> slime: heh so do i[09:32:59] <edwardk> on the other hand, if i'm aiming for something that runs on a reasonably wide set of machines i suppose there is something to be said for "wearing the hair shirt" ;)[09:33:05] *** ShadowIce has joined ##OpenGL[09:33:12] *** Zerflag has quit IRC[09:33:42] *** ShadowIce has quit IRC[09:33:44] <edwardk> one thing though, is i can use apitrace to capture the stream of what i send to the card[09:33:56] <edwardk> and apitrace can play it _back_ at much higher rates than i can play it[09:34:16] <edwardk> and .. i'm not cpu bound, so something is blocking me that i'm not figuring out[09:34:26] <edwardk> i mean i'm definitely not cpu bound[09:34:40] <edwardk> i render a single triangle, with no VBO data[09:34:48] <edwardk> and set up a few uniforms[09:34:51] <edwardk> thats my frame[09:34:57] <edwardk> its all fragment shader overhead[09:35:01] <slime> OpenGL Profiler.app, Instruments, OpenGL Driver Monitor, and OpenGL timer queries can help[09:35:31] <edwardk> going to go fetch those[09:35:44] <edwardk> i'm pretty new to the current toolbox for supporting this crud[09:36:13] <slime> opengl profiler and opengl driver monitor are in the Graphics Tools for Xcode download, which also has the Quartz Debug application[09:36:14] <edwardk> i basically just decided i was going to go write some opengl stuff again and see how much of my old tricks 'just work now' rather than being too slow[09:37:28] <edwardk> oh, hey the downloads for apple developers site actually opened for me today[09:38:15] <edwardk> yay[09:38:19] <edwardk> i can run quartz debug again[09:38:30] <edwardk> i used to use it to let me turn on highdpi for a bunch of things[09:40:25] <edwardk> dahlia: anyways other signed distance field references are somewhat few and far between[09:40:42] <edwardk> dahlia: iq pretty much was the first person to really try to do them shader-side[09:41:03] *** Garner has joined ##OpenGL[09:42:15] *** Shockk has left ##OpenGL[09:42:30] <dahlia> edwardk: ya there's this also http://http.developer.nvidia.com/GPUGems3/gpugems3_ch34.html[09:42:47] *** Burga has quit IRC[09:43:04] <edwardk> yeah i'm pretty much staying polygon free at the moment =)[09:43:23] *** luxigo has joined ##OpenGL[09:44:14] <edwardk> once nice thing about spheretracing/raymarching/conetracing is that it is incredibly simple and divergence free[09:45:54] <edwardk> my current approach is that i'm trying to build lots of little signed distance fields with tight bounding boxes, then cone trace, which is raymarching with frusta to get a bound on the front of the scene, after doing a manually mipmapped hierarchical z-buffer cull for the individual SDFs, that gets me a pretty tight range of signed distance fields to draw,[09:45:54] *** abs25 has joined ##OpenGL[09:45:54] <edwardk> which matters because i can't get the hardware to z-cull them before the fragment shader runs[09:47:05] <edwardk> so once i have a nice z range to run SDFs in per 8x8 tile or so, then i sphere trace out the remainder of the SDF, that gives me a 'z-prepass' style buffer which i can tag/stencil whatever with the ID of the SDF that drew it[09:47:12] <dahlia> is this a demoscene like thing or are you trying to use them in a real application?[09:47:16] <edwardk> then i have to go back and set up lighting[09:47:31] <edwardk> well[09:47:33] <edwardk> its a mix[09:47:40] <edwardk> i used to do demoscene stuff way back in the day[09:47:48] <edwardk> and i do a lot of haskell stuff nowadays[09:47:56] <edwardk> but i looked around at the state of our gaming infrastructure[09:48:03] <edwardk> and it was pretty sad, to be honest[09:48:24] <edwardk> so the main thing i wanted to do was fix things up so that the tools we could offer were at least not _obviously worse_ than what you could get in many other languages.[09:48:42] <edwardk> so so far i've made a dent in achieving that part of my goal[09:48:42] <dahlia> I just want a better understanding of what's going on in those shadertoy demos. Once I have that then maybe I'll see if it's something that will fit into an application somehow[09:49:11] <dahlia> I kinda understand the sign change inside/outside but thats about it[09:49:13] <edwardk> the second part of my goal is when i looked around we had a couple of studios playing around with haskell for games e.g. chucklefish is playing with it for pixel art style game[09:49:25] <edwardk> but there isn't anyone really using it for anything that looks good ;)[09:49:38] <edwardk> so i wanted to show we could do something technically impressive with haskell[09:49:46] <edwardk> and if nothing else 'real time raytracing' makes the rubes happy[09:49:56] <edwardk> and spheretracing is a fast way to do that[09:50:16] <edwardk> so i figured if i can set up a signed distance field arena i can put basic FPS controls on it and let you shoot your friends in the face[09:50:23] <edwardk> and it at least would have fun arenas[09:50:29] <edwardk> because i could do anything i want[09:50:36] <dahlia> I kinda remember someone showing off a voxel raytracer in haskell once[09:50:40] <edwardk> and as a mathematician, the math part of SDFs is not my problem ;)[09:50:59] <edwardk> there are various toys in haskell for graphics, but they've all been toys[09:51:40] <centrinia> Even the Functional Reactive Programming stuff?[09:51:43] <edwardk> so i figured if i set up a reasonably modern pipeline, got haskell able to talk to modern opengl, do separate shader objects, use ggx lighting, area lights rather than point lights, do tone mapping, etc.[09:51:47] <dahlia> well I had some calculus ages ago but not much beyond that other than what the web can force into my skull ;)[09:51:54] <edwardk> i don't particularly care about FRP. nobody has demonstrated that it can ever be fast[09:52:33] <edwardk> and i realize that is heresy within the world of haskell i come from these days, but as far as i'm concerned its true[09:52:41] <centrinia> :([09:52:49] <edwardk> there are some bits of the scene i'm looking at that i can probably describe with FRP-like vocabulary[09:52:52] <edwardk> but not much of it[09:53:02] <edwardk> e.g. all my physics is basically offloading to the GPU[09:53:33] <edwardk> FRP implementations all universally use crappy euler integrators, etc. to anyone who knows what you should do there, its kinda terrifying that folks take it seriously[09:54:13] <edwardk> I've done some work with functional hybrid modeling for experiment design and the like, there are some real ideas that work buried in the FRP machinery, but FRP itself has a lot of semantic problems to me[09:55:17] <edwardk> FHM is great for things like modeling circuits, building up systems of stochastic differential algebraic equations for markets/option pricing, current through circuits, time varying simulations, etc. but its definitely not FRP[09:55:52] <edwardk> FRP makes the mistake in some sense of tying causality to the equations it describes. x = y + z in FRP terms tells you not just the equation, but imparts causality[09:55:57] <edwardk> but it does it within the timestep[09:56:16] <edwardk> so x is determined by y + z, you can't read it backwards, propagator style[09:56:25] <edwardk> this works great on paper until you go to model something like a circuit[09:56:36] <edwardk> and have someone push a button and want current to flow the 'wrong way' down that wire[09:57:29] <edwardk> lots of systems don't admit that unidirectional causality flow required by FRP, and FRP has no way to capture the dependency chains so it has lots of failure modes that involve spinning forever, tricky semantics,e tc.[09:58:14] <edwardk> so given that i've watched some of my smarted friends fall down the FRP rabbit hole typically for about a year each, and each of them has emerged from the other side with nothing to show for it, i've definitely decided to avoid hanging my hat on FRP[09:58:35] <Yaniel> oh, edwardk[09:58:39] <Yaniel> long time no see[09:58:57] <edwardk> heya yaniel[09:59:11] <edwardk> decided to start stomping around and playing with graphics again[09:59:41] *** Zerflag has joined ##OpenGL[10:00:32] <Yaniel> I've been mostly busy with other stuff[10:01:04] <edwardk> Yaniel: trying to think where i know you from, flipcode back in the day?[10:01:38] <Yaniel> nah, #haskell-game[10:01:41] <edwardk> ah =)[10:01:49] <foobaz> i have to agree, if you want to mess around with weird languages, learn rust and go[10:01:55] <Yaniel> not that I've touched haskell much[10:01:59] <edwardk> rust doesn't have a place to fit into my toolbox[10:02:31] <Yaniel> more working on my low-level skills by writing C (aiming to get a decent engine written in the end)[10:02:50] <edwardk> i have haskell for the esoteric, and the notions of parametricity i can get out of rust aren't strong enough to write the kind of abstract code i like to write on one hand, and the notion of "how we want to deal with memory management today" keeps changing fast enough that it makes my head spin[10:03:02] <edwardk> fair nuff[10:04:46] <edwardk> e.g. Haskell's notion of "Monad", "Category", "Functor", etc. are unthinkable thoughts in the current design of Rust.[10:04:47] <dahlia> I've been watching these vids, he's got some interesting ideas http://www.gamasutra.com/view/news/226070/Video_Jon_Blow_on_building_a_new_programming_language_for_games.php[10:05:19] <bjz_> edwardk: why is that?[10:05:41] <edwardk> bjz_: lack of higher kinded polymorphism kills those examples[10:05:47] <edwardk> same thing that kills them for Java, C#, F#, etc.[10:06:11] <dahlia> "higher kinded"?[10:06:13] <edwardk> leaving basically haskell, scala and a bunch of heavier weight languages as the only languages you can think about them in[10:06:35] <bjz_> edwardk: that is intended for implementation post 1.0. there are lots of areas where it is important for safe abstraction[10:06:39] <edwardk> In java you have generics, right? Foo<A> and the like[10:06:39] *** slidercrank has quit IRC[10:06:48] <dahlia> ya[10:07:05] <dahlia> and other languages[10:07:06] <bjz_> edwardk: things like abstracting over smart pointers and such[10:07:11] <edwardk> bjz_: go lured a bunch of folks promising they'd get around to generics some day too, so i'm not holding my breath ;)[10:07:21] *** garFF has joined ##OpenGL[10:07:22] <bjz_> edwardk: yeah, no worries[10:07:47] <edwardk> bjz_: anywyas it isn't clear that there is a story there that encompasses both that and polymorphic recursion[10:07:57] <edwardk> and the latter i use quite a bit these days, for things like fingertrees[10:08:24] <edwardk> dahlia: well, how can i write a thing that takes 'Foo's that uses Foo at several types?[10:08:35] <edwardk> dahlia: haskell lets you write that notion down.[10:08:59] <edwardk> an example would be C# has LINQ. it also has "the reactive framework"[10:09:04] <bjz_> edwardk: yeah, it's still early days for Rust, and I don't think it will ever get as expressive type system wise as haskell. But it is good enough for my needs.[10:09:08] * dahlia guesses cast it to a void type[10:09:09] <edwardk> both of these use the same method names, SelectMany, Join, etc.[10:09:16] <edwardk> dahlia: great so basically you're writing ruby?[10:09:28] <dahlia> never used ruby, have no idea[10:09:39] <edwardk> but you can't abstract over the choice of LINQ vs. Rx. you have to write code to work with one or the other[10:09:44] <edwardk> and cut and paste it to work with the other[10:09:47] <dahlia> thats just what I do in c++[10:09:49] <bjz_> dahlia: well, you are getting rid of the type information[10:09:51] <edwardk> that isn't development in this decade ;)[10:09:55] <dahlia> or cast to Object in c#[10:10:04] *** Zerflag has quit IRC[10:10:13] <dahlia> no the type info isnt lost[10:10:18] <edwardk> the point here is that both of these languages force you to use object as an escape valve, and then force you to recover that information later by downcasting.[10:10:54] <dahlia> I have something in the object which identifies it when I do it in c++[10:10:55] <edwardk> once you can downcast and 'is instance of?' is a question you can ask, then at a very deep fundamental level you've broken OOP. Why? Liskov substitutability is the underlying principle that makes OOP go[10:11:07] <dahlia> in c# I use "is" keyword[10:11:18] <edwardk> it says if X is a subclass of Y then I can pass an X whenever I could pass you a Y.[10:11:19] <bjz_> dahlia: you give up the type system's ability to verify things at compile time. which could either lead to a segfault or a runtime exception.[10:11:31] <edwardk> but if you can ask 'is instance of' you can trivially violate that safety[10:11:41] <dahlia> bjz_: yes but I have runtime checks[10:11:56] <edwardk> so your whole programming discipline devolves into unwritten rules you have to follow to get through a minefield[10:11:57] <dahlia> I havent had a segfault yet[10:12:08] <edwardk> its not a segfault thing[10:12:20] *** garFF has quit IRC[10:12:30] <dahlia> that was in response to bjz_[10:12:34] *** hahuang65 has quit IRC[10:13:05] <edwardk> in a language like haskell if i hand you a function a -> a that works forall a, then i can know that that function hands you back the thing you gave it, because you have no other information to do anything with it. on the other hand in java/c#/etc it can launch missiles, check to see if a = Int then add 1 and hand it back to you, etc.[10:13:07] <bjz_> edwardk: I was talking about if you cast in C++ to the wrong thing. which can happen after refactoring[10:13:09] <dahlia> granted it's not designed into c++ but that doesnt mean I cant do it safely[10:13:15] <edwardk> you lose all ability to reason about the behavior of your code from the types[10:13:28] <dahlia> and I do hate c++[10:13:37] <bjz_> dahlia: doing stuff like that makes your code brittle[10:13:47] <edwardk> so i just don't do that any more[10:13:48] *** hahuang65 has joined ##OpenGL[10:13:49] <dahlia> edwardk: no I dont. the type information is preserved[10:13:55] <edwardk> i work in languages which don't force me to lie[10:14:01] <dahlia> bjz_: its not been brittle yet[10:14:06] <bjz_> dahlia: where is is preserved?[10:14:28] <edwardk> preserved in runtime checks you have to pay for forever[10:14:30] <dahlia> in the object[10:14:42] <dahlia> I ask the object what it is[10:15:02] <dahlia> why is that a problem?[10:15:03] <edwardk> what you've done is remove the ability for an external user to reason about the behavior of your code because you want to fit into a language with fewer tools for abstraction[10:15:09] <edwardk> thats fine[10:15:13] <edwardk> i get that folks need to get stuff done[10:15:15] <edwardk> and collect a paycheck[10:15:19] <bjz_> dahlia: not in C++, it may be preserved in C#, but you still have to throw some kind of run time failure when it could be a compile time error[10:15:23] *** slidercrank has joined ##OpenGL[10:15:26] <dahlia> edwardk: you've not seen my code, how can you know that?[10:15:47] <dahlia> bjz_: I define it myself in the object definition[10:15:58] <edwardk> dahlia: i can say that categorically about upcasting/downcasting through object, its not about you. its about the fact that it is categorically impossible to do[10:16:02] * dahlia sighs[10:16:19] <bjz_> dahlia: what happens when your instance of check fails?[10:16:24] <dahlia> ok well I'll rewrite my code then[10:16:56] <edwardk> anyways this whole question stated with 'why don't i use those languages' when i can help it[10:16:58] <dahlia> bjz_: if it's not the expected type then I dont use it for the expected type[10:17:01] <edwardk> i don't use them because of this[10:17:14] <edwardk> because things that should be caught at compile time are caught if at all at runtime[10:18:18] *** hahuang65 has quit IRC[10:18:20] <edwardk> and higher kinded polymorphism and the ability to know that liskov substitutability / parametricity will _never_ be violated no matter whose code I invoke are big tools in my toolbox.[10:18:23] <dahlia> I would think that anyone who has used an entity-component model has encountered similar type issues at some level[10:18:28] *** hahuang61 has joined ##OpenGL[10:18:52] <edwardk> and my point is that most of those issues are artifacts of the limitations of the languages in which you are working, not fundamental[10:18:52] <bjz_> edwardk: agreed. I think higher kinded polymorphism is very useful, but the lack of it can be worked around. it does need to be added post 1.0 to Rust, at least, if we are serious about having a decent type system[10:19:07] <dahlia> edwardk: yes I agree[10:19:42] <edwardk> bjz_: anyways, the problem i have is that pretty much without it 9 lines out of 10 of what i write can't typecheck ;)[10:19:52] <edwardk> i write painfully abstract code for the most part[10:20:19] <bjz_> edwardk: yeah, then Rust is not the lang for you, and that's fine :)[10:21:22] <edwardk> bjz_: e.g. https://github.com/ekmett/hask/blob/master/src/Hask/Tensor/Compose.hs[10:21:47] <bjz_> edwardk: heh, yup[10:22:01] <bjz_> edwardk: haskell will always have Rust beat at that kind of thing[10:22:08] <edwardk> that goes further and abuses polymorphic kinds though[10:22:34] <edwardk> that module actually provides proof in haskell that 'a monad is a monoid in the category of endofunctors' is actually something you can write in code and program with[10:23:25] <edwardk> but it pretty much is a showstopper for me[10:23:29] <bjz_> edwardk: but on the flip-side, whilst writing 'fast' code in haskell is possible, it is not ideomatic. Rust makes fast code easier to write[10:23:47] <edwardk> e.g. i use polymorphic recursion to deal with name capture in every single AST i build these days because it forces me to think about 'name capture' just enough[10:23:49] <bjz_> edwardk: I use 'fast' as a blunt instrument[10:24:00] <bjz_> edwardk: it is more nuanced than that I know[10:24:06] <edwardk> i also do fast haskell, too ;)[10:24:45] <edwardk> lens tries to push the boundaries of both at the same time, mostly by using the theory to drive optimizations that otherwise wouldn't work[10:25:00] <bjz_> yeah, lens is cool[10:25:11] <edwardk> there is the don stewart school of how to make haskell fast, with all the unboxed ops, etc.[10:25:19] <bjz_> anyway, we are a bit off topic here[10:25:51] <edwardk> my usual approach is a bit different, go deeper down the rabbit hole, build an EDSL for my domain, write all my domain specific optimizations.. then turn it into a compiler targeting whatever i need to emit.. say, GLSL ;)[10:25:57] <bjz_> edwardk: can you post a link though?[10:25:57] <edwardk> see, there brought it back into topic =)[10:26:07] <bjz_> heh[10:26:10] * bjz_ claps[10:26:10] <edwardk> to fast haskell code?[10:26:23] <bjz_> the 'don stewart' approach[10:26:33] <bjz_> unboxed ops[10:26:39] <edwardk> oh, hrmm, hackage.haskell.org/package/bytestring[10:26:49] <edwardk> which is pretty terrifying in the internals[10:27:25] <edwardk> i also use that style here and there https://github.com/ekmett/concurrent-supply/blob/master/src/Control/Concurrent/Supply.hs#L146 uses a bunch of unboxed tuples, etc.[10:28:05] *** Match has joined ##OpenGL[10:28:40] <edwardk> anyways, didn't mean to start a language war =)[10:28:53] <edwardk> i'm mostly lurking to talk graphics and reboot my thinking[10:29:54] <edwardk> i did a bunch of graphics stuff in the 90s, then stopped, recently did some work on metropolis light transport raytracing for a client, and that got me thinking graphics thoughts again[10:30:48] <edwardk> so now i'm playing around with clustered shading, SDFs, light propagation volumes, etc.[10:30:58] <edwardk> and trying to catch up on the state of the art[10:31:45] <edwardk> on the plus side in the meantime since when i used to do graphics, i went and picked up a math degree, so the math goes down a lot easier now =)[10:33:10] <edwardk> oh, and https://www.cs.drexel.edu/~mainland/publications/talks/mainland12simd-chalmers.pdf and the like basically pretty much fits into what i'd consider the nice way to do optimization in haskell[10:33:12] *** Voidwalkr has quit IRC[10:34:38] <edwardk> we've always had the pretty way and the fast ugly way, and the nice thing about being in a community this academic is that they can just afford to keep throwing PhD students at it until the pretty way runs rewrites itself into the fast ugly way.[10:36:05] <edwardk> i was hoping to be able to showcase some of the new simd work in my current graphics project, but it doesn't look ready enough for prime time that i could do so and still have users. basically i'd like a small low level optimized glm -style library so that i can test out a lot of my shader math cpu side.[10:36:27] <edwardk> but the simd-support we have through llvm is kinda sad at this point[10:37:17] *** luxigo has quit IRC[10:38:54] <edwardk> has anyone here implemented the ola olsson stuff for clustered shading?[10:39:24] <edwardk> that is the kinda question i'm going to have to leave up overnight isn't it? =)[10:40:15] <Yaniel> yep[10:42:35] <dahlia> edwardk: you mean this? http://www.highperformancegraphics.org/previous/www_2012/media/Papers/HPG2012_Papers_Olsson.pdf[10:44:12] *** goliath has joined ##OpenGL[10:44:14] *** hahuang61 has quit IRC[10:45:55] <edwardk> dahlia: yeah.[10:46:09] *** luxigo has joined ##OpenGL[10:46:10] <edwardk> i've been hacking up something closer to the avalanche writeup on the topic than the olsson paper[10:46:23] <edwardk> http://www.humus.name/Articles/PracticalClusteredShading.pdf[10:46:24] *** foobaz has quit IRC[10:46:48] <edwardk> in my case its a bit worse because i'm trying to do it for all SDFs, not triangles[10:46:57] <edwardk> so we'll see how i can deal with the fill rate[10:48:23] <edwardk> but so far i like it a lot better than tiled approaches[10:49:06] <dahlia> no I haven't done either but I'm interested in better deferred shading techniques[10:49:11] *** foobaz has joined ##OpenGL[10:50:14] <edwardk> i've pretty much bitten off more than i can chew in my current project, but i figure that is the way i learn the most[10:50:51] <edwardk> the avalanche writeup is a pretty good followup to the olsson paper, and the olsson one is pretty impressive in its own right[10:51:00] <edwardk> the avalanche one shows it can be pretty simple[10:51:11] <edwardk> which is good, because the olsson presentation is downright terrifying[10:51:13] <dahlia> I get so deep into my engine that I totally forgot about the game ideas I started from ;)[10:51:19] <edwardk> heh[10:51:23] <edwardk> i can empathize[10:51:50] <dahlia> there's something to be said about just using Unity :/[10:52:09] <edwardk> i wrote something like 40 complete soup-to-nuts engines back in the 90s, swapping out things over and over to go to different backends, techniques for occlusion culling, etc.[10:52:34] <edwardk> and i think in the end code from me wound up in only 4-5 games.. all written by other people[10:52:50] <edwardk> kinda sad in retrospect[10:53:04] <dahlia> oh I did 2d for ages but only barely touched 3D until the last maybe 7-8 years[10:53:18] <edwardk> same on the demoscene front, never bothered to actually do a demo myself, but there were a bunch of demos who sent me props as a result of helping with algorithms, bah =P[10:54:43] *** Zupoman has joined ##OpenGL[10:54:55] *** Zupoman has joined ##OpenGL[10:56:09] *** japro has joined ##OpenGL[11:00:29] *** Zerflag has joined ##OpenGL[11:04:58] *** AndroUser466 has joined ##OpenGL[11:05:08] *** Zerflag has quit IRC[11:05:18] *** AndroUser466 has quit IRC[11:05:44] *** panda81_ has joined ##OpenGL[11:14:16] *** Hadrien has joined ##OpenGL[11:14:37] *** japro has quit IRC[11:14:53] *** samrat has quit IRC[11:23:45] *** samrat has joined ##OpenGL[11:27:34] *** zagabar has joined ##OpenGL[11:27:38] *** Jonas__ has quit IRC[11:29:16] *** HuntsMan2 has quit IRC[11:29:53] *** shintah has joined ##OpenGL[11:30:32] *** samrat has quit IRC[11:32:56] *** kuldeepdhaka has joined ##OpenGL[11:33:36] *** Jonas__ has joined ##OpenGL[11:33:52] *** samrat has joined ##OpenGL[11:33:56] *** centrinia has quit IRC[11:35:48] <zagabar> I am writing a mesh renderer for a game which is supposed to be able to render moving entities with meshes from a 3D modelling software. I am not sure what the smartest approach is regarding how to setup the vertex buffers. if every entity had the same mesh, I would use instancing and one single draw call. But since they are different I see two alternatives. Ethier duplicate vertex data in the buffers so[11:35:50] <zagabar> that every entity has its own section of the buffers and then draw with one draw call, or fill the arrays only with data from different meshes, and use one instanced draw call per entity type. Which of these methods is best? Or is there another better approach I haven't thought of?[11:39:11] *** Jeanne-Kamikaze has joined ##OpenGL[11:40:56] <Bloodust> I do buffer per model[11:41:43] <Bloodust> that way I dont necessarely have to use unsigned int indices for rendering[11:43:07] <Bloodust> my instancing support is draw call per entity type[11:44:09] <Bloodust> Id start with 1 model per vbo for now[11:44:37] <Bloodust> and if you really need to go all in by reducing draw calls, then you can do all sorts of crazy shit later on[11:46:28] *** ESphynx has quit IRC[11:47:13] <zagabar> right. good point about starting out simple[11:48:07] *** mizux has joined ##OpenGL[11:48:36] *** garFF has joined ##OpenGL[11:49:01] <zagabar> should I then have one VAO per entity type too and set up all pointers just once, and then pretty much just loop through entity types and bind their VAO and then an instanced rendering call?[11:49:28] *** garFF has quit IRC[11:50:04] *** garFF has joined ##OpenGL[11:51:17] *** wiky has joined ##OpenGL[11:51:47] *** garFF has quit IRC[11:52:06] <Bloodust> vbo & vao make a pair[11:52:17] <Bloodust> so one vao & vbo per model[11:52:33] <Bloodust> or more than one if the model is huuuuuuge but I doubt thats the case[11:53:38] *** Codex_ has joined ##OpenGL[11:54:39] *** Guest72481 has quit IRC[11:54:53] *** luxigo has quit IRC[11:56:09] *** luxigo has joined ##OpenGL[11:56:20] *** telex has quit IRC[11:58:21] *** Wagoo has joined ##OpenGL[11:58:23] *** hexagoxel has joined ##OpenGL[11:58:39] *** telex has joined ##OpenGL[12:00:39] <zagabar> Bloodust: alright that makes sense. thanks :)[12:01:32] *** Waynes has joined ##OpenGL[12:08:25] *** soulz has joined ##OpenGL[12:14:00] *** nmschulte has quit IRC[12:16:55] *** nmschulte has joined ##OpenGL[12:20:05] *** pazul has joined ##OpenGL[12:20:52] *** ManDay has joined ##OpenGL[12:28:38] *** TheTeapot has joined ##OpenGL[12:30:02] *** Demon_Fox has quit IRC[12:34:39] *** panda81_ has quit IRC[12:36:30] *** foreignFunction has joined ##OpenGL[12:37:06] *** luxigo has quit IRC[12:40:06] *** jdolan has joined ##OpenGL[12:40:47] *** huntercool has quit IRC[12:43:58] *** Biliogadafr has joined ##OpenGL[12:45:38] *** Misu has joined ##OpenGL[12:47:39] *** jdolan has quit IRC[12:48:14] *** abs25 has quit IRC[12:50:54] *** paul424 has joined ##OpenGL[12:54:38] *** robot-beethoven has quit IRC[12:56:19] *** snakenerd has joined ##OpenGL[12:56:38] *** BearishMushroom has joined ##OpenGL[12:57:36] <paul424> I have a great idea for culling system[12:57:49] <paul424> how do I check whtehr there is one already ? without revealing it ?[12:57:54] <paul424> google papers ?[13:02:38] *** garFF has joined ##OpenGL[13:04:32] <antto> google will steal your idea as you google for it ;P~[13:04:36] *** samrat has quit IRC[13:05:06] <paul424> and the plus is it's so simple it could improve other occlude algorithms[13:07:17] <antto> if it's so simple, chances are high that someone else already thought about it[13:08:12] *** Beetny has quit IRC[13:09:53] <paul424> yeah , also it would required to draw the elements in the sorted order[13:10:06] *** Hadrien has quit IRC[13:12:33] <paul424> Why just all engines have got away from sorting the 3d objects and using the Z-Buffer[13:12:39] <paul424> that's very costy ...[13:14:36] *** huntercool has joined ##OpenGL[13:14:54] *** snakenerd has quit IRC[13:16:38] *** Misu2 has joined ##OpenGL[13:16:42] *** Misu has quit IRC[13:17:12] *** TheTeapot has quit IRC[13:17:31] <katu> paul424: if its simple, its guaranteed its been already tried[13:17:50] <paul424> Why just all engines have got away from sorting the 3d objects and using the Z-Buffer , BTW ?[13:18:02] <katu> got away?[13:18:16] <katu> i dont know what that .. means ... you mean stopped doing that?[13:18:18] <katu> well, some didnt[13:18:27] *** Match has quit IRC[13:18:32] <paul424> yeaj stopped that[13:18:43] <paul424> like which one do some sorting ?[13:18:53] <katu> updating vbos is expensive[13:19:30] <katu> however sometimes world chunks inside the frustrum (be it octree, or fixed minecraft like slabs) are still rendered ordered[13:19:36] <tm604> also transparency[13:19:38] <katu> because transpancy[13:19:39] <katu> yup[13:20:19] <paul424> well the transparent hmm yeap >_>[13:20:22] <katu> paul424: generally you dont want to sort individual tris, but bigger chunks you instantiate on demand[13:21:11] <paul424> katu updating vbos is expensive , what does it mean in terms of sorting ? I meant sorting them before they are send to GPU[13:21:19] *** Misu has joined ##OpenGL[13:21:31] <katu> so? camera moves and you sort again?[13:21:54] <paul424> yes[13:22:11] <katu> the "order" is perspective dependent. which is why you sort on draw call/buffer level, not tri level[13:22:53] *** snakenerd has joined ##OpenGL[13:22:58] <katu> paul424: of course you can sort stuff at cutoff distance (and some engines indeed do that, because again, transparency)[13:23:54] *** Misu2 has quit IRC[13:24:01] *** qeed has joined ##OpenGL[13:24:02] <katu> but generally its a hassle, usually only very rough front-to-back is held (on draw call level), so zbuffer can reject fragments early[13:28:26] *** garFF has quit IRC[13:36:00] *** samrat has joined ##OpenGL[13:38:30] *** kuldeepdhaka has quit IRC[13:41:31] *** garFF has joined ##OpenGL[13:43:18] *** t4nk256 has joined ##OpenGL[13:43:55] *** garFF has quit IRC[13:44:57] <t4nk256> well back to immediate mode[13:45:17] <t4nk256> java can't handle VBOs properly[13:47:19] *** paul424 has quit IRC[13:51:30] *** shingshang has quit IRC[13:52:09] <Codex_> t4nk256: why?[13:52:10] *** jokoon has joined ##OpenGL[13:52:18] *** urraka has joined ##OpenGL[13:52:33] <t4nk256> Because java sucks?[13:52:37] <Codex_> it doesnt support the calls required?[13:53:04] <jokoon> so if I do gl_FragCoord.xy, it converts it to a vec2 right ?[13:53:17] <Codex_> yup[13:54:48] <jokoon> isn't fragcoord a vec2 anyways ? -_-[13:54:48] <t4nk256> java does "support" the calls with bindings like lwjgl[13:55:12] <t4nk256> but you probly want to use a library to actually do the setup for you[13:56:01] <t4nk256> because you can end up with just a black screen no errors and several wasted hours of troubleshooting otherwise[13:56:48] <Codex_> black scrren if you fail to initialize shaders is modern opengl for you.[13:57:32] <t4nk256> nope no such errors[13:57:48] <t4nk256> infact nothing at all to indicate whats wrong[13:59:47] *** paperManu_ has joined ##OpenGL[14:01:13] <t4nk256> atleast immediate mode is uncomplicated enough for java to handle[14:01:48] *** navitsu has joined ##OpenGL[14:02:13] *** DrBenway has quit IRC[14:03:42] *** shingshang has joined ##OpenGL[14:04:12] *** kuldeepdhaka has joined ##OpenGL[14:05:46] *** AnAsian has quit IRC[14:07:15] *** zzuegg has quit IRC[14:08:56] *** zzuegg has joined ##OpenGL[14:09:04] <tm604> t4nk256: java handles VBOs just fine. Have you tried the goharsha.com tutorials?[14:10:07] <t4nk256> tm604: well you might eventually get it working in a weird configuration[14:10:21] <t4nk256> but its more trouble than its worth[14:10:27] <t4nk256> better to use c++[14:10:32] <tm604> so far none of the issues you describe are anything to do with Java.[14:10:36] *** DrBenway has joined ##OpenGL[14:10:42] <tm604> have you tried those tutorials?[14:13:23] <t4nk256> tm604: thats the old lwjgl[14:13:35] <t4nk256> lwjgl 3 uses glfw[14:13:52] <t4nk256> anyway i know HOW to use vbos[14:13:53] <navitsu> can anyone tell me what's new with this lwjgl 3? :D[14:17:21] <t4nk256> the tutorials don't even use interleaved vbos[14:18:33] <tm604> t4nk256: so use your existing GLFW setup code?[14:18:45] <tm604> if you can't even get a triangle rendered, complaining about interleaved VBOs seems odd.[14:18:46] *** jokoon has quit IRC[14:21:17] <t4nk256> tm604: the problem is not rendering it[14:21:35] <t4nk256> the problem is encapsulating it[14:21:55] <t4nk256> it returns to a black screen with the slightest encapsulation[14:22:16] <t4nk256> you pretty much end up with a giant block of code in one class[14:23:04] <tm604> so it's nothing to do with OpenGL, you changed (and broke) the previously-working code? It's a bit of a jump from that to "java can't handle VBOs properly" :([14:23:47] <tm604> anyway, run it through apitrace or similar to see what's different.[14:25:14] <Codex_> opengl is known to have difficult data passing in it[14:25:45] <t4nk256> tm604: I said java sucks, Opengl is awesome[14:25:50] <Codex_> if you fail that, you lose frame rates or cant get it to screen[14:27:39] *** Jeanne-Kamikaze has quit IRC[14:28:11] *** HunterD has joined ##OpenGL[14:28:16] *** Waynes has quit IRC[14:28:55] <HunterD> for mobile platforms, is there a performance difference between shadow map implementation from spot light and directional light?[14:28:58] *** Jeanne-Kamikaze has joined ##OpenGL[14:29:11] *** Waynes has joined ##OpenGL[14:30:20] <Yaniel> well there is hardly a difference in the implementation[14:30:28] <Yaniel> mostly the view frustum[14:35:19] <HunterD> Yaniel: so it should make no difference which type of shadow map I will implement[14:36:16] *** Hadrien has joined ##OpenGL[14:37:51] *** Hadrien has quit IRC[14:40:09] <HunterD> any ideas why i get this artifact? http://imgur.com/Xr7BRh9[14:41:09] <urraka> no idea about shadow stuff but that looks like some GL_REPEAT somewhere[14:41:51] <urraka> well that just comes to mind[14:42:47] <urraka> actually i dont see how it could be that now that i\ve said that[14:44:01] *** wiky has quit IRC[14:45:29] <HunterD> if my shadow map does not reach the edge of the texture in which it is being rendered the artifact does not show up[14:46:05] <HunterD> it might be some repeat... I follow some example code, not much experience with shadows either :)[14:53:38] *** slidercrank has quit IRC[14:53:54] *** Vtec234 has joined ##OpenGL[14:55:55] *** HunterD_ has joined ##OpenGL[14:56:55] *** HunterD_ has quit IRC[14:57:09] *** hahuang61 has joined ##OpenGL[14:58:06] *** HunterD has quit IRC[14:58:55] *** ruuns has joined ##OpenGL[15:00:15] *** bjz_ has quit IRC[15:00:21] *** HunterD has joined ##OpenGL[15:00:22] *** bjz has joined ##OpenGL[15:01:49] *** snakenerd has quit IRC[15:01:51] *** hahuang61 has quit IRC[15:02:21] *** Vtec234 has quit IRC[15:05:15] *** xissburg has joined ##OpenGL[15:09:00] *** slidercrank has joined ##OpenGL[15:09:34] *** Kane has joined ##OpenGL[15:15:04] *** Crehl has joined ##OpenGL[15:15:36] *** Hadrien has joined ##OpenGL[15:17:23] *** navitsu has quit IRC[15:19:36] *** stooopid has joined ##OpenGL[15:24:03] *** bkre_ has joined ##OpenGL[15:32:54] *** karswell has quit IRC[15:33:35] *** karswell has joined ##OpenGL[15:33:48] *** dusted has joined ##OpenGL[15:34:22] *** HuntsMan has joined ##OpenGL[15:38:55] *** Alina-malina has quit IRC[15:39:19] *** t4nk256 has quit IRC[15:44:46] *** Alina-malina has joined ##OpenGL[15:44:55] *** Alina-malina has quit IRC[15:44:55] *** Alina-malina has joined ##OpenGL[15:53:24] *** Tenzin has joined ##OpenGL[15:55:31] *** krnlyng has quit IRC[15:57:45] *** bjz has quit IRC[15:58:06] *** bjz has joined ##OpenGL[15:59:01] *** centrinia has joined ##OpenGL[16:06:02] *** Khlorghaal has joined ##OpenGL[16:07:56] *** b4b has joined ##OpenGL[16:10:29] *** Hadrien has quit IRC[16:14:18] *** BearishMushroom has quit IRC[16:15:14] <zagabar> if I have two shaders both with a vec3 uniform at location 1, if I use glUniform3f(LOCATION_1, ...values...), does that uniform only apply to the currently bound shader, or will location 1 contain the same data on both shaders if I just switch shader program using glUseProgram() ?[16:16:52] <zagabar> hm, seems like the docs imply that it is for the current program only[16:16:55] <Yaniel> yes[16:19:01] *** ManDay has quit IRC[16:21:15] *** metredigm has joined ##OpenGL[16:27:06] *** metredigm has quit IRC[16:32:36] *** Khlorghaal has quit IRC[16:34:04] *** Khlorghaal has joined ##OpenGL[16:42:19] *** stooopid has quit IRC[16:47:15] *** Twinklebear has joined ##OpenGL[16:47:28] *** Lemml has quit IRC[16:49:49] *** danicampa901 has joined ##OpenGL[16:50:17] *** danicampa901 has left ##OpenGL[16:55:33] *** jdolan has joined ##OpenGL[16:58:46] *** groton has joined ##OpenGL[16:59:07] *** Lemml has joined ##OpenGL[17:00:56] *** jdolan has quit IRC[17:01:50] *** BitPuffin has joined ##OpenGL[17:04:17] *** navitsu has joined ##OpenGL[17:05:14] <Polarina> zagabar, you can set up a uniform buffer object and share that between programs.[17:05:47] *** wreed has joined ##OpenGL[17:06:03] *** Gamecubic has joined ##OpenGL[17:09:24] *** Jeanne-Kamikaze has quit IRC[17:13:00] *** samrat has quit IRC[17:14:36] *** samrat has joined ##OpenGL[17:16:02] *** Voidwalkr has joined ##OpenGL[17:16:36] *** Lemml has quit IRC[17:18:10] *** Lemml has joined ##OpenGL[17:18:40] *** BearishMushroom has joined ##OpenGL[17:24:21] *** Waynes1 has joined ##OpenGL[17:26:38] *** Ad1_RN has joined ##OpenGL[17:27:17] *** centrinia has quit IRC[17:27:30] *** Waynes has quit IRC[17:29:45] *** Voidwalkr has quit IRC[17:30:03] *** Voidwalkr has joined ##OpenGL[17:30:24] *** Ad1_RnR has quit IRC[17:37:06] *** nmschulte has quit IRC[17:45:33] *** BreadProduct has quit IRC[17:53:08] *** ManDay has joined ##OpenGL[17:58:26] *** Orion] has joined ##OpenGL[17:58:36] *** anivemin has joined ##OpenGL[18:04:15] *** anivemin has quit IRC[18:05:54] *** junaidnaseer2 has joined ##OpenGL[18:09:46] *** Zerflag has joined ##OpenGL[18:11:10] *** HunterD_ has joined ##OpenGL[18:11:15] *** HunterD has quit IRC[18:11:22] *** HunterD_ is now known as HunterD[18:21:38] *** Plasmastar has quit IRC[18:25:02] *** linuxuz3r has joined ##OpenGL[18:25:24] *** Plasmastar has joined ##OpenGL[18:25:46] *** aethersis has joined ##OpenGL[18:26:42] <aethersis> if I decide to use float based texture, will it make computations in fragment shader significantly longer?[18:28:25] <Polarina> aethersis, float textures have higher bandwidth and memory requirements than a normal texture. If you have those two to spare, you shouldn't see any significant performance degradation.[18:28:35] <aethersis> that's what I meant[18:28:38] <aethersis> it's alright then[18:28:48] <aethersis> I need em' ![18:28:54] <Polarina> :)[18:29:02] <aethersis> however I was hoping my program will have better performance :<[18:29:16] <aethersis> it turns out that it won't be able to handle a grid sized 150^3[18:29:27] <aethersis> *above 150^3[18:29:33] <Polarina> If you do not need the extra precision of single-precision floating point numbers, you can use half-precisions instead.[18:29:37] <aethersis> it's still 100x faster than on CPU[18:29:57] <aethersis> yeah half precision should suffice[18:40:45] *** PasNox has joined ##OpenGL[18:43:02] *** BitPuffin has quit IRC[18:44:34] *** MLM has joined ##OpenGL[18:45:05] *** Misu has quit IRC[18:45:40] *** Misu has joined ##OpenGL[18:58:47] *** Keniyal has quit IRC[19:05:06] *** BitPuffin has joined ##OpenGL[19:06:33] *** Gamecubic has quit IRC[19:06:59] *** Gamecubic has joined ##OpenGL[19:09:45] *** FrodoTheHobbit1 has quit IRC[19:11:13] *** b4b has joined ##OpenGL[19:11:54] *** konom has joined ##OpenGL[19:11:59] *** karswell has quit IRC[19:12:35] *** karswell has joined ##OpenGL[19:13:42] *** samrat has quit IRC[19:14:16] *** HunterD_ has joined ##OpenGL[19:14:31] *** HunterD has quit IRC[19:14:41] *** HunterD_ is now known as HunterD[19:15:39] *** samrat has joined ##OpenGL[19:16:00] *** ManDay has quit IRC[19:17:18] *** shingshang has quit IRC[19:17:45] *** devbug_ has joined ##OpenGL[19:18:05] *** TheGhostinator has joined ##OpenGL[19:18:05] *** TheBeerinator has quit IRC[19:18:19] *** BlackPhoenix has joined ##OpenGL[19:18:27] *** Codex2 has joined ##OpenGL[19:18:30] *** xishe has joined ##OpenGL[19:18:44] *** Zero has joined ##OpenGL[19:18:55] *** varialus_ has joined ##OpenGL[19:19:08] *** Zero is now known as Guest2035[19:19:12] *** Khlorghaal_ has joined ##OpenGL[19:19:19] *** Voidwalkr has quit IRC[19:19:29] *** Voidwalkr has joined ##OpenGL[19:20:16] *** reed has joined ##OpenGL[19:20:53] *** Madsy has quit IRC[19:21:27] *** BlackFox has quit IRC[19:21:39] *** Khlorghaal has quit IRC[19:21:39] *** devbug has quit IRC[19:21:40] *** TunnelCat has quit IRC[19:21:40] *** varialus has quit IRC[19:21:41] *** varialus_ is now known as varialus[19:22:01] *** Codex_ has quit IRC[19:22:15] *** wreed has quit IRC[19:22:15] *** xish has quit IRC[19:24:26] *** SugarCube has quit IRC[19:33:44] *** clauswitt has joined ##OpenGL[19:37:44] *** SugarCube has joined ##OpenGL[19:39:38] *** clauswitt has quit IRC[19:40:16] *** zzuegg has quit IRC[19:40:33] *** dusted has quit IRC[19:44:12] <Codex2> http://sivut.koti.soon.fi/~terop/clouds2.png[19:49:51] *** reed has quit IRC[19:57:45] *** seangrove has joined ##OpenGL[20:01:44] *** rishin458 has joined ##OpenGL[20:02:40] <rishin458> is opengl versions hardware dependent??[20:02:55] <cmr> rishin458: maybe? what are you getting at[20:05:00] <rishin458> what version should i learn opengl 4 or 2 or 1 ...?[20:05:10] <derhass_> 3[20:05:15] <derhass_> ^^[20:06:04] <rishin458> im a beginner.... but most of the system still support only ver2 or ver 1. ??[20:06:38] *** paperManu_ has quit IRC[20:07:48] <derhass_> rishin458: what makes you think so?[20:07:55] <rishin458> opengl 3 and 4 is hard to understand .... i think i should start with opengl 1[20:08:01] <derhass_> no[20:08:07] <Polarina> rishin458, that's not a good idea.[20:08:14] <derhass_> opengl 1 us completely outdated[20:08:17] <derhass_> *is[20:08:35] <rishin458> hmmmm :<[20:08:49] <derhass_> don't waste your time on such stuff[20:08:54] <cmr> rishin458: opengl 3.2 is a good bet, or if you want really universal, GL ES 2[20:08:57] <cmr> (for mobile etc)[20:09:05] <cmr> most stuff can be backported to 2.1 with loss of efficiency.[20:09:08] *** Jeanne-Kamikaze has joined ##OpenGL[20:09:45] <derhass_> cmr: well. "most" is a bit too much[20:10:02] <derhass_> what you say is true for the simple stuff[20:11:12] *** erhan_ has joined ##OpenGL[20:11:15] <rishin458> actually i want to create very simple animations for my c program like fractles..... and what i found that vers3 or 4 will take a lomg time to learn[20:11:41] <cmr> rishin458: then just use SDL2 or something, draw pixels into a surface and display those :)[20:12:19] <rishin458> hmmm...ty[20:12:51] <cmr> derhass_: which techniques couldn't be backported or safely ignored/implemented worse for the old cards?[20:13:13] <derhass_> cmr: well, "safely ignored" is relative[20:13:26] <derhass_> and "backported" too[20:14:02] <derhass_> we have geometry shaders, tesselation, compute shaders, layered rendering, and lots of small features which aren't directly available in 2.x[20:14:30] <cmr> I'm refering specifically to 3.2 and ES2[20:14:49] <cmr> (and gs was the bit that made me say "most")[20:14:53] <derhass_> well. gl3.2 has geometry shaders, instancing and so on[20:15:25] <cmr> instancing if necessary could be emulated with a uniform and a nasty CPU loop no? probably so slow as to no longer be useful..[20:16:22] <derhass_> in the end, you can use a gpu from 1985, if you do all rendering on the cpu[20:18:52] <rishin458> animation in ope[20:19:39] <rishin458> animation in html5 canvas is much more easier than opengl any version:?[20:21:50] *** rishin458 has quit IRC[20:24:25] *** reed has joined ##OpenGL[20:24:32] *** Voidwalkr has quit IRC[20:25:04] <Bloodust> hah[20:25:16] *** DolpheenDream has joined ##OpenGL[20:33:38] *** kriskropd has quit IRC[20:33:43] *** Guest2035 has quit IRC[20:34:13] *** TunnelCat has joined ##OpenGL[20:36:22] *** DrBoneStrong has joined ##OpenGL[20:38:30] *** Syzygy_ has quit IRC[20:38:55] *** jdolan has joined ##OpenGL[20:39:25] *** DrBoneStrong has left ##OpenGL[20:40:51] *** garFF has joined ##OpenGL[20:45:42] *** PasNox has quit IRC[20:46:51] *** abs25 has joined ##OpenGL[20:51:37] *** grzywacz has joined ##OpenGL[20:51:37] *** grzywacz has joined ##OpenGL[20:52:26] *** Zero has joined ##OpenGL[20:52:50] *** Zero is now known as Guest25324[20:53:08] *** MLM has quit IRC[20:53:19] *** Zero|2 has joined ##OpenGL[20:54:54] *** Orion] has quit IRC[20:56:17] *** Orion] has joined ##OpenGL[20:57:38] *** Thandruil has joined ##OpenGL[20:58:06] *** TunnelCat has quit IRC[20:58:38] <Thandruil> Hey guys, this the correct place for questions?[20:59:04] <cmr> Thandruil: about opengl, yes.[20:59:12] *** Guest25324 has quit IRC[20:59:51] <Thandruil> Coolcool[21:00:20] <Thandruil> I'm trying to draw a polygon but it's not working like I want it to work[21:00:30] <Thandruil> I kinda expected this, becasue tesselation is a weird thing[21:00:44] <Thandruil> I'll upload a picture of what I'm trying to achieve[21:01:05] <Thandruil> 3[21:01:18] <derhass_> 3?[21:01:24] <Thandruil> woops[21:01:30] <Thandruil> was drawing on my keyboard[21:01:45] *** ruuns has quit IRC[21:02:49] <Thandruil> imgur.com/DlNibBi[21:02:51] *** zzuegg1 has joined ##OpenGL[21:02:58] *** Waynes1 has quit IRC[21:03:05] <Thandruil> hmm[21:03:14] <Thandruil> imgur.com/DINibBi[21:03:20] <Thandruil> l => I[21:03:59] <Bloodust> did you write that ? :D[21:04:11] <Thandruil> Yeah[21:04:31] <derhass_> Thandruil: first of all, GL_POLYGON is depreacted[21:04:44] <derhass_> Thandruil: but putting that asie, it cannot be used to draw concave polygons[21:04:53] <derhass_> *aside[21:05:03] <derhass_> you need to triangulate that yourself[21:05:05] <Thandruil> ah, that explains[21:05:10] <Thandruil> I thought that already[21:05:34] <derhass_> Thandruil: a simple way to do that is the "ear clipping" algorithm[21:05:42] <derhass_> https://en.wikipedia.org/wiki/Polygon_triangulation#Ear_clipping_method[21:07:14] <Thandruil> So okay, that would work I guess[21:07:36] <Thandruil> But would that also work when I'm using N quality for the ring/curve[21:08:43] <Thandruil> The curve is rendered for example with N steps: x=cos(angle), y=sin(angle)[21:08:58] <derhass_> it will of course work[21:09:13] <derhass_> but you can proably directly generate the tiranlges anyway[21:09:19] <derhass_> no need to later trianglualte anything[21:12:00] *** zzuegg1 is now known as zzuegg[21:12:02] *** karswell has quit IRC[21:12:34] <Thandruil> imgur.com/5jOqk8x[21:12:35] *** karswell has joined ##OpenGL[21:13:43] <derhass_> Thandruil: there is one triangle missing[21:14:47] *** garFF has quit IRC[21:16:05] <Thandruil> oh i see now[21:16:10] <Thandruil> middle to top left[21:16:38] *** roboman2444 has quit IRC[21:17:04] *** roboman2444 has joined ##OpenGL[21:19:45] *** bjz has quit IRC[21:20:21] *** drag0nius has joined ##OpenGL[21:20:23] *** bjz has joined ##OpenGL[21:20:38] <drag0nius> what is the easiest shading algorithm to implement (generaly, not opengl specific) ?[21:20:51] <drag0nius> i've already implemented z-buffer[21:20:53] <drag0nius> if it helps[21:21:26] *** Zerflag has quit IRC[21:21:29] <cmr> drag0nius: simple bilinear filtering based on vertex colors, probably the simplest you'll get beyond just single flat color[21:21:49] <cmr> errr, *interpolation[21:23:50] *** Smilex has joined ##OpenGL[21:23:51] <derhass_> drag0nius: the simplest? flat shading[21:24:52] <drag0nius> so i'll start with flat shading, then get something more complex[21:26:23] *** paperManu_ has joined ##OpenGL[21:30:43] *** bjz has quit IRC[21:32:12] *** Zerflag has joined ##OpenGL[21:34:32] *** BearishMushroom has quit IRC[21:34:36] *** zzuegg has quit IRC[21:35:08] *** BearishMushroom has joined ##OpenGL[21:35:17] *** Smilex has quit IRC[21:39:02] *** centrinia has joined ##OpenGL[21:40:06] *** Zero|2 has quit IRC[21:42:01] *** Sos has joined ##OpenGL[21:42:34] *** glYoda has quit IRC[21:42:44] *** glYoda has joined ##OpenGL[21:43:48] *** HunterD has quit IRC[21:45:31] *** samrat has quit IRC[21:45:52] *** telex has quit IRC[21:46:16] <aethersis> drag0nius define best :D[21:46:39] <aethersis> fastest? easiest? most precise?[21:46:39] *** telex has joined ##OpenGL[21:46:57] *** b4b has quit IRC[21:47:33] <drag0nius> i've around 12h to add any kind of lightning effect to my zbuffer rendering[21:48:28] <drag0nius> don't want to start learning something i won't be able to finish[21:49:17] <derhass_> just make a simple diffuse n dot l per fragment or even only per vertex[21:49:17] *** b4b has joined ##OpenGL[21:50:46] <aethersis> I will have to implement some uber epic hard lighting/shading[21:50:55] <aethersis> I hope you will be able to help guys, I'm counting on you xD[21:51:18] <Bloodust> drag0nius ... void main(){ color = max(dot(normal, light_direction), 0.0); }[21:51:20] <aethersis> I wan't to make volumetric fire/smoke that's both a light source and it's receiver[21:51:46] <aethersis> is it going to be uber hard?[21:52:10] <drag0nius> is normal from some specific range?[21:52:23] <Bloodust> normal and light direction are normalized[21:52:56] <drag0nius> yeah, but i'm not using it in open/webgl :P[21:53:26] <aethersis> Bloodlust, you're a pro OpenGL guy[21:53:28] <Bloodust> then what are you doing ? :o[21:53:30] <aethersis> I haz a question[21:53:47] <aethersis> if everyone gives me a wrong answer, I will waste dozens of hours on it xD[21:54:08] <Bloodust> aethersis well its not going to be uber hard[21:54:10] <aethersis> I haz a fluid solver based on fragment shaders. It's in 2D[21:54:19] <Bloodust> but is pretty high up there[21:54:19] *** pazul has quit IRC[21:54:24] <aethersis> I want to implement it in 3d[21:54:30] <drag0nius> i was calculating plane and line intersection and there is (i think) normal as a side effect, but it's not normalized (eg. [-42, 59, 267])[21:54:56] <aethersis> the problem is DATA STRUCTURE![21:55:00] <aethersis> tex3d good?[21:55:19] <drag0nius> i need to make that normal and light direction same length?[21:55:30] <aethersis> I dunno how to handle this tex3d thing[21:55:33] <Bloodust> drag0nius normalizing does that[21:55:41] <aethersis> because I need 3d von neumann neighbourhood[21:55:52] <aethersis> can I split tex3d to 3x 2d inputs?[21:55:54] <Bloodust> aethersis well 3d texture should be fine but Im not familiar with your needs[21:56:14] <Bloodust> 3d texture is like a texture array[21:56:23] <aethersis> or can tex3d be devoured as a whole thing in the shader? if so, then am I able to access above and below fragment?[21:56:31] <aethersis> like with this texture sampler thing[21:57:17] <aethersis> can I do something like this: uniform sampler3D x0; ???[21:57:21] <Bloodust> yes[21:57:46] <aethersis> and then vec4 UP = texture(x0, vUV + vec3( 0 , 0 , -stepZ); ?!?[21:58:03] <aethersis> is that allowed?[21:58:05] <Bloodust> something like that[21:58:09] <aethersis> :OOOO[21:58:11] <Bloodust> 3d texture is just a 3d array[21:58:13] <aethersis> jesus opengl is awesome[21:58:16] <Bloodust> where 2d texture is just 2d array[21:58:20] <Bloodust> its just data :D[21:58:21] <aethersis> it's soooooo good then[21:58:22] <aethersis> AWESOME[21:58:33] <aethersis> I was afraid I will have to somehow split it manually in some crazy loops on CPU etc[21:59:08] <Bloodust> 2m30s to launch http://www.nasa.gov/multimedia/nasatv/#.VHJJKWOX9I0[21:59:13] <aethersis> I will also need a mesh voxelization algorithm xD[21:59:16] *** erhan_ has quit IRC[21:59:41] <aethersis> what are they launching?[21:59:49] <Bloodust> people to ISS[21:59:53] <aethersis> :O[21:59:57] <aethersis> hope it won;t explode[22:00:06] <aethersis> flying a rocket is like flying a bomb[22:00:14] <Bloodust> hope not[22:00:34] <aethersis> hopefuly these rockets are better than the ones that launch russian satellites[22:00:41] <aethersis> is that baikonur?[22:00:54] <Bloodust> I dont know what that is[22:00:57] <Bloodust> the rocket is soyuz[22:00:59] <aethersis> I mean the place[22:01:07] <Bloodust> dunno, its in russia[22:01:12] <aethersis> yeah, it's soyuz so it must be launched from baikonur[22:01:16] <aethersis> NOT RUSSIA! KAZACHSTAN![22:01:18] *** d_aniel has quit IRC[22:01:30] <aethersis> oh he said[22:01:33] <aethersis> zazheganie[22:01:35] <aethersis> it means ignition[22:01:37] <aethersis> vpusk[22:01:55] <Bloodust> rrright[22:02:04] <aethersis> WE HAVE LIFTOFF![22:02:36] <aethersis> jesus christ ,I wouldn't want to be onboard that thing[22:02:42] <aethersis> what tremendous power[22:03:27] *** snakenerd has joined ##OpenGL[22:03:44] <aethersis> the woman astronaut looks very happy[22:03:59] <Bloodust> happy because she didnt explode in launch :D[22:04:11] <aethersis> lmfao xD[22:04:17] <aethersis> have you ever played kerbal space program?[22:04:24] <Bloodust> looks like they are in squatting position[22:04:28] <Bloodust> ive never noticed that before[22:04:30] <Bloodust> and noI havent[22:04:44] <aethersis> they are with they backs pointed at earth[22:04:48] <aethersis> you didn't know that?[22:04:55] <Bloodust> Oh I knew that :D[22:04:57] <Bloodust> thats obvious :D[22:05:21] <aethersis> bloodlust, will you help me with this crazy 3d solver thing?[22:05:32] <Bloodust> aethersis maybe tomorrow[22:05:41] <aethersis> no not tomorrow[22:05:45] <aethersis> in a few weeks or even months[22:05:49] <aethersis> 2d is not ready yet[22:05:56] <aethersis> there will be a few critical issues to solve[22:06:22] <aethersis> first it will be mouse handling - how to determine how "deep" the mouse is and what exactly i'm clicking[22:06:28] <aethersis> in 3d space it's not so obvious[22:06:33] <Bloodust> well Ill be here[22:06:44] <aethersis> the second problem will be 3d mesh voxelization and loading for collisions[22:07:11] <aethersis> collision handling is pretty straightforward though and I'm not even sure if voxelization will be necessary[22:07:12] *** pazul has joined ##OpenGL[22:07:23] <aethersis> and finally it will be lighting and shading of the whole thing[22:07:49] <aethersis> in general this solver is a torture for any hardware - GTX 760 most likely won't be handle domain greater than 150^3 cells[22:07:51] *** junaidnaseer2 has quit IRC[22:07:54] <aethersis> which kinda sucks :/[22:08:01] <aethersis> I mean 150^3 at ~20 fps[22:08:56] <Bloodust> mm[22:09:19] *** bkre has joined ##OpenGL[22:09:35] <Bloodust> you probably dont need that high precisioun[22:09:45] <aethersis> but it will be ugly[22:09:54] <Bloodust> you'll have few control points and fill the area between them with particles[22:09:58] <aethersis> therefore I will have to find some crazy way to improve precission artificially[22:10:09] <aethersis> it's not particle based, it's semi-lagrangian lattice[22:10:14] *** snakenerd has quit IRC[22:10:18] *** reed has quit IRC[22:10:40] <aethersis> HOWEVER, you can kinda fill the lattice with particles or something similar for artificially greater precission[22:10:46] <Bloodust> sure but the visuals will be particles[22:10:58] <aethersis> I read a crazy paper about adding wavelet turbulence for detail improvement. They got some kind of oscar for it[22:11:11] <aethersis> the visuals are 3d texture xD[22:11:28] <Bloodust> mmm yeah no[22:11:49] <aethersis> what?[22:11:54] *** bkre_ has quit IRC[22:12:01] <aethersis> it's impossible to display it as it is?[22:12:17] <aethersis> I will have to turn the texture data into particles?![22:12:26] <Bloodust> well yeah, you cant just draw a solid cube and attach the texture int oit[22:12:47] <Bloodust> you can draw a bunch of slices but that wont look good[22:13:52] <aethersis> XD[22:14:01] <aethersis> ok, so that's another problem I will need help with[22:14:20] <aethersis> I've been trying to learn OpenGL from books, but I took 3 attempts and failed every time[22:14:25] <Bloodust> :P[22:14:29] <aethersis> I must code something practical and once I code this, I will improve a lot[22:14:58] <aethersis> learning how to use FBO was a huge improvement for me XD[22:15:10] <aethersis> until recently I couldn't imagine how could there be more than 2 shaders lmao[22:15:41] <Bloodust> :P[22:16:59] <aethersis> screw you, gauss! xD[22:17:52] *** phao has joined ##OpenGL[22:18:18] <phao> Hi... I was making some opengl code some months ago and I was wondering how I could create automated unit tests for that.[22:18:23] *** manny-_ has joined ##OpenGL[22:18:34] <phao> Is there any guide talking about suggestions on how to do it?[22:18:41] *** manny-_ has quit IRC[22:19:36] <aethersis> unit tests and opengl ?! are you kidding me?![22:19:45] <aethersis> #define GL_CHECK_ERRORS assert(glGetError() == GL_NO_ERROR);[22:19:48] <aethersis> this is your unit test lmfao[22:19:53] <Bloodust> dunno, one way would probably be render to texture ?[22:20:27] <phao> Bloodust, I've seen something like that... After rendering to some buffer, I'd have to compare the results to a pre-rendered image that I'd know to be right.[22:20:37] <phao> That sounds extremely brittle...[22:20:46] <phao> specially for games...[22:20:53] <Bloodust> transform feedback also[22:20:57] <Bloodust> but yeah its not nice[22:20:59] <cmr> it's how piglit (the regression tests for the open source drivers) do it, but they do very simple test cases.[22:21:15] *** groton has quit IRC[22:21:23] <phao> =([22:21:38] <phao> Bloodust, "transform feedback".. that's news to me... idk what that is.[22:21:45] <dahlia> I have tests for a lot of utility and math stuff but none for rendering[22:21:57] *** garFF has joined ##OpenGL[22:21:57] *** absof25 has joined ##OpenGL[22:22:02] <phao> Bloodust, I did very little of opengl using fixed function stuff[22:22:07] <phao> it wasn't pretty or sophisticated.[22:22:20] *** abs25 has quit IRC[22:22:29] <Bloodust> transform feedback is for vertices what render to texture is for fragment shaders[22:22:42] <Bloodust> s/vertices/vertex shader[22:22:47] <phao> dahlia, If rendering code is "dumb code" then that's fine... I guess[22:23:11] <phao> For example, I had a rendering code that just went through 3 (or 4?) collections of things to render.[22:23:26] <phao> and the code to render each thing (item in the collection) was pretty straightforward.[22:23:31] <dahlia> phao: ya no way to test for regressions without running and looking at everything[22:23:40] <phao> SO I could, i guess, just test the collections to see if they're properly populated[22:23:43] <phao> and ignore rendering code.[22:23:48] *** SparkDog has quit IRC[22:23:57] <chrisf> phao: http://aras-p.info/blog/2007/07/31/testing-graphics-code/ http://aras-p.info/blog/2011/06/17/testing-graphics-code-4-years-later/ might be worth reading[22:24:22] <phao> ok[22:24:24] <dahlia> but I have more trouble with things not working on different computer configurations than I have regressions[22:24:59] <chrisf> phao: you won't get the same pixels across different hw and driver versions[22:25:12] <phao> chrisf, I see.[22:25:41] <aethersis> 1/(0.4+x^4-x^2*0.3)[22:25:44] <aethersis> boom volcano![22:25:46] <aethersis> xD[22:26:38] <aethersis> phao here's my rendering procedure: http://postimg.org/image/3yyzoweqt/[22:27:13] <aethersis> and I didn't even think about how'd I write a unit test for it. I think it's simply impossible. Instead I test each procedure separately and check it visualy because I know what the result should be[22:27:32] <phao> The thing about tests, as I hear and experienced myself a little bit[22:27:41] <phao> is that you gotta write the code from the ground up to support tests.[22:28:04] <aethersis> would you write unit tests for assembler? xD[22:28:05] <phao> Trying to hook them in later isn't very nice. It can work, but seems like a lot of work.[22:28:08] <cmr> that might be true of fine-grained unit testing, but simple integration or functional tests are often sufficient.[22:28:35] <aethersis> I bet you are some java programmer, phao[22:28:46] <phao> cmr, I still gotta learn the different meanings of these different test types[22:29:03] <phao> like I know what unit tests are. I sort of know what integration tests are.[22:29:10] <phao> functional tests, I don't, really.[22:29:18] <phao> aethersis, I'm some programmer.[22:29:26] *** __zoot__ has joined ##OpenGL[22:32:17] *** varialus has quit IRC[22:32:48] <chrisf> phao: you might be better off keeping the gl driver out of your test scope -- get it working, and then just verify that you're asking the driver to do the right things[22:32:58] *** zzuegg has joined ##OpenGL[22:33:36] <chrisf> phao: can intercept the api to verify that[22:34:11] <chrisf> phao: or just verify that your app's representation of the commands is sane, and trust whatever thin layer you have between that and the driver is correct[22:34:33] <phao> To intercept, you would suggest writing my own intermediate API or is there some nice technique there?[22:35:54] <chrisf> if you want to intercept at the gl level, you might borrow apitrace[22:37:45] <phao> I see.[22:37:58] <phao> My issue I guess is that there are too many API calls.[22:38:06] <phao> Seems like a difficult thing to do (the testing).[22:38:37] <chrisf> go up a layer if it makes more sense[22:39:22] <phao> I see.[22:42:54] *** ransun has joined ##OpenGL[22:45:00] *** Demon_Fox has joined ##OpenGL[22:46:42] *** Garmine has quit IRC[22:46:59] *** Garmine has joined ##OpenGL[22:47:23] *** Garmine is now known as Guest47784[22:47:27] *** absof25 has quit IRC[22:49:50] *** void256 has joined ##OpenGL[22:49:56] *** ransun has left ##OpenGL[22:57:10] *** b4b has quit IRC[22:57:43] <phao> chrisf, I'm facing some issues like that to test my SDL code as well. Code that doesn't involve SDL is fine to test, but code that does touch it doesn't seem to be as easy.[22:59:13] *** Biliogadafr has quit IRC[22:59:22] <aethersis> phao, are you writing something huge?[22:59:29] <phao> No.[22:59:37] <phao> Really! No. =D[22:59:48] <aethersis> then why do you need these tests[23:00:02] <phao> But I intend to... so I'd like to know how to deal with that issue, because I can already see it'll arrive.[23:00:17] *** linuxuz3r_ has joined ##OpenGL[23:00:20] <cmr> aethersis: tests aren't just about size, it's about quality and being able to have confidence when making changes, instead of paranoia[23:00:39] *** Biliogadafr has joined ##OpenGL[23:00:43] <aethersis> but how can there be unit tests for 3d or even 2d render?[23:00:46] <aethersis> how are you going to test it[23:01:01] <phao> aethersis, the approach chrisf mentioned seems pretty good[23:01:15] <cmr> I don't think it's possible or desirable to unit test the renderer, at least not at a very fine grain level[23:01:18] <aethersis> it sounds very crazy t ome[23:01:28] <phao> You can try to get by with testing if you made the right calls.[23:01:36] <cmr> at least not without a disproportionate amount of effort[23:01:55] <cmr> on the other hand, you can at least make sure that when you render a scene, lights are being used, meshes getting rendered, etc.[23:02:06] *** drag0nius has quit IRC[23:02:10] <aethersis> cmr exactly! I assume I'm so pro I will never make an error! xD[23:02:24] <cmr> and to a certain extent, you can do image diffs on fixed scenes and flag for human review when greater than, say, 5-10% difference[23:02:24] <phao> cmr, Do you have code that does testing like that?[23:02:33] *** linuxuz3r has quit IRC[23:03:08] <cmr> phao: not that would be useful to you, probably :) it's in Rust and uses a library that wraps gl into a fairly high level api, all things compared[23:03:12] <aethersis> cmr 5-10% difference is a huge difference[23:03:35] <cmr> aethersis: indeed it is. there's also perceptual diff algorithms one could use, http://pdiff.sourceforge.net/ being one tool[23:03:39] *** Tenzin has quit IRC[23:04:02] <phao> cmr, I see.[23:04:07] <cmr> phao: I don't test at the graphics level, I instrument my renderer and query it for events that should have happened when rendering a scene[23:04:13] <aethersis> all this unit testing opengl code sounds like an overkill to me[23:04:20] <phao> cmr, I see.[23:04:45] <phao> Was the instrumentation code written manually?[23:04:49] <cmr> yes[23:04:55] <phao> I feared that.[23:04:57] <cmr> and wrapped in an ifdef[23:05:09] <cmr> basically event "probes" that stash stuff in a global[23:05:11] <phao> i see.[23:05:21] <cmr> not very elegant, but effective in my experience[23:05:44] <cmr> the equivalent of programmatically looking at printfs inserted into the renderer ;)[23:05:44] <phao> Well, I'd probably do it localized to file scope.[23:06:48] <phao> Do you think assertions could do the trick in your case?[23:06:58] *** Guest47784 has quit IRC[23:07:08] *** Burga has joined ##OpenGL[23:07:37] <cmr> maybe? I think it'd be a bit messier[23:07:46] <cmr> in that each test case would need its own set of assertions[23:07:53] *** Garmine42 has joined ##OpenGL[23:07:54] <cmr> which would be gross[23:08:12] <phao> No... I mean...[23:08:18] <phao> You said:[23:08:23] <phao> "I instrument my renderer and query it for events that should have happened when rendering a scene"[23:08:30] <cmr> ah[23:08:50] <phao> So what about having assertions for example, right before the return statement in the renderer functions.[23:09:12] <cmr> what would be asserted?[23:09:29] <phao> That that events that should have happened did.[23:09:43] *** Tenzin has joined ##OpenGL[23:09:55] <cmr> Oh, that's basically what happens, it just happens outside of the renderer, when I iterate through the list of events[23:10:04] <phao> I see.[23:10:27] <phao> Do you think it'd be any worse having it inside the rendering functions?[23:10:49] <cmr> probably not[23:10:50] <phao> As a kind of post-condition checking assertions.[23:11:10] *** glararan has joined ##OpenGL[23:11:42] *** Lemml has quit IRC[23:13:16] *** mayankmadan has joined ##OpenGL[23:14:00] <aethersis> what does cmr stand for[23:14:09] <cmr> aethersis: they are my initials[23:14:35] <cmr> I chose this nick in memorial of dmr (denis ritchie) when he died[23:17:07] *** Demon_Fox has quit IRC[23:17:15] <phao> I was doing it before it was cool[23:17:17] * phao hides[23:17:21] <phao> hehehehe[23:17:25] <cmr> lol[23:17:40] * cmr is not very original[23:17:41] *** Demon_Fox has joined ##OpenGL[23:18:13] <phao> that's true for everyone of us who having nicknames as initials[23:18:17] <phao> initials as nicknames***[23:18:17] <cmr> :P[23:18:47] *** groton has joined ##OpenGL[23:19:03] *** paul424 has joined ##OpenGL[23:22:58] *** abs25 has joined ##OpenGL[23:23:28] <phao> cmr, do you write games?[23:24:08] *** Burga has quit IRC[23:24:14] <cmr> phao: I wish :P I just toy around with various game engine related things and dream about making a game[23:24:25] <phao> Why is that?[23:24:43] <phao> If you can understand game engine related topics, you probably can make a game.[23:24:45] <cmr> lack of time, lack of inspiration, plus the underlying technology is just more fun to play with[23:24:51] <phao> hahahaha[23:24:52] <phao> =D[23:24:53] <cmr> for me at least[23:25:10] *** stef has quit IRC[23:25:14] <phao> What I like about games is that they're concrete problems.[23:25:25] <phao> I've never made an engine or anything like that. I'm not that good yet =D[23:25:27] <phao> But...[23:25:50] <phao> I've made foundational general kind of code... and it's good when you have a concrete problem to solve[23:25:51] *** abs25 has quit IRC[23:25:55] <phao> instead of an abstract general one.[23:26:43] <cmr> graphics/game related things are mostly just a hobby for me, I'm a math/cs student by day.[23:26:52] <phao> I see.[23:27:11] <cmr> if I were to actually make a game, then I'd have to face feedback and people *maybe* playing it ;)[23:27:27] <phao> hehehe[23:27:30] <phao> yep[23:27:33] *** karswell has quit IRC[23:28:08] *** karswell has joined ##OpenGL[23:28:38] <Codex2> dont worry. noone is going to play it.[23:28:39] *** Kane has quit IRC[23:28:44] <cmr> yup[23:29:28] *** Tenzin has quit IRC[23:29:57] *** kuldeepdhaka has quit IRC[23:30:03] *** Burga has joined ##OpenGL[23:31:42] *** navitsu has quit IRC[23:32:28] *** stef has joined ##OpenGL[23:34:27] *** Twinklebear has quit IRC[23:36:02] *** Madsy has joined ##OpenGL[23:36:02] *** Madsy has joined ##OpenGL[23:37:15] *** Twinklebear has joined ##OpenGL[23:38:32] *** stefkos has quit IRC[23:40:05] *** Twinklebear has quit IRC[23:41:37] *** hahuang61 has joined ##OpenGL[23:42:08] *** Twinklebear has joined ##OpenGL[23:45:01] *** lenarhoyt has joined ##OpenGL[23:46:46] *** abs25 has joined ##OpenGL[23:48:07] *** iKlsR has joined ##OpenGL[23:50:05] *** paperManu_ has quit IRC[23:51:55] <glararan> Any idea how to get back data from texture 2D array for specific layer?[23:52:31] <void256> https://www.opengl.org/sdk/docs/man/docbook4/xhtml/glGetTexImage.xml ?[23:52:51] <void256> with GL_TEXTURE_2D_ARRAY and level set to the layer you want?[23:53:12] <derhass_> level != layer[23:53:34] <void256> hmm, what's a layer?[23:53:36] <void256> o_O[23:54:30] <glararan> yea layer !=´level :D I studied that :D[23:54:44] <glararan> that's why I asking.. glGetTexImage is useless for layer selection :/[23:54:51] <derhass_> void256: layer is the layer of the array textur. level is the mipmap level[23:55:15] <derhass_> glararan: you can attach it to an fbo and read it back via glReadPixels[23:55:36] <glararan> hmm[23:56:16] <glararan> I attached texture to 2D array texture and I need to debug if there are correct data :D[23:56:44] <derhass_> glararan: what? you attached a texture to a texture array?[23:56:52] <glararan> image*[23:57:07] <void256> but but but I'm pretty sure when I've uploaded GL_TEXTURE_2D_ARRAY data I specified the layer as the level o_O[23:57:13] *** Biliogadafr has quit IRC[23:57:22] <derhass_> void256: no[23:57:23] *** BearishMushroom has quit IRC[23:57:23] <glararan> hmm :D[23:57:26] <void256> what?[23:57:35] <aethersis> all these mad bits of data flowing as electrons through billions of transistors with the speed of light[23:57:40] <aethersis> https://www.youtube.com/watch?v=IUZEtVbJT5c[23:59:30] <void256> derhass_: I meant of course the depth parameter of glTexImage3D ^^[23:59:55] <derhass_> void256: of course :)