November 26, 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 26, 2014 [00:00:26] <Codex_> tank093: and texture coords just go in normally as attributes[00:00:30] <t4nk093> ^ what?[00:00:39] <t4nk093> thats not what i asked[00:01:05] <t4nk093> do i have to bind the array texture and render all of those objects[00:01:18] *** neure has quit IRC[00:01:25] <t4nk093> and then bind the texture atlas and render all those objects[00:01:27] *** bjz has quit IRC[00:01:30] <t4nk093> 2 sepearte draw calls?[00:01:40] <slime> you could bind the array texture and non-array texture to separate texture units, and then draw it in one draw call, assuming your shader code handles that[00:01:46] *** neure has joined ##OpenGL[00:01:53] *** t4nk093 has quit IRC[00:02:08] *** t4nk107 has joined ##OpenGL[00:02:10] *** bjz has joined ##OpenGL[00:02:13] <slime> on the other hand it might noe be a good idea to do that[00:02:15] <slime> not *[00:02:23] <t4nk107> well that was annoying got dced for some reason[00:02:46] *** delicado has quit IRC[00:02:54] *** mukunda has joined ##OpenGL[00:03:07] <t4nk107> do i need 2 seperate draw calls for array texture and texture atlas object?[00:03:27] <t4nk107> or can all the objects be drawn with one call?[00:03:49] <slime> [19:01] <slime> you could bind the array texture and non-array texture to separate texture units, and then draw it in one draw call, assuming your shader code handles that[00:04:43] <Stragus> You probably want to split, and bind different textures and shaders[00:04:57] *** Baldwin has quit IRC[00:05:42] *** Baldwin has joined ##OpenGL[00:06:07] *** mukunda_ has quit IRC[00:07:45] *** anivemin has joined ##OpenGL[00:08:41] *** bkre_ has joined ##OpenGL[00:10:07] <t4nk107> slime thats the other thing[00:10:18] <t4nk107> what would the shader code be?[00:10:28] <t4nk107> 2 sampler varables?[00:11:02] <t4nk107> also how would it tell the difference between the 2 types of objects?[00:11:57] *** anivemin has quit IRC[00:12:19] <dca> i have rendering to texture which i then render to display.[00:12:19] <dca> but adding one more (smaller) output texture as GL_COLOR_ATTACHMENT1 corrupts the piece of screen space[00:12:27] <dca> what could be the problem?[00:19:34] <t4nk107> is there a way to tell the difference between 2 different types of objects in the shader?[00:20:00] <t4nk107> so you can use one sampler of a certain type and another sampler for the other type[00:20:11] <t4nk107> basically 2 textures[00:20:44] <foobaz> pass an int, switch on the int[00:20:50] *** shintah has quit IRC[00:24:22] *** bjz_ has joined ##OpenGL[00:25:50] *** luxigo has quit IRC[00:26:57] *** bjz has quit IRC[00:29:30] *** abs25 has joined ##OpenGL[00:30:04] *** bjz_ has quit IRC[00:31:24] *** ByronJohnson has quit IRC[00:33:09] *** Jeanne-Kamikaze has quit IRC[00:33:15] *** absof25 has joined ##OpenGL[00:33:25] *** ByronJohnson has joined ##OpenGL[00:35:08] *** meoblast001 has quit IRC[00:35:26] *** meoblast001 has joined ##OpenGL[00:36:21] *** abs25 has quit IRC[00:37:21] *** Zupo has joined ##OpenGL[00:37:40] *** snakenerd has joined ##OpenGL[00:37:55] *** Zupoman has quit IRC[00:39:30] *** snakenerd has joined ##OpenGL[00:40:43] *** snakenerd has quit IRC[00:42:34] *** paul424 has quit IRC[00:44:01] *** abs25_ has joined ##OpenGL[00:47:09] *** absof25 has quit IRC[00:47:45] *** garFF has quit IRC[00:51:34] *** staylor_ has quit IRC[00:53:09] *** pro_metedor has joined ##OpenGL[01:01:34] *** friden has joined ##OpenGL[01:02:40] *** jdolan has quit IRC[01:03:01] *** jdolan has joined ##OpenGL[01:10:10] *** bkre_ has quit IRC[01:10:22] *** hexagoxel has quit IRC[01:11:10] *** pro_metedor has quit IRC[01:12:10] *** hahuang61 has quit IRC[01:13:22] *** pazul has quit IRC[01:17:30] <Stragus> t4nk107, don't add such a memory load and branch in your shader, think how many millions times the operations will have to be performed[01:17:49] <Stragus> Don't be lazy and use two shaders :)[01:18:00] *** snakenerd has joined ##OpenGL[01:21:34] *** razieliyo has quit IRC[01:24:03] *** TyrfingMjolnir has joined ##OpenGL[01:24:37] *** ablephar` has quit IRC[01:25:20] *** snakenerd has quit IRC[01:28:47] *** derhass has quit IRC[01:31:52] *** indefini has quit IRC[01:31:57] <foobaz> think about how many millions of times he will be switching between shaders, that is an expensive operation too[01:36:14] <Stragus> That's only twice per frame, so that will take a while to reach millions[01:37:24] <roboman2444> Shader branches can be horribly slow[01:37:38] <roboman2444> especially if some pixels branch one way and other branch a different way[01:37:59] *** friden has quit IRC[01:38:13] *** mizux has quit IRC[01:38:19] *** friden has joined ##OpenGL[01:38:52] <glYoda> well control flow itself isn't necessarily expensive (beyond the cost associated with performing a logical test and the corresponding branch)[01:39:12] <glYoda> the expense comes with divergent control flow[01:39:55] <roboman2444> imagine a switch case in a shader[01:40:05] <foobaz> that is as divergent as it gets :)[01:40:05] <glYoda> what about it?[01:40:08] <roboman2444> where every pixel in a 16x16 block takes a different path[01:40:16] <glYoda> foobaz not necessarily[01:40:26] <glYoda> it can be but that isn't a requirement[01:40:41] <glYoda> furthermore this is heavily dependent upon how the compiler handles a switch construct[01:41:22] <glYoda> and discussing the worst case isn't terribly interesting to begin with… since this isn't a more common case one is likely to encounter[01:42:04] <glYoda> i.e. you'll find that it's very common to branch on uniform (i.e. non divergent) state within the shader[01:42:08] *** Crehl has quit IRC[01:42:23] <glYoda> at least in the realm of 3D[01:43:36] *** ruuns has quit IRC[01:44:30] *** cr`nge has quit IRC[01:45:13] <dca> guys, i render to texture using FBO. I want to scale down this texture a few times. what is an shortest way to accomplish that? use mipmap generation function?[01:46:25] *** konom has quit IRC[01:46:58] *** mtv has joined ##OpenGL[01:48:11] <mtv> this call to glTexImage2D has a data argument of 0[01:48:51] <mtv> right where you pass the array with image data, it takes a pointer to that, however there is only a zero in that argument[01:48:59] <slime> that would be a null pointer[01:49:11] <slime> which makes the function just allocate the necessary memory without uploading anything[01:49:23] <slime> er, create the texture without uploading data, rather[01:49:35] <slime> so you can call glTexSubImage2D later[01:49:41] <slime> or render to it[01:51:25] <mtv> okay, so once i bind a framebuffer, thats where glDrawTriangles will render to[01:51:32] <mtv> correct?[01:52:09] <slime> if you've attached the texture to the framebuffer object and such, yeah[01:54:30] <mtv> which framebuffer is the screen? clor_Attachment0?[01:55:18] <glYoda> the system drawable is always FBO ID zero[01:55:28] <glYoda> as per the spec[01:55:56] <mtv> yeah i'll just google search that next time[01:56:06] *** Twinklebear has joined ##OpenGL[01:56:33] *** anivemin has joined ##OpenGL[01:59:03] <chrisf> dca: glGenerateMipmap is the most concise way; if you need a specific filter, do it yourself[01:59:45] *** TyrfingMjolnir has quit IRC[02:00:22] *** mtv has quit IRC[02:00:24] <chrisf> dca: (or any other strange requirements)[02:00:26] *** TyrfingMjolnir has joined ##OpenGL[02:00:42] *** BitPuffin has quit IRC[02:00:48] *** anivemin has quit IRC[02:00:49] *** indefini has joined ##OpenGL[02:01:08] <dca> ok, thanks[02:01:19] *** bjz has joined ##OpenGL[02:01:32] <dca> after glGenerateMipmap all mimpaps will be acessible when sampling in shader?[02:02:44] <foobaz> yes[02:03:05] <foobaz> if you’re doing 3d, you should use anisotropic filtering instead of plain mipmaps[02:03:46] <foobaz> it is an extension to opengl, they can’t put it in core due to patent issues, but it’s supported by practically all GPUs[02:04:44] <dca> i just want to apply gaussian filters to scaled-down textures and blend it to original[02:07:04] *** LifeBlood has joined ##OpenGL[02:08:28] *** metredigm has joined ##OpenGL[02:15:42] *** konom has joined ##OpenGL[02:16:59] *** SleekoNiko has joined ##OpenGL[02:17:01] *** konom has joined ##OpenGL[02:18:42] *** abs25_ has quit IRC[02:22:41] *** Jonatan has quit IRC[02:22:58] *** Jonatan has joined ##OpenGL[02:23:20] *** Majiet has joined ##OpenGL[02:32:07] *** b4b has joined ##OpenGL[02:36:36] *** garFF has joined ##OpenGL[02:37:30] *** ikrima has joined ##OpenGL[02:39:48] *** metredigm has quit IRC[02:40:58] *** garFF has quit IRC[02:41:53] *** bjz has quit IRC[02:45:08] *** centrinia has joined ##OpenGL[02:49:19] *** roboman2444 has quit IRC[02:54:32] *** aphorisme has joined ##OpenGL[02:57:20] *** anivemin has joined ##OpenGL[03:01:43] *** Zerflag_ has quit IRC[03:01:53] *** anivemin has quit IRC[03:02:24] *** Zerflag has joined ##OpenGL[03:07:06] *** Zerflag has quit IRC[03:07:34] <aphorisme> Is there any reason to have two different buffer objects involved in the same vao?[03:08:16] <aphorisme> I'm always working with offset.[03:08:30] <aphorisme> But maybe I'm missing something.[03:09:06] *** Zerflag has joined ##OpenGL[03:11:06] <foobaz> yes, like if you want to pass some floats and some ints[03:11:25] <foobaz> that could be one vbo actually, but it could also be two[03:11:36] <foobaz> i always use one[03:11:39] <warchild> while we are on the subject of vaos, does anyone have any suggestions as to why a call to gldrawelements would segfault[03:11:51] *** mukunda is now known as mukunda_[03:12:07] <foobaz> maybe you would want to use two VBOs if one changes frequently, and the other never changes[03:12:08] <urraka> your IBO is bad, glDrawElements = NULL[03:13:30] <aphorisme> thanks.[03:17:04] *** Twinklebear has quit IRC[03:19:53] *** centrinia has quit IRC[03:21:45] *** shingshang has joined ##OpenGL[03:23:15] *** pizthewiz has quit IRC[03:26:52] *** aphorisme has quit IRC[03:29:09] *** Keniyal has quit IRC[03:38:02] *** zajfy has quit IRC[03:43:14] *** puerum has joined ##OpenGL[03:49:22] *** Hunts has joined ##OpenGL[03:49:32] *** Codex_ has quit IRC[03:52:20] *** HuntsMan has quit IRC[03:57:48] *** urraka has quit IRC[03:58:54] *** centrinia has joined ##OpenGL[04:05:45] *** xissburg has quit IRC[04:08:31] *** RockLee has joined ##OpenGL[04:09:30] *** phao has quit IRC[04:11:22] *** CainJacobi has joined ##OpenGL[04:12:03] *** b4b has quit IRC[04:13:21] *** TyrfingMjolnir has quit IRC[04:14:37] *** LifeBlood has quit IRC[04:16:13] *** LifeBlood has joined ##OpenGL[04:24:03] *** xishe has joined ##OpenGL[04:25:18] *** garFF has joined ##OpenGL[04:27:39] *** xish has quit IRC[04:29:46] *** garFF has quit IRC[04:30:24] *** TyrfingMjolnir has joined ##OpenGL[04:40:43] *** TyrfingMjolnir has quit IRC[04:41:14] *** Codex_ has joined ##OpenGL[04:46:07] *** anivemin has joined ##OpenGL[04:50:59] *** anivemin has quit IRC[04:52:16] *** TheGhostinator has quit IRC[04:52:45] *** samrat has joined ##OpenGL[04:53:12] *** Cabanossi has quit IRC[04:54:52] *** Cabanossi has joined ##OpenGL[05:01:06] *** Orion] has quit IRC[05:01:53] *** samrat has quit IRC[05:04:28] *** samrat has joined ##OpenGL[05:05:06] *** meoblast001 has quit IRC[05:14:54] *** TunnelCat has joined ##OpenGL[05:16:54] *** jdolan has quit IRC[05:17:28] *** jdolan has joined ##OpenGL[05:22:14] *** staylor_ has joined ##OpenGL[05:23:28] *** linuxuz3r_ has quit IRC[05:24:22] *** linuxuz3r has joined ##OpenGL[05:33:14] *** ikrima has quit IRC[05:51:23] *** samrat has quit IRC[05:52:19] *** TunnelCat has quit IRC[05:52:29] *** akaWolf has quit IRC[05:52:43] *** akaWolf has joined ##OpenGL[05:54:01] *** roboman2444 has joined ##OpenGL[05:54:34] *** CptRageToaster has joined ##OpenGL[05:58:58] *** descent__ has joined ##OpenGL[06:02:14] *** RyanPridgeon has quit IRC[06:02:33] *** RyanPridgeon has joined ##OpenGL[06:14:03] *** garFF has joined ##OpenGL[06:17:48] *** staylor_ has quit IRC[06:17:58] *** descent__ has quit IRC[06:18:34] *** garFF has quit IRC[06:21:11] *** Zupo2 has joined ##OpenGL[06:23:29] *** Zupo has quit IRC[06:29:22] *** qeed has quit IRC[06:29:28] *** ikrima has joined ##OpenGL[06:31:08] *** LifeBlood has quit IRC[06:33:21] *** ESphynx has joined ##OpenGL[06:33:33] <ESphynx> hey guys, if only stuff close to the camera seems to be properly lit up, what could that mean?[06:33:56] <ESphynx> (this is only happening on my Nexus 10, on desktop and Tegra Note things are fine :S)[06:34:54] *** anivemin has joined ##OpenGL[06:36:34] <slime> precision issues?[06:37:41] <dahlia> ESphynx: are you the one who showed me some c-like language you wrote once?[06:38:10] <dahlia> thought the nick was like yours[06:38:18] *** samrat has joined ##OpenGL[06:38:18] <ESphynx> dahlia: That would likely be me ( ec-lang.org )[06:38:30] <dahlia> ya I was trying to remember[06:38:43] <ESphynx> slime: I would doubt it's a precision thing :S I do have GL_NORMALIZE on :\[06:38:57] <slime> I mean for calculations inside the shader[06:39:04] <ESphynx> slime: 1.2 / no shader :P[06:39:24] <ESphynx> dahlia: I'm working hard on a GIS visualization SDK for eC now[06:39:30] <dahlia> ESphynx: I've been watching this guy's videos and it kinda reminded me of your thing https://www.youtube.com/watch?v=TH9VCN6UkyQ[06:39:40] <ESphynx> (I need to make videos)[06:39:41] *** anivemin has quit IRC[06:41:22] <ESphynx> there's like this line where things are dark and beyond they're bright :P[06:41:53] <dahlia> oh so it doesnt just fade?[06:42:18] <ESphynx> dahlia: well it sort of gouraud on those triangles[06:42:26] <ESphynx> but I think the vertices is either there's shading or it's 0[06:44:05] <dahlia> dunno, I kinda remember seeing it get darker as it moves away long ago when I was using fixed function but I dont remember what I did. My only guess is use a light direction instead of position[06:44:21] <ESphynx> thing is this is new in this new version of my software, the previous demos didn't do that so I'm wondering what I'm doing differently :P[06:44:45] <ESphynx> (and also so weird that it works fine on the Tegra note)[06:46:02] <dahlia> didnt know ffp worked on mobile[06:46:23] *** ikrima has quit IRC[06:46:41] <ESphynx> dahlia: it does with GLES 1.2[06:47:18] <ESphynx> after many years, I'm finally going to be moving away from the FFP this week ( I hope ) :P[06:47:27] <ESphynx> but I want to get this working properly first :P[06:47:36] *** Ephemeral has quit IRC[06:47:52] <dahlia> just do it. Shaders are fun :)[06:48:17] <ESphynx> I think they are, I just don't get why you can't keep a default shader that works like the FFP :P[06:48:43] <ESphynx> yeah it's really strange... I got lots of geometry and it's clear there that the computed light is '0' past a certain distance away from the camera[06:49:23] * dahlia agrees with slime[06:50:52] *** Ephemeral has joined ##OpenGL[06:50:59] <ESphynx> dahlia: on ?[06:51:13] <dahlia> might be precision[06:51:17] <ESphynx> precision issue inside my non-existent shader? :P[06:51:24] <ESphynx> but precision where? :P[06:51:49] <dahlia> dunno. isnt mobile usually half float in the gpu?[06:51:54] <ESphynx> http://stackoverflow.com/questions/13517867/opengl-objects-that-are-far-away-appearing-as-black -- hmm mipmapping problem[06:51:59] <dahlia> for fragment?[06:52:07] <ESphynx> I'm guessing that ^^^[06:52:19] <ESphynx> http://stackoverflow.com/questions/13517867/opengl-objects-that-are-far-away-appearing-as-black -- looks very much like that[06:52:32] <ESphynx> (3D minesweeper... interesting concept :P)[06:54:53] *** ikrima has joined ##OpenGL[06:54:56] *** fatalhalt has joined ##OpenGL[06:55:12] <Ephemeral> #indieproblems, converting ancient bullshit pure openGL code to SFML code.[06:57:11] *** mat^2 has quit IRC[06:57:30] *** RyanPridgeon has quit IRC[06:59:02] *** disappointment has quit IRC[06:59:17] *** Demon_Fox has quit IRC[07:00:17] *** LifeBlood has joined ##OpenGL[07:01:55] <roboman2444> Ephemeral, nah, you should be rewriting it to gl3 core stuff[07:02:00] *** ivan\ has quit IRC[07:02:01] *** ivan\_ has joined ##OpenGL[07:02:25] <ESphynx> didn't seem to be the mipmapping thing :S[07:04:08] *** ivan\_ is now known as ivan\[07:05:00] <ESphynx> glYoda: Om[07:05:38] <Ephemeral> roboman2444, I don't hvae the time to learn the root openGL stuff. :p[07:06:17] <roboman2444> you should tho[07:06:26] <roboman2444> great skill to have[07:08:13] <ESphynx> Hmm I'll try disabling the texture altogether :P[07:09:10] <ESphynx> nope definitely not the texture, so it's got to be something to do with the normals or light? :S[07:10:19] *** TyrfingMjolnir has joined ##OpenGL[07:15:46] *** akaWolf has quit IRC[07:16:24] *** akaWolf has joined ##OpenGL[07:19:07] *** Zerflag has quit IRC[07:22:22] *** t4nk107 has quit IRC[07:22:26] *** TyrfingMjolnir has quit IRC[07:23:23] *** Gamecubic has quit IRC[07:23:37] *** ikrima has quit IRC[07:24:52] *** Zupo2 has quit IRC[07:25:31] *** CptRageToaster has quit IRC[07:26:24] *** shintah has joined ##OpenGL[07:28:42] *** foreignFunction has joined ##OpenGL[07:29:28] *** fatalhalt has quit IRC[07:29:54] <ESphynx> since you guys have no answer for me I'm resorting to scotch :([07:33:41] *** DolpheenDream has quit IRC[07:36:22] *** Lemml has joined ##OpenGL[07:36:56] <Ephemeral> lols[07:40:34] <dahlia> too bad I dont drink, I could use some scotch after all this webgl $*@)[07:40:47] <Stragus> ESphynx, what kind of numbers are you dealing with?[07:40:55] <ESphynx> dahlia: I hope to start on WebGL tomorrow morning :P[07:41:17] <ESphynx> Stragus: center of the earth coordinates in meters?[07:41:19] <dahlia> ESphynx: I hope you like javascript :P[07:41:24] <Stragus> If the mobile ship uses half-floats internally (5 bits of exponent) and you use big coordinates, something's going to break[07:41:31] <Stragus> mobile chip*[07:41:33] <ESphynx> dahlia: I let Emscripten generate me JavaScript from eC :P[07:42:03] <ESphynx> Stragus: the thing is this works properly in my previous versoins :|[07:42:12] <dahlia> ESphynx: emscripten slower than painstakingly handcrafted javascript[07:42:30] <ESphynx> dahlia: I'll have to see what kind of results we get :|[07:42:34] <ESphynx> dahlia: another alternatie is NaCl[07:42:49] <dahlia> ya but then only chrome[07:43:06] <ESphynx> we saw something that brings it to other platforms...[07:43:11] <dahlia> and NaCL dev tools are horrid[07:43:15] <ESphynx> dahlia: have you had any experience with Emscripten's performance?[07:43:30] <dahlia> and the debugger is.... well I'm too polite to say[07:43:33] <ESphynx> dahlia: well hopefully we'll improve on that :)[07:43:47] <dahlia> ESphynx: yes[07:43:55] <ESphynx> dahlia: one way or another my goal is to get this GIS demo ready by Christmas :P[07:43:59] <Stragus> Eh well. ESphynx, I suspect you are exceeding half-float's exponent range[07:44:04] <ESphynx> dahlia: http://ecere.com/tmp/nzdemo2.jpg[07:44:08] <Stragus> If you were the one doing astronomical rendering[07:44:24] <ESphynx> Stragus: well not sure if the Eart qualifies as astronomical :P[07:44:43] <ESphynx> Stragus: but I do localize vertices[07:44:50] <dahlia> ESphynx: if you dont have much work to do quickly emscripten is pretty nice[07:45:03] <ESphynx> dahlia: I want performance :|[07:45:11] <dahlia> I found that stuff like sorting std::list is really slow[07:45:17] <ESphynx> But I was thinking if the Unreal engine works this should work? :)[07:45:25] <dahlia> and native javascript array sort much faster[07:45:27] <ESphynx> dahlia: oh I'm staying away from C++[07:45:50] <dahlia> ESphynx: the unreal demos Ive seen have very simple scenes[07:46:02] <ESphynx> dahlia: and all my sorting is usually done trough C's qsort which should nicely map to JS native sort I hope :)[07:46:36] <dahlia> well you can call JS pretty easily[07:46:55] <ESphynx> dahlia: From Emscripten?[07:46:56] <dahlia> but emscripten stuffs everything into typed arrays[07:47:05] <dahlia> code, data, all that[07:47:18] <dahlia> so native stuff would require marshalling[07:47:19] <ESphynx> dahlia: you seem to know a bunch about Emscripten :P care to help out? :P[07:47:35] <dahlia> ESphynx: sorry busy[07:47:41] <ESphynx> who isn't ;P[07:48:11] <dahlia> but the #emscripten channel on irc.mozilla.org is sometimes helpful[07:48:17] <ESphynx> yeah I saw that[07:48:24] <ESphynx> might be hanging out there this week :P[07:48:28] <ESphynx> but first I need to fix that lighting ;)[07:48:36] <ESphynx> dahlia: saw that shot above?[07:48:54] <dahlia> the Hawke's Bay thing?[07:48:56] <ESphynx> yeah[07:49:06] *** TyrfingMjolnir has joined ##OpenGL[07:49:09] <ESphynx> that's what I'm trying to get into the browser :P[07:49:29] <ESphynx> you can zoom down at ground level view as well with terrain :P it's all 3D[07:49:30] <dahlia> doesnt look difficult[07:49:58] <ESphynx> well I just need to port everything from FFP to shaders really :P[07:50:12] <ESphynx> and deal with all the Emscripten issues that come up[07:50:17] <dahlia> dynamic loading of meshes and textures and heightfields and all that stuff?[07:50:26] <ESphynx> yeah all that stuff.[07:50:43] <ESphynx> real time dynamically adjusting terrain meshes[07:50:57] <dahlia> ya browser event model and http stack make a lot of that pretty easy[07:51:22] <ESphynx> yeah the loading is the latter fun part :P[07:51:47] <ESphynx> i'm not even thinking about that yet :P Just wanna get some Emscripten stuff working and basic WebGL going and then I'll deal with fetching the data and all that :P[07:52:05] <ESphynx> not sure how I'll handle the 10gb of data :P[07:52:16] <dahlia> heh[07:52:23] <ESphynx> i'll probably need to upgrade servers ;)[07:53:21] <ESphynx> Stragus: So what do you think is being cut out?[07:53:29] *** TyrfingMjolnir has quit IRC[07:53:30] <ESphynx> My normal, vertices or the view matrix or what?[07:53:36] <ESphynx> the geometry does display fine at the right place[07:54:28] <dahlia> are your normals unit length?[07:54:54] <dahlia> hmmm does FFP use a rotation-only matrix in normals? I kinda thought maybe it doesnt[07:55:09] *** TyrfingMjolnir has joined ##OpenGL[07:55:21] <ESphynx> dahlia: they are :| I normalized them myslef and I set glNormalize[07:55:58] <ESphynx> there is GL_LIGHT_MODEL_LOCAL_VIEWER but I think this is only for specular lighting?[07:56:02] <ESphynx> and that thing doesn't exist in GL ES[07:56:57] <dahlia> and your lights are direction rather than position? I think for direction set w to 0[07:57:16] <dahlia> but I really dont know whats going on :)[07:57:28] <ESphynx> they are direction yeah , w set to 0[07:57:53] <ESphynx> (again everything's perfectly fine on the Tegra Note :P)[07:58:08] *** akaWolf has quit IRC[07:58:12] <dahlia> whats it not fine on?[07:58:17] <ESphynx> Nexus 10[07:58:32] <ESphynx> (also fine on the desktop)[07:58:50] *** akaWolf has joined ##OpenGL[07:58:59] *** telex has quit IRC[07:59:18] <ESphynx> I got 2 lights, one in view space and one in world space...[07:59:24] <ESphynx> both do the same[08:00:40] *** telex has joined ##OpenGL[08:02:19] *** CainJacobi has quit IRC[08:02:49] *** garFF has joined ##OpenGL[08:07:22] *** garFF has quit IRC[08:13:08] *** MLM has quit IRC[08:13:23] *** RockLee has quit IRC[08:15:24] *** Hunts has quit IRC[08:17:43] *** clauswitt has joined ##OpenGL[08:21:04] *** Madsy has quit IRC[08:23:37] *** anivemin has joined ##OpenGL[08:24:47] *** akaWolf has quit IRC[08:25:19] *** akaWolf has joined ##OpenGL[08:27:07] *** bb010g has quit IRC[08:28:40] *** anivemin has quit IRC[08:32:38] *** Beetny has joined ##OpenGL[08:33:08] *** samrat has quit IRC[08:40:36] *** samrat has joined ##OpenGL[08:46:18] *** ikrima has joined ##OpenGL[08:46:24] *** Khlorghaal has quit IRC[08:48:51] *** robot-beethoven has joined ##OpenGL[08:59:23] *** puerum has quit IRC[09:03:35] *** Burga has joined ##OpenGL[09:04:27] *** linuxuz3r has quit IRC[09:06:48] *** Folkol has joined ##OpenGL[09:12:28] *** xishe has quit IRC[09:14:05] <ra4king> What's the best strategy for updating a super tiny amount of memory (barely a few hundred bytes) per frame?[09:14:20] <ra4king> glBufferSubData is good or is mapping it a better strategy?[09:17:17] <Bloodust> Id imagine both being fine[09:17:32] <Bloodust> ofc persistent mapping would be the best, probably[09:17:39] *** Alina-malina has quit IRC[09:20:02] *** bjz has joined ##OpenGL[09:20:12] *** Alina-malina has joined ##OpenGL[09:20:12] *** Alina-malina has quit IRC[09:20:13] *** Alina-malina has joined ##OpenGL[09:22:33] <ra4king> Bloodust: for such a tiny amount of data though?[09:25:03] <Bloodust> I belive sync is a sync no matter how small data you need to update[09:26:40] <Bloodust> but since I have no real experience on this, I suggest you try it out[09:28:58] *** doev has joined ##OpenGL[09:29:30] *** Waynes has joined ##OpenGL[09:34:32] *** Madsy has joined ##OpenGL[09:37:26] <ra4king> Bloodust: heh, it's such a tiny amount of data that there is barely any need for a performance benchmark[09:37:29] <ra4king> I was just curious[09:39:18] *** zzuegg2 has joined ##OpenGL[09:39:26] *** anivemin has joined ##OpenGL[09:40:17] *** zzuegg has quit IRC[09:42:35] *** Waynes has quit IRC[09:44:18] *** anivemin has quit IRC[09:48:48] *** xgearx has joined ##OpenGL[09:50:23] <dahlia> are there any easy tricks for drawing normals (for debugging) in a ES 2 app? Like without needing to constricut a new vbo? I know I could just use a GS if I had 3 but I dont :([09:50:36] <dahlia> *construct[09:51:31] *** foreignFunction has quit IRC[09:51:34] <Bloodust> just output the normals from your fragment shader instead of color[09:51:35] *** garFF has joined ##OpenGL[09:51:55] <Bloodust> or do you want actual lines?[09:52:09] <xgearx> Hello! I use opengl es (android). I draw texture using ((GL11Ext) gl10).glDrawTexfOES() method. How can i do it with predefined angle of rotation relative to the center of texture (texture created from Bitmap)?[09:52:38] <Bloodust> Ive never heard of glDrawTexfOES :o[09:52:41] <dahlia> Bloodust: ya I want to see the lines so I can see the direction they point[09:53:06] <xgearx> glDrawTexfOES - https://docs.oracle.com/javame/config/cldc/opt-pkgs/api/jb/jsr239/javax/microedition/khronos/opengles/GL11Ext.html#glDrawTexfOES%28float,%20float,%20float,%20float,%20float%29[09:53:54] <dahlia> hmmm I guess color could kinda give a hint of direction[09:53:58] <Bloodust> xgearx why not just use normal opengl?[09:54:09] <Bloodust> like, glDrawArrays etc. ?[09:54:19] <xgearx> trying to suuport legacy project[09:55:00] <Bloodust> right well glDrawArrays has been supported since forever[09:55:16] <Bloodust> and if ES 1 doesnt support it, you can use glBegin/glEnd stuff[09:55:17] *** roxlu has joined ##OpenGL[09:55:45] <Bloodust> and with those you can just rotate the quad you are texturing[09:56:10] *** garFF has quit IRC[09:56:21] <slime> ES1 doesn't have glBegin/glEnd[09:56:25] <slime> it does have glDrawArrays though[09:56:37] <Bloodust> fancy[09:57:01] <Adrinael> A good thumb rule for what es1 has and doesn't have[09:57:07] <Adrinael> Useful and you want to use it? Nope.[09:57:30] <xgearx> Bloodust, maybe you can highlight some examples?[09:59:33] <Bloodust> umm[09:59:45] <xgearx> i mean, i have texture, how i can draw it with rotation using glDrawArrays[10:00:00] <Bloodust> you draw a quad[10:00:02] <Bloodust> rotate the quad[10:00:19] <Bloodust> and slap a texture on it[10:00:55] *** linuxuz3r has joined ##OpenGL[10:01:18] <xgearx> quad with size like texture size?[10:01:29] <Bloodust> I suppose[10:01:49] *** Alina-malina has quit IRC[10:02:35] <xgearx> inb4 - sorry for stupid questions because i am totally n00b in al gl stuf but trying to support gl (android related) code :([10:03:29] *** erhan_ has joined ##OpenGL[10:04:43] <Bloodust> this might help http://www.songho.ca/opengl/gl_vertexarray.html[10:05:52] *** Alina-malina has joined ##OpenGL[10:05:52] *** Alina-malina has quit IRC[10:05:53] *** Alina-malina has joined ##OpenGL[10:11:07] <slime> Adrinael: I'd say glDrawArrays is more useful than glBegin/glEnd[10:13:15] *** ivan\ has quit IRC[10:14:42] *** wutata- has joined ##OpenGL[10:17:02] *** Zerflag has joined ##OpenGL[10:17:27] *** anivemin has joined ##OpenGL[10:18:07] *** anivemin has quit IRC[10:21:04] *** redeemed has joined ##OpenGL[10:21:24] *** bjz has quit IRC[10:22:50] *** bjz has joined ##OpenGL[10:23:13] *** Tag_ has joined ##OpenGL[10:23:33] <Tag_> good morning[10:24:08] *** Alina-malina has quit IRC[10:24:30] *** Jeanne-Kamikaze has joined ##OpenGL[10:31:22] *** _ami_ has joined ##OpenGL[10:31:44] *** mat^2 has joined ##OpenGL[10:31:57] <_ami_> Hi. eglReleaseThread() s basically similar to eglMakeCurrent(dpy, NULL, NULL, NULL)?[10:32:19] *** linuxuz3r has quit IRC[10:32:47] <_ami_> Is it advisable to call eglReleaseThread()/eglMakeCurrent(dpy,NULL-3.) after eglTerminate()?[10:34:10] <_ami_> since eglTerminate() only marks the current context for pending deletion.[10:34:38] *** linuxuz3r has joined ##OpenGL[10:38:31] *** garFF has joined ##OpenGL[10:42:57] *** karab44 has joined ##OpenGL[10:44:23] *** navitsu has joined ##OpenGL[10:45:18] *** timsche has joined ##OpenGL[10:45:30] *** delicado has joined ##OpenGL[10:46:22] <delicado> hi are GL_CHAR as uniforms still consume a single component in GL_MAX_VERTEX_UNIFORM_COMPONENTS as if it were a 4 byte float?[10:51:48] *** ikrima has quit IRC[10:51:56] *** hdon has quit IRC[10:52:17] *** karab44 has quit IRC[10:55:31] *** karab44 has joined ##OpenGL[10:57:22] *** Zerflag has quit IRC[10:58:05] *** Zerflag has joined ##OpenGL[10:58:06] *** ozette has joined ##OpenGL[10:58:30] *** Keniyal has joined ##OpenGL[11:00:29] *** Zerflag_ has joined ##OpenGL[11:00:42] *** Zerflag has quit IRC[11:00:53] *** Tag_ has quit IRC[11:04:55] *** centrinia has quit IRC[11:05:18] *** Zerflag_ has quit IRC[11:07:34] *** TyrfingMjolnir has quit IRC[11:07:42] <AbigailBuccaneer> delicado, yes[11:08:02] <AbigailBuccaneer> but in OpenGL 3.0+ it's guaranteed to be at least 1024 so in reality this is not much of a problem[11:08:39] *** AbigailBuccaneer has left ##OpenGL[11:08:43] *** AbigailBuccaneer has joined ##OpenGL[11:09:25] <Adrinael> If it _is_ a problem, pack them to INT32 and bitwise the bytes out[11:10:04] <AbigailBuccaneer> i was just about to say, it may be more efficient to pack four one-byte uniforms into an int32 depending on the drivers, but typically not[11:19:36] *** navitsu2 has joined ##OpenGL[11:20:41] *** navitsu has quit IRC[11:24:20] *** navitsu has joined ##OpenGL[11:24:25] *** navitsu2 has quit IRC[11:26:32] *** Ad1_RnR has joined ##OpenGL[11:27:27] *** mat^2 has quit IRC[11:30:12] *** Ad1 has quit IRC[11:30:14] *** konom has quit IRC[11:33:07] *** mat^2 has joined ##OpenGL[11:41:15] *** hdon has joined ##OpenGL[11:43:48] *** Crehl has joined ##OpenGL[11:47:42] *** Jeanne-Kamikaze has quit IRC[11:48:17] *** sinanislekdemir has joined ##OpenGL[11:48:55] *** garFF has quit IRC[12:04:04] *** samrat has quit IRC[12:04:10] *** paul424 has joined ##OpenGL[12:06:57] *** clauswitt has quit IRC[12:08:49] *** ozette has quit IRC[12:16:03] *** karab44 has quit IRC[12:21:50] *** robot-beethoven has quit IRC[12:25:50] *** samrat has joined ##OpenGL[12:35:36] *** Crehl has quit IRC[12:36:26] *** Burga has quit IRC[12:47:36] *** clauswitt has joined ##OpenGL[12:56:36] *** doev has quit IRC[12:57:38] *** navitsu has quit IRC[13:00:17] *** mat^2 has quit IRC[13:02:59] *** mat^2 has joined ##OpenGL[13:17:51] *** _ami_ has quit IRC[13:20:30] *** paperManu_ has joined ##OpenGL[13:21:36] *** pazul has joined ##OpenGL[13:21:53] *** Beetny has quit IRC[13:22:07] *** centrinia has joined ##OpenGL[13:29:01] *** RyanPridgeon has joined ##OpenGL[13:29:32] *** indefini has quit IRC[13:31:10] *** snakenerd has joined ##OpenGL[13:32:09] *** erhan__ has joined ##OpenGL[13:32:57] *** erhan_ has quit IRC[13:33:42] *** erhan__ is now known as erhan_[13:36:03] *** Ryp has joined ##OpenGL[13:36:48] *** samrat has quit IRC[13:37:27] *** adsc has joined ##OpenGL[13:42:48] *** centrinia has quit IRC[13:43:42] <Ryp> hi ! Does anyone here is coding for a PBR engine ?[13:44:45] <AbigailBuccaneer> Ryp, if you have a question, it's better to ask it, than to try and find an audience for it before you do[13:49:54] *** Alina-malina has joined ##OpenGL[13:49:59] *** Alina-malina has quit IRC[13:49:59] *** Alina-malina has joined ##OpenGL[13:56:50] *** linuxuz3r_ has joined ##OpenGL[13:57:55] *** Folkol has quit IRC[13:59:32] *** linuxuz3r has quit IRC[14:03:12] *** paperManu_ has quit IRC[14:09:38] *** doev has joined ##OpenGL[14:10:29] *** indefini has joined ##OpenGL[14:11:38] *** xgearx has quit IRC[14:12:20] *** xgearx has joined ##OpenGL[14:13:09] *** urraka has joined ##OpenGL[14:15:25] *** BitPuffin has joined ##OpenGL[14:19:17] *** samrat has joined ##OpenGL[14:21:07] *** linuxuz3r_ has quit IRC[14:21:09] *** roxlu has quit IRC[14:22:41] *** paul424 has quit IRC[14:22:41] *** roxlu has joined ##OpenGL[14:23:54] *** Ryp has quit IRC[14:24:35] *** qeed has joined ##OpenGL[14:27:20] *** Ryp has joined ##OpenGL[14:28:02] <Ryp> AbigailBuccaneer you're right. does anyone who do PBR can tell me what textures he is binding to the shader, and if all the assets have to follow the same rules when bound to a shader ?[14:30:19] *** garFF has joined ##OpenGL[14:30:47] *** Zupo has joined ##OpenGL[14:34:57] *** marvimias has joined ##OpenGL[14:35:11] <marvimias> http://msdn.microsoft.com/en-us/library/windows/desktop/ee416307%28v=vs.85%29.aspx how do I set up the cascaded shadow frustum modelview matrices?[14:35:19] *** Ryp1 has joined ##OpenGL[14:36:33] <Bloodust> with math[14:36:54] <marvimias> Bloodust, Care to explain? :P[14:37:42] *** Ryp has quit IRC[14:38:08] <Bloodust> well you know how to construct a view frustum[14:38:17] *** Ryp1 has quit IRC[14:38:39] <Bloodust> just construct a bunch of view frustums that fit the description of CSM :D[14:39:23] *** Codex_ has quit IRC[14:39:23] *** ruuns has joined ##OpenGL[14:40:13] *** delicado has quit IRC[14:40:22] *** ntx has quit IRC[14:40:50] * Bloodust throws random CSM code at marvimias http://www.asawicki.info/news_1283_cascaded_shadow_mapping.html[14:41:27] *** Syzygy has joined ##OpenGL[14:43:44] *** CaptainSifff has joined ##OpenGL[14:44:21] *** TyrfingMjolnir has joined ##OpenGL[14:45:52] *** Syzygy has quit IRC[14:48:04] *** puckipedia has left ##OpenGL[14:49:39] *** [ESphynx] has joined ##OpenGL[14:49:42] <[ESphynx]> good morning guys[14:49:49] <[ESphynx]> I never could figure out my lighting problem last night :S[14:50:00] <[ESphynx]> the scotch didn't help :([14:50:49] <[ESphynx]> It's definitely not the normals and I can't see how it could be the lights either, and I tried with both textures and fog disabled...[14:51:06] <[ESphynx]> (not the lights -- they're directional, w = 0)[14:51:33] <Bloodust> fog? FFP fog?[14:51:49] <[ESphynx]> and re: it being the huge vertices value, the thing is the geometry does display fine where it's supposed to, and it previously worked on that device...[14:51:50] <[ESphynx]> Yes FPP[14:51:54] <Bloodust> haah[14:52:26] *** rosseaux has quit IRC[14:53:58] <[ESphynx]> Bloodust, my lighting works only close to the camera[14:54:19] <Bloodust> I cant help you, I dont understand FFP[14:54:36] <[ESphynx]> Bloodust, :P[14:55:25] *** Syzygy has joined ##OpenGL[14:58:59] *** rosseaux has joined ##OpenGL[15:00:00] *** sparky has joined ##OpenGL[15:00:28] <sparky> does anyone know if there's a way to ask opengl specifics about the gpu you're running on (like there is in OpenCL)?[15:00:40] <sparky> like, vendor, number of cores etc[15:01:09] <Bloodust> I belive amd and nvidia both have extensions for that[15:03:40] <sparky> I'm finding this but it's not very specific GL_VENDOR[15:03:49] <sparky> would be nice if it could provide a bit more info[15:05:35] <AbigailBuccaneer> sparky, GL_RENDERER[15:06:01] *** ville has quit IRC[15:06:48] *** Khruu has quit IRC[15:07:13] *** timsche has quit IRC[15:07:29] <marvimias> Bloodust, it's not that easy, but that's a nice link[15:07:35] <marvimias> I use opengl btw, but it should be nearly similar[15:08:00] *** shingshang has quit IRC[15:08:33] <marvimias> Bloodust, http://topbot.org/forum/index.php?/topic/2020-cubicus-voxel-game-in-java/page-3 that's my game btw[15:08:47] <Bloodust> Sorry, we couldn't find that![15:08:53] <Bloodust> You do not have permission to view this forum.[15:10:04] *** rosseaux has quit IRC[15:10:36] *** Jubb has quit IRC[15:10:47] <marvimias> Bloodust, http://i.gyazo.com/9db1c464c59aa8b9793d2b389612b259.png[15:10:54] <marvimias> http://i.gyazo.com/763e2ced6886ad3c987170dd367ad6e3.mp4[15:11:00] *** rosseaux has joined ##OpenGL[15:11:29] *** Folkol has joined ##OpenGL[15:11:32] <Bloodust> greedy meshing?[15:12:11] *** jdolan has quit IRC[15:12:26] *** Khruu has joined ##OpenGL[15:14:46] <Adrinael> sparky, there's GLX_MESA_query_renderer, for Mesa[15:15:03] *** mat^2 has quit IRC[15:15:10] <sparky> Adrinael: we're using stock opengl I'm afraid[15:15:21] <sparky> would be a bit much to switch just to get this feature[15:15:35] <sparky> it also has to work within Qt etc[15:17:22] *** ntx has joined ##OpenGL[15:19:24] *** zajfy has joined ##OpenGL[15:19:40] *** Ryp has joined ##OpenGL[15:20:20] *** pazul has quit IRC[15:20:43] *** shingshang has joined ##OpenGL[15:21:34] <marvimias> Bloodust, No, since I have lighting info per vertex[15:23:08] <sparky> Bloodust: any idea what that extension might be called[15:23:26] <sparky> say I wanted to knock things like clock speed or "cuda cores"[15:23:51] <sparky> that information is available as per tradition in opencl for instance but isn't very traditional information in graphics apis[15:23:52] *** Zupo has quit IRC[15:24:02] <sparky> are you aware of an extension to get something like that?[15:24:20] <Bloodust> I know theres an extension to get the memory information but dont know about the rest[15:24:48] *** Zupo has joined ##OpenGL[15:24:56] <marvimias> Bloodust, No, since I have lighting info per vertex[15:25:13] <Bloodust> yeah I heard you the first time :P[15:25:58] <sparky> memory information?[15:26:03] <sparky> as in how much? or speed?[15:26:14] <Bloodust> amount[15:26:26] <Adrinael> If you want the amount of cuda cores, use an nvidia extension. Cudas are nvidia stuff.[15:26:39] <Bloodust> http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt[15:29:58] <sparky> Adrinael: we've already established that[15:30:13] <sparky> we're trying to home in on which one. I'm not finding such an extension on their website[15:30:38] <Adrinael> Oh, I'm missing half of the conversation[15:30:50] <sparky> np[15:30:52] *** slidercrank has joined ##OpenGL[15:31:14] *** jdolan has joined ##OpenGL[15:32:00] *** pazul has joined ##OpenGL[15:32:05] <sparky> thanks Bloodust[15:32:12] <Bloodust> np[15:33:47] *** Zupo2 has joined ##OpenGL[15:34:18] *** ville has joined ##OpenGL[15:35:13] *** xissburg has joined ##OpenGL[15:36:30] *** Zupo has quit IRC[15:38:03] *** HaltingState has quit IRC[15:39:09] *** HaltingState has joined ##OpenGL[15:40:29] *** RockLee has joined ##OpenGL[15:48:31] *** [ESphynx] has quit IRC[15:51:56] *** pazul has quit IRC[15:59:31] *** SugarCube has quit IRC[16:00:07] *** SugarCube has joined ##OpenGL[16:01:24] *** clauswitt has quit IRC[16:02:16] *** Guest29953 has quit IRC[16:06:29] *** Jack_ has joined ##OpenGL[16:06:42] *** b4b has joined ##OpenGL[16:07:01] *** bjz_ has joined ##OpenGL[16:07:09] *** bjz has quit IRC[16:07:12] *** doev has quit IRC[16:09:33] <xgearx> Bloodust, let say i successfully draw bitmap texture using glDrawArrays. How i can apply rotation?[16:12:56] *** SugarCube has quit IRC[16:13:49] *** ij has left ##OpenGL[16:14:08] *** soulz has quit IRC[16:15:40] *** SugarCube has joined ##OpenGL[16:18:19] *** Portals has joined ##OpenGL[16:18:50] *** timsche has joined ##OpenGL[16:19:32] *** razieliyo has joined ##OpenGL[16:19:32] <Portals> My glMapBufferRange scales my texture (only using the most lower left pixel) across the whole screen. But when I use glBufferSubData with the same data, it works.[16:20:49] <Portals> Bloodust, you know what the problem is?[16:22:13] <Bloodust> just rotate the quad with a rotation matrix[16:23:06] *** telex has quit IRC[16:24:00] <Portals> The problem isn't that it is scaled.[16:24:40] *** telex has joined ##OpenGL[16:25:06] *** sinanislekdemir has quit IRC[16:25:09] *** Gamecubic has joined ##OpenGL[16:25:25] <Portals> I can show you the problem on twitch, if you want to help[16:26:58] *** garFF has quit IRC[16:27:49] *** BreadProduct_ has joined ##OpenGL[16:28:12] <Bloodust> your problem is, you dont know how to rotate a quad?[16:29:46] *** Portals has quit IRC[16:30:52] *** BreadProduct has quit IRC[16:32:33] *** BreadProduct__ has joined ##OpenGL[16:32:34] *** BreadProduct__ is now known as BreadProduct[16:33:52] *** RockLee has quit IRC[16:34:01] *** BreadProduct_ has quit IRC[16:38:23] *** BearishMushroom has joined ##OpenGL[16:38:46] *** Syzygy_ has joined ##OpenGL[16:42:45] *** Syzygy has quit IRC[16:44:29] <sparky> glYoda: hey yoda, you around?[16:45:52] *** Ryp has quit IRC[16:46:07] *** ville has quit IRC[16:47:28] *** Ryp has joined ##OpenGL[16:47:38] <xgearx> Bloodust, yes, i should use glRotatef ?[16:48:22] *** ville has joined ##OpenGL[16:51:26] *** MLM has joined ##OpenGL[16:52:39] *** Ryp1 has joined ##OpenGL[16:55:23] *** luxigo_ has joined ##OpenGL[16:56:54] *** Ryp has quit IRC[16:58:01] <Bloodust> xgearx in es1 yes[16:58:18] *** TyrfingMjolnir has quit IRC[17:00:36] *** doev has joined ##OpenGL[17:02:58] <ESphynx> So I tested my old app , and it still works fine, no lighting issue :S[17:03:09] *** neure has quit IRC[17:03:26] *** Keniyal has quit IRC[17:04:11] *** Ad1 has joined ##OpenGL[17:05:46] <sparky> ESphynx: bump this![17:05:57] <ESphynx> sparky: bump what?[17:06:02] <sparky> this[17:06:07] <ESphynx> this++ ?[17:06:25] <sparky> it's a catch-phrase. I like bump mapping :)[17:06:27] <ESphynx> add a bumpmap?[17:06:40] <ESphynx> I tried doing some bumpmappnig with the FFP[17:06:43] <ESphynx> hit a wall :P[17:06:46] <ESphynx> I tried real hard :P[17:06:59] <Bloodust> hahaha[17:07:00] <sparky> did they phase out the dot3 combiner[17:07:03] <ESphynx> but now I just want my lighting to work as it obviously does in my other app... I so don't get it[17:07:03] <Bloodust> why even bother :D[17:07:21] <ESphynx> sparky: tried with the DOT3 yeah... but yeah so much not working as it should[17:07:29] <ESphynx> Bloodust: I stopped bothering[17:07:35] <ESphynx> now I just bother about this bug[17:07:46] <ESphynx> before I can finally lay OpenGL 1.2 to rest and move on to shaders...[17:07:51] <sparky> ESphynx: an example of a platform which does not support pixel shaders doing bump mapping --> http://lukasz.dk/files/ps2_normalmapping.pdf[17:07:54] <Bloodust> 1.2 jesus[17:07:58] <ESphynx> Please... Help! (imagine me as Leeloo)[17:08:02] <sparky> using alpha blending modes to achieve the dot product[17:08:09] <sparky> one channel at a time[17:08:22] <sparky> and a sphere map to achieve (sort of) per pixel normalization of the interpolated light vector[17:08:29] *** xgearx has quit IRC[17:08:41] <ESphynx> sparky: that is quite cool[17:09:16] <ESphynx> sparky: that is sort of what I had tried... but I failed.[17:09:22] <sparky> the difficult part was achieving results identical to a signed dot product using unsigned multiply adds of alpha blending but it works[17:09:56] <ESphynx> I don't quite remember where I went wrong[17:10:37] <ESphynx> but as I initially thought I'd just quickly test this DOT3 thing and get it to work and ended up wasting lots of time, I had to move on[17:10:51] <ESphynx> (knowing when I move on to shaders I'd get proper Dot3 mapping)[17:11:11] <sparky> section 3.2 has the details on that part[17:11:15] *** Khlorghaal has joined ##OpenGL[17:11:19] <sparky> how to achieve the dot product using alpha blending operations[17:11:43] <sparky> I am not sure this route will have you spending any less time :)[17:11:51] <sparky> but at least it's an example of prior success :)[17:15:41] <ESphynx> sparky: that's precisely the route I attempted[17:15:51] <ESphynx> I don't remember my conflusion as to why it failed :S[17:16:06] <ESphynx> thought I had a branch somewhere with my attmeps :P[17:16:29] <ESphynx> ah 'bumpMappingAttempts' :)[17:16:49] <sparky> the problem could perhaps be the combining channels part[17:17:00] <ESphynx> sparky: yeah I think you need multiple rendering passes?[17:17:03] <sparky> the PS2 allows you to add values with modulo 255 instead of clamping[17:17:19] <ESphynx> I do'nt think I wanted to do multiple rendering passes[17:17:32] <sparky> so you can basically do (Red+Green)%256 instead of clamped[17:17:32] <ESphynx> as that required too much tweaking of the rendering stuff[17:17:49] <sparky> oh this definitely requires multiple passes yes[17:17:59] <ESphynx> yeah... when I started on this attempt I had not fully realized that[17:18:13] <ESphynx> and when I realized that I think I decided to forget about it and come back to bumpmapping when I have shaders :P[17:18:16] <sparky> main reason is on ps2 you would have to pass the value to alpha on each attempt[17:18:28] *** Zerflag has joined ##OpenGL[17:18:32] <sparky> so first pass you pass X to alpha[17:18:35] <sparky> then Y to alpha[17:18:38] <sparky> and then Z toalpha[17:18:48] <ESphynx> ah yeah eh[17:19:01] <ESphynx> anyways, saved the paper for the sake of interest :P[17:19:06] <sparky> and each time you generate Red, then Green and then Blue but you have to feed the right value into source alpha which is why it requires 3 passes[17:19:09] <ESphynx> but I don't think I'll ever attempt that with the FFP :)[17:19:11] <sparky> (on a ps2)[17:19:22] *** metredigm has joined ##OpenGL[17:19:27] <sparky> mind you that ffp has fancier blendmodes than a ps2[17:19:31] <ESphynx> sparky: did you work for square enix or something? :P[17:19:36] <sparky> so I am not entirely sure you'd need as much complexity[17:19:49] <ESphynx> sparky: any hint for me on my lighting bug? :P[17:19:51] <sparky> IO-Interactive at the time[17:19:57] *** Gamecubic has quit IRC[17:20:00] <ESphynx> cool :)[17:20:09] <ESphynx> oh they are owned by Square Enix now! :P[17:20:15] <sparky> today they are yes[17:20:23] <ESphynx> I wasn't that far off :P[17:20:28] <sparky> I moved to the US and worked for sony for about 5 years[17:20:39] <sparky> and then finally moved back to square (I'm now with Crystal D)[17:20:57] <sparky> in cali[17:21:01] <ESphynx> nice :)[17:21:05] <Bloodust> heh, crystal D[17:21:10] <ESphynx> sparky: My geometry far away is dark :P[17:21:10] <sparky> :)[17:21:27] <ESphynx> my lights are fine, my normals are fine, things are fine on the tegra and desktop, but dark on the Nexus 10 :P why on Earth[17:21:38] <ESphynx> What could I possibly be doing all wrong :P[17:21:43] *** metredigm has quit IRC[17:22:22] <sparky> ESphynx: well if you're not using shaders I don't really know how to help you I'm afraid[17:22:35] <sparky> I don't know much about ffp on Nexus[17:22:49] *** shintahW2 has joined ##OpenGL[17:26:05] *** shintahW has quit IRC[17:26:06] *** shintahW2 is now known as shintahW[17:29:53] <sparky> ESphynx: next project, skinshading in ffp[17:29:55] <sparky> :)[17:30:07] <Bloodust> haha[17:30:49] *** Orion] has joined ##OpenGL[17:31:42] <ESphynx> :P[17:36:43] *** BreadProduct has quit IRC[17:38:02] *** doev has quit IRC[17:39:51] *** mat^2 has joined ##OpenGL[17:42:39] *** matpow2 has joined ##OpenGL[17:42:41] *** wutata- has quit IRC[17:42:48] *** matpow2 has quit IRC[17:45:50] *** Sound has joined ##OpenGL[17:46:00] *** luxigo_ is now known as luxigo[17:47:55] <ESphynx> got it[17:48:20] <ESphynx> elucidated my mystery...[17:48:27] <ESphynx> I had 2 instances of my 'nearPlane' variable :P[17:48:32] <ESphynx> pretty sure that's it[17:48:58] *** Match has joined ##OpenGL[17:52:23] *** marcheu has quit IRC[17:52:29] *** marcheu has joined ##OpenGL[17:55:56] *** redeemed has quit IRC[17:57:05] <ville> fun compilers can emit warnings if you shadow global or class variables with function locals[17:57:38] *** centrinia has joined ##OpenGL[18:02:37] *** kuldeepdhaka has joined ##OpenGL[18:03:55] *** erhan_ is now known as bionic_man[18:09:52] *** sparky has quit IRC[18:10:14] *** t4nk339 has joined ##OpenGL[18:14:25] *** t4nk339 has quit IRC[18:15:27] *** Jack_ has quit IRC[18:17:54] *** RockLee has joined ##OpenGL[18:20:44] *** timsche has quit IRC[18:21:25] *** Gamecubic has joined ##OpenGL[18:21:29] *** adsc has quit IRC[18:33:27] <ESphynx> nice, got all my lighting now :P[18:33:43] <Stragus> What was the issue finally?[18:34:26] <ESphynx> Stragus: I was previously fixing this stuff up by setting my near plane to the 'n' value of the frustum, and then setting n to 1 and dividing all other parameters that that 'near plane' value[18:34:41] <ESphynx> turns out I had 2 instances in my 2 libraries of this 'nearPlane' and I wasn't doing this properly anymore :P[18:35:07] <ESphynx> i.e. the device being picky about the projection matrix[18:35:19] <Stragus> And that caused lighting issues?...[18:35:22] <ESphynx> Yeah.[18:35:30] <ESphynx> I had fought with this in the past and worked around it[18:35:32] <Stragus> Geometry was still visible but with incorrect lighting? Or are you performing multiple passes?[18:35:39] <ESphynx> but I had forgotten all about it[18:35:50] <ESphynx> single pass. geometry still visible yes, incorrect lighting.[18:35:57] <Stragus> That is weird[18:36:05] <ESphynx> yeah well I think it's buggy.[18:36:09] <ESphynx> but I had worked around the bug[18:36:14] <ESphynx> and forgot all about the work around :P[18:36:23] <Stragus> :) Right[18:37:04] <ESphynx> thanks for the moral support everyone :P[18:37:26] <ESphynx> the thing now though... Tegra Note has got only 1 GB of ram and a somewhat decent GPUb[18:37:43] <ESphynx> but Nexus 10 has got a less than capable GPU despite but at least its got 2 GB of ram[18:37:59] <ESphynx> the former terminates my app for using too much mem while the latter just lags :P[18:38:06] <ESphynx> me thinks I need a Nexus 9 :P[18:38:26] <Stragus> You can fit a lot of stuff in 1GB[18:38:36] <ESphynx> Stragus: seems my app can only use 325 mb or so[18:38:40] <ESphynx> before getting terminated :([18:38:58] <Stragus> What uses so much? Vertices, textures or what?[18:39:02] <ESphynx> been cutting fat and stuff and still going to try more[18:39:07] <ESphynx> vertices I think right now.[18:39:11] <ESphynx> this area map[18:39:22] <Stragus> Then you need levels of details and/or loading/unloading on the fly[18:39:26] <ESphynx> Stragus: http://ecere.com/tmp/nzdemo.jpg[18:39:30] <ESphynx> I do have all that.[18:39:43] <ESphynx> but when looking towards the horizon there's quite a bit visible :P[18:40:11] <Stragus> Right, you'll need more aggressive levels of details there...[18:40:18] *** bionic_man has quit IRC[18:40:33] <ESphynx> still I find 325 mb rather restrictive :P[18:40:46] <ESphynx> but I need to inspect in more details where the memory goes :)[18:40:59] <Stragus> I hope every little bump of that rendering isn't based on triangles, you use normal maps or such?[18:41:08] <ESphynx> Stragus: I actually have both :P[18:41:17] *** RockLee has quit IRC[18:41:43] <Stragus> The level of detail isn't comparable but this used very low memory: http://www.rayforce.net/newproject031.png[18:41:45] <ESphynx> the sunshading map is a texture but there also is a lot of triangles, though I've reduced the details on Android[18:42:18] <ESphynx> Stragus: isn't comparable... as in what do you see as more detailed[18:42:45] <ESphynx> Stragus: as a fun sideline to my GIS work, I do hope to make games with nice terrain and that kind of look :P[18:43:05] <Stragus> What per-vertex data do you store?[18:43:20] <ESphynx> tex coord , normal, vertex?[18:43:28] <Stragus> In... floats?[18:43:38] <ESphynx> yeah[18:43:53] <ESphynx> the heavy map is that land cover[18:43:58] <ESphynx> it's using up 100 mb[18:44:06] <ESphynx> it's a bunch of small areas[18:44:08] <Stragus> Use 16 bits integers, and render in batches plus some X/Y/Z offsets[18:44:28] <ESphynx> I already do batches[18:44:38] <ESphynx> 16 bit integers... can I do that with FFP?[18:44:43] <ESphynx> with a scale I guess?[18:44:49] <Stragus> Oww, fixed pipeline[18:44:56] <Stragus> Hum. I don't actually remember[18:45:04] <ESphynx> in fact[18:45:06] <ESphynx> I'm rendering to texture[18:45:26] <ESphynx> so definitely should look into reducing that big area maps to 16 bit ints.[18:45:40] *** Misu has joined ##OpenGL[18:45:43] *** paul424 has joined ##OpenGL[18:45:43] <ESphynx> that would cut in half again[18:45:57] <Stragus> Yes, very rarely do you need floats for per-vertex data[18:46:03] <Stragus> Including normals and texcoords[18:46:10] *** jdolan has quit IRC[18:46:21] <ESphynx> yeah, wise thing.[18:46:29] <ESphynx> that's what I'm doing , cutting down the fat[18:46:32] <ESphynx> is that your terrain Stragus?[18:46:42] <Stragus> Yes[18:46:44] <ESphynx> What were you saying ishigher res? mine or that?[18:46:52] <ESphynx> I like the look of that :P[18:46:53] <Stragus> Yours seemed more detailed[18:47:07] <ESphynx> care to share what you have going on there? :)[18:47:11] <ESphynx> bump maps?[18:47:38] <ESphynx> the hill close to the camera 's got a nice look :)[18:47:46] <Stragus> Yes, bump maps mostly, nothing too special[18:47:59] <ESphynx> how do you do the trees? and the ripes / reflections on the water?[18:48:28] <Stragus> The trees are instances of the same geometry, all trees are just 4 polygons: http://www.rayforce.net/newproject032.png[18:48:52] <ESphynx> 4 polygons eh[18:49:02] <Stragus> The water was quite a shader trick though, it merges multiple "moving" normal maps which follow water flow, mostly visible in rivers[18:49:15] <Stragus> Rivers: http://www.rayforce.net/newproject024.png[18:49:19] *** huntercool has quit IRC[18:49:19] <ESphynx> Is yoru stuff open sourced? :)[18:49:25] *** RockLee has joined ##OpenGL[18:49:46] <Stragus> Not really, it was just a pet project some time ago, I had greater plans before the day work became crazy[18:50:21] <ESphynx> RayForce is your thing too?[18:50:27] <ESphynx> ray tracing?[18:50:32] <Stragus> Something from work, yes, CUDA raytracing[18:50:35] <ESphynx> CUDA ray tracing?[18:50:51] <ESphynx> that is the future :P[18:50:52] *** huntercool has joined ##OpenGL[18:51:21] <Stragus> They use it for heavy physic simulations rather than pretty rendering, hence the lack of eye candy[18:51:30] <ESphynx> ah[18:51:33] <ESphynx> cool stuff[18:52:02] *** abs25 has joined ##OpenGL[18:52:04] <ESphynx> it's LGPL rayforce?[18:52:12] <Stragus> Now that I think about it, the trees of 3 polygons were kind of fancy[18:52:18] *** japro has joined ##OpenGL[18:52:31] <Stragus> Yes, the public repostiory is probably very outdated. Some client just wanted it LGPL'ed long ago[18:52:38] <Stragus> of 4* polygons[18:53:56] <Stragus> The trees were raytraced with global illumination, automatically decomposed into 4 polygons to preserve the appearance from any angle, while generating proper normal maps for lighting[18:54:05] <ESphynx> nice[18:54:19] <ESphynx> so your engine is not using Rayforce?[18:54:24] <ESphynx> in those shots?[18:54:37] <Stragus> No no, it's OpenGL[18:54:49] <Stragus> I just put the screenshots on that server long ago. :p[18:54:54] <ESphynx> I want to do water like that and bumpmaps :P[18:55:05] <ESphynx> bump up the eye candy :P[18:55:07] <ESphynx> and trees :P[18:55:14] <ESphynx> and I love your skies too[18:55:14] <Stragus> The water looks nice in flowing rivers[18:55:21] <ESphynx> http://www.rayforce.net/newproject029.png -- pretty[18:55:27] <japro> bumpmaps... that is so retro :D[18:55:28] <ESphynx> I imagine it does!![18:55:37] <ESphynx> Stragus: do you sahre that code? :P[18:55:42] <Stragus> Now I feel like working on that project again :)[18:55:58] <Stragus> The shaders for the rivers?[18:56:02] <ESphynx> yeah[18:57:40] <Stragus> Looking into it, they may not make much sense without the support code[18:57:54] <ESphynx> cool :) thanks :)[18:58:17] <ESphynx> Stragus: I'm building a new WebGL / GL ES 2.0 / OpenGL 4.4 engine for Ecere :)[18:58:21] <ESphynx> and Gnosis[18:58:28] <ESphynx> and some games I want to make :)[18:58:41] <enleeten> Egames by ESphynx[18:58:44] <ESphynx> hehe[18:59:08] <Stragus> The basic idea is to have a normal texture with wave-like shapes, and every point of the map "flows" that texture in some direction (random or not) over time[18:59:35] <ESphynx> every point of the map 'flows' ?[18:59:44] <Stragus> All fragments between these 4 points just interpolate the four normals, with some sharpening that counter balances the smoothing[19:00:07] <Stragus> All point of the map has a surface water flow 2D vector[19:00:39] <Stragus> When flowing down a river, all nearby points will have a similar vector, so the waves will build up and you'll actually see flow in that direction[19:00:47] <ESphynx> all point of the map ... by map you mean your scene map (not texture map?)[19:01:09] <Stragus> On flat areas, the vectors are random and the little waves just cancel each other everywhere, looking like random water surface noise[19:01:10] <ESphynx> i.e. a current map? :)[19:01:13] *** soulz has joined ##OpenGL[19:01:18] <Stragus> Yes, the "world map"[19:01:23] <ESphynx> nice[19:01:28] *** Waynes has joined ##OpenGL[19:01:36] <ESphynx> I imagine I can generate that from altitude differences or what not? :)[19:01:59] <Stragus> Yes, for example[19:02:42] <ESphynx> the waves building up... you're modifying the normal texture?[19:02:46] <Stragus> Once you have your good-looking per-fragment normal, then you can do... fancy per-pixel lighting, shiny sun specular lighting, even reflections and refractions (which I didn't do)[19:03:06] <ESphynx> this sounds like so much fun[19:03:30] <Stragus> No no, the normal texture is fixed, but you are accumulating 4 different texels (normal texels) at any point[19:03:59] <Stragus> When all the map vectors point in the same direction, the waves build up and it looks like actual flow[19:04:10] *** soulz has quit IRC[19:04:19] <Stragus> Shaders are fun, that kind of stuff is relatively easy too[19:06:08] *** razieliyo has quit IRC[19:06:18] *** Twinklebear has joined ##OpenGL[19:06:19] <ESphynx> hope I get the chance to play with all that :P[19:06:20] *** meoblast001 has joined ##OpenGL[19:06:39] <Stragus> You need to step away from the fixed pipeline first :p[19:06:57] *** shingshang has quit IRC[19:07:12] *** soulz has joined ##OpenGL[19:07:48] <ESphynx> Stragus: yeah, that's sort of my goal of the day :P[19:08:04] <ESphynx> get this Android demo going relatively well then moving away from FFP[19:08:21] <ESphynx> though now I think I'll want to move away from per vertex floats and cut some more fat :P[19:08:27] <Stragus> Do you really targets platforms without GLSL?[19:08:45] <ESphynx> Stragus: historically I tried to support platforms that only have 1.2[19:08:53] <ESphynx> Solaris SunSparc machines :P[19:09:07] <ESphynx> from before 2000 :P[19:09:17] <Stragus> :) Yes well... These days, I try to support OpenGL 2.1 and up[19:09:40] <ESphynx> though from now on I'm really going to target GLSL and up[19:09:44] <Stragus> I have versions of my shaders working even on GLSL 1.2, but I wouldn't to lower than that[19:09:54] <Stragus> ... go* lower[19:10:02] <ESphynx> it's more a matter of getting a working demo with what I currently have before starting over :P[19:10:25] <ESphynx> I meant OpenGL 1.2[19:10:27] <ESphynx> not GLSL :P[19:10:44] <Stragus> I know :p[19:10:47] <ESphynx> hehe[19:10:53] <Stragus> But, over here, I target GLSL 1.2 and up[19:11:00] <Stragus> Which is still very old by any standard[19:11:20] *** Zupoman has joined ##OpenGL[19:11:38] <ESphynx> for sure[19:13:00] *** ShadowIce has joined ##OpenGL[19:19:25] *** bkre_ has joined ##OpenGL[19:19:50] *** Baldwin_ has joined ##OpenGL[19:21:53] *** Baldwin has quit IRC[19:22:40] *** ShadowIce has quit IRC[19:23:04] *** ShadowIce has joined ##OpenGL[19:23:30] *** Match has quit IRC[19:25:02] *** foreignFunction has joined ##OpenGL[19:26:07] *** zzuegg has joined ##OpenGL[19:29:14] *** zzuegg2 has quit IRC[19:30:14] *** ShadowIce has quit IRC[19:31:04] *** bkre__ has joined ##OpenGL[19:31:04] *** Ryp1 has quit IRC[19:31:13] *** Ryp has joined ##OpenGL[19:31:18] *** tehrain has joined ##OpenGL[19:31:54] *** bkre_ has quit IRC[19:33:01] *** Ryp has quit IRC[19:33:11] *** Ryp has joined ##OpenGL[19:36:13] *** sulky has quit IRC[19:37:39] *** jdolan has joined ##OpenGL[19:40:56] *** centrinia has quit IRC[19:42:23] *** luxigo has quit IRC[19:42:34] *** navitsu has joined ##OpenGL[19:44:06] <pink-rg> anyone here using GPUPerfstudio?[19:44:16] <pink-rg> it's really annoying that it locks your executable[19:45:12] *** RyanPridgeon has quit IRC[19:49:40] *** Ardi_2 has joined ##OpenGL[19:50:45] *** navitsu has quit IRC[19:52:34] *** paperManu has quit IRC[19:54:24] *** Ardi_3 has joined ##OpenGL[19:54:29] *** Ardi_2 has quit IRC[19:54:37] *** Ad1 has quit IRC[19:55:13] *** Sound has quit IRC[19:56:03] *** hahuang61 has joined ##OpenGL[19:57:55] *** centrinia has joined ##OpenGL[19:58:09] *** Ardi_4 has joined ##OpenGL[19:58:37] *** Biliogadafr has joined ##OpenGL[19:58:42] *** OliverUv has quit IRC[19:59:09] *** Ardi_3 has quit IRC[19:59:16] *** OliverUv has joined ##OpenGL[20:00:11] *** abs25 has quit IRC[20:02:07] *** paperManu has joined ##OpenGL[20:02:34] *** Ardi_5 has joined ##OpenGL[20:02:53] *** Ardi_4 has quit IRC[20:06:15] *** Ardi_6 has joined ##OpenGL[20:07:05] *** Ardi_5 has quit IRC[20:10:44] *** Ardi_7 has joined ##OpenGL[20:10:49] *** Ardi_6 has quit IRC[20:11:00] *** derhass has joined ##OpenGL[20:14:03] *** phaazon has joined ##OpenGL[20:14:08] *** phaazon has left ##OpenGL[20:18:41] *** Crehl has joined ##OpenGL[20:18:45] *** Ardi_7 has quit IRC[20:19:27] *** Ardi_7 has joined ##OpenGL[20:19:55] *** mbrittsess has joined ##OpenGL[20:20:46] <mbrittsess> Good afternoon[20:21:57] *** paperManu has quit IRC[20:22:05] <mbrittsess> I've got a question about OpenGL 4.x[20:22:46] <mbrittsess> I'm sketching out a design for a scripting language binding for OpenGL 4.x, and I've run into an issue with assigning values to Uniforms[20:23:28] <mbrittsess> I'd like my binding to throw an exception if you try to assign to a nonexistent Uniform[20:23:36] *** garFF has joined ##OpenGL[20:23:54] *** Misu has quit IRC[20:23:59] <derhass> mbrittsess: a) what has this to do with 4.x. b) why?[20:23:59] <mbrittsess> But I can't see a way to tell the difference between a Uniform which never existed to begin with (because you misspelled the name, for example), and a Uniform which was discarded by the compiler because it's unused[20:24:59] *** pizthewiz has joined ##OpenGL[20:25:04] <mbrittsess> glGetUniformLocation(), glGetProgramResourceLocation(), all just say that they return -1 for inactive variables, which, if I'm interpreting this correctly, is both nonexistent uniforms, and discarded uniforms[20:25:21] <mbrittsess> (among other things)[20:25:59] *** Keniyal has joined ##OpenGL[20:27:28] <Bloodust> turn off all optimization and compile[20:27:31] <Bloodust> get list of uniforms[20:27:41] <Bloodust> turn optimizations back on and compile[20:27:45] <Bloodust> get list of uniforms[20:27:49] <Bloodust> compare[20:28:49] *** Misu has joined ##OpenGL[20:29:33] <mbrittsess> How unintrusive can I make that? Is "turning off optimizations" something that affects the whole GL, or can it be used for just one shader compilation?[20:30:32] <slime> you can't usually turn off optimizations[20:30:55] <derhass> mbrittsess: there is no gl feature for that. some gl implmentations might support some pragmas[20:31:11] <mbrittsess> Sounds about right.[20:31:13] <derhass> but you should never rely on that[20:31:37] <mbrittsess> Is there really no way to tell the difference between nonexistent uniforms and discarded uniforms? It seems like a pretty big gap[20:31:50] <slime> you could parse the shader source[20:32:24] <derhass> mbrittsess: the gl explicitely considers trying to set nonexisting/nonactive uniforms not an error[20:32:36] <mbrittsess> I would rather not limit users of the binding, to only being able to use the exact form of shading language that my reinvent-the-wheel parser understands <_<[20:33:18] <marvimias> What is a modelview matrix?[20:33:20] <mbrittsess> Maybe the GL considers that, but from my point of view, trying to set the value of a uniform that never existed, is almost certainly an error, and something the developer would want to know about loudly and quickly. Hence, why I'm trying to make that throw an exception[20:33:22] <derhass> mbrittsess: I don't see why one would an exception in such a case[20:33:26] <marvimias> In OpenGL[20:33:43] <marvimias> https://www.youtube.com/watch?v=fGWHigI_1dY[20:33:48] <marvimias> Check that video out[20:33:51] <Stragus> mbrittsess, not necessarily. You may set the same values for a bunch of different shaders, and only some shaders actually use these values[20:33:55] <derhass> mbrittsess: but that view is quite limited. what about the case where different shaders might be selected, some with that uniform, some without?[20:34:00] <slime> marvimias: or you could make your thing notify them that it doesn't exist or was optimized out, without throwing an exception[20:34:02] <marvimias> I've got the sub-frustums part working[20:34:03] <Stragus> Would you want the code to have to track which shaders actually use which uniforms?[20:34:07] <slime> (it is also useful to know if a thing was optimized out)[20:34:23] <marvimias> like dividing the z-range[20:34:25] *** meoblast001 has quit IRC[20:34:37] <slime> er, mbrittsess*[20:34:44] <Stragus> I would say the issue is with you wanting to throw exceptions for something that should *not* be an exception of any sort[20:34:47] <marvimias> Anyone able to help me out?[20:34:54] <Stragus> It will only be more troublesome to use your wrapper[20:35:02] <slime> aye[20:35:42] *** t4nk845 has joined ##OpenGL[20:35:43] <mbrittsess> Well...let me put the usage case like this[20:36:10] <t4nk845> can anyone see anything wrong with this shader?[20:36:10] <marvimias> So you all know what a a modelview matrix is right? https://www.youtube.com/watch?v=fGWHigI_1dY Check that video out. I've got the sub-frustums part working. like dividing the z-range[20:36:11] <t4nk845> http://pastebin.com/DGyA3Qqk[20:36:21] <marvimias> http://msdn.microsoft.com/en-us/library/windows/desktop/ee416307%28v=vs.85%29.aspx[20:36:27] <mbrittsess> If you have a bunch of related shaders, which all nominally have a "BaseColor" uniform, some of which might not use it, then yeah, "Program.BaseColor = SomeColor" shouldn't throw an exception, even for the ones where it's discarded because it's not used[20:36:31] <marvimias> how do I set up the cascaded shadow frustum modelview matrices?[20:36:36] <mbrittsess> But if you did "Program.VaseColor = SomeColor"[20:36:51] <mbrittsess> Well, would you want that to fail silently, or throw a "No such uniform 'VaseColor'" error?[20:37:01] <slime> mbrittsess: neither[20:37:19] <t4nk845> that fragment shader doesn't seem to render anything[20:37:23] <mbrittsess> From the way I've always programmed, I've always tried to make it so that programmer mistakes are detected as automatically as possible[20:37:24] <slime> it should indicate that there's no such active uniform without throwing an exception, ideally[20:38:01] <ville> mbrittsess: then opengl is the wrong interface to be using[20:38:24] <marvimias> So you all know what a a modelview matrix is right? https://www.youtube.com/watch?v=fGWHigI_1dY Check that video out. I've got the sub-frustums part working. like dividing the z-range[20:38:25] <marvimias> how do I set up the cascaded shadow frustum modelview matrices?[20:38:32] <marvimias> http://msdn.microsoft.com/en-us/library/windows/desktop/ee416307%28v=vs.85%29.aspx[20:38:37] <mbrittsess> Okay, but it still gives you some kind of warning, even if it's not an exception[20:39:29] *** sulky has joined ##OpenGL[20:39:37] *** CainJacobi has joined ##OpenGL[20:40:09] <mbrittsess> I just think assigning to a discarded uniform is okay, and not something to concern the developer with, but assigning to one that never existed in the first place, *is* something the programmer should be informed of...and it seems strange that OpenGL gives no way to distinguish between the two and take my own action[20:40:14] <slime> mbrittsess: especially because it's useful to know that the uniform variable name isn't affecting final output, regardless of whether it's not a valid name or it was optimized out[20:40:25] <marvimias> Anyone?[20:40:48] <t4nk845> need some help[20:40:54] <t4nk845> http://pastebin.com/DGyA3Qqk[20:41:29] <t4nk845> its rendering just a black screen[20:41:49] <t4nk845> thats the fragment shader[20:42:51] *** Ardi_7 is now known as navitsu[20:43:09] <t4nk845> anyone?[20:43:41] <mbrittsess> Oh well, thanks for your help, everyone[20:44:32] *** paperManu has joined ##OpenGL[20:44:53] <derhass> t4nk845: have you already confirmed that the fragment shader is the issue?[20:45:06] <marvimias> So you all know what a a modelview matrix is right? https://www.youtube.com/watch?v=fGWHigI_1dY Check that video out. I've got the sub-frustums part working. like dividing the z-range[20:45:07] <t4nk845> yeah[20:45:11] <marvimias> how do I set up the cascaded shadow frustum modelview matrices?[20:45:14] <marvimias> http://msdn.microsoft.com/en-us/library/windows/desktop/ee416307%28v=vs.85%29.aspx[20:45:25] <t4nk845> if i remove the if else and just use one or the other it works fine[20:46:47] <derhass> and your uniform and textrue setup is correct?[20:47:29] <marvimias> Anyone able to help me?[20:48:15] <t4nk845> yeah as i said it renders one or the other if i remove the if else and only use one uniform[20:49:30] <derhass> t4nk845: well. thats exactly why I'm asking. in that case, one uniform will be optimized away[20:49:55] <t4nk845> what?[20:50:04] <t4nk845> optimized away?[20:50:05] *** stef has quit IRC[20:50:59] <urraka> maybe both uniforms are bound to the same texture unit or something, and it fails when both uniforms are used[20:51:53] *** stef has joined ##OpenGL[20:52:28] *** sulky has quit IRC[20:52:56] <t4nk845> no they are bound to seperate texture units[20:53:48] <t4nk845> is the syntax correct for the texture() function?[20:55:37] <marvimias> <marvimias> So you all know what a a modelview matrix is right? https://www.youtube.com/watch?v=fGWHigI_1dY Check that video out. I've got the sub-frustums part working. like dividing the z-range[20:55:37] <marvimias> <marvimias> how do I set up the cascaded shadow frustum modelview matrices?[20:55:38] <marvimias> <marvimias> http://msdn.microsoft.com/en-us/library/windows/desktop/ee416307%28v=vs.85%29.aspx[20:55:59] *** mbrittsess has quit IRC[21:01:32] <marvimias> Anyone able to help me?[21:04:44] *** RockLee has quit IRC[21:07:12] *** Jeanne-Kamikaze has joined ##OpenGL[21:08:06] *** BtbN has quit IRC[21:08:59] *** BtbN has joined ##OpenGL[21:13:14] *** jdolan has quit IRC[21:15:01] *** Waynes has quit IRC[21:15:45] *** ESphynx has quit IRC[21:15:55] *** samrat has quit IRC[21:16:19] *** ESphynx has joined ##OpenGL[21:17:34] *** samrat has joined ##OpenGL[21:19:46] <t4nk845> still need help herere[21:20:47] *** pizthewiz has quit IRC[21:22:11] *** samrat has quit IRC[21:22:15] *** pizthewiz has joined ##OpenGL[21:22:22] *** DolpheenDream has joined ##OpenGL[21:23:14] *** Garner has quit IRC[21:24:38] *** abs25 has joined ##OpenGL[21:24:50] *** Zerflag has quit IRC[21:26:47] *** Kane has joined ##OpenGL[21:31:27] *** CaptainSifff has quit IRC[21:31:38] *** Rutix has quit IRC[21:37:17] *** zagabar has quit IRC[21:37:32] *** elveni has joined ##OpenGL[21:37:42] *** zagabar has joined ##OpenGL[21:37:42] *** zagabar has joined ##OpenGL[21:39:18] *** b4b has quit IRC[21:39:58] *** xissburg has quit IRC[21:40:34] *** LifeBlood has quit IRC[21:40:50] *** b4b has joined ##OpenGL[21:41:01] *** hahuang61 has quit IRC[21:42:06] *** kuldeepdhaka has quit IRC[21:42:27] *** hahuang65 has joined ##OpenGL[21:48:13] <t4nk845> is there a way to convert vec3 (floating point vector 3d) to ivec3 (integer)[21:48:19] <t4nk845> in the shader code[21:48:37] *** staylor_ has joined ##OpenGL[21:49:53] *** roxlu has quit IRC[21:50:08] *** kuldeepdhaka has joined ##OpenGL[21:53:03] *** snakenerd has quit IRC[21:53:09] <t4nk845> hello?[21:53:59] <ESphynx> hi t4nk845[21:54:18] <ESphynx> t4nk845: my guess is there would be a way :) but I have yet a lot to learn about shaders :P[21:54:36] <derhass> t4nk845: ivec3(foo)[21:54:53] <ESphynx> good guess :P[21:54:58] <t4nk845> that didn't work[21:55:04] <derhass> that's not a guess[21:55:21] <derhass> t4nk845: what are you doing?[21:55:21] <ESphynx> derhass: I was referring to my guess that there would be a way :P[21:55:25] <t4nk845> ERROR: 0:15: error(#160) Cannot convert from: "const float" to: "highp 4-component vector of vec4"[21:55:52] <slime> what's your code?[21:55:54] <Stragus> Paste more code[21:57:09] <t4nk845> http://pastebin.com/yDh98gid[21:57:38] <chrisf> t4nk845: what driver are you running this against?[21:59:04] <t4nk845> uh why does the driver have to do with the error?[21:59:34] <derhass> well. it generates it[21:59:44] <derhass> and that error message doesn't make sense[21:59:53] *** centrinia has quit IRC[21:59:58] <chrisf> t4nk845: each driver contains its own shader compiler; that error message is nuts, and your shader looks fine.[22:00:21] <t4nk845> i thought the error message didn't make sense[22:00:33] <t4nk845> couldn't convert float to float?[22:01:19] <chrisf> you should reconsider lines 16-18 though -- did you mean to have an `else` there?[22:01:42] <Stragus> Crazy compiler[22:01:58] <Stragus> What about ivec2( (int)texCoord.x, (int)texCoord.y ); ?[22:02:13] *** Garner has joined ##OpenGL[22:03:02] *** SpicyShibe has quit IRC[22:03:40] <chrisf> t4nk845: actually, your texelFetch needs one more parameter -- third parameter is `int lod`[22:05:35] <derhass> chrisf: that one is optional[22:05:43] <t4nk845> Stragus: http://pastebin.com/WiiBTa1W[22:05:56] <t4nk845> ERROR: 0:15: error(#132) Syntax error: ")" parse error[22:06:30] <derhass> Stragus: glsl does not supprt typecasts[22:06:31] *** jdolan has joined ##OpenGL[22:06:31] <slime> the correct way to cast is to use int(foo) instead of (int) foo[22:06:44] <slime> but also, texelFetch takes unnormalized coordinates[22:06:47] <slime> so that won't do what you expect[22:07:13] <t4nk845> slime: ivec2(texCoords.xy) didn't work[22:07:16] <derhass> yeah. the code is weird, but it should compile (the original version, not the (int) one)[22:07:18] <chrisf> derhass: no, it's not optional for texelFetch.[22:07:23] <t4nk845> texCoords is a vec4[22:07:27] <derhass> chrisf: it is[22:07:28] <t4nk845> vec3 i mean[22:07:57] <Stragus> Sorry, ivec2( int(texCoord.x), int(texCoord.y) ); is what I meant, indeed[22:09:03] <chrisf> derhass: it is for various other texture lookup functions; not texelFetch.[22:09:20] <t4nk845> Stragus: the same error again but this time instead of )[22:09:24] <t4nk845> its says missing ;[22:09:57] *** Syzygy_ has quit IRC[22:10:02] <derhass> chrisf: read the spec[22:10:02] <slime> chrisf: the description in the glsl spec says "The level-of- detail 'lod' (if present) is as described in sections 2.11.7 under Texel Fetches and section 3.8 Texturing of the OpenGL Graphics System Specification."[22:10:13] *** konom has joined ##OpenGL[22:10:42] <slime> t4nk845: well, do you have a missing ; ?[22:10:56] <chrisf> derhass: slime: it is present in some overloads, depending on whether the sampler type *has* levels.[22:11:09] <slime> ah[22:11:29] <slime> yeah that makes sense, thanks[22:11:40] <t4nk845> slime: apparently i had a missing )[22:11:55] <t4nk845> the error is back to that nonsense at the start now[22:12:04] <t4nk845> ERROR: 0:15: error(#160) Cannot convert from: "const float" to: "highp 4-component vector of vec4"[22:12:09] *** Match has joined ##OpenGL[22:12:31] <derhass> chrisf: maybe I remember this incorrectly[22:12:34] <derhass> chrisf: hmmmmm[22:14:10] <t4nk845> the sampler type is sampler2D[22:15:40] <t4nk845> why does it say const float in the error[22:15:40] *** jdolan has quit IRC[22:15:52] <t4nk845> how is it const?[22:16:32] <derhass> that error message is just misleading[22:16:37] <derhass> are you sure it is for this shader?[22:17:10] *** jdolan has joined ##OpenGL[22:17:28] <t4nk845> yup the vertex shader doesn't have any casts[22:17:43] <derhass> t4nk845: but chrisf has a point: you should add the lod parameter[22:17:55] <t4nk845> what?[22:18:02] <t4nk845> isnt that optional?[22:18:15] <derhass> t4nk845: we came to the conclusion that it isn't[22:18:52] <urraka> in the reference docs it doesnt appear inside [][22:18:53] <derhass> chrisf: I now think you're right[22:19:06] <t4nk845> https://www.opengl.org/wiki/Sampler_%28GLSL%29[22:19:11] <t4nk845> it does appear inside [][22:19:37] <urraka> https://www.opengl.org/sdk/docs/man/html/texelFetch.xhtml[22:19:42] <urraka> https://www.opengl.org/sdk/docs/man/html/texture.xhtml[22:20:21] <t4nk845> ok wow[22:20:24] <t4nk845> that worked[22:20:28] <t4nk845> well done chrisf[22:20:36] <t4nk845> but........[22:20:46] *** apoc has quit IRC[22:20:50] <t4nk845> the stupid if else is still not working[22:22:06] <t4nk845> http://pastebin.com/5CfCsX00[22:22:35] <t4nk845> i think its something to do with non uniform flow control?[22:23:36] *** garFF has quit IRC[22:25:38] <urraka> are you sure the texCoords.z is right[22:26:37] *** aphorisme has joined ##OpenGL[22:26:50] <urraka> you could try some math to see if the 'if' is a problem but i dont see why it would be[22:27:31] <urraka> like mix(texture2, texture1, clamp(texCoords.z, 0, 1))[22:29:26] *** BitPuffin has quit IRC[22:29:46] <t4nk845> it renders stuff if outColor is assigned at the end to something not inside the non uniform flow control[22:30:32] *** paul424 has quit IRC[22:30:47] <derhass> that conclusion is wrong. the compiler will optimize out texAtlas completely again with yout code[22:30:49] <chrisf> t4nk845: you still have the problem of texelFetch expecting unnormalized coordinates.[22:31:27] <t4nk845> wait are they getting normalized somewhere?[22:31:44] <derhass> t4nk845: i hope so[22:31:54] <derhass> t4nk845: as texture() expects normalized texcoords[22:31:57] <chrisf> t4nk845: texture() takes 0..1; texelFetch takes 0..dim-1[22:32:42] <chrisf> t4nk845: i suppose the real question is -- why are you using texelFetch?[22:33:01] <japro> so i made some progress trying to come up with a fxaa like scheme that does better on diagonals (for very vectory data). i wonder if the "step" search can be reasonably done with some kind of binary search[22:33:14] <t4nk845> i am passing the texCoords as a vertexAttribPointer[22:33:25] *** Biliogadafr has quit IRC[22:33:25] <t4nk845> glVertexAttribPointer(1, 3, GL_FLOAT, false, 0, 0);[22:33:26] *** staylor_ has quit IRC[22:33:34] <t4nk845> the false should mean it doesn't normalize[22:33:57] <derhass> that parameter is something completely different[22:34:06] <derhass> it has no meaning for GL_FLOAT attributes[22:34:21] <t4nk845> no it says right in the specs that what thats supposed to ddo[22:34:56] <t4nk845> oh wait[22:34:57] <t4nk845> nvm[22:35:03] <t4nk845> misread that[22:35:04] <derhass> yes, it does :)[22:35:34] <t4nk845> so how do i pass it the unnormalized coords?[22:35:37] <derhass> t4nk845: how do you bind those textures, and how do you set up the uniforms?[22:35:49] <derhass> I really think that your shader is not the root cause[22:37:04] <t4nk845> how do you stop it from normalizing the coords?[22:37:19] *** Gamecubic has quit IRC[22:37:20] <derhass> it doesnt normalize things[22:37:28] <derhass> you provide the coords[22:37:45] *** Gamecubic has joined ##OpenGL[22:37:47] *** abs25 has quit IRC[22:37:49] <t4nk845> because i am passing it 0-1 for the texture() and 0-dim-1 for texelFetch[22:38:01] <derhass> that's correct[22:38:08] *** tehrain has quit IRC[22:40:03] <t4nk845> what do you mean thats correct? how do you stop it from normalizing those coords?[22:40:14] <derhass> it doesn't touch those coords[22:40:48] <t4nk845> ?[22:41:05] *** seangrov` has joined ##OpenGL[22:41:46] *** HuntsMan has joined ##OpenGL[22:42:15] <t4nk845> derhass: ?[22:42:27] <derhass> t4nk845: I don't know what else I could say[22:42:42] <derhass> t4nk845: nobody said that the GL would normalize your coords[22:42:45] <t4nk845> chrisf said it does normalize them?[22:43:00] <chrisf> t4nk845: texelFetch *expects* unnormalized.[22:43:04] <slime> t4nk845: texture() expects normalized coordinates, which you've provided presumably[22:43:11] <slime> texelFetch() expects unnormalized coordinates[22:43:16] <chrisf> t4nk845: you're passing the same thing to both, but converting one set to int[22:43:18] *** seangrove has quit IRC[22:43:29] <slime> normalized meaning in the range of [0, 1], and unnormalized meaning in the range of [0, dimensions)[22:43:43] <chrisf> t4nk845: which behaves like any normal float->int conversion; there is nothing else happening there.[22:44:00] *** telex has quit IRC[22:44:04] *** Lemml has quit IRC[22:44:41] *** telex has joined ##OpenGL[22:44:45] <t4nk845> what does any of this have to do with the if else?[22:44:57] <derhass> nothing[22:45:05] <slime> it has to do with what you're passing into texelFetch[22:45:22] <slime> your x and y coordinates will either be 0 or 1, rather than the expected full range of [0, dimensions)[22:46:06] *** paperManu has quit IRC[22:46:30] <t4nk845> slime i haven't normalized them anywhere so it should be getting 0- dim-1[22:47:09] <t4nk845> whenever i actually use the texture it gives[22:47:16] <chrisf> t4nk845: in that case, the coords passed to texture() won't make sense.[22:47:20] <slime> t4nk845: if your texCoords input ranges from [0, dimensions) then your texture() call will give unexpected values back[22:47:25] <slime> since texture() expects normalized coordinates[22:47:26] <chrisf> t4nk845: one of these is sensible; the other isnt.[22:48:34] <t4nk845> thats not the point, it doesn't matter what it returns[22:48:53] <t4nk845> its only given to outColor when it would not be undefined[22:49:20] <derhass> whatever that is supposed to mean[22:49:40] <t4nk845> the sampled values are merely stored in texture1 and texture2[22:49:53] <t4nk845> the if else statement decides what to give to outColor[22:50:01] *** Biliogadafr has joined ##OpenGL[22:50:17] <t4nk845> so it should always recieve a correctly sampled value[22:50:52] *** BearishMushroom has quit IRC[22:52:06] <derhass> assuming your multitexture setup is correct[22:52:50] <t4nk845> its not a multitexture[22:53:23] <derhass> you sample from both textures[22:53:25] <chrisf> t4nk845: oh, hang on -- are you encoding your coordinates cleverly[22:53:44] <t4nk845> chrisf: encoding?[22:54:05] <chrisf> so if z<1 then x,y are unnormalized; otherwise they are normalized ?[22:54:17] <t4nk845> yeah[22:54:37] <t4nk845> the zcoord is there for the array texture[22:55:05] <t4nk845> but in order to render both array texture and texture atlas objects in one draw call[22:55:20] <chrisf> right[22:55:22] <t4nk845> if the layer no: texCoord.z is 0[22:55:25] <derhass> apart from the issue that you cant sample your arry layer 0[22:55:27] *** garFF has joined ##OpenGL[22:55:33] <t4nk845> then it uses textureAtlas[22:55:38] <derhass> you still have a multi-texture setup[22:55:45] <derhass> the whole concept is weird[22:56:04] <chrisf> derhass: tricks to avoid breaking batches usually are[22:56:12] <t4nk845> derhass: what? you CAN sample layer 0[22:56:14] <urraka> he could give z = 0.00001 :p[22:56:26] <urraka> oh wait no[22:56:30] <urraka> he's doing < 1[22:56:53] <t4nk845> i am doing < 1 instead of == 0 because of floating point precision[22:56:57] <t4nk845> inaccuracy[22:57:18] <t4nk845> just to avoid as many sources of error as possible[22:57:24] <derhass> t4nk845: one can, your code can't[22:58:17] <t4nk845> derhass: if i remove the if else it can sample layer 0 just fine[22:58:31] *** Match_it has joined ##OpenGL[22:58:36] <chrisf> t4nk845: there's nothing wrong with your control flow. i'd verify that your sampler uniform setup is correct, and that you have the two textures bound and set up correctly[22:58:40] *** Match_it has quit IRC[22:58:52] <derhass> yeah. if you fix the bug, it goes away. that is not really surprising[22:59:22] *** Biliogadafr has quit IRC[22:59:51] *** glYoda has quit IRC[22:59:56] <t4nk845> chrisf: http://pastebin.com/tri1ZnYe[23:00:03] *** glYoda has joined ##OpenGL[23:00:08] *** Biliogadafr has joined ##OpenGL[23:00:11] <t4nk845> it seems to be set correctly[23:00:41] <t4nk845> derhass: what? its not a bug[23:00:54] <t4nk845> thats on purpose[23:01:27] <t4nk845> layer 0 is foregone to allow for a texture atlas[23:02:04] <urraka> that shows nothing about your sampler uniform and texture setup[23:03:42] <chrisf> t4nk845: btw, file a bug with your gl vendor about that crazy error message.[23:04:23] <t4nk845> amd radeon?[23:06:18] *** Dudi has joined ##OpenGL[23:08:30] <t4nk845> should i be using textureRect instead of texture2d?[23:08:58] <t4nk845> because it says something about Rect not having power of 2 restrictions on size[23:10:55] *** b4b has quit IRC[23:10:56] *** slime has quit IRC[23:12:29] *** slime has joined ##OpenGL[23:12:48] <chrisf> t4nk845: there havent been power of 2 restrictions on size for a long time.[23:14:58] *** foreignFunction has quit IRC[23:18:26] <chrisf> t4nk845: without the big picture it's difficult to give you good advice, though[23:19:13] *** urraka has quit IRC[23:22:55] <t4nk845> hmm[23:24:18] <t4nk845> chrisf: the active texture unit doesn't matter does it? when i call glDrawElements?[23:24:27] *** hahuang65 has quit IRC[23:24:49] *** jdolan has quit IRC[23:25:10] *** pink-rg has quit IRC[23:26:06] *** Dudi has quit IRC[23:31:06] <chrisf> t4nk845: for you, it only matters for binding, uploading, and setting texture parameters[23:31:20] <chrisf> t4nk845: it has no effect at draw time[23:31:36] *** japro has quit IRC[23:33:19] *** Biliogadafr has quit IRC[23:36:22] *** zzuegg has quit IRC[23:37:13] *** Keniyal has quit IRC[23:40:25] *** navitsu has quit IRC[23:41:16] *** zzuegg has joined ##OpenGL[23:42:42] *** seangrov` has quit IRC[23:46:34] *** Jeanne-Kamikaze has quit IRC[23:47:15] *** jdolan has joined ##OpenGL[23:50:47] *** Match has quit IRC[23:50:49] *** zzuegg has quit IRC[23:50:55] *** xissburg has joined ##OpenGL[23:51:47] <t4nk845> chrisf: ok for some weird reason the texture is a thick black vertical line near the beginning and then completly transparent for the rest[23:52:26] <t4nk845> i am not sure why its black because its using the exact same code to load the texture into the atlas[23:52:35] <t4nk845> as is used to load textures into the texture array[23:52:52] <t4nk845> i mean to read the images into a bytebuffer[23:53:24] <t4nk845> which is then passed in via glTexSubImage2D and glTexSubImage3D[23:54:13] *** paperManu has joined ##OpenGL[23:54:31] *** zzuegg has joined ##OpenGL[23:58:54] <t4nk845> this is really weird now[23:59:25] <t4nk845> Its the exact same code, how can it work perfectly for array textures then fail at normal gl_texture_2d