May 18, 2008 
< | 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 | 31 | >
May 18, 2008 [00:00:12] *** CNU_ has quit IRC[00:00:23] *** groton has joined ##OpenGL[00:04:03] *** LiraNuna has joined ##OpenGL[00:08:39] *** blbmp has quit IRC[00:11:51] *** Thunderbird has quit IRC[00:17:09] *** CNU has joined ##opengl[00:21:28] *** SmokingRope has joined ##OpenGL[00:22:42] *** neoneye has quit IRC[00:24:02] *** rutski has joined ##OpenGL[00:27:35] *** IJs\laptop has joined ##OpenGL[00:28:01] *** blbmp has joined ##OpenGL[00:29:43] *** jpin has joined ##OpenGL[00:33:01] *** rutski has quit IRC[00:39:11] *** huperniketes has joined ##OpenGL[00:40:39] *** huperniketes has quit IRC[00:42:02] *** Yustme has quit IRC[00:42:50] *** karabash has quit IRC[00:45:47] *** Darius_ has quit IRC[00:49:36] *** prophile has quit IRC[00:50:00] *** Xmas| has quit IRC[00:50:02] *** mastro has quit IRC[00:51:21] *** huperniketes has joined ##OpenGL[00:53:18] *** neunon has joined ##opengl[00:54:43] *** mastro has joined ##OpenGL[01:01:42] *** neoneurone has quit IRC[01:02:15] *** groton has quit IRC[01:03:54] *** scy has left ##opengl[01:05:36] *** DobosCake has quit IRC[01:10:22] *** ced117 has quit IRC[01:22:57] *** speedy1 has quit IRC[01:32:50] *** m4ggus has quit IRC[01:35:19] *** amalon has quit IRC[01:37:05] *** MatthiasM has quit IRC[01:37:11] *** MatthiasM has joined ##opengl[01:48:09] *** dvoid2 has quit IRC[01:56:24] *** ajww has quit IRC[02:00:08] *** hibread has joined ##opengl[02:06:59] *** ajww has joined ##OpenGL[02:07:42] *** Hanabi has joined ##OpenGL[02:16:51] *** Burga has joined ##OpenGL[02:33:49] *** charlie5 has quit IRC[02:33:54] *** charlie5 has joined ##OpenGL[02:40:22] *** Dew420 has joined ##OpenGL[02:41:31] *** Hanabi has quit IRC[02:58:43] *** TheLorax has joined ##opengl[03:02:48] *** norv has joined ##OpenGL[03:03:32] *** Dew420 has quit IRC[03:20:59] *** Amorphous has quit IRC[03:21:15] *** Xmas| has joined ##OpenGL[03:21:30] *** blight_ has quit IRC[03:21:30] *** speedy1 has joined ##OpenGL[03:22:06] *** Amorphous has joined ##opengl[03:22:14] *** lolage0 has quit IRC[03:26:01] *** HuntsMan has joined ##opengl[03:27:38] *** X-Scale has joined ##OpenGL[03:33:04] *** rutski has joined ##OpenGL[03:43:58] *** IJs\laptop has quit IRC[03:44:35] *** johnnyl has joined ##OpenGL[03:53:25] *** aalex has joined ##OpenGL[03:53:28] *** KU0N has quit IRC[03:59:19] *** Xmas| has quit IRC[04:07:36] <johnnyl> anyone looking for programming help?[04:07:50] <johnnyl> tassks rather[04:09:42] <rsp> I need help :([04:10:04] <rsp> For three days I've been trying to figure out why my tex coords are messed up when I use VBOs[04:21:39] *** rsp has left ##opengl[04:22:16] *** speedy1 has quit IRC[04:34:48] *** X-Scale has quit IRC[04:38:47] *** kattmat has quit IRC[04:39:08] *** johnnyl has quit IRC[04:45:59] *** mm765^sleep is now known as mm765[04:51:52] *** enoex has joined ##OpenGL[04:57:56] *** Lucine2 has joined ##OpenGL[04:58:16] *** Lucine has quit IRC[05:06:57] *** Narcotic has joined ##OpenGL[05:14:48] *** TheLorax has quit IRC[05:20:03] *** charlie5 has quit IRC[05:20:55] *** charlie5 has joined ##OpenGL[05:25:53] *** juanmabc has left ##opengl[05:40:09] *** Baba has joined ##OpenGL[05:40:40] *** Baba is now known as baballama[05:49:35] *** Dew420 has joined ##OpenGL[05:52:18] *** charlie5 is now known as charlie_phb[05:53:35] *** charlie_phb is now known as charlie5[06:02:38] <Ragnarok> whats the point of mipmaping[06:04:05] *** BahamutZERO has quit IRC[06:07:58] *** Walt has quit IRC[06:09:53] <ville> Ragnarok: to get decent texturing[06:10:02] <Ragnarok> oh ok[06:12:16] <ville> truth to be told they're for speed also[06:14:39] *** Dew420 has quit IRC[06:18:33] <glYoda> actually mip-mapping is advantageous WRT LOD calculation[06:20:04] <glYoda> as your mip-map levels will correspond to specific detail levels during rendering[06:20:10] *** Dew420 has joined ##OpenGL[06:21:44] <glYoda> this allows one to optimize by varying the detail level as depth (via the camera) increases[06:30:06] <Ragnarok> so I should always use mipmaping?[06:31:09] <glYoda> no like anything else you should use it when its needed[06:33:09] <Plagman> <rsp> For three days I've been trying to figure out why my tex coords are messed up when I use VBOs[06:33:15] <Plagman> you're probably doing something wrong[06:33:44] <Plagman> pastebin snippet of code rendering correctly w/o VBOs and snippet of code rendering incorrectly w/ VBOs[06:33:49] <Plagman> with the same data[06:34:02] <Plagman> actually, you're not there anymore so don't do anything[07:00:37] *** mm^away has joined ##opengl[07:05:47] *** mm765 has quit IRC[07:07:44] *** sohail has quit IRC[07:13:18] *** ajww has quit IRC[07:14:33] *** Burga has quit IRC[07:25:12] *** mm^away is now known as mm765[07:30:05] *** Dew420 has quit IRC[07:31:59] *** Dew420 has joined ##OpenGL[07:37:29] *** lolage0 has joined ##OpenGL[07:52:14] *** Narcotic has quit IRC[07:54:32] *** Dew420 has quit IRC[07:57:57] *** amz has quit IRC[08:01:47] *** nathan_ has joined ##OpenGL[08:05:08] *** blbmp has quit IRC[08:08:47] *** karabash has joined ##OpenGL[08:11:03] *** norv has quit IRC[08:12:25] *** nathan__ has joined ##OpenGL[08:12:35] *** jpin has quit IRC[08:12:45] *** nathan_ has quit IRC[08:13:15] *** Joakim has quit IRC[08:13:27] <karabash> hi[08:13:43] *** Joakim has joined ##OpenGL[08:14:28] *** neoneye has joined ##OpenGL[08:14:29] *** blbmp has joined ##OpenGL[08:16:42] *** replor has joined ##OpenGL[08:17:48] *** Darius_ has joined ##opengl[08:24:28] *** ced117 has joined ##OpenGL[08:28:21] *** Lucine2 has quit IRC[08:29:09] *** Burga has joined ##OpenGL[08:33:47] *** Lucine has joined ##OpenGL[08:37:02] *** huperniketes has quit IRC[08:37:03] *** lgbr has quit IRC[08:37:05] *** ohsix has quit IRC[08:37:05] *** sjd has quit IRC[08:37:06] *** quicksilver has quit IRC[08:37:06] *** bobbens has quit IRC[08:37:06] *** the_darkside_986 has quit IRC[08:37:07] *** memfr0b has quit IRC[08:39:11] *** memfr0b has joined ##opengl[08:39:17] *** lgbr has joined ##OpenGL[08:39:47] *** quicksilver has joined ##opengl[08:43:22] *** dolphin has joined ##OpenGL[08:44:01] *** huperniketes has joined ##OpenGL[08:44:10] *** ohsix has joined ##opengl[08:44:46] *** Dew420 has joined ##OpenGL[08:48:07] *** bobbens has joined ##opengl[08:53:23] *** sjd has joined ##OpenGL[08:53:23] *** the_darkside_986 has joined ##OpenGL[08:54:26] *** freeksh0w86_ has joined ##opengl[08:56:29] *** the_darkside_986 has quit IRC[08:57:54] *** sjd has quit IRC[09:02:44] <Ragnarok> i wish i could create shit like that[09:02:45] <Ragnarok> http://ohad.visual-i.com/exper/shots/terrain_shot_2.jpg[09:31:17] *** dvoid has joined ##OpenGL[09:33:02] *** groton has joined ##OpenGL[09:33:08] *** Joakim has quit IRC[09:33:23] *** Joakim has joined ##OpenGL[09:41:41] *** Joakim has quit IRC[09:41:42] *** joakim12 has joined ##OpenGL[09:48:28] *** nathan__ has quit IRC[09:48:42] *** nathan_ has joined ##OpenGL[09:51:21] *** Arc has joined ##OpenGL[09:51:29] <Arc> hey[09:51:58] *** amalon has joined ##opengl[09:52:20] <Arc> does anyone know off hand how to do a "glowmap" (texture applied in addition to standard diffuse texture which is uneffected by lighting/shading) with opengl 1.x?[09:55:45] *** reviver has joined ##OpenGL[10:00:30] <Arc> while I can make some educated guesses about glDisable(GL_LIGHTING) (is this specific to the active texture?), but I'm down to trial and error at this point[10:00:31] *** HuntsMan has quit IRC[10:00:36] *** HuntsMan has joined ##opengl[10:05:07] *** sohail has joined ##OpenGL[10:05:51] *** scy has joined ##opengl[10:14:55] *** blbmp has quit IRC[10:21:03] *** reviver is now known as reviver_[10:22:07] *** reviver_ is now known as reviver[10:23:57] *** Walt has joined ##opengl[10:24:10] *** reviver is now known as reviver__[10:25:01] *** reviver__ has quit IRC[10:25:19] *** reviver has joined ##OpenGL[10:31:58] *** Suprano has joined ##OpenGL[10:36:40] *** mm765 is now known as mm765^away[10:44:42] *** HuntsMan has quit IRC[10:46:38] *** gusano has quit IRC[10:49:21] *** JernejL_ has joined ##OpenGL[10:50:37] *** reviver has quit IRC[10:53:21] *** JernejL has joined ##OpenGL[10:56:00] *** charlie5 has quit IRC[10:56:39] *** Suprano has quit IRC[10:56:39] *** nathan_ has quit IRC[10:56:47] *** nathan_ has joined ##OpenGL[11:07:42] *** Jernej has quit IRC[11:09:03] *** JernejL_ has quit IRC[11:09:55] *** Yustme has joined ##opengl[11:16:16] *** charlie5 has joined ##OpenGL[11:22:54] *** Avidius has joined ##OpenGL[11:22:55] *** amalon has quit IRC[11:26:07] <Avidius> hi, does anyone know if opengl's 'Unproject()' call works the way i think it would? Like when it calculates a 3d world coord from a 2d mouse coord, does it stop at specific depth (say when its depth hits an object, like a terrain etc)?[11:28:52] <MatthiasM> no[11:29:15] <MatthiasM> look in the OpenGL SDK - link in the channel topic[11:34:24] *** nathan_ has quit IRC[11:34:39] *** nathan_ has joined ##OpenGL[11:35:14] *** hubbe3 has quit IRC[11:38:50] *** hubbe3 has joined ##OpenGL[11:39:36] *** Roderic has joined ##OpenGL[11:39:37] *** Roderic is now known as Ingenu[11:41:41] *** karabash has quit IRC[11:43:27] *** charlie5 has quit IRC[11:45:30] *** Suprano has joined ##OpenGL[11:58:31] *** Burga has quit IRC[12:10:29] *** dvoid has quit IRC[12:15:55] *** mm765^away is now known as mm765[12:19:56] *** LtJax has joined ##opengl[12:23:28] *** Obfuscate has quit IRC[12:23:48] *** Obfuscate has joined ##opengl[12:25:43] *** Avidius has quit IRC[12:32:21] *** dolphin has quit IRC[12:37:37] *** charlie5 has joined ##OpenGL[12:38:29] *** Bacta has joined ##OpenGL[12:38:44] <Bacta> How easy would it be to write a ray-tracing engine like that used in Wolfenstein 3D?[12:46:08] <Bacta> sorry ray casting[12:50:05] <Ingenu> what about checking whether the source code isn't available already ?[12:51:37] *** Suprano has quit IRC[12:51:46] <Bacta> Wolfenstein 3D code is[12:51:55] <Bacta> but the graphical functions are mostly written in assembler[12:52:00] *** Suprano has joined ##OpenGL[12:52:11] *** servus has quit IRC[12:52:43] <Ingenu> it shouldn't be difficult, although I see no reason to do that today (beside cheer fun if that's your thing[12:52:46] <Ingenu> )[12:56:02] *** Suprano has quit IRC[12:56:27] *** Suprano has joined ##OpenGL[13:05:28] <Bacta> Just seems like an interesting project[13:09:15] *** X-Scale has joined ##OpenGL[13:16:11] *** Sabman has joined ##openGL[13:18:25] *** Ademan has quit IRC[13:19:21] *** Ademan has joined ##OpenGL[13:26:20] *** dolphin has joined ##OpenGL[13:41:58] *** blight_ has joined ##opengl[13:42:22] *** dolphin has quit IRC[13:43:27] *** Suprano has quit IRC[13:45:53] *** Suprano has joined ##OpenGL[13:48:07] *** Xmas| has joined ##OpenGL[13:48:52] *** neoneurone has joined ##OpenGL[13:54:32] *** rsp has joined ##opengl[13:55:55] <rsp> hibread: hi[13:56:55] <rsp> I've cleaned up my code a LOT but it's still not enough to get rid of the tex coord problem http://www.tinyurl.com/668xkx[13:57:35] <rsp> Anyone here want to help? This problem is driving me insane it's got something to do with the tex coord VBO, I'll zip everything needed[13:58:01] <rsp> And yes, I have RTFM like 10 times and it's correct written[13:59:04] *** Suprano has quit IRC[13:59:09] *** Maerz has joined ##OpenGL[14:00:04] *** Maerz has joined ##OpenGL[14:00:35] *** Maerz is now known as Suprano[14:02:59] <MatthiasM> rsp: looks like one of your coordinates is stuck at 0 (or some other value) :)[14:06:02] <rsp> Ok :O[14:07:31] <rsp> www.sendspace.com/file/id9am7 as you can see in model.cpp I am uploading the tex coords correctly to the VBO afaik, I've RTFM a lot[14:08:19] *** dvoid__ has joined ##OpenGL[14:10:36] <MatthiasM> well - I won't look through several 100KB of stuff[14:10:52] <rsp> The vectors have the valid data[14:11:21] <MatthiasM> then your glTexCoordPointer calls are wrong[14:12:21] <rsp> glTexCoordPointer(2,GL_FLOAT,0,0);[14:12:26] *** rnx has quit IRC[14:13:14] <MatthiasM> rsp: it's easy - there are only 2 optionms: either the data is wrong - your your pointer setup :)[14:13:37] <rsp> Couldn't it be the way the data is loaded to the object[14:13:45] <rsp> I don't know how though[14:14:29] <MatthiasM> maybe everything is ok and the models should look like that ?[14:14:35] <rsp> No :P[14:15:15] <rsp> Do you know what it might be if the texture is repeated over a model when it should only be drawn twice[14:15:19] <MatthiasM> ^start with a simplier model - create a cube and load that[14:16:25] *** Suprano has quit IRC[14:16:28] *** Maerz has joined ##OpenGL[14:19:30] *** amalon has joined ##opengl[14:24:54] *** rutski has quit IRC[14:33:09] *** nadalizade2 has joined ##OpenGL[14:36:24] *** KU0N has joined ##OpenGL[14:43:38] *** BahamutZERO has joined ##OpenGL[14:44:42] *** nathan_ has quit IRC[14:45:01] *** nathan_ has joined ##OpenGL[14:47:52] *** Bacta has quit IRC[14:47:59] *** Suprano has joined ##OpenGL[14:48:31] *** IJs\laptop has joined ##OpenGL[14:58:10] *** m4ggus has joined ##OpenGL[14:58:16] *** nathan_ has quit IRC[14:58:27] *** nathan_ has joined ##OpenGL[15:01:46] *** aalex has quit IRC[15:04:00] *** Maerz has quit IRC[15:08:49] *** Sabman has quit IRC[15:10:14] *** charlie5 has quit IRC[15:12:57] *** charlie5 has joined ##OpenGL[15:15:25] *** Suprano has quit IRC[15:17:10] *** nathan_ has quit IRC[15:17:23] *** nathan_ has joined ##OpenGL[15:20:19] *** odietsch has joined ##OpenGL[15:20:30] *** Swords has joined ##OpenGL[15:22:36] *** ghenriks has quit IRC[15:25:24] *** nadalizade2 has left ##OpenGL[15:26:24] <MatthiasM> :)[15:27:26] <rsp> :([15:28:26] <hibread> what the fuck is that about!?![15:28:29] <hibread> :)[15:29:40] *** LtJ4x has joined ##opengl[15:29:47] <rsp> hibread: halp :([15:29:58] <rsp> I feel so owned by OpenGL[15:30:04] *** LtJax has quit IRC[15:32:24] <MatthiasM> did you try it with a simpliuer model ?[15:32:28] *** rsp has quit IRC[15:33:55] *** rsp has joined ##opengl[15:34:00] * rsp <3 Pidgin[15:35:37] *** Suprano has joined ##OpenGL[15:37:44] *** Swordsman has quit IRC[15:42:13] *** prophile has joined ##opengl[15:42:14] *** freeksh0w86_ has quit IRC[15:45:47] *** amalon has quit IRC[15:51:38] *** Tibor__ has joined ##OpenGL[15:52:12] *** scy has left ##opengl[15:56:40] *** Xmas__ has joined ##OpenGL[16:00:24] *** nathan_ has quit IRC[16:00:38] *** nathan_ has joined ##OpenGL[16:02:46] *** ced117 has quit IRC[16:04:55] *** juanmabc has joined ##opengl[16:10:12] *** Xmas| has quit IRC[16:12:40] *** m4ggus has quit IRC[16:14:21] *** m4ggus has joined ##opengl[16:18:04] *** cami has joined ##OpenGL[16:20:53] *** Diagmato has joined ##OpenGL[16:21:22] *** nathan_ has quit IRC[16:28:44] *** scrav has quit IRC[16:28:44] *** ville has quit IRC[16:29:40] *** scrav has joined ##OpenGL[16:29:45] *** rnx has joined ##opengl[16:35:44] *** cami has quit IRC[16:47:53] *** prophile has quit IRC[16:54:32] *** gusano has joined ##OpenGL[17:02:05] *** ville has joined ##opengl[17:05:14] *** mm765 is now known as mm765^away[17:06:14] *** hubbe3 has quit IRC[17:06:17] *** ata has joined ##opengl[17:06:23] *** ata has left ##opengl[17:07:01] *** Watermelon2 has joined ##OpenGL[17:07:02] *** hubbe3 has joined ##OpenGL[17:13:04] *** pfo has joined ##OpenGL[17:26:23] *** Walt has quit IRC[17:27:18] *** cami has joined ##OpenGL[17:29:09] *** miCam has joined ##OpenGL[17:29:34] *** neoneye has quit IRC[17:38:44] *** groton has quit IRC[17:39:31] *** IJs\laptop has quit IRC[17:46:08] *** cami has quit IRC[17:55:56] *** juanmabc has quit IRC[17:55:59] *** juanmabc_ has joined ##opengl[17:57:28] *** bbeausej has joined ##OpenGL[18:02:05] *** Walt has joined ##opengl[18:03:24] *** nplus has quit IRC[18:04:11] *** nplus has joined ##OpenGL[18:12:14] *** fargiolas has joined ##OpenGL[18:16:00] *** charlie5 is now known as charlie_zzz[18:18:14] *** m4ggus has quit IRC[18:23:41] *** m4ggus has joined ##OpenGL[18:24:22] *** gusano has quit IRC[18:28:13] *** Ragnarok has quit IRC[18:34:59] *** Ingenu has quit IRC[18:36:16] *** DobosCake has joined ##OpenGL[18:38:02] *** juanmabc_ is now known as juanmabc[18:41:17] *** scy has joined ##opengl[18:41:27] *** DobosCake has quit IRC[18:41:55] *** DobosCake has joined ##OpenGL[18:49:03] *** TheLorax has joined ##opengl[18:49:37] *** DobosCake has quit IRC[18:49:55] *** DobosCake has joined ##OpenGL[18:53:11] *** scrav has quit IRC[18:54:04] *** DobosCake has quit IRC[18:54:06] *** scrav has joined ##OpenGL[18:54:20] *** DobosCake has joined ##OpenGL[18:54:24] *** amz has joined ##opengl[18:58:24] *** Watermelon2 has quit IRC[19:02:44] *** DobosCake has quit IRC[19:03:20] *** DobosCake has joined ##OpenGL[19:04:05] *** Xmas__ is now known as Xmas|[19:07:47] *** lolage0 has quit IRC[19:08:47] *** DobosCake has quit IRC[19:18:17] *** Watermelon2 has joined ##OpenGL[19:23:10] *** amalon has joined ##opengl[19:26:15] *** m4ggus has quit IRC[19:28:30] *** Sabman has joined ##openGL[19:30:31] *** nytejade has joined ##OpenGL[19:36:05] *** mm765^away is now known as mm765[19:45:51] *** prophile has joined ##opengl[19:51:17] *** TheLorax has quit IRC[19:57:13] *** charlie_zzz is now known as charlie5[20:08:27] *** amalon has quit IRC[20:09:03] *** scy has left ##opengl[20:14:34] *** ulusoy has joined ##OpenGL[20:14:47] <ulusoy> hi[20:15:42] *** speedy1 has joined ##OpenGL[20:15:58] <ulusoy> i developed a cad software an i add 3. dimension[20:16:12] *** aalex has joined ##OpenGL[20:16:43] <ulusoy> i need help about selection[20:17:22] <ulusoy> everybody sleeping ?[20:18:24] *** ulusoy has left ##OpenGL[20:20:06] *** blbmp has joined ##OpenGL[20:23:01] *** blbmp has quit IRC[20:23:09] *** blbmp has joined ##OpenGL[20:25:28] *** Watermelon2 has quit IRC[20:29:53] *** mm765 is now known as mm765^sleep[20:32:45] <Jupp3> wow, he waited 2.5 minutes for an answer[20:32:52] <Jupp3> but didn't ask anything[20:32:58] <Jupp3> (except that if we are sleeping)[20:33:13] *** obmij has joined ##OpenGL[20:33:41] <obmij> anyone got a glVertexAttribPointer example?[20:33:59] <obmij> I'm trying to pass an array of floats for vec3 in GLSL through attribute[20:34:11] <obmij> I can't seem to be able to do it[20:34:15] <obmij> so anyone got an example code?[20:34:25] <prophile> what are you having trouble with?[20:34:34] <prophile> your shader's getting zeroes or what?[20:34:38] <obmij> yeah[20:34:39] <obmij> seems like it[20:34:46] <obmij> attribute vec3 whatever;[20:34:56] <prophile> and you're binding the attribute properly?[20:35:07] <obmij> well let me grab the 3 lines[20:35:10] <prophile> http://www.opengl.org/sdk/docs/man/xhtml/glBindAttribLocation.xml[20:35:33] <obmij> ok I was missing that[20:35:49] <obmij> no no hold on[20:35:54] <obmij> I wasn't[20:36:03] <obmij> 1 sec let me pastebin[20:37:04] *** Xmas| has quit IRC[20:38:26] <obmij> http://pastebin.ca/1022061[20:38:48] <obmij> anything missing there?[20:39:09] <obmij> oh wait[20:39:11] <obmij> I was missing bind[20:39:15] <prophile> yes[20:39:17] <prophile> yes you were[20:39:18] <obmij> go long names confuse me[20:39:25] <obmij> god*[20:39:52] <prophile> let's reduce all the gl functions to just the prefix 'g'[20:39:54] <obmij> Man don't you agree, OGL's got long arse function names[20:40:01] <prophile> and then replace all the rest of the name with the initial[20:40:07] <prophile> so instead of glVertexattribPointer[20:40:16] <prophile> we'd have glVAP[20:40:17] *** miCam has quit IRC[20:40:17] <prophile> *gVAP[20:40:18] <prophile> much nicer[20:40:19] <prophile> and then uh[20:40:23] <prophile> glBindTexture[20:40:24] <prophile> gBT[20:40:27] <obmij> :D[20:40:56] <prophile> then we'll reimplement it in C++ so we don't have to have the suffix for the different types, just override the thing[20:40:59] <prophile> *overload[20:42:51] *** hibread has quit IRC[20:45:00] <obmij> so I have to call this before Linking the shader program?[20:45:28] <glYoda> no you have to call this before using the program[20:45:59] <glYoda> you can link directly after compilation as this is completely independent of your uniform / attribute et al setup[20:46:47] <glYoda> OTOH when it comes time to use this particular program object you will need to properly define / setup those uniform(s), attribute(s) etc.[20:47:08] <obmij> So for simply a vec3 , it would be glBindAttribLocation (program,0,"tan"); // 0 because there's just 1 row![20:47:34] <obmij> attribute vec3 tan;[20:47:41] <obmij> in the vertex shader code[20:47:56] <prophile> correct[20:47:59] <obmij> great[20:48:04] * obmij goes to fix[20:48:25] *** Daigmato has joined ##OpenGL[20:56:21] *** neric_ has joined ##OpenGL[20:58:47] *** Sabman has left ##openGL[20:59:10] <obmij> if I have two separate attributes in my shader, I shouldn't do glBindAttribLocation (program,0,"att1"); and glBindAttribLocation (program,1,"att2"); right?[21:00:59] <glYoda> yes you need to bind *each* attribute / uniform[21:01:35] <obmij> I know that but[21:01:44] <obmij> I don't have to boost up the index by 1 each time[21:01:49] <obmij> because that is meaningless isn't it?[21:02:01] *** neric has quit IRC[21:03:20] <speedy1> haug glYoda :)[21:04:02] <glYoda> ?[21:04:18] <obmij> glYoda I see others doing it... is it really meaningful?[21:04:38] <obmij> imagine I have vec3 att1 then mat4 att2 and then vec3 att3[21:04:57] *** Diagmato has quit IRC[21:04:59] <obmij> the index for att1 and att3 bind location call should be 0... right?[21:05:10] <speedy1> (haug - native-american word for greetings)[21:05:48] <glYoda> obmij yes its meaningful[21:06:23] <glYoda> being that you really don't want all attribute / uniform location(s) mapped to the same index[21:06:28] <obmij> so it should be 0 for att1 1 , 2 , 3 , 4 for att2's 4 rows and 5 for att3?[21:07:18] <glYoda> generally speaking there is a 1:1 mapping for location -> index[21:08:03] <obmij> and index should be 'row' wise, so a mat3 would take up 3 'indicies'[21:08:20] <glYoda> for ( i = 0; i < N; ++i ) { ... set attribute / uniform [ i ] = i; ... }[21:13:09] <obmij> oh wait it's column major[21:15:16] *** fifthrune has joined ##OpenGL[21:15:25] *** TurboAWAY has quit IRC[21:16:32] <fifthrune> Hello all. I am having a screen flickering problem with OpenGL vid/apps. I have an Intel 945 GMA vid card. Disabling compiz-fusion does not remove the flickering.[21:17:43] <phrosty> this channel is for opengl progamming, you'd be better to ask in ##linux[21:18:56] <fifthrune> oh ok. wasn't sure, thanks for clearing that up[21:19:48] <obmij> http://www.opengl.org/sdk/docs/man/xhtml/glBindAttribLocation.xml , the 2nd paragraph of Description is confusing me[21:20:16] *** fifthrune has left ##OpenGL[21:20:30] <obmij> and there seems to be built in indicies as well, is there a chance I might conflict with those?[21:21:49] <obmij> if I'm using GL_VERTEX_ARRAY and if I Bind Attrib "att1" to index 0 wouldn't those conflict or something?[21:26:16] <speedy1> obmij: yup they could conflict[21:26:51] <speedy1> also, nvidia and ati are not fully in agreement on which one has preference when you enable both[21:27:33] <obmij> so I have to be funny aware of what GL_..._ARRAY I have active[21:27:36] <obmij> fully*[21:27:37] <speedy1> so best thing is to play it safe and avoid conflicts by disabling all attribs which are not used[21:27:48] *** dv_ has joined ##OpenGL[21:28:09] *** prophile has quit IRC[21:28:12] <obmij> speedy1, can you explain the 2nd paragraph of that manual page?[21:28:23] <obmij> 2nd paragraph of Description[21:29:06] <glYoda> what exactly seems to be the problem here?[21:29:10] <obmij> for a mat3 must I do for example (program,index,"matrix[0]") (program,index+1,"matrix[1]") (program,index+2,"matrix[2]")[21:29:37] <obmij> index being for example 3 texcoords I aint using[21:29:40] <glYoda> i + 0, i + 1 == mat2, i +0, i +1, i + 2 == mat3, ... for matN[21:29:50] <speedy1> noup[21:29:55] <obmij> glYoda would the function calls look like I mentioned?[21:30:15] <speedy1> no need to use [1] indirections if I recollect correctly[21:30:16] <glYoda> since we like to count from zero[21:30:49] <speedy1> Other matrix columns are then[21:30:50] <speedy1> automatically bound to locations[21:30:57] <obmij> oh[21:30:59] <speedy1> automatically is the magic work[21:31:01] <speedy1> word[21:31:16] <obmij> so if I bind "matrix" to index being for example 10[21:31:22] <obmij> 10,11 and 12 are used up[21:31:23] <speedy1> yup[21:31:25] *** neric_ has quit IRC[21:31:26] <obmij> so next time I have to think about 13[21:31:39] <glYoda> and yes those other ( + 1, +2, +3, ... + N) attribute / uniform locations are transparently handled by the server[21:31:52] <glYoda> which the link you were given also clearly states[21:32:09] <glYoda> you only need to worry about i + 0[21:32:12] <glYoda> or i[21:32:24] <obmij> but next time I can't use i+1[21:32:31] <obmij> for some future bind, can I?[21:32:32] <glYoda> correct[21:32:40] <obmij> ok[21:33:06] <obmij> hmm[21:33:09] <glYoda> basically the server will tightly pack your attribute / uniform matrix data[21:33:19] <obmij> now the only question remains, how do I make sure I'm not bothering an already used up index[21:33:58] <glYoda> well you should already know what you are using on the client side...[21:34:18] <obmij> yeah I do but indices differ for ATI and nVidia[21:34:45] <glYoda> ignore what speedy1 stated for a moment since that is completely irrelevant to your problem here[21:34:52] *** juanmabc has quit IRC[21:35:12] <obmij> no no somewhere on opengl.org I read[21:35:18] <obmij> http://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/attributes.php[21:35:40] <glYoda> specifically note the following statement in the manual page linked earlier -- "Applications are not allowed to bind any of the standard OpenGL vertex attributes using this command, as they are bound automatically when needed. Any attribute binding that occurs after the program object has been linked will not take effect until the next time the program object is linked."[21:35:56] <glYoda> i.e. let the GL server transparently handle this for you[21:36:16] <glYoda> the server will handle the built-ins[21:37:38] <glYoda> and yes Nvidia (heh) made a complete cluster-fuck out of this unfortunately[21:37:54] *** prophile has joined ##opengl[21:38:03] <obmij> god damn[21:38:17] <glYoda> and there isn't much you can do about that other than to offset any custom attributes to a index greater than whatever they are using for their built-ins[21:38:28] <obmij> mhm[21:38:37] <glYoda> as per usual blame Nvidia for this[21:39:01] <obmij> but I guess most huge game/graphics designers/programmers have these in mind already[21:39:04] <obmij> so it's the norm[21:39:17] <prophile> glYoda, I remembered my question[21:39:20] <prophile> so like[21:39:23] <prophile> a few weeks ago I asked you what GPU I should get[21:39:24] <prophile> and you told me[21:39:26] <prophile> and I forgot, and put it to the back of my mind[21:39:29] <prophile> now i'm getting kernel panics off this GPU[21:39:35] <prophile> so I probably do need to upgrade[21:39:38] <prophile> what was it you suggested I get?[21:40:05] <speedy1> btw. why are you rebinding the attrib locations at all?[21:40:08] <glYoda> obmij well working over vendor fuck-ups is a frequent occurrence in this business yes[21:40:29] <obmij> speedy1, getting rid of GL_..._ARRAYs for a change :/[21:40:34] <obmij> but I guess I[21:40:39] <speedy1> glyoda: it's not that bad - you just need to disable the attribs which are not used and all works[21:40:52] <speedy1> and not count on precedence between built ins and generics[21:41:01] <obmij> naw speedy1[21:41:02] <glYoda> speedy1 its never that bad when you don't mind doing it[21:41:13] <obmij> so you know[21:41:27] <glYoda> I OTOH would prefer if Nvidia handled this shit transparently as *hint* other vendors do[21:41:32] <speedy1> the precedence is not really well defined in the docs[21:41:44] <obmij> you know[21:41:50] <speedy1> obmij: I just link the program and query the assigned indices[21:41:54] <obmij> I think I'll just stick to *buffers[21:42:09] <obmij> and not worry about attribute totally[21:42:12] <obmij> it's the safest[21:42:29] <obmij> don't you agree?[21:42:36] <glYoda> prophile R580, RV630, RV670, ... are all fine[21:42:44] <obmij> glBindBuffer ?[21:42:50] <obmij> eh? :)[21:43:16] <obmij> and use vertex Color for tangents or whatever[21:43:29] *** |t4bz| has joined ##OpenGL[21:43:32] <obmij> because I don't know whether my program will go on an nVidia card or an ATI card or an Intel card[21:43:37] *** t4bz has quit IRC[21:44:19] <obmij> nVidia is a pretty nasty irresponsible 'entity' for an 'industry leader'[21:44:44] <obmij> "oh screw the standard, we do things OUR way!"[21:44:47] <speedy1> nah, don't listen to ATI fanboy propaganda ;)[21:45:01] <obmij> naw I know the ATI fanboys are crazy :D[21:45:10] <obmij> but I'm just looking at the situation I have at hand right here[21:45:19] <obmij> my card is an nVidia GeForce 8800 GTX btw[21:45:26] <obmij> and back when I bought it 9800 wasn't out[21:45:29] <obmij> so it was the highest-end[21:45:50] *** HuntsMan has joined ##opengl[21:45:50] <obmij> eVga btw[21:45:56] <obmij> had to put $680 CAD ;D[21:45:58] <obmij> $80 for tax[21:47:35] <glYoda> LOL I think its well known that Nvidia routinely tried to push forwards their own "standards" when it comes to this marketplace.... anyone who would disagree w/ this is foolish[21:48:07] <glYoda> lets see here... Cg, NV_[vertex, fragment]_program, CUDA, ... the list goes on[21:48:26] <glYoda> now whether or not this is a "bad thing" just depends upon what you want to do[21:48:27] <speedy1> it's well known that ATI sabotages opengl by not imlementing their hw. features :p[21:48:33] <glYoda> and who you want to do it with[21:49:48] <glYoda> speedy1 funny I've got them implemented here[21:50:03] <speedy1> yeah on the 5% of the market[21:50:07] <glYoda> so I think that aptly disproves your point[21:50:28] <glYoda> umm if I was using Windows I'd be using D3D[21:50:35] <speedy1> you said it[21:50:38] <speedy1> :)[21:51:00] <glYoda> if I'm using a Mac then I've got what I want[21:51:08] <glYoda> Linux no one cares about[21:51:09] *** neric has joined ##OpenGL[21:51:14] * speedy1 is a game developer[21:51:15] <bobbens> yeah, screw linux![21:51:16] <glYoda> so in the end it all sounds good to me[21:52:06] <obmij> I'd develop of all platforms[21:52:08] <obmij> not only linux[21:52:09] <obmij> but even FreeBSD[21:52:16] <obmij> which is mainly a ServerOS[21:52:23] <obmij> for all*[21:52:39] *** fargiolas has quit IRC[21:52:49] <obmij> and when it gets down to porting to XBOX, I'll just make a quick D3D port[21:52:58] <glYoda> and since speedy1 seems to suffer from reading comprehension issues here let me reinforce my earlier statement -- if I was using Windows on Nvidia / ATI / ... I'd be using D3D.[21:53:30] <speedy1> bah - that is not the path filled with roses[21:53:31] <HuntsMan> glYoda: yeah, you've got vertex texturing in the X1600 :P[21:53:36] <glYoda> D3D is a wonderful environment on Windows.[21:53:47] <obmij> glYoda, cross platformism[21:53:52] <obmij> is the future![21:54:07] <bobbens> who cares about cross platformism! it's all about me! egocentrism ftw![21:54:10] <obmij> I dunno, but I really hate putting all my eggs in 1 basket[21:54:19] <obmij> MS going rouge one day![21:54:22] <glYoda> in any case I realize why I no longer waste my time on this channel :P[21:54:30] <speedy1> if I had a sig I would put "D3D is a wonderful environment on Windows" this in :D:D[21:54:36] <obmij> oh we're going to charge $11,000 for D3D12[21:54:53] <bobbens> glYoda: you probably want #opengl on irc.microsoft.com[21:54:58] <obmij> hehehe[21:55:13] <obmij> yeah go make their OCD a hollow shell for D3D[21:55:21] <obmij> like Ballmer wanted[21:55:31] *** glYoda has left ##OpenGL[21:55:34] <obmij> man[21:55:35] <speedy1> LOL[21:55:38] <obmij> he's d3dYoda[21:55:40] <obmij> I swear[21:55:42] <obmij> he's an inside job[21:55:49] <bobbens> there's soo many people like that[21:55:54] <HuntsMan> IYoda xD[21:55:57] <bobbens> C# coders with their D3D and windows[21:56:08] <obmij> Man, I swear[21:56:19] <obmij> I wouldn't die without ruining D3D first[21:56:32] <obmij> and making all my software/games/whatever I make cross platform[21:56:50] <obmij> Microsoft has shown signs of abuse before[21:56:50] <bobbens> I don't make crossplatform, but I don't make it hard to port[21:56:53] <obmij> and will do it later[21:56:59] <bobbens> I try to be crossplatform, but C standard only covers soo much[21:57:04] <bobbens> and you can only get so far with libraries :)[21:57:05] <HuntsMan> bobbens: i'm a C# coder using OpenGL on Linux :B[21:57:14] <obmij> lol HuntsMan[21:57:27] <obmij> but Microsoft is really abusive of what is 'its'[21:57:41] <obmij> or what belongs to it[21:57:48] <obmij> whichever sounds correct[21:57:52] <bobbens> ms in 10 years will be only a gaming company[21:57:56] <bobbens> making consoles and shit[21:58:04] <obmij> Hahahaha EXACTLY my prediction[21:58:13] <obmij> the only thing they have that is keeping them alive[21:58:19] <obmij> XBOX 360 and this Live! bullshit[21:58:22] *** kenws has joined ##OpenGL[21:58:27] *** DobosCake has joined ##OpenGL[21:58:34] <obmij> Vista was a complete joke[21:58:39] <obmij> everybody's running away screaming[21:58:46] <obmij> Steve Bummer is trying to buy yahoo! fails[21:58:51] <obmij> is getting beaten up by Google[21:59:00] <obmij> so it's only bet is.... XBOX 360![21:59:03] <bobbens> it'll take a while[21:59:04] <obmij> where are the fans are![21:59:12] <bobbens> but they'll start to move more resources to consoles and games[21:59:16] <bobbens> OS will start rotting[21:59:21] <obmij> it is already[21:59:25] <bobbens> linux and mac will go for the kill[21:59:28] <obmij> people are getting ubuntu[21:59:35] <obmij> and yes, people are switching to Mac[21:59:42] <obmij> Jobs is doing a great marketing campaign[21:59:43] <bobbens> MS OS are still surviving thanks to inertia[21:59:46] <bobbens> and bribes :P[21:59:56] <obmij> naw mostly 3rd party software[22:00:00] <obmij> that is not cross platform[22:00:05] <obmij> and people need for their jobs or w/e[22:00:07] <obmij> but WINE is fixing that[22:00:21] <bobbens> i'm talking about governments deciding to switch to linux[22:00:26] <bobbens> then ms comes in and bribes[22:00:29] <obmij> They are, it's easy for them[22:00:30] <bobbens> voila all windows again with latest version[22:00:37] <obmij> hehe true[22:00:42] <obmij> the government of 'Nigeria'[22:00:45] <obmij> maybe[22:00:58] <bobbens> MS makes money by making the companies and goverments pay licenses for linux[22:00:58] <obmij> most of Europe and also China is *nix[22:01:02] <bobbens> they like having the users pirate it[22:01:17] <obmij> err[22:01:22] <obmij> pay licences for what?[22:01:36] *** TheLorax has joined ##opengl[22:01:53] <obmij> you probably meant Windows right?[22:02:18] *** amalon has joined ##opengl[22:10:40] *** juanmabc has joined ##opengl[22:10:54] <bobbens> obmij: err yeah[22:11:00] <bobbens> had to gratinate the macarroni :)[22:11:09] <bobbens> has at least a finger depth of emmental cheese :)[22:11:13] *** nplus has quit IRC[22:11:49] *** juanmabc has quit IRC[22:13:14] *** nplus has joined ##OpenGL[22:13:37] *** enoex_ has joined ##OpenGL[22:15:20] *** juanmabc has joined ##opengl[22:15:32] <Arc> hey does anyone here know how to achieve a glowmap texture with opengl 1.x?[22:15:38] <Arc> ie, with additive blending, etc[22:17:29] <HuntsMan> you can use additive blending setting the blending equation to GL_ONE and GL_ONE[22:17:39] <HuntsMan> like glBlendFunc(GL_ONE, GL_ONE);[22:20:27] <Arc> what does that do?[22:20:27] <Arc> i mean not the end effect as seen but what does GL_ONE itself do[22:20:39] <Arc> I've looked and not found a good set of docs for the blending functions[22:20:54] <MatthiasM> Arc: read the red book - and the OpenGL SDK[22:21:44] <Arc> what section of the red book[22:21:59] <Arc> (besides that I find the redbook almost unparsable)[22:22:22] <MatthiasM> then search yourself a book that you can read[22:22:56] *** enoex has quit IRC[22:23:33] <Arc> you're saying that the texture blending functions are only properly documented in books, there isn't a decent tutorial or description on the web..[22:24:37] <MatthiasM> Arc: I'm saying that you should learn to read[22:24:51] <MatthiasM> the specification explains everything with math[22:25:00] <MatthiasM> and the book with images :)[22:26:33] <HuntsMan> Arc: one * source + one * dest = source + dest[22:27:58] <Arc> but what is source and dest[22:28:21] *** LiQuiDninja has joined ##OpenGL[22:29:53] <Arc> if GL_ONE means multiply them by 1 (do nothing) then the above statement would mean that it's straight up addition[22:30:17] <MatthiasM> that's why it's called ADDITIVE BLENDING ![22:30:33] <Arc> what I lack is knowing how the blending works overall, because I don't know where that statement fits in[22:30:53] <MatthiasM> then read the red book or the GL spec[22:34:44] *** amalon has quit IRC[22:38:38] <Arc> and you can't say which chapter of the red book even covers blending in regards to multitexturing[22:38:42] <Arc> the blending chapter does not[22:39:36] <MatthiasM> you didn't asked about multitexturing[22:40:26] *** MiNiNaJaPa has joined ##OpenGL[22:40:52] <Arc> glowmaps are generally multitextured[22:41:20] <HuntsMan> Arc: source = source fragment in the framebuffer, dest = fragment generated[22:42:24] <MatthiasM> Arc: you asked about gl1.1 => multipass texturing[22:42:43] <Arc> gl1.x[22:43:10] <MatthiasM> and that's a clearly defined target why ?[22:43:30] <Arc> because 2.0 shaders are not available in Mesa[22:43:56] <MatthiasM> ^glsl can also be used with 1.5 :)[22:44:06] <HuntsMan> or use ARB ASM shaders[22:44:08] <Arc> the only shaders we have reliable access to is the ARB vertex shaders[22:44:15] *** MiNiNaJaPa has left ##OpenGL[22:44:34] <Arc> fragment shaders are not available on our target cards[22:44:48] <HuntsMan> what's your target card?[22:45:02] *** Darius_ has left ##opengl[22:45:05] <Arc> i915 and r200[22:45:22] <Arc> with fallback going for rage128[22:45:29] <HuntsMan> rage128!?!?!?!?[22:45:39] <Arc> you'd be suprised how many of those are still floating around[22:46:18] <HuntsMan> BTW your product is a game or something?[22:47:02] <Arc> rage128 has multitexturing with max 2 texture units, which means that bump (= 2 units) + color + glow we'll require 2 passes on r128[22:47:07] <Arc> it's a game engine[22:47:41] <HuntsMan> well, gamers don't use rage128's[22:47:42] <Arc> freely licensed, targetting very low-end consumer hardware, educational software, etc[22:47:51] <Arc> we're not targetting who you would describe as "gamers" :-)[22:48:16] <Arc> we're targetting 95%+ of computer owners, families, who aren't going to upgrade their i915[22:48:30] *** DobosCake has quit IRC[22:48:31] <obmij> wow[22:48:36] <obmij> my bump mapper looks sweet[22:48:41] <obmij> the bricks look glossy :D[22:48:53] * obmij goes to add parallax[22:49:23] <Arc> our bumpmap + color map is fine, 2 pass (which I'd like to allow to be 1-pass), but I need to bootstrap multitexture blending knowledge to do that[22:49:31] *** fengee has joined ##OpenGL[22:49:38] <HuntsMan> multitexture blending?[22:50:05] <MatthiasM> Arc: try google - there are a lot of tutorials out there[22:50:52] <Arc> the current way has the bumpmap in it's own pass and then color in a second pass, the two bumpmap textures use multitexture blending combinign the dot3 for tslv translation[22:50:57] <obmij> 2 pass?[22:51:03] <obmij> for only bump map? ridiculus[22:51:28] <Arc> well it got the job done at the time, and yea on some systems with only 2 texture units max it'll still be 2 pass[22:51:32] <HuntsMan> Arc: google for the texture environment[22:51:39] <obmij> Arc, I must say[22:51:43] <obmij> you're making little sense[22:51:58] *** Yustme has quit IRC[22:52:07] <obmij> Bump mapping doesn't need 2 passes, far from something like that[22:52:14] <obmij> faaar away[22:52:15] <HuntsMan> Arc: BTW the R200 does have fragment shaders[22:52:20] <obmij> you're doing some voodoo magic over there[22:52:26] <Arc> obmij: without shaders.[22:52:30] <obmij> oh[22:52:32] <obmij> then ok[22:52:42] *** cami has joined ##OpenGL[22:52:52] <Arc> we're using a cubemap as a second texture to translate the dot3 to the correct light tangent[22:53:06] <obmij> light tangent?[22:53:12] <obmij> now you're making no sense[22:53:16] <Arc> tangent space light vector[22:53:22] <obmij> Ok, then that makes sense[22:53:33] <obmij> However I'm moving normal out of tangent space[22:53:38] <obmij> because it has many further uses[22:53:49] <obmij> which you might end up needing[22:54:02] <obmij> Not for bump mapping, but further 'effects' if you will[22:54:16] <obmij> you could move light INTO tangent space (as you seem to be doing)[22:54:16] <Arc> HuntsMan: not according to glxinfo, I don't believe..[22:54:23] <obmij> which is a tad bit faster[22:54:34] <HuntsMan> Arc: the HW might support, and drivers don't, that's common for ATI :P[22:54:47] <Arc> we have GL_ATI_fragment_shader but that's not ARB[22:55:00] <obmij> avoid NVIDIA or ATI[22:55:03] <obmij> extensions[22:55:04] <Arc> and i915 certainly doesn't support that[22:55:13] *** hubbe3 has quit IRC[22:55:14] <obmij> vendor specific[22:55:15] *** hubbe3 has joined ##OpenGL[22:55:21] <Arc> I have no problem writing a fragment shader just for ATI cards but not until our core render path is settled[22:55:22] <HuntsMan> Arc: it also does[22:55:42] <obmij> Arc, just never do[22:55:45] <obmij> you gotta realize[22:55:45] <Arc> whats the name of the fragment shader extension I should be looking at[22:55:49] <obmij> Intel, nVidia, ATI[22:55:52] <obmij> they all coexist[22:55:55] <HuntsMan> ARB_fragment_program[22:56:22] <obmij> unless you're not going to sell the program[22:56:23] <Arc> no-go on Mesa[22:56:37] <obmij> or release it to the public[22:56:47] <Arc> maybe with the released specs the DRI team will be able to add support[22:56:59] <obmij> but I still wonder why the hell you're using a cubemap ... for anything[22:57:05] <Arc> I was shocked to learn OS10.3 + Rage128 supported a whole suite of shaders, but not VBO[22:57:08] <obmij> are you trying to cheat over the cross/dot product[22:57:08] <obmij> ?[22:57:15] <obmij> for some speed boost?[22:57:28] <Arc> obmij: I didn't write the code.[22:57:35] <Arc> all I know is it works[22:57:36] <obmij> meh, today's stuff is fast enough[22:57:45] <obmij> don't be a clock cycle scrooge[22:57:46] *** Satan_Inside has joined ##OpenGL[22:57:57] <obmij> make your code more easier to understand :)[22:58:12] <Arc> what I don't understand is the blending functions that glue it together[22:58:22] <Arc> I know that so long as I keep these statements in the correct order it continues to work[22:58:31] * obmij storms off[22:58:33] *** obmij has quit IRC[22:59:27] <Arc> I'm just the maintainer, not the sole developer. there's parts of the codebase I don't understand fully, and only about 20% of the code deals with rendering[22:59:29] *** HuntsMan has quit IRC[22:59:31] <Arc> (most is physics)[23:00:07] *** scy has joined ##opengl[23:00:41] *** HuntsMan has joined ##opengl[23:02:24] *** cami has quit IRC[23:04:40] *** juanmabc has quit IRC[23:04:47] *** juanmabc has joined ##opengl[23:07:17] <prophile> PEOPLE RUNNING AROUND ON FIRE[23:07:58] <MatthiasM> prophile: what are you doing ?[23:08:14] <prophile> lighting people on fire[23:08:19] <MatthiasM> o_O[23:08:26] <rsp> Postal 2[23:08:42] <prophile> cmon, join me, it's fun[23:08:52] <prophile> for every second a person runs around on fire that you've lit, you get one point[23:08:55] * MatthiasM lights prophile[23:08:55] * rsp joins[23:09:02] <prophile> but if they survive, you lose all your points[23:09:15] <prophile> 60 bonus points for setting a toddler or younger on fire[23:09:16] *** TheLorax has quit IRC[23:09:49] <prophile> and 60 bonus points if their fire ends in a spectacular explosion, plus 30 extra points for every other person taken out in that explosion[23:09:55] <prophile> hey, I think I feel a game coming on here[23:09:59] * prophile sketches some design ideas down[23:10:00] * rsp lol[23:10:22] <rsp> Todays standards...[23:10:24] <prophile> TWISTED SON OF A BITCH GAMES PRESENTS[23:10:34] <prophile> LIGHT PEOPLE ON FIRE II[23:10:39] <rsp> 2.3[23:10:44] <prophile> MUCH WORSE THAN LAST TIME[23:10:57] <prophile> my imagination is way too active[23:11:01] <prophile> and vivid[23:11:16] <bobbens> that game would probably do very well[23:11:24] <prophile> shotgun![23:11:39] * prophile scribbles it down and mails it to himself, to copyright it[23:11:50] <prophile> i'd have to use the photorealistic fire trick from GPU gems[23:11:51] <rsp> He's serious guys![23:12:29] * rsp lol at Intel realtime fire 50fps on 16 core system[23:13:58] *** joakim12 has quit IRC[23:14:37] *** joakim12 has joined ##OpenGL[23:17:26] *** rsp has left ##opengl[23:23:04] <Arc> so glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_ADD)[23:24:15] <Arc> then [...] GL_COMBINE_RGB, GL_ADD)[23:24:30] *** KU0N has quit IRC[23:24:33] <Arc> and set the source0 and source1 to GL_TEXTURE and GL_PREVIOUS respectively?[23:24:52] *** Walt has quit IRC[23:25:08] *** Walt has joined ##opengl[23:25:41] <Arc> what I think I still lack is an understanding of how multipass and singlepass multitexturing work differently[23:26:09] <Arc> or more specifically, what the code will have to do differently depending on if it's rendering everything in one pass or in 2 passes[23:26:24] *** justjohn has joined ##OpenGL[23:26:50] *** Sabman has joined ##openGL[23:30:15] <Arc> oh[23:30:37] <Arc> ok question, GL_PREVIOUS, does it refer to the previous texture or the /result/ of the previous texture?[23:30:53] <speedy1> result of the previous texture stage[23:30:57] <MatthiasM> prevous state output[23:31:06] <Arc> ok and then[23:31:43] <Arc> the difference between multipass and singlepass is in singlepass multitexturing you use GL_PREVIOUS to add/mod/etc the previous texture result[23:31:56] <speedy1> on multipass - you blend in the blending unit[23:32:14] <speedy1> on singlepass - you can use texture stages for blending and manipulating current fragment[23:32:25] <Arc> "blending unit"?[23:32:40] <speedy1> alpha blending unit which comes after the texture stage[23:33:15] <speedy1> ie if you want to sum 3 textures, you can do it in single pass and sum textures via texture stages[23:33:38] <speedy1> or you can do 3 passes and sum textures via alpha blending, each in its own pass[23:34:05] *** amalon has joined ##opengl[23:34:05] <Arc> ok so there's some operations you can do with multitexturing that you cant with multipass single texturing[23:34:12] <speedy1> yup[23:34:36] <Arc> I assume that gl.GL_COMBINE_RGB, gl.GL_DOT3_RGB is one of them[23:35:03] <speedy1> yup, blending unit has narrower range of operations available[23:35:30] <Arc> blending unit is turning on GL_BLEND?[23:35:46] <speedy1> dunno by heart, check the opengl spec[23:38:25] *** rutski has joined ##OpenGL[23:47:03] *** bbeausej has quit IRC[23:48:47] *** scy has left ##opengl[23:50:48] <Arc> Q: if you're using combine with GL_PREVIOUS with your TEXTURE0, and you're using normal material colors (which as I understand are drawn before any texturing)[23:51:09] <Arc> er, that used on TEXTURE1[23:51:24] <Arc> does GL_PREVIOUS mean TEXTURE0 or TEXTURE0 + the material color[23:51:40] <MatthiasM> ^read the spec[23:51:51] <speedy1> and keep in mind GL_PREVIOUS is simply the result of the previous stage[23:52:02] <MatthiasM> it's all explained in the OpenGL extension[23:52:11] <Arc> I don't understand the scope of the previous stage in this context[23:52:43] <MatthiasM> you have N stages - they are cascaded - edg one gets the resuilt of the prevoius as input[23:52:55] <MatthiasM> the last one is used to blend with the framebuffer[23:52:55] <speedy1> and each stage has multiple inputs and 1 output[23:53:33] <Arc> so the material colors are applied to the framebuffer first, then the textures are blended with that[23:53:50] <MatthiasM> no :/[23:54:19] <speedy1> the result of the lighting equation (if enabled) can be one of the inputs to the texture stage[23:54:33] <Arc> AH[23:55:27] <Arc> im trying to determine how to mix the dot3 map result with the material colors[23:55:49] <Arc> or if that's even possible[23:56:36] <MatthiasM> well - you don't need to use the texture in each stage[23:57:15] *** level1_ has joined ##OpenGL[23:57:31] <level1_> hi, is GLShader a standard part of openGL?[23:57:44] <MatthiasM> yes[23:57:51] <level1_> wheres the api for it?[23:57:54] <level1_> or some .h file[23:58:05] <Arc> level1_: you're on GNU/Linux using MESA?[23:58:07] <MatthiasM> read the channel topic[23:58:08] <level1_> yeah[23:58:23] <Arc> MESA has very limited shader support[23:58:23] <level1_> well, nvidia drivers, but mesa source could should work[23:58:35] <level1_> I just want to figure out what the api is[23:59:13] <Arc> that shouldn't be a problem, shaders are far better documented than the fixed pipeline stuff[23:59:57] <Arc> if you're a KDE developer, I'll suggest that you want to stick with a fixed pipeline lest you end up with code that requires proprietary drivers to run