May 17, 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 17, 2008 [00:01:25] *** Suprano has joined ##OpenGL[00:07:21] *** Tenac has quit IRC[00:07:35] *** Tenac has joined ##opengl[00:10:24] *** mm^away is now known as mm765[00:16:12] *** bbeausej has joined ##OpenGL[00:27:57] *** enoex has joined ##OpenGL[00:28:11] *** Justme has quit IRC[00:30:57] *** Jorachim has joined ##openGL[00:30:57] *** scy has left ##opengl[00:31:13] *** JernejL has quit IRC[00:31:43] *** Lacerta has quit IRC[00:34:08] *** JernejL has joined ##OpenGL[00:35:30] *** prophile has quit IRC[00:36:19] *** LordMetroid has joined ##OpenGL[00:36:41] *** Lacerta has joined ##OpenGL[00:38:12] *** magnet_ has quit IRC[00:39:36] *** karabash has quit IRC[00:40:35] <LordMetroid> When I do a tranformation of my world coordinates to screen coordinates, do I need to perform two transformations for objects? One to place it in the correct worldly position and then one for positioning it in relation to the camera?[00:43:11] <Lacerta> yes[00:44:06] <LordMetroid> Bahh, dang![00:44:12] <LordMetroid> More expensive :([00:46:06] <LordMetroid> Couldn't I just normalize the object coordinates instead of doing a complete transormation?[00:47:45] <Lacerta> LordMetroid: what are you doing exactly?[00:47:55] <LordMetroid> manual transformation[00:48:29] <Lacerta> projecting?[00:49:26] <LordMetroid> Yeah[00:49:45] *** m4ggus has quit IRC[00:50:09] *** bbeausej has left ##OpenGL[00:50:53] *** darka has quit IRC[00:51:00] <Lacerta> well you multiply a coordinate with modelview and then with projection matrix[00:51:57] <Lacerta> that's essentially what happens for every coordinate when rendering so i don't think it's that expensive[00:52:12] <LordMetroid> the matrix is the expensive shit[00:52:42] <Lacerta> yeah, luckily the computer does it for you :)[00:53:00] <LordMetroid> Nah, I am forced to do it in this case[00:53:10] <LordMetroid> And I have very limited resources[00:53:25] <Lacerta> i meant that as a joke[00:54:04] <LordMetroid> hehehehe[00:56:15] <Lacerta> limited resources mean you do some mobile apps?[00:56:34] <LordMetroid> yeah[00:56:45] <LordMetroid> Just for fun though[00:56:56] <LordMetroid> Maybe I can impress a future employee too[00:58:20] *** dv_ has quit IRC[00:59:01] *** amalon has joined ##opengl[00:59:19] *** dv_ has joined ##OpenGL[00:59:24] *** Ademan has quit IRC[00:59:40] *** Ademan has joined ##OpenGL[01:01:40] *** cami has joined ##OpenGL[01:01:58] <Lacerta> hmm.. sry i can't think of how you could reduce the operations of getting the screen coordinates[01:02:08] <Lacerta> perhaps you can't[01:04:52] <LordMetroid> Why not just add the object world coords to the projection transformation...?[01:06:32] *** obmij has quit IRC[01:08:51] <Lacerta> how exactly would you do it?[01:09:35] <Lacerta> projection matrix doesn't have that 'offset' column if that's what you mean[01:10:54] <LordMetroid> I am not using OpenGL functions... I am doing it all manually[01:11:22] <Lacerta> shouldn't matter[01:13:09] <LordMetroid> I can perform a sin(theta) on either the object internal vertex or I could perform the operation on a world coordinate+internal coordinate[01:21:15] *** enoex has quit IRC[01:21:58] *** Iceshadow has quit IRC[01:22:02] <Lacerta> i don't know what kind of renderer you are writing but if you need the same kind of capabilities as openGL, you'll be doing essentially the same operations anyway[01:22:29] *** Suprano has quit IRC[01:23:33] <Lacerta> i guess you could take a few shortcuts by not using matrices or perhaps assuming that the 'camera' is at a certain position/orientation[01:26:18] *** JernejL has quit IRC[01:28:45] *** dvoid_ has quit IRC[01:31:01] <Lacerta> like the original Duke3D renderer :)[01:31:12] <Lacerta> getting all twisty when looking up or down[01:31:37] *** enoex_ has joined ##OpenGL[01:36:00] *** MatthiasM has quit IRC[01:36:07] *** MatthiasM has joined ##opengl[01:39:56] *** speedy1 has quit IRC[01:41:41] *** cami has quit IRC[01:47:09] *** amz has joined ##opengl[01:57:32] *** HuntsMan has joined ##opengl[02:01:22] *** neoneurone has quit IRC[02:04:58] *** TheLorax has joined ##opengl[02:12:51] *** hibread has joined ##opengl[02:13:32] *** enoex has joined ##OpenGL[02:17:19] *** Jorachim has quit IRC[02:23:51] *** neric has joined ##OpenGL[02:24:12] *** enoex_ has quit IRC[02:30:16] <hibread> morning all[02:33:20] <LordMetroid> morning[02:33:49] <LordMetroid> euhm, 0233 hundread hours[02:37:59] <hibread> 1007 hours here[02:41:14] *** charlie has joined ##OpenGL[02:41:32] *** Dew420 has quit IRC[02:41:44] *** charlie has quit IRC[02:42:41] *** Dew420 has joined ##OpenGL[02:43:16] *** Swordsman has joined ##OpenGL[02:53:36] *** juanmabc has quit IRC[03:05:45] *** deg has joined ##OpenGL[03:07:10] *** Walt_ has joined ##opengl[03:09:49] *** amalon has quit IRC[03:09:54] *** KU0N has quit IRC[03:10:13] *** Walt has quit IRC[03:10:21] *** TheLorax has quit IRC[03:21:01] *** Amorphous has quit IRC[03:21:51] *** speedy1 has joined ##OpenGL[03:21:58] *** Amorphous has joined ##opengl[03:25:12] *** |t4bz| has quit IRC[03:25:46] *** t4bz has joined ##OpenGL[03:27:58] *** LordMetroid has quit IRC[03:28:52] *** Walt_ is now known as Walt[03:33:58] *** jparishy|mac has joined ##OpenGL[03:34:33] <jparishy|mac> Hey guys, I'm having this odd problem on the iPhone with OpenGL ES and I was just knowing if anyone knows why this would happen. http://img516.imageshack.us/img516/2780/picture3tx6.png[03:35:14] <speedy1> seems like texture coords are not good for the second triangle[03:36:33] *** Dew420 has quit IRC[03:36:42] *** mastro has quit IRC[03:46:24] *** brutopia has quit IRC[03:46:57] <jparishy|mac> Yep, speedy1, you're right :P fixed[03:46:58] <jparishy|mac> thanks[03:47:05] <speedy1> np. :)[03:50:09] *** brutopia has joined ##opengl[03:57:19] *** gotan666 has joined ##OpenGL[04:00:09] *** rutski has joined ##OpenGL[04:02:58] *** Dew420 has joined ##OpenGL[04:11:33] *** blight_ has quit IRC[04:24:09] *** Burga has joined ##OpenGL[04:25:34] *** enoex has quit IRC[04:49:31] *** charlie_zzz is now known as charlie5[05:01:46] *** chrisjw has quit IRC[05:05:54] *** mm765 is now known as mm765^away[05:06:21] *** chondrite has joined ##OpenGL[05:08:00] *** charlie5 has quit IRC[05:12:27] *** speedy1 has quit IRC[05:13:54] *** kaotrix has quit IRC[05:18:38] *** peda_ has joined ##OpenGL[05:20:24] *** charlie5 has joined ##OpenGL[05:25:38] *** garou is now known as everyolne[05:25:50] *** everyolne is now known as garou[05:36:25] *** peda__ has quit IRC[05:37:59] *** m4ggus has joined ##opengl[05:49:05] *** rutski has quit IRC[05:50:28] *** rnx has left ##opengl[05:51:40] *** Dew420 is now known as Dew420[a][06:08:46] *** deg has quit IRC[06:18:57] *** chondrite has quit IRC[06:19:00] *** Killari has quit IRC[06:32:14] *** BahamutZERO has quit IRC[06:42:08] *** TheLorax has joined ##opengl[06:44:29] *** [this] has joined ##opengl[06:54:31] *** mm765^away is now known as mm765[06:54:32] *** [this] has quit IRC[06:55:17] *** Tenac has quit IRC[07:01:32] *** TehLorax has joined ##opengl[07:02:06] *** TheLorax has quit IRC[07:14:48] *** TehLorax has quit IRC[07:14:51] *** mm^away has joined ##opengl[07:18:21] *** mm765 has quit IRC[07:20:32] *** Ademan has quit IRC[07:25:54] *** mm^away is now known as mm765[07:28:02] *** Swords has joined ##OpenGL[07:32:08] *** amz has quit IRC[07:39:10] *** jparishy|mac has quit IRC[07:44:48] *** Swordsman has quit IRC[07:50:25] *** rutski has joined ##OpenGL[08:23:49] *** Killari has joined ##OpenGL[08:35:18] *** gotan666 has quit IRC[08:35:20] *** Ragnarok has joined ##opengl[08:35:35] <Ragnarok> blah this terrain creation is a pain using triangle strips[08:36:05] *** Andon has quit IRC[08:53:42] *** cami has joined ##OpenGL[08:53:57] *** cami has quit IRC[08:56:52] *** fargiolas has joined ##OpenGL[08:57:32] *** Yustme has joined ##opengl[08:58:00] *** dv_ has quit IRC[08:58:59] *** dv_ has joined ##OpenGL[09:00:39] <hibread> Ragnarok: never use triangle strips[09:01:28] <Ragnarok> why[09:03:22] <hibread> because they achieve nothing on the current hardware[09:03:33] <hibread> unless you're using something like a wii... or anythiung obscure?[09:03:52] <hibread> you're better off using index triangle lists[09:04:46] <hibread> and if you're after the last bit of performance, you'll need to sort the list such that you can take advantage of post vertex processing cache[09:06:55] <Ragnarok> use VBO?[09:08:48] *** darka has joined ##opengl[09:11:54] <hibread> Ragnarok: sorry, im back. Yeah always use VBO's; you can use either index lists or triangle strips with them[09:12:12] *** LacertaII has joined ##OpenGL[09:12:13] *** sohail has quit IRC[09:12:14] <hibread> but VBO's with a sorted index list triangle will wreak best performance[09:12:49] *** peda__ has joined ##OpenGL[09:12:50] *** peda_ has quit IRC[09:13:18] <hibread> http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html[09:13:24] <hibread> I think thats the popular read[09:14:02] <Ragnarok> thank you[09:14:16] <Ragnarok> ill have to read it when i wake up gotta go to bed for work[09:14:43] <hibread> http://ati.amd.com/developer/gdc/2007/Sander-Fast_Triangle_Reordering_for_Vertex_Locality_and_Reduced_Overdraw(Siggraph07).ppt[09:14:50] <hibread> that also might be a worthy read[09:14:57] <hibread> as a quick rundown[09:15:09] <Ragnarok> can't open it[09:15:30] <hibread> http://www.cs.princeton.edu/gfx/pubs/Sander_2007_>TR/tipsy.pdf[09:15:35] <hibread> seems to be a pdf of a similar thing[09:16:07] <hibread> thats the paper i followed to create my optimizer[09:17:16] <Ragnarok> sweet thanks[09:17:37] <hibread> I can't recall if this piece of information is included, but make sure to re-sort the actual vertex list after creation of the index list so that contiguous memory reads can happen (random access has overhead)[09:18:49] <hibread> there are latencies for changing columns/rows etc.. so contiguous reads are best. So after creation of the optimized index list, run over the list onces again to resort the vertices as much as posible[09:19:31] <hibread> Ragnarok: but seriously.. that a fair bit of work for not huge gains... unless you're really trying to get the very last bit of performance out, it just turns out to be good programming practice[09:20:01] <hibread> *algorithm practice, rather[09:20:41] <hibread> Ragnarok: straight forward index lists as they are loaded from the model file will suffice in general[09:22:57] *** neoneurone has joined ##OpenGL[09:29:58] *** d29 has joined ##OpenGL[09:31:37] *** d29 has quit IRC[09:46:58] *** scy has joined ##opengl[09:55:32] *** Andon has joined ##OpenGL[09:55:57] *** groton has joined ##OpenGL[10:00:55] *** dvoid_ has joined ##OpenGL[10:05:17] *** loon_ has joined ##OpenGL[10:06:14] *** hubbe3 has quit IRC[10:07:03] *** hubbe3 has joined ##OpenGL[10:07:24] *** loon_ has quit IRC[10:22:08] *** Andon has quit IRC[10:23:15] *** Andon has joined ##OpenGL[10:26:05] *** DobosCake has quit IRC[10:26:33] *** nplus has joined ##OpenGL[10:35:24] *** blbmp has quit IRC[10:36:19] *** Lemml has joined ##OpenGL[10:38:49] *** dvoid_ has quit IRC[10:39:31] *** dvoid_ has joined ##OpenGL[10:45:27] *** DobosCake has joined ##OpenGL[10:45:54] *** JernejL has joined ##OpenGL[10:51:52] *** Jernej has joined ##OpenGL[10:53:34] *** juanmabc has joined ##opengl[11:00:14] *** BahamutZERO has joined ##OpenGL[11:01:52] *** amalon has joined ##opengl[11:08:27] *** JernejL has quit IRC[11:17:14] *** mm765 is now known as mm765^away[11:19:28] *** gotan666 has joined ##OpenGL[11:24:38] *** prophile has joined ##opengl[11:24:57] *** [AD]Turbo has joined ##OpenGL[11:25:56] <[AD]Turbo> hola[11:26:45] *** gotan666 has quit IRC[11:27:21] *** [AD]Turbo is now known as TurboAWAY[11:41:00] *** dust-- has joined ##OpenGL[11:44:47] *** m4ggus has quit IRC[11:44:52] *** m4ggus_ has joined ##opengl[11:44:54] *** m4ggus_ is now known as m4ggus[12:18:13] *** karabash has joined ##OpenGL[12:18:46] *** dvoid2 has joined ##OpenGL[12:25:27] *** hd_ has joined ##OpenGL[12:25:30] *** karabash has quit IRC[12:27:02] *** neoneye has joined ##OpenGL[12:28:35] *** Xmas| has joined ##OpenGL[12:31:03] *** Tenac has joined ##OpenGL[12:31:16] *** hd_ has left ##OpenGL[12:32:18] *** Suprano has joined ##OpenGL[12:32:47] *** Ademan has joined ##OpenGL[12:35:06] *** dust-- has quit IRC[12:35:35] *** dvoid_ has quit IRC[12:39:57] *** Lemml has quit IRC[12:44:07] *** Jupp3 has joined ##OpenGL[12:45:18] *** Jup4 has joined ##OpenGL[12:45:19] *** Jupp3 has quit IRC[12:45:34] *** Jup4 is now known as Jupp3[12:50:54] *** ced117 has joined ##OpenGL[13:04:35] *** blight_ has joined ##opengl[13:04:42] *** neoneye has quit IRC[13:18:02] *** LtJax has joined ##opengl[13:18:38] *** Ademan has quit IRC[13:19:38] *** Ademan has joined ##OpenGL[13:21:45] *** Lacerta has quit IRC[13:22:04] *** LacertaII is now known as Lacerta[13:26:05] *** Lucine has quit IRC[13:28:25] *** mm765^away is now known as mm765[13:28:47] *** Lucine has joined ##OpenGL[13:29:33] *** Burga has quit IRC[13:35:10] *** snoffler has joined ##opengl[13:39:59] *** snoffler has quit IRC[13:50:36] *** neoneye has joined ##OpenGL[14:02:09] *** cami has joined ##OpenGL[14:02:22] *** cami has quit IRC[14:04:03] *** rutski has quit IRC[14:05:15] *** kenws has joined ##OpenGL[14:07:03] *** amalon has quit IRC[14:07:30] *** rutski has joined ##OpenGL[14:09:14] *** rsp has joined ##opengl[14:09:24] <rsp> Hi![14:10:58] *** m4ggus has quit IRC[14:13:53] *** Darius_ has joined ##opengl[14:22:11] *** chondrite has joined ##OpenGL[14:30:49] *** darka has quit IRC[14:32:01] *** juanmabc has quit IRC[14:36:48] *** rnx has joined ##opengl[14:40:19] *** nplus has quit IRC[14:42:09] *** amalon has joined ##opengl[14:42:46] *** Jorachim has joined ##openGL[14:45:07] *** ghenriks has joined ##opengl[14:46:14] *** Thunderbird has joined ##opengl[14:47:36] <Thunderbird> when I have two opengl contexts say context1 and context2 which share display lists (context2 shares with context1)[14:48:03] <Thunderbird> what happens to textures and other resources when context1 is destroyed, does context2 inherit them?[14:57:07] *** Xmas| has quit IRC[14:57:51] *** Dew420[a] is now known as Dew420[14:59:24] *** Walt_ has joined ##opengl[15:00:44] *** XSource has joined ##OpenGL[15:02:05] *** Dew420 has quit IRC[15:10:58] *** deg has joined ##opengl[15:15:52] <deg> do glMapBuffer and glUnmapBuffer copy the whole buffer content to client memory and back to server memory?[15:16:08] *** Walt has quit IRC[15:17:03] <Thunderbird> you get a pointer to the buffers but there is no guarantee where they are[15:17:17] <Thunderbird> it depends also on what type of usage you asked for[15:18:00] <deg> i just wondered if it's technically possible for my application to directly access the graphics card memory[15:18:15] <Thunderbird> this is the closest there is[15:18:23] <Thunderbird> I use it for this purpose in wine[15:18:28] *** Swords2 has joined ##OpenGL[15:18:29] <Thunderbird> and it gives a huge performance boost[15:20:02] <Thunderbird> proper usage of glBufferData is very important for the driver; you basically give it hints on what you plan to do[15:20:20] <Thunderbird> e.g. uploads only, uploads and downloads and so on[15:22:17] *** Yustme has quit IRC[15:22:30] *** odietsch^ has joined ##OpenGL[15:22:30] <deg> i have a related question regarding glDrawRangeElements. is the range of the vertex array copied into server memory for processing, while the not-range-version copies the vertexdata for each vertex on demand?[15:24:05] *** Yustme has joined ##opengl[15:24:10] <Thunderbird> I don't have experience with those calls[15:24:20] <hibread> deg: nothing to do with any of that[15:24:21] <Thunderbird> (if you aren't already use VBOs there)[15:25:59] <hibread> deg: http://www.opengl.org/sdk/docs/man/xhtml/glDrawRangeElements.xml start and end represent the smallest value the index list has, and the end represents the maxiumum value the index list has[15:26:28] <rsp> hibread: I'm still in texcoords hell xD[15:26:44] <hibread> rsp: still haven't worked it out? :p[15:27:10] <rsp> Naw :P[15:28:26] <hibread> maybe this will cheer you up http://www.youtube.com/watch?v=3C1BSbq5aB0&feature=related[15:29:01] *** Dew420 has joined ##OpenGL[15:29:39] <rsp> lool[15:29:42] <deg> hibread: yes, I understand that, but I just wondered why that would speed up the process, and my guess is, that the range you define is copied as a whole chunk to faster memory.[15:29:43] *** chondrite has quit IRC[15:30:51] <hibread> im not entirely sure, but i do recall that it may have to do with the size of individual indices (32bit or 16bit etc). If the range is small even though you might be using very large index numbers, it can still send using 16bit values[15:30:58] <hibread> if that is wrong, i've got no idea[15:35:21] *** Swords has quit IRC[15:39:20] *** tmccrary has joined ##OpenGL[15:39:21] *** tmccrary has left ##OpenGL[15:39:25] *** tmccrary has joined ##OpenGL[15:39:26] <deg> ok, it's not that i'm having problems with the functions or anything, I'm just reading the red book and it sometimes leaves questions unanswered. thx for helping me out[15:39:51] *** Dew420 has quit IRC[15:39:56] <hibread> I use it.. but id imagine if i didn't use it, the performance would be the same[15:40:04] <hibread> glDrawElements vs glDrawRangeElements[15:40:07] <tmccrary> If I'm using a small repeating texture, say 128x128 or something like that, how does the repeating effect texture memory?[15:40:12] *** Dew420 has joined ##OpenGL[15:40:15] <hibread> but since i already know the range, i may as well[15:40:33] <hibread> tmccrary: repeating?[15:40:45] <tmccrary> what I mean by that is, I have a small texture defined to repeat and I if I scale texture coordinates to say 10x larger[15:41:03] <hibread> well its still only stored once..[15:41:04] <rsp> hibread: http://www.youtube.com/watch?v=6EANBQDrmW8&feature=related[15:41:27] <tmccrary> The reason I ask is that I want to use a small normal map to simulation subsurface scattering[15:41:35] <hibread> rsp: hell he moves gay! :)[15:41:53] *** karabash has joined ##OpenGL[15:41:57] <tmccrary> it's all just random normals to simulate light diffusing through a surface[15:42:04] <tmccrary> so I need it to be pretty high res[15:42:23] <rsp> lol[15:42:28] <tmccrary> but I don't want to pay the penalty, especially since the entire noise map is just a bunch of random vectors[15:42:47] <hibread> can't use a noise function?[15:42:48] <hibread> in glsl?[15:43:02] <hibread> whats your question about the memory usage though?[15:43:26] <hibread> you create a texture at 128x128 and thats it.. only 128x128 is used regardless of how you map that to your mesh[15:43:33] <tmccrary> ok, cool[15:43:40] <tmccrary> that's what I wanted to verify, thanks[15:45:56] <hibread> just make sure to use mipmaps for performance and visual quality[15:46:05] <hibread> along with large levels of anistropic filtering[15:46:19] <hibread> anisotropic even[15:46:41] *** Xmas| has joined ##OpenGL[15:48:16] *** Andon has quit IRC[16:01:41] *** juanmabc has joined ##opengl[16:01:44] *** amalon has quit IRC[16:02:13] *** tmccrary has left ##OpenGL[16:03:12] *** Suprano has quit IRC[16:03:37] *** Suprano has joined ##OpenGL[16:10:28] *** Jorachim has quit IRC[16:18:07] *** hubbe3 has quit IRC[16:18:34] *** hubbe3 has joined ##OpenGL[16:22:09] *** scy has left ##opengl[16:22:37] *** scy has joined ##opengl[16:27:25] *** baballama has quit IRC[16:27:28] *** Dew420 has quit IRC[16:29:12] *** Dew420 has joined ##OpenGL[16:29:39] *** Andon has joined ##OpenGL[16:35:49] <hibread> hey guys, what do you thinks the best way of "randomly" sampling pixels around a central pixel? Currently im working with my SSAO algorithm but have a few banding artifacts that could be ironed out with more random samples. Currently ive got a const array of vec2 that im using to offset. Im using GF7 hardware, so i dont think procedurally generated indexing is possible. It also seems im limited to only 20 samples before a limit is hit[16:36:48] <hibread> *indexing to the const array that is[16:39:10] *** mm765 is now known as mm765^sleep[16:39:33] <Xmas|> you could calculate an additional offset based on the screen space position[16:40:11] <hibread> hmm.. sort of like a jitter?[16:40:16] <Xmas|> yes[16:40:34] <hibread> could i use a noise function for the jitter?[16:40:44] <Xmas|> noise is expensive[16:41:33] <hibread> vec2 noise2( someVec2);[16:41:40] <hibread> ill have to give it a try[16:41:42] <hibread> see how expensive[16:41:55] <Xmas|> I don't think GF7 fragment shader can dynamically index const arrays, but you can obviously do that with a texture...[16:42:22] <Xmas|> built-in noise is not implemented AFAIK[16:43:40] *** LiQuiDninja has joined ##OpenGL[16:44:04] <hibread> yeah i was thinking to have say an array (texture lookup) of n number elements (say a sample pattern of 13x13), and have the texture arranged in such away that you can pick any point in it, and guarantee that the subsequent 16 (or what ever sample quantity) would be reasonably sparsely layed out[16:44:34] <hibread> and use one random type function to select a starting point with in the 1D texture[16:44:37] *** jparishy has joined ##OpenGL[16:45:50] <Xmas|> maybe use a const array of n vec2 sample offsets, and then do one texture lookup based on the screen position to get a rotation angle[16:46:24] <hibread> and rotate all sample points about the center?[16:46:34] <Xmas|> yes, by rotating the offsets[16:46:36] <hibread> expensive to rotate 16 vec2's each fragment though?[16:46:51] <hibread> doesn't sound cheap[16:47:03] <hibread> some trig there[16:47:05] <Xmas|> depends, you could actually store a mat2 in a 4-component texture[16:47:34] <Xmas|> then rotating is just 2 2-component dot products[16:47:43] <hibread> hehe yeah true.. but still.. matrix multiplications aren't that cheap considering ill have to do 16 (or what ever) of them... but still not a shabby idea[16:47:50] <hibread> hmm[16:47:53] <hibread> yeah true[16:47:54] <hibread> 2D[16:47:58] <Xmas|> which is a perfect match for the GF7 architecture because it can do two dp2 in a single cycle[16:48:24] <hibread> sounds like a fair concept[16:48:57] <hibread> how much noise do you think will be created by having randomish samples... atm there is absolutely no noise at all.. just abit of banding and particular angles[16:48:59] *** rutski has quit IRC[16:49:08] <hibread> *at[16:49:41] <hibread> ill make a screenshot of what ive got so far in a sec[16:50:11] *** Suprano has quit IRC[16:50:28] <Xmas|> by the way, the texture that contains the rotations can be pretty small, 4x4 or so[16:50:39] <Xmas|> you can repeat that pattern over the whole screen[16:50:40] *** Suprano has joined ##OpenGL[16:51:38] *** flithm has joined ##OpenGL[16:52:14] <hibread> err.. so how do you propose you select the texture coordinates per frag?[16:52:46] <flithm> hey everyone... I'm trying to do some multitexturing here, and I've got the basics working. I can combine two textures, but I'd like vary the strength of one texture (ie its alpha). Can anyone point me in the right direction?[16:54:22] <Xmas|> hibread, screen position in pixels / texture size[16:54:46] <hibread> so there is no randomness. Tiled in a sense[16:54:52] <Xmas|> flithm, which operation do you mean by "combine"[16:55:02] <hibread> depending on the texture dimensions[16:55:04] *** prophile has quit IRC[16:55:28] <Xmas|> yes, but you don't need true randomness to avoid banding[16:56:12] <flithm> Xmas|: well, when I enable the second texture unit the result looks like the two texture units combined. I haven't specified any texenv operands or anything yet, but I've tried a few things with no real success.[16:56:36] <Xmas|> if the pattern repeats only every 4th pixel, you can get 4 times smaller bands[16:58:05] <Xmas|> flithm, ok, the default is GL_MODULATE which means the two textures get multiplied[16:58:24] <hibread> Xmas|: yep looks like a plan which should perform well. And besides, i could probably up the size of the rotation texture by quite a bit without compromising performance[16:59:06] *** dv_ has quit IRC[16:59:15] <flithm> ahhh I get it. so, do you know how I can set the correct operands so that the alpha of the second texture can be varied?[16:59:45] <hibread> Xmas|: http://img353.imageshack.us/img353/5561/testao2hb8.png there is some banding there, but regardless, thats what my implimentation is looking like thus far[16:59:55] <Xmas|> flithm, it's best if you explain exactly what mathematical operation you want to perform with the colors[17:00:02] *** dv_ has joined ##OpenGL[17:00:26] <hibread> ive just got the object moving about randomly atm, hence why its half in the ground[17:00:54] <Xmas|> hmm... are you sure the size of the filter kernel is right?[17:01:15] <hibread> there is no "right" with this algorithm.. its just hacking about until it looks the best :)[17:01:42] <flithm> Xmas|: okay... I believe what I want is to keep the first texture unit colors in tact, then add to them the result of the second texture unit with its RGBs scaled by some factor (so tex1 + (tex2 * scalar), or maybe tex1 * (tex2 * scalar))... does that make sense?[17:01:50] <hibread> what do you suggest should change? I can spread the filter out.. increase the samples effective size.. etc etc[17:02:38] <hibread> but this is really a high frequency ambient occlusion.. it wont be effective if the kernel was much larger.. unless i misunderstand what you mean[17:03:54] <Xmas|> don't worry, just forget what I wrote...[17:04:11] <Xmas|> flithm, those are two quite different things[17:04:49] <Xmas|> adding will obviously make things brighter, while multiplication acts like a filter[17:05:34] <Ragnarok> why is it that you do gluLookAt(0.0, 0.0, 10.0........) but when the other way you go glRotatef(0.0f, 0.0f, -10.0f);[17:07:09] *** LordMetroid has joined ##OpenGL[17:07:48] <flithm> Xmas|: hrmm... well I think for now addition might be good enough. really what I want is the equivalent of say when you're blending during rendering and you do glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) -- that's what I'd like, then to be able to specify the alpha value in some way[17:07:50] <hibread> Xmas|: so what did you mean? Im always open to suggestions[17:12:42] <Xmas|> flithm, yes you can do that with a GL_COMBINE texture environmen using linear interpolation, and the constant color as the lerp factor[17:13:30] <flithm> Xmas|: great, that helps a bunch, I'm gonna try a few things here[17:14:05] <Xmas|> hibread, I'm not too familiar with SSAO, but can you use non-uniform filter weights?[17:17:38] <hibread> filter weights?[17:17:50] <hibread> non-uniform based on?[17:18:07] <Xmas|> is each sample you take equal?[17:18:21] <hibread> equal in what way?[17:18:33] <Xmas|> equal in the effect it has on the final result[17:19:24] <hibread> yeah its all calculated using some real math. The location of each sample is calculated in screen space (XYZ) so the distance is known. THe angle between the subject pixel (center one) and the sample is also taken and attenuats its influence[17:19:43] <hibread> distance from subject to sample, that is[17:19:57] <hibread> so bump mapping works with this algorithm quite nicely[17:20:15] <Xmas|> is the attenuation linear?[17:20:44] *** m4ggus has joined ##opengl[17:21:43] <hibread> attenuation of a particular sample is based on the area of the cap of a hemisphere subtended by the vector to the sample, and the "radius" of the sample. The radius atm is constant... assume a particular "Size" of the sampled pixel[17:22:28] <hibread> so its purely attenuated on the distance from the subject pixel, and the angle to it[17:22:43] <hibread> so that'd be a inverse square relationship i guess?[17:23:21] <hibread> i could take samples halfway across the screen if i like, and the sample would essentially have no impact on the subject pixel[17:23:44] *** Watermelon2 has joined ##OpenGL[17:24:40] <Xmas|> yeah, the question is, how would the result look with an infinite number of samples?[17:24:52] <flithm> Xmas|: thanks that totally did the trick on the multitexturing thing![17:25:23] <hibread> Xmas|: the further a pixel is away in world space the less impact you will get. So you could sample every pixel on the screen and get a very usable occlusion[17:25:58] <hibread> but 1600x1200x1600x1200 doesn't sound like a useable number of samples :)[17:26:40] <Xmas|> and your goal is to get a result that is very close to ideal with just 16 samples[17:27:44] <hibread> Im not up for photo realism if thats what you think. Merely darkening crevisas somewhat realistically will suffice[17:28:14] <hibread> there are techniques for low frequency (as apposed to the high frequency exposed here) occlusion, but im yet to impliment that[17:29:02] <hibread> which lets you have occlusion from futher distances more efficiently and effectively and accurately[17:30:25] *** flithm has left ##OpenGL[17:31:20] <hibread> The combination of HDR lighting, some form of shadow mapping (say variance shadow mapping) and SSAO sampled over the ambient portion of the scene, should create an effective solution[17:32:00] <hibread> anywho, im outta ere. Cheers for ya help Xmas|[17:34:11] <rsp> bye hibread[17:35:26] *** amz has joined ##opengl[17:35:51] <hibread> later rsp![17:35:56] *** hibread has quit IRC[17:37:04] *** fargiolas has quit IRC[17:37:21] *** fargiolas has joined ##OpenGL[17:45:57] *** aalex has joined ##OpenGL[17:46:01] *** deg has quit IRC[17:47:35] *** Xmas| has quit IRC[17:59:51] <Ragnarok> lighting will take a while to get used to[18:03:39] *** LuchoVtn3d has joined ##OpenGL[18:04:36] <jparishy> I have another problem :D Is there anything special I have to do to get OpenGL to not draw the transparent parts of my image? Because it just draws the parts white[18:05:31] <rnx> blending[18:10:00] <jparishy> any specific blendfunc? I enabled blending then used glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);[18:10:01] <Ragnarok> yeah[18:10:04] <jparishy> But it did not work[18:10:42] <Ragnarok> jparishy, did you disable depth_test?[18:10:51] <jparishy> i did not.[18:10:56] <Ragnarok> try that[18:11:25] <Ragnarok> and look at this[18:11:26] <Ragnarok> http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=09[18:14:02] *** LuchoVtn3d has quit IRC[18:14:05] *** amalon has joined ##opengl[18:14:27] <jparishy> Hm it seems that if depth_test is not enabled, the transparent objects do not draw at all.[18:18:56] *** hubbe3 has quit IRC[18:19:11] *** hubbe3 has joined ##OpenGL[18:20:02] <jparishy> It's probably an iphone specific problem, i'll have to ask my friend when he comes on.[18:22:57] *** sohail has joined ##OpenGL[18:23:12] *** jparishy is now known as jparishy|mac[18:23:38] *** aalex has quit IRC[18:26:33] *** bbeausej has joined ##OpenGL[18:26:42] *** Xmas| has joined ##OpenGL[18:27:30] *** jparishy|mac has quit IRC[18:30:36] *** fargiolas is now known as fargiolas|afk[18:30:46] *** fargiolas has joined ##OpenGL[18:31:22] *** fargiolas is now known as fargiolas|afk[18:33:02] *** Watermelon2 has quit IRC[18:41:29] *** Suprano has quit IRC[18:42:43] *** HuntsMan has quit IRC[18:43:28] *** Dew420 has quit IRC[18:45:12] *** LiQuiDninja has quit IRC[18:47:50] *** Dew420 has joined ##OpenGL[19:03:38] *** Suprano has joined ##OpenGL[19:06:52] *** m4ggus has quit IRC[19:14:12] *** Dew420 has quit IRC[19:23:07] *** bbeausej has quit IRC[19:23:30] *** huperniketes has quit IRC[19:24:27] *** Dew420 has joined ##OpenGL[19:39:53] *** neoneye has quit IRC[19:41:03] *** Suprano has quit IRC[19:46:29] *** Suprano has joined ##OpenGL[19:48:18] *** Suprano has quit IRC[19:52:33] *** Suprano has joined ##OpenGL[20:01:17] *** KU0N has joined ##OpenGL[20:01:54] *** bbeausej has joined ##OpenGL[20:02:32] *** mastro has joined ##OpenGL[20:11:15] *** LordMetroid has quit IRC[20:20:08] *** Joakim has quit IRC[20:20:25] *** Joakim has joined ##OpenGL[20:23:42] *** Swords2 is now known as Swordsman[20:34:06] *** amalon has quit IRC[20:34:56] *** dv_ has quit IRC[20:36:52] *** Jorachim has joined ##openGL[20:38:12] *** Suprano has quit IRC[20:38:38] *** Suprano has joined ##OpenGL[20:40:38] *** fargiolas|afk has quit IRC[20:46:32] *** karabash has quit IRC[20:47:16] *** amalon has joined ##opengl[20:49:22] *** Suprano has quit IRC[20:52:11] *** Suprano has joined ##OpenGL[20:55:52] *** Plagman_ has quit IRC[21:01:13] *** scy has left ##opengl[21:06:03] *** neoneye has joined ##OpenGL[21:10:30] *** amalon has quit IRC[21:17:43] *** odietsch^ has quit IRC[21:17:53] *** kattmat has joined ##OpenGL[21:17:59] <kattmat> hi[21:26:51] *** XSource has quit IRC[21:27:02] *** blbmp has joined ##OpenGL[21:29:33] *** snakesqzns has quit IRC[21:35:44] *** Jorachim has quit IRC[21:42:21] *** speedy1 has joined ##OpenGL[21:43:42] *** Killari has quit IRC[21:47:17] *** Killari has joined ##OpenGL[21:58:42] *** Walt_ has quit IRC[22:05:57] *** Walt has joined ##opengl[22:06:34] *** Dew420 has quit IRC[22:16:10] *** dispraekailo has quit IRC[22:22:18] *** jparishy_ has joined ##OpenGL[22:27:25] *** LtJax has quit IRC[22:27:56] *** Walt has quit IRC[22:32:28] *** bbeausej has quit IRC[22:38:22] *** Suprano has quit IRC[22:47:04] *** LiraNuna has quit IRC[22:50:17] *** LiraNuna has joined ##OpenGL[22:52:28] *** Dew420 has joined ##OpenGL[22:56:39] *** dispraekailo has joined ##OpenGL[23:02:59] *** scrav has joined ##OpenGL[23:07:29] *** Plagman_ has joined ##OpenGL[23:07:29] *** Plagman has quit IRC[23:08:00] *** amalon has joined ##opengl[23:08:23] *** Plagman_ is now known as Plagman[23:12:53] *** LiraNuna has quit IRC[23:17:12] *** Tenac has quit IRC[23:20:36] *** Walt has joined ##opengl[23:24:06] *** scy has joined ##opengl[23:24:52] *** karabash has joined ##OpenGL[23:26:09] *** Dew420 has quit IRC[23:27:45] *** tzaeru has joined ##OpenGL[23:27:51] <tzaeru> 卍[23:34:07] <rsp> wtf[23:36:11] *** prophile has joined ##opengl[23:36:22] <Lacerta> it's a rectangle[23:40:23] *** kenws has quit IRC[23:43:52] *** juanmabc has quit IRC[23:50:59] *** juanmabc has joined ##opengl[23:52:12] *** nplus has joined ##OpenGL[23:52:22] *** groton has quit IRC[23:53:07] *** m4ggus has joined ##OpenGL[23:54:20] *** jparishy_ has quit IRC