May 14, 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 14, 2008 [00:05:41] *** gaffa has quit IRC[00:10:12] *** DR0ID_ has joined ##OpenGL[00:13:12] *** DR0ID_ has left ##OpenGL[00:13:17] *** groton has quit IRC[00:14:10] *** Bollinger has quit IRC[00:14:41] *** neunon has joined ##opengl[00:17:26] *** chrisjw has quit IRC[00:19:53] *** neoneurone has quit IRC[00:21:52] *** JernejL has quit IRC[00:25:58] *** chrisjw has joined ##opengl[00:30:36] *** juanmabc has quit IRC[00:33:10] *** Xmas| has joined ##OpenGL[00:35:02] *** Suprano has quit IRC[00:37:59] *** m4ggus has quit IRC[00:39:46] *** darka has quit IRC[00:40:15] *** m4ggus has joined ##OpenGL[00:42:28] *** Suprano has joined ##OpenGL[00:42:52] *** prophile has quit IRC[00:44:24] *** LordMetroid has quit IRC[00:44:49] *** Ragnarok has quit IRC[00:46:43] *** m4ggus has quit IRC[00:46:48] *** m4ggus_ has joined ##OpenGL[00:46:53] *** m4ggus has joined ##OpenGL[00:47:04] *** m4ggus_ has quit IRC[00:53:44] *** _boto has quit IRC[00:59:12] *** neunon has quit IRC[01:02:28] *** TheLorax has joined ##opengl[01:04:42] *** basro has left ##OpenGL[01:10:41] *** Sabman has joined ##openGL[01:19:40] *** tmccrary has joined ##OpenGL[01:20:21] *** xonev has joined ##OpenGL[01:25:09] *** odietsch has quit IRC[01:25:15] *** KU0N has quit IRC[01:30:46] *** reviver has joined ##OpenGL[01:31:31] *** reviver has quit IRC[01:32:14] *** reviver has joined ##OpenGL[01:32:16] *** neunon has joined ##opengl[01:34:53] *** phrosty has quit IRC[01:35:58] *** MatthiasM has quit IRC[01:36:05] *** MatthiasM has joined ##opengl[01:38:20] *** Burga has quit IRC[01:47:25] *** speedy1 has quit IRC[01:48:24] *** eu-prleu-peupe1 has quit IRC[01:48:52] *** Xmas| has quit IRC[01:51:13] *** Madsy has quit IRC[01:54:31] *** enoex has quit IRC[01:54:59] *** enoex has joined ##OpenGL[01:56:47] *** amz has joined ##opengl[01:58:00] *** reviver has quit IRC[02:00:51] *** m4ggus has quit IRC[02:00:58] *** m4ggus has joined ##OpenGL[02:04:40] *** TheLorax has quit IRC[02:05:19] *** Madsy has joined ##opengl[02:11:20] *** LtJax has quit IRC[02:13:08] *** bbeausej has quit IRC[02:14:02] *** Suprano has quit IRC[02:26:17] *** karabash has quit IRC[02:27:09] *** tmccrary has quit IRC[02:43:20] *** DMINATOR has quit IRC[02:47:58] *** grumbel has quit IRC[02:48:24] *** smiler has quit IRC[02:48:24] *** brutopia has quit IRC[02:49:14] *** smiler has joined ##opengl[02:49:14] *** brutopia has joined ##opengl[03:02:55] *** LordMetroid has joined ##OpenGL[03:06:32] *** Encryption767 has quit IRC[03:06:55] *** LordMetroid has quit IRC[03:14:56] *** mm765^away is now known as mm765[03:20:57] *** Amorphous has quit IRC[03:22:12] *** Amorphous has joined ##opengl[03:27:57] *** replor has joined ##OpenGL[03:34:39] *** phrosty has joined ##opengl[03:42:13] *** TheLorax has joined ##opengl[03:48:57] *** phrosty has quit IRC[03:49:35] *** LiraNuna has joined ##OpenGL[03:49:49] *** phrosty has joined ##opengl[03:50:33] *** hibread has joined ##opengl[04:00:56] *** Ragnarok has joined ##OpenGL[04:01:12] <Ragnarok> anyone know where I can find better tutorials than nehe and not with glut[04:05:40] *** TheLorax has quit IRC[04:06:10] <Madsy> Ragnarok: Yes. It's called "the OpenGL 2.1 specification"[04:06:16] <Ragnarok> blah[04:06:17] <Ragnarok> xD[04:06:24] <Ragnarok> that book uses glut :P[04:06:24] <Madsy> You'll find it for *gasp* free of charge on OpenGL.org[04:06:31] <Ragnarok> yes i've red it[04:06:31] <hibread> Ragnarok: yep its called learning opengl properly with something like the redbook or superbible or opengl distilled or... yep and then once you've learned the basics move onto more specific books say in the gpu gems series etc etc[04:06:55] * Ragnarok is scared of learning GLSL[04:06:56] <Madsy> Read *SPECIFICATION* it doesn't use any other APIs than what it defines.[04:07:07] <hibread> Ragnarok: well you'll have to know it from opengl 3.0 onwards[04:07:13] <hibread> and really.. its not scary at all[04:07:23] <Ragnarok> hibread, learn what with ogl 3?[04:07:23] <Madsy> You don't even know what "specification" means?[04:07:37] <Ragnarok> Madsy, yes i do else I wouldn't be here :P[04:08:09] <Madsy> Then why did you just say something stupid like "that book uses glut"[04:08:11] <hibread> Ragnarok: opengl 3.0 will swipe out the fixed function pipeline completely iirc[04:08:31] <Ragnarok> i heard it will be a more OO look and feel *shrugs*[04:09:06] <hibread> Ragnarok: more "objects" orientated yes, but that doesn't matter for this argument. You'll have to learn the glsl at some stage in the future[04:09:28] <Ragnarok> or go with Cg[04:09:29] <Ragnarok> ?[04:09:45] <Ragnarok> but glew i think makes it easier to handle exts[04:10:00] <hibread> so if you're serious about this opengl programming gear for the long hall, learn it properly the first place with some good books, including the "Orange book" (glsl)[04:11:34] <Ragnarok> thanks[04:11:47] <Ragnarok> ill get the blue book[04:12:05] <Madsy> Don't.[04:12:14] <hibread> I thought you wanted tutorials?[04:12:17] <Ragnarok> the superBible?[04:12:37] <Madsy> Like, don't *buy* the blue book. The OpenGL 2.1 specification is just as good for reference.[04:12:44] <Madsy> And it's free.[04:12:56] <Ragnarok> okay but the superbible isn't free?[04:13:06] <hibread> Madsy: is there anything extra contained in the blue book, albeit spec 1.4 only[04:14:23] <hibread> over the online spec anyway[04:14:34] <Madsy> I think I have the 1.4 as well. But they keep pushing new revisions.[04:14:53] <Madsy> The book isn't worth its price tag, in my opinion.[04:15:07] <Madsy> It doesn't contain anything you didn't allready know.[04:15:33] <hibread> it looks like version 4 (opengl 1.4) is the latest..[04:15:44] <Madsy> Of course if you like paper better than html, you might find it convenient as a reference.[04:34:38] *** phrosty has quit IRC[04:36:11] *** blight__ has quit IRC[05:00:05] <Lucine2> Then again you can always print things.[05:00:25] <Lucine2> I can't wait to get learning on OpenGL, still learning Assembly (class) and C++ right now. :/[05:15:01] *** rnx has left ##opengl[05:20:12] *** peda_ has joined ##OpenGL[05:24:59] *** Sabman has quit IRC[05:31:14] *** hibread has quit IRC[05:37:59] *** peda__ has quit IRC[05:47:32] *** m4ggus has quit IRC[06:07:05] *** lolage0 has joined ##OpenGL[06:09:48] *** enoex has quit IRC[06:13:37] *** amz has quit IRC[06:14:52] <Ragnarok> Lucine2, HLA or NASM?[06:23:49] *** bolides has joined ##OpenGL[06:31:32] *** meteors has quit IRC[07:00:32] *** mm^away has joined ##opengl[07:05:05] *** darka has joined ##opengl[07:13:40] *** BahamutZERO has quit IRC[07:17:39] *** mm765 has quit IRC[07:29:41] *** phrosty has joined ##opengl[07:29:55] *** mm^away is now known as mm765[07:53:40] *** darka has quit IRC[07:57:54] *** scy has joined ##opengl[07:58:12] *** Jupp3 has quit IRC[08:02:06] <rutski> are glGetError calls compiled into display lists[08:02:07] <rutski> ?[08:32:36] *** rutski has quit IRC[08:41:17] *** andikr has joined ##OpenGL[08:47:07] *** scy has left ##opengl[08:48:36] *** Burga has joined ##OpenGL[09:01:58] *** hd_ has joined ##OpenGL[09:05:54] *** [this] has joined ##opengl[09:06:48] *** sanjin has joined ##OpenGL[09:08:46] *** Roderic has joined ##OpenGL[09:08:47] *** Roderic is now known as Ingenu[09:10:40] *** rutski has joined ##OpenGL[09:12:31] *** kaotrix has quit IRC[09:17:56] *** Ingenu has quit IRC[09:21:44] *** rutski has quit IRC[09:21:47] *** mattn__ has quit IRC[09:28:19] *** hd_ has left ##OpenGL[09:30:52] *** [AD]Turbo has joined ##OpenGL[09:32:17] *** belou has joined ##OpenGL[09:33:39] <[AD]Turbo> yo[09:39:45] *** groton has joined ##OpenGL[09:42:04] *** gotan666 has joined ##OpenGL[09:48:23] *** sohail has quit IRC[09:59:59] *** karabash has joined ##OpenGL[10:08:42] *** lgbr has quit IRC[10:20:57] *** neoneye2 has joined ##OpenGL[10:21:33] *** lgbr has joined ##OpenGL[10:24:00] *** dvoid_ has joined ##OpenGL[10:36:51] *** blbmp has left ##OpenGL[10:37:10] *** lgbr has quit IRC[10:46:48] *** sanjin has left ##OpenGL[10:47:16] *** Lucine2 has quit IRC[10:51:34] *** Lucine2 has joined ##OpenGL[10:57:44] *** korff has joined ##OpenGL[10:57:56] *** Suprano has joined ##OpenGL[11:00:13] *** BahamutZERO has joined ##OpenGL[11:04:39] *** mm765 is now known as mm765^away[11:08:17] *** LordMetroid has joined ##OpenGL[11:12:32] *** joakim_ has joined ##OpenGL[11:13:16] *** prophile has joined ##opengl[11:13:41] *** gotan666 has quit IRC[11:20:06] *** andikr has quit IRC[11:25:26] *** nplus has quit IRC[11:26:11] *** andikr has joined ##OpenGL[11:29:10] *** Rangar has joined ##OpenGL[11:30:54] *** joakim__ has quit IRC[11:39:35] *** Burga has quit IRC[11:48:56] *** karabash has quit IRC[11:52:56] *** Roderic has joined ##OpenGL[11:52:57] *** Roderic is now known as Ingenu[11:58:02] *** nplus has joined ##OpenGL[12:01:39] *** kandinski has quit IRC[12:02:27] *** kandinski has joined ##OpenGL[12:11:36] *** lordmetroid_ has joined ##OpenGL[12:12:22] *** KU0N has joined ##OpenGL[12:13:22] *** lgbr has joined ##OpenGL[12:15:07] *** lordmetroid_ has quit IRC[12:27:44] *** LordMetroid has quit IRC[12:31:41] *** mapreduce has quit IRC[12:31:42] *** gotan666 has joined ##OpenGL[12:31:45] *** mapreduce has joined ##OpenGL[12:32:47] *** fargiolas has joined ##OpenGL[12:33:00] *** neoneye2 has quit IRC[12:40:58] *** Jorachim has joined ##openGL[12:46:41] *** neoneye2 has joined ##OpenGL[12:59:46] *** darka has joined ##opengl[13:02:24] *** mm765^away is now known as mm765[13:10:31] *** karabash has joined ##OpenGL[13:18:42] *** Ademan has quit IRC[13:19:59] *** Ademan has joined ##OpenGL[13:25:19] *** Defty has quit IRC[13:25:27] *** nplus has quit IRC[13:25:44] *** enoex has joined ##OpenGL[13:25:59] *** sanjin has joined ##OpenGL[13:43:30] *** gotan666 has quit IRC[13:43:51] *** gotan666 has joined ##OpenGL[13:54:40] *** sanjin has left ##OpenGL[13:59:06] *** Darius_ has joined ##opengl[14:06:38] *** darka has quit IRC[14:10:29] *** blight_ has joined ##opengl[14:11:32] *** LordMetroid has joined ##OpenGL[14:19:05] *** nplus has joined ##OpenGL[14:22:13] *** bolides is now known as meteors[14:25:34] *** Jorachim has quit IRC[14:27:05] *** joakim__ has joined ##OpenGL[14:33:24] *** ahelon has quit IRC[14:43:12] *** LordMetroid has quit IRC[14:45:55] *** joakim_ has quit IRC[14:48:59] *** fargiolas has quit IRC[14:50:59] *** hibread has joined ##opengl[14:51:55] <hibread> oi[14:53:06] *** Eforen has joined ##opengl[14:59:39] *** [this] has quit IRC[15:00:33] *** Watermelon2 has joined ##OpenGL[15:02:43] *** rnx has joined ##opengl[15:07:37] *** hubbe3 has quit IRC[15:08:07] *** hubbe3 has joined ##OpenGL[15:15:28] *** stuckie has quit IRC[15:19:19] *** Watermelon2 has quit IRC[15:20:31] *** Watermelon2 has joined ##OpenGL[15:23:30] *** Suprano has quit IRC[15:26:40] *** Jorachim has joined ##OpenGL[15:27:50] *** Suprano has joined ##OpenGL[15:30:38] *** frosch_bin has joined ##OpenGL[15:32:41] *** Wagoo has quit IRC[15:34:57] *** frosch_bin has left ##OpenGL[15:36:28] *** frosch_bin has joined ##OpenGL[15:39:30] *** bbeausej has joined ##OpenGL[15:50:34] *** Rangar has quit IRC[15:50:57] *** Rangar has joined ##OpenGL[15:57:59] *** fargiolas has joined ##OpenGL[16:01:17] *** korff has quit IRC[16:02:52] *** frosch_bin has left ##OpenGL[16:07:38] *** huperniketes1 is now known as huperniketes[16:08:49] *** tmccrary has joined ##OpenGL[16:15:12] *** despen has joined ##OpenGL[16:15:29] *** scy has joined ##opengl[16:15:35] *** despen has left ##OpenGL[16:26:23] *** amz has joined ##opengl[16:34:44] *** Wagoo has joined ##opengl[16:40:48] *** odietsch has joined ##OpenGL[16:43:42] *** andikr has quit IRC[16:45:42] *** LordMetroid has joined ##OpenGL[16:48:22] <hibread> guys, whats the proper way (if there is one) to declare and initialize arrays (const or otherwise) in glsl? I'm receiving both warning C7516: OpenGL does not allow constant arrays and warning C7549: OpenGL does not allow C style initializers. const vec3 array[2] = { vec3( 0.8, 1.0, 0.0), vec3(1.0, 0.7, 1.0) }; is my test array[16:48:49] <hibread> use uniform variables i guess?[16:50:21] <quicksilver> http://groups.google.com/group/comp.graphics.api.opengl/browse_thread/thread/1ff14b402404d62e[16:50:25] <quicksilver> http://www.gamedev.net/community/forums/topic.asp?topic_id=422784[16:50:32] <quicksilver> hibread: doesn't really answer your question but relevant at least[16:51:45] <hibread> quicksilver: yeah cheers, i found both of those :)[16:52:04] <hibread> well, im on nvidia hardware atm.. so ill just plod along with the warnings[16:52:50] *** fargiolas has quit IRC[16:56:22] *** Jorachim has quit IRC[16:57:27] *** amz has quit IRC[17:01:04] *** sohail has joined ##OpenGL[17:01:33] *** Jupp3 has joined ##OpenGL[17:08:06] *** Jorachim has joined ##OpenGL[17:08:50] *** LordMetroid has quit IRC[17:10:05] *** speedy1 has joined ##OpenGL[17:17:11] *** belou has quit IRC[17:18:01] *** rsp has joined ##opengl[17:18:08] <rsp> Hi[17:18:20] <rsp> hibread: :)[17:19:01] <hibread> gday fella. Whats happening?[17:19:12] <rsp> Can't get VBO's to work :'([17:19:28] <rsp> I took a week off from programming and now I'm diving into it[17:19:58] <hibread> whats not happening?[17:20:03] <rsp> Rendering[17:20:17] <rsp> I have a vector with floats I want to draw with glDrawArrays[17:23:34] <hibread> yes thats good :) what else have you discovered?[17:24:34] <tmccrary> 1) check the errors opengl reports[17:25:00] <tmccrary> 2) Make sure your mesh is visible (i.e. don't render a set of black triangles on a black background)[17:25:20] <tmccrary> 3) Simplify, try rendering a cube or even a single triangle this way.[17:25:47] *** Roderic has joined ##OpenGL[17:25:50] <hibread> and you see nothing?[17:26:14] <quicksilver> tmccrary: I implemented that distance field alpha testing algorithm :)[17:26:21] <rsp> I'll check. Just gonna go for one last try[17:26:22] <tmccrary> quicksilver: awesome[17:26:25] <rsp> first[17:26:41] <tmccrary> Pretty easy? I haven't dug into it myself yet (though I will be soon)[17:26:42] <hibread> tmccrary: sorry i thought rsp posted all that :)[17:27:00] <hibread> quicksilver: got any screenies? :)[17:27:27] <quicksilver> I have to warn you, it's a big ugly because it's using a low resolution source render[17:27:34] <quicksilver> http://roobarb.jellybean.co.uk/~jules/Picture%20119.png[17:27:49] <quicksilver> will be much nicer when I up the resolution of the 'initial' render it uses to build the distance field.[17:28:28] <tmccrary> yeah looks cool, you can see the definition at the edges[17:28:33] <quicksilver> the one on the right is standard magnification for comparison[17:29:04] <quicksilver> it's a bit nicer to play with because you can resize the window to any old aspect ratio[17:29:15] <quicksilver> and see it redraw dynamically[17:29:20] <tmccrary> thats cool[17:30:07] <quicksilver> the intensities are off too because I was lazy and the blend modes are wrong ;)[17:30:21] <quicksilver> just got it working on the train in this morning before I got into work[17:31:43] <rsp> glGetError says 1285 what is that[17:32:14] <hibread> that relates to a GL enum[17:32:55] <rsp> Do I have to switch all of them[17:33:04] <hibread> yep[17:33:15] <hibread> orr[17:33:38] <hibread> #define glError() { for(long err = glGetError(); err; err = glGetError()) { fprintf(stderr, "glError: %s caught at %s:%u\n", (char*)gluErrorString(err), __FILE__, __LINE__); } }[17:33:46] <rsp> :D:D[17:34:12] <hibread> courtesy of Satan_Inside[17:34:23] <rsp> Satan_Inside: nice one[17:37:39] <rsp> hmm out of memory[17:38:45] *** hubbe3 has quit IRC[17:39:16] *** hubbe3 has joined ##OpenGL[17:40:37] *** CNU_ has joined ##opengl[17:41:06] <rsp> Maybe it's time to paste some code!![17:42:22] <rsp> www.pasteall.org/784[17:42:48] <rsp> vBuffer is a GLuint[17:42:56] *** Ingenu has quit IRC[17:43:01] <rsp> obviously[17:43:59] <rsp> I think the problem is in the lower render part[17:44:13] <rsp> I might have taken an example wrong (stupid variable naming)[17:45:26] <hibread> you want to bind the VBO not the size[17:45:44] <hibread> bind vBuffer[17:45:51] <rsp> lol[17:46:50] *** [AD]Turbo is now known as TurboAWAY[17:50:47] *** dankna has joined ##OpenGL[17:50:54] *** Walt has joined ##opengl[17:51:28] <dankna> so, I get behavior that's as if the depth test is disabled, but it's not[17:51:52] <dankna> I read the FAQ about insufficient precision if you pass a tiny zNear to gluPerspective, and I had indeed been doing that so I changed to passing a huge one instead but no joy[17:52:03] <dankna> anyone able to suggest avenues of investigation?[17:52:04] <hibread> dankna: you've setup the context with depth buffer support?[17:52:14] <dankna> good question, double-checking.[17:52:51] <dankna> thanks![17:52:55] <dankna> I can't believe I missed that[17:53:11] <hibread> :)[17:53:59] <rsp> hibread: seg fault[17:54:22] <rsp> glBindBufferARB(GL_ARRAY_BUFFER,vBuffer);[17:56:40] <hibread> any glerrors?[17:57:48] <rsp> Nope[17:57:52] <rsp> It's a pointer error[17:57:58] *** Watermelon2 has quit IRC[17:58:04] <dankna> if it's segfaulting, vBuffer isn't set up correctly somehow.[17:58:09] <rsp> vBuffer is supposed to be GLuint vBuffer; right?[17:58:12] <dankna> or it's being told it's bigger than it is.[17:58:34] <dankna> also you need to be passing its address, not its value[17:58:48] <rsp> Yeah &[17:58:58] <rsp> In glBindBuffersARB too?[17:59:21] <dankna> can't answer that question without more context about your program and what glBindBufferARB actually does, but I suspect so[17:59:23] <rsp> That's when I get can't convert GLuint* to GLuint[17:59:46] <hibread> dankna: the unsigned int holds the id.. so it should be its value when binding... pass the address when glGen...()[17:59:56] <dankna> gotcha.[18:00:51] <hibread> rsp: you shouldn't be getting a segfault on the bind if its a valid ID...[18:01:07] <rsp> nah it's not the bind[18:01:38] <rsp> I have my old "cout<<"lol"<<endl;"[18:01:51] <rsp> With it, I found out glDrawArrays is[18:01:56] <hibread> what OS are yo on?[18:02:08] <rsp> What should I give as arg2[18:02:17] <rsp> Right now it's the freakin size of Vertices, I guess it's wrong[18:02:23] <rsp> Should be &Vertices[0] probably[18:02:37] *** Jorachim has quit IRC[18:03:01] <hibread> glDrawArrays(GL_TRIANGLES,0,Vertices.size());[18:03:04] <rsp> Linux[18:03:10] <rsp> That's what I use[18:03:17] <rsp> It seg faults there[18:03:42] <hibread> you have gdb installed?[18:03:57] <hibread> i'd use that anyway, to see where the segfault is[18:04:09] <rsp> It obly refers to the function I am in![18:05:10] <hibread> yeah true. I'd be doing something silly like dividing the Vertices.size() by some arb number... 3,4, 10, what ever... see if it segfaults. If it doesn't you might have sizings wrong somwhere[18:05:18] <hibread> when passing to glDrawArrays[18:06:20] <rsp> size is nFloats[18:06:23] <rsp> It should be ok?[18:07:19] <rsp> glBufferData might be wrong?[18:08:05] <hibread> ohhh[18:08:06] <hibread> hang on[18:08:17] <hibread> you're drawing triangles not vertices with that draw call[18:08:23] <hibread> divide the number of vertices by 3[18:08:27] <hibread> that should be the number of triangles[18:08:46] <hibread> glDrawArrays(GL_TRIANGLES,0,Vertices.size() / 3);[18:09:32] <rsp> That didn't help :'([18:09:44] <rsp> I'll repaste current[18:10:04] <hibread> glDrawArrays(GL_TRIANGLES,0, 1);[18:10:07] <hibread> does that even work?[18:10:32] <rsp> It does not[18:10:46] <rsp> Is the glVertexPointer pointing to the wrong address[18:11:52] <hibread> well assuming you have a mesh with atleast one triangle, that call should work. So somethings not right with the glBufferData call or even the generation of the buffer etc?[18:12:12] <rsp> www.pasteall.org/785[18:14:28] <hibread> rsp: I think its just a matter of debugging your sizes etc[18:14:46] <rsp> Ok[18:15:21] <hibread> why are you multiplying Vertices.size() by 3? Vertices is an array of floats...[18:15:37] <hibread> theres an issue i think[18:15:40] <hibread> get rid of the 3[18:15:56] <rsp> I followed an exampel with a variable that was named size or something[18:16:03] <rsp> That's what I think of[18:16:42] <hibread> if you had a triangle array of triangles that consisted of 3 floats, then you'd do triangles.size() * 3 * sizeof( float)[18:17:03] <hibread> rid of the *3[18:17:08] <rsp> That's true, that didn't help it either though[18:17:16] <rsp> But it was a step in the right direction[18:19:12] <rsp> data should be &Vertices[0] right[18:19:42] *** Yustme has joined ##opengl[18:20:13] <hibread> hmmm[18:20:17] <hibread> probalby not hey[18:20:26] <hibread> getting the address of a copy?[18:20:36] <hibread> i should bloody know this! :)[18:20:47] <rsp> I thought you should give a pointer to the first element[18:20:57] <hibread> yeah you do[18:20:59] <hibread> but with vectors...[18:21:01] <rsp> When you are using a vector[18:21:09] <hibread> yeah it should return a reference[18:21:20] <rsp> Because with an ordinary array you seem to use foobar[18:21:25] <rsp> not &foobar[0][18:23:14] <dankna> those are actually synonymous[18:23:24] <dankna> C has a very weak notion of contexts[18:23:31] <dankna> that's only used for promoting certain things to pointers[18:23:34] <dankna> like array and function names[18:24:02] <hibread> dankna: so what would be the proper usage here to get a pointer to the first element?[18:24:13] <dankna> show me the type declaration of Vertices[18:24:19] <dankna> oh[18:24:20] <dankna> you pasted it[18:24:25] <hibread> vector<float>[18:24:31] <dankna> okay, that's different[18:24:37] <dankna> you need to use the appropriate STL method to get a pointer[18:24:46] <hibread> .at() ?[18:24:47] <dankna> you cannot treat a C++ vector as if it were a C array, because it's not, it's an object[18:25:07] <hibread> but the [] operator returns a reference[18:25:16] <hibread> so i guess thats not the same thing...[18:25:17] *** karabash has quit IRC[18:25:28] <dankna> well, I'm not that familiar with the STL, but my guess is that you also have no guarantee that the elements are stored adjacently[18:25:44] <hibread> yeah they are in std::vectors[18:25:48] <dankna> if it doesn't have a "get content array" function, you might have to copy all the elements into a freshly-allocated array[18:26:15] <rsp> &foobar[0] is valid when I use OpenAL[18:26:18] <hibread> nah that shouldn't be necessary[18:26:21] <rsp> Should be the same?[18:26:22] <dankna> again, your root problem is trying to treat a vector as an array[18:26:53] <dankna> rtfm on vectors and how to do what you want, I'm sure it's a common requirement so there's probably a way to do it[18:27:14] *** nplus has quit IRC[18:27:18] *** nplus has joined ##OpenGL[18:28:54] <rsp> This error is weird[18:29:02] <rsp> It doesn't work with an ordinary array either[18:29:12] *** gotan666 has quit IRC[18:29:16] <quicksilver> if you want to use a vector as an array you must copy out to a fresh array.[18:29:33] <hibread> quicksilver: im pretty sure thats not the case :) but i could be wrong[18:29:40] <rsp> As I said[18:29:48] <rsp> I have used vectors as arrays with OpenAL[18:29:59] <rsp> You use &foo[0][18:30:02] <quicksilver> a = new int [v.size()]; copy( v.begin(), v.end(), a);[18:30:11] <quicksilver> according to a very old mailing list posting.[18:30:17] <hibread> as the memory is garaunteed to be contiguous in memory[18:30:22] *** JernejL has joined ##OpenGL[18:30:24] <quicksilver> OK, maybe it works these days.[18:30:31] <quicksilver> I don't think it's guaranteed by the standard :)[18:30:35] <quicksilver> but it might work in practice.[18:30:50] <quicksilver> see e.g. http://gcc.gnu.org/ml/gcc-help/2002-11/msg00204.html[18:30:52] <hibread> *guaranteed even[18:30:57] <rsp> My error is deeply nested since it doesn't worn with an ordinary array hibread[18:31:03] <rsp> work[18:32:16] <hibread> rsp: good luck :)[18:32:33] <quicksilver> I think you're right.[18:32:34] *** neoneye2 has quit IRC[18:32:34] <quicksilver> see this:[18:32:35] <quicksilver> http://groups.google.com/group/comp.lang.c++/msg/408d058c256d7699[18:32:40] <quicksilver> (it should be OK)[18:33:40] *** Iceshadow has joined ##OpenGL[18:34:18] *** rnx has quit IRC[18:34:21] <hibread> quicksilver: yep cool. Well rsp, looks like what you've got there is ok[18:35:19] <quicksilver> rsp: erm, I have a question. But I don't know much about VBOs.[18:35:24] <hibread> rsp: so you've now rid of the *3 in the glBufferData and even tried say glDrawArrays( GL_TRIANGLES,0,1); ?[18:35:30] <quicksilver> rsp: do you make that glBufferDataARB call before you fill the vector?[18:35:45] <rsp> This includes the code and some models that is set to render www.sendspace.com/file/5wa3ry maybe the error is out of the code I pasted[18:35:53] <hibread> also, the /3 in that glDrawArrays should be /9 since there is 9 floats per triangle[18:36:22] *** Walt has quit IRC[18:36:37] <rsp> I'll try all this[18:37:44] *** hubbe3 has quit IRC[18:37:50] *** hubbe3 has joined ##OpenGL[18:39:19] <rsp> quicksilver: Yeah as you can see in model.cpp it's in the bottom of Model::Load where the model file has been processed[18:39:55] <rsp> So I make the BufferData call after there is data in the vector[18:40:19] <quicksilver> ok, because when you add more data to a vector it can move[18:40:22] <quicksilver> so the point goes invalid[18:40:27] <quicksilver> but if that's not your problem ;)[18:40:56] <hibread> glBufferDataARB( GL_ARRAY_BUFFER_ARB, Vertices.size() * sizeof(float), &Vertices[0], GL_STATIC_DRAW_ARB);[18:40:57] <hibread> glDrawArrays(GL_TRIANGLES,0,Vertices.size()/ 9);[18:41:04] <rsp> Does that work for you[18:41:05] <hibread> those should be your 2 calls[18:41:53] <hibread> i haven't tried it[18:41:58] <rsp> try make it[18:43:44] *** joakim_ has joined ##OpenGL[18:43:52] <hibread> segfaults here too[18:44:01] <rsp> This is wrong![18:44:15] <rsp> This is programming"[18:44:16] <hibread> rsp: ill have a look[18:44:33] <rsp> nice[18:44:44] <rsp> If you cout the Vertices vector you can see there is data[18:46:00] <hibread> rsp: ive commented out the render() function in game.cpp and it still segfaults[18:46:11] <hibread> oh hang on[18:46:27] <hibread> nope[18:46:29] <hibread> my mistake[18:46:30] <rsp> I think it's just glDrawArrays :/[18:47:03] <rsp> I have to say though[18:47:10] <rsp> There are some strange values[18:48:24] <ville> dankna: ISO/IEC 14882:2003 guarantees vector storage to be contiguous, which was an oversight in the original 1998 version when it was left out[18:48:31] <dankna> ville: thanks[18:48:35] <dankna> that satisfies my curiosity[18:48:42] <quicksilver> rsp: erm.[18:48:59] <quicksilver> rsp: in youre initial paste you had this : glBindBufferARB(GL_ARRAY_BUFFER_ARB,Vertices.size());[18:49:03] <quicksilver> is taht still what you have?[18:49:06] *** PhrostByte has joined ##opengl[18:49:20] <rsp> quicksilver: no xD[18:49:24] <quicksilver> ah good[18:49:26] <quicksilver> sorry I'm a bit behind[18:49:29] <quicksilver> I wasn't following[18:49:35] <quicksilver> it's vBuffer now?[18:49:40] <ville> I haven't followed the discussion, but what is the actual type of this vertices array?[18:49:51] <dankna> it's a vector<float>[18:50:06] <rsp> nevermind what I said the values in the vector are ok[18:50:20] <hibread> ive got 3 triangles on the screen now[18:50:28] <rsp> nice one[18:50:37] <hibread> by just putting in /9 instead of /3[18:50:41] <hibread> in glDrawArrays[18:50:42] <ville> Ok then it should be cool to give out to gl calls the first element's address. Just as long as you don't go out of bounds due to indexing[18:51:09] *** rnx has joined ##opengl[18:51:23] <hibread> rsp: how come its not loading the models? Just for testing purposes you're using the 3 triangles?[18:51:51] <rsp> It loads the models into the vectors just fine[18:53:29] <rsp> How did you get it do draw them[18:53:43] <hibread> hmm its not working now...[18:53:44] <hibread> haha[18:53:49] <rsp> :)...[18:54:19] <rsp> btw mouse is not centered you have to play around with it to turn the camera[18:56:49] * rsp summons God[18:56:56] <rsp> LordHavoc: hi[18:57:19] *** hubbe3 has quit IRC[18:57:50] *** hubbe3 has joined ##OpenGL[18:58:11] *** phrosty has quit IRC[18:59:50] <hibread> rsp: well ive got stuff renderering[19:00:02] <rsp> w00t![19:00:03] *** joakim__ has quit IRC[19:00:05] <hibread> but its a whole pile of random lines :)[19:00:12] *** joakim__ has joined ##OpenGL[19:00:18] <rsp> :)/:([19:01:16] <rsp> but it's using the VBO?[19:01:20] <rsp> How did you do it[19:02:39] *** joakim_ has quit IRC[19:02:49] <hibread> glEnableClientState(GL_TEXTURE_COORD_ARRAY);[19:02:54] <hibread> i commented out that line[19:03:18] <hibread> and the glDisableClientState also below it (but wont make any difference)[19:03:33] <hibread> i guess it assumed there was texture data but you haven't issued any[19:03:51] <hibread> glBufferDataARB( GL_ARRAY_BUFFER, Vertices.size()*sizeof(GLfloat), &(Vertices[0]), GL_STATIC_DRAW );[19:04:01] <hibread> glDrawArrays(GL_TRIANGLES,0,Vertices.size() / 9);[19:04:33] <rsp> Yeah I get them too now[19:04:47] <hibread> get what?[19:05:05] <rsp> rnd lines[19:05:10] <hibread> ah ok yep[19:05:20] <hibread> well, atleast its working somewhat[19:05:31] <rsp> Yeah[19:05:32] <rsp> lol[19:05:41] <rsp> High fps xD[19:06:00] <rsp> it renders the models 100 times per frame[19:06:13] *** hubbe3 has quit IRC[19:06:15] <rsp> I was going to use it as reference for glBegin/glEnd vs VBOs[19:06:17] <hibread> well... before when you werer rendering without VBO's, you wouldn't been using more than just vertices right?[19:06:20] <hibread> like triangle index data[19:06:22] <hibread> etc[19:06:34] <rsp> Before I would use Triangles[19:06:39] <rsp> (vector)[19:06:48] <rsp> I'm gonna look into it[19:06:56] *** hubbe3 has joined ##OpenGL[19:07:01] <hibread> so thats your problem now. You're just issuing vertices in order without indexing them[19:07:31] *** LordMetroid has joined ##OpenGL[19:07:58] <hibread> you'll need an index buffer (GL_ELEMENT_ARRAY_BUFFER)[19:08:22] <hibread> rather than your vertices which uses GL_ARRAY_BUFFER[19:08:51] <hibread> sorry.. I ment aswell as[19:09:28] <rsp> Thanks[19:09:33] *** lgbr_ has joined ##OpenGL[19:09:55] <rsp> I'm gonna have to vacuum up "some" rice that I pathetically dropped on the floor first![19:10:16] *** PhrostByte has quit IRC[19:10:33] *** lgbr has quit IRC[19:10:45] <rsp> Was gonna go get water and headphones got stuck behind the plate :D:D[19:14:32] *** phrosty has joined ##opengl[19:15:45] <rsp> hibread: When I have a model with a lot of textures etc will I have to know what vertices I am dealing with when I am working with the texcoords?[19:15:58] <hibread> nice work! Hopefully you'll do better at programming than cooking rice pudding. Or rather, your engine being able to drag the skin off a rice pudding, which the VBO's should help with[19:16:28] <rsp> hahahaha[19:17:02] <hibread> you shuld have texture coordinates for each vertex[19:17:10] <hibread> 1 to 1 ratio of each[19:17:13] *** hubbe3 has quit IRC[19:17:15] <hibread> goes for normals too[19:17:53] *** charlie5 is now known as charlie_zzz[19:18:00] *** hubbe3 has joined ##OpenGL[19:18:01] <hibread> number of vertices == number of texturecoords == number of normals etc... the index list can be what it likes though[19:18:54] <hibread> you can either have them interleaved in one array whilst using offsets, or have separate buffers[19:19:04] <hibread> unless this is not what you're asking?[19:19:29] *** dankna has left ##OpenGL[19:19:53] *** dolphin has joined ##OpenGL[19:19:56] <rsp> When do I know what texture to apply[19:21:14] <hibread> that would be specific to your implimentation[19:21:27] <hibread> what textures do you have?[19:21:36] <hibread> normally there is 1 texture "set" per model[19:21:45] *** lgbr_ is now known as lgbr[19:21:54] <hibread> diffuse texture, specular, bump.... etc[19:22:02] <hibread> all using the same set of texture coords[19:22:19] <rsp> Yeah I know but I have a few test models that have more than one regular texture per models[19:22:31] <rsp> Don't ask why, it's for GameCube maybe it's different there what's best[19:22:38] <hibread> if there are more than one texture per model, you'll have to split the model up into sub models where each texture set is applied to each submodel[19:23:54] <hibread> more than one texture in what way?[19:24:04] <hibread> one for the head, one for the body?[19:24:08] <hibread> that type of concept?[19:24:14] <rsp> Yeah exactly[19:24:23] <rsp> One for the body and one for an eye[19:24:25] <rsp> Check the data folder[19:24:47] <hibread> well then the model file should tell you for which vertices,texturecoords,indices etc a particular texture is for[19:24:58] *** mapreduce has quit IRC[19:25:03] *** mapreduce has joined ##OpenGL[19:25:04] <hibread> is there a flag somewhere indexing the particular texture?[19:26:22] <rsp> In the .obj?[19:26:28] <hibread> yeah[19:26:29] <rsp> Check the .mtl files[19:26:45] <rsp> The _Scene one[19:26:50] <rsp> has more materials than 1[19:27:12] <rsp> then in the .obj you use the keyword usemtl foo[19:27:36] <rsp> Then you announce your faces[19:28:03] *** Lemml has joined ##OpenGL[19:28:18] <rsp> pointing to vertex# as previously defined by v foo foo foo[19:28:28] <hibread> so wheres the problem?[19:29:18] *** enoex has quit IRC[19:34:53] *** rutski has joined ##OpenGL[19:35:30] *** pfo is now known as pfo_sushi[19:36:33] <rsp> Maybe I'm making things more advanced than they are[19:37:16] <rsp> If I make my own models which I will, I could only use one regular texture and it would work right[19:37:24] <rsp> With texture mapping[19:37:25] <hibread> rsp: i think you just have to split up the renderable object into material pieces[19:39:12] <rsp> Ok[19:39:34] <hibread> and render each piece separatly[19:39:46] *** huperniketes has quit IRC[19:41:21] *** huperniketes has joined ##OpenGL[19:42:25] <rsp> render those things 100 times: 30 fps[19:42:37] <rsp> with VBOs: 1305 fps[19:43:15] <hibread> so you're getting 1305fps rendering 100 of those objects?[19:43:19] <hibread> what hardware btw?[19:43:28] <hibread> and how many triangles per object?[19:43:29] <rsp> GeForce 8800GTS (640mb version)[19:44:31] <rsp> Is the vertices the same ammount if they arn't indexed? should be right[19:44:43] <rsp> Or like would it affect performance a lot[19:45:22] <hibread> not sure on your question? Vertices the same amount?[19:45:33] <rsp> 2347000 vertices = 1305fps[19:45:53] <rsp> remove one 0[19:45:56] <rsp> lol[19:45:59] <hibread> hehe[19:46:16] <hibread> it all depends on how the indexing has been done[19:46:18] <tmccrary> it depends on what else has to be done[19:46:19] <tmccrary> also[19:46:23] <rsp> texturing[19:46:35] <rsp> shaders[19:46:36] <tmccrary> yeah, textures, shaders, etc[19:46:37] <rsp> etc[19:46:42] <rsp> lol[19:46:54] <rsp> Looks like we see this from the same angle tmccrary[19:47:10] <tmccrary> an 8800 GTS can render a hell of a lot of flat, unlit triangles :)[19:47:11] <hibread> and on the 8800 you have unified shaders.. so atm all the power is being issued to vertex processing[19:47:17] <quicksilver> tmccrary: OK, fixed my algorith to work properly with a 1024-pix source[19:47:28] <quicksilver> tmccrary: http://roobarb.jellybean.co.uk/~jules/Picture%20120.png[19:47:37] <tmccrary> nice[19:47:42] <tmccrary> looks much more smooth[19:47:49] <rsp> hibread: how do I use shaders in C speak[19:47:52] <hibread> quicksilver: worked well. Vector drawing :)[19:47:58] <rsp> Like in my actual Render()[19:48:10] *** dust-- has joined ##OpenGL[19:48:10] <hibread> haha hey? read up on the GLSL[19:48:10] <rsp> How do I say "hey lets put this here"[19:48:23] <rsp> not like the actual shader file[19:48:54] <hibread> rsp: sorry i have no idea what you're asking :)[19:48:57] <rsp> lol[19:49:06] <rsp> So I have three hundred shader files in a dir[19:49:09] <rsp> And my apps just uses them? XD[19:49:34] <quicksilver> that's a 256-pix-wide texture[19:50:23] <hibread> rsp: thats all totally up to you. You could create a material manager that managers all the different types of materials (shader complimenting varying number of textures and uses.... etc etc)[19:50:32] <rsp> ok[19:50:44] <quicksilver> being drawn at approx 650 pix.[19:50:49] <rsp> But how do I actually do it hibread!![19:51:04] <rsp> is there like a glShader(thismaterial);[19:51:08] <quicksilver> I should try with more dramatic scale ratio.[19:51:13] <rsp> Or how do I apply[19:51:24] <hibread> rsp: you are asking how shaders work?[19:51:37] <rsp> Yeah how you use them[19:51:40] <rsp> Not how you write them[19:52:03] <hibread> you create a program and link compiled shader sources[19:52:15] <hibread> you then at runtime bind the said program[19:52:33] *** karabash has joined ##OpenGL[19:54:09] <rsp> GL_ELEMENT_ARRAY_BUFFER hibread[19:54:12] <rsp> That's what I need now?[19:54:42] <hibread> yep. Create a VBO using that enum to create the elements (indices)[19:54:51] <rsp> When I use VBOs, the vertex data is on my G80 right?[19:55:29] <hibread> not always[19:55:33] <hibread> but thats the plan[19:55:40] <rsp> Yeah[19:55:47] <rsp> If I were a Mesa user it would be the CPU[19:55:49] <rsp> right?[19:55:56] <hibread> its up to the driver where it stores it.. on video memory, agp memory etc[19:56:03] <hibread> no idea[19:56:10] <rsp> ok[19:56:21] <rsp> I want to check avail vid mem, is that possible[19:56:31] <hibread> not that i know of[19:56:48] <rsp> Or do I have to do an uggly way like getting max vid mem and decrease when I load stuff to it[19:56:55] <hibread> you're best to just keep a record yourself[19:57:56] <hibread> you'd have to keep tabs on any frame buffer objects, texture objects and vertex buffer objects... but that sounds like it could get messy[19:58:13] <rsp> Yeah[20:02:11] *** DMINATOR has joined ##OpenGL[20:08:28] <Andon> You'll almost never encounter a situation where a vertex buffer object's so large that it's thrashing between CPU / GPU... you're more likely to exceed the maximum number of indices or vertices first.[20:09:58] <hibread> Andon: but i guess if you over used textures or what ever...[20:10:13] <tmccrary> What I've done is written an algorithm to determine the optimal vbo size for a given card (largely related to the size of the T&L cache on the card)[20:10:27] <tmccrary> Then I make sure that each VBO is slightly smaller than that size[20:10:47] <tmccrary> Finally, I wrote a wrapper around the VBO api[20:11:00] <tmccrary> it hides the fact that I'm using VBO's from the rendering code[20:11:17] <rsp> Is that where GL3 is heading[20:11:18] <tmccrary> and also allows it automatically batch the data into the appropriate sized vbos[20:12:06] *** dolphin has quit IRC[20:12:24] *** joakim_ has joined ##OpenGL[20:12:34] *** joakim__ has quit IRC[20:14:32] *** amalon has joined ##opengl[20:14:36] *** m4ggus has joined ##OpenGL[20:15:26] *** Iceshadow has quit IRC[20:16:51] <Andon> I've seen proxy textures used to determine video memory in GL before. It's a nasty hack, with little precision - but people have tried it :)[20:17:12] <Andon> A lot of times now, the model/memory is listed in the device string.[20:21:06] <hibread> interesting. I wonder why there has never been a way of requesting memory size?[20:27:17] <Andon> I think the philosophy of OpenGL's been to decouple client/server and hide a lot of that stuff. But I do think when the VBO extension was being finalized there should have been some consideration for querying memory; it should have been clear the direction the API was moving.[20:28:01] <hibread> yep good call[20:28:10] *** reviver has joined ##OpenGL[20:28:12] <hibread> im outta ere. Catchyas![20:28:58] *** neoneurone has joined ##OpenGL[20:29:15] *** hibread has quit IRC[20:32:04] <rsp> nooo :([20:33:57] *** reviver has quit IRC[20:37:24] *** groton has quit IRC[20:37:35] *** groton has joined ##OpenGL[20:37:55] *** groton_ has joined ##OpenGL[20:38:17] *** biberao has joined ##OpenGL[20:39:08] *** biberao has left ##OpenGL[20:39:46] *** groton_ has quit IRC[20:40:56] *** amalon_ has joined ##opengl[20:41:33] <quicksilver> http://roobarb.jellybean.co.uk/~jules/Picture%20121.png[20:41:40] <quicksilver> that's with 128-pixel wide textures[20:48:55] *** rnx has quit IRC[20:56:48] *** amalon has quit IRC[21:04:01] *** Roderic has quit IRC[21:06:40] *** ahelon has joined ##opengl[21:19:41] *** reviver has joined ##OpenGL[21:21:27] *** Jorachim has joined ##OpenGL[21:21:36] *** juanmabc has joined ##opengl[21:22:44] *** Jorachim has quit IRC[21:25:49] *** blbmp has joined ##OpenGL[21:26:48] *** groton has quit IRC[21:26:58] *** groton has joined ##OpenGL[21:27:15] *** sohail has quit IRC[21:27:57] *** korff has joined ##OpenGL[21:30:26] *** sohail has joined ##OpenGL[21:35:44] *** SmokingRope has joined ##OpenGL[21:37:26] *** Suprano has quit IRC[21:43:03] *** vampirefrog has joined ##OpenGL[21:43:04] *** Suprano has joined ##OpenGL[21:48:13] *** hubbe3 has quit IRC[21:52:53] *** hubbe3 has joined ##OpenGL[21:58:22] *** fargiolas has joined ##OpenGL[22:12:33] *** Lemml has quit IRC[22:18:27] *** kiras has joined ##OpenGL[22:19:21] *** TurboAWAY has quit IRC[22:19:43] *** tortan has joined ##OpenGL[22:21:15] <tortan> Nobody is talking here?[22:23:18] <bobbens> this is irc and freenode, be chill[22:26:36] *** neunon has quit IRC[22:29:30] *** neoneye2 has joined ##OpenGL[22:30:56] *** Jorachim has joined ##OpenGL[22:32:03] *** sjd has joined ##opengl[22:34:08] *** tortan has left ##OpenGL[22:34:15] *** vampirefrog has quit IRC[22:34:23] *** Yustme has quit IRC[22:34:49] *** Darius_ has quit IRC[22:35:58] *** Jorachim has quit IRC[22:43:37] *** mm765 is now known as mm765^sleep[22:47:33] *** ahelon has quit IRC[22:53:00] *** Xmas| has joined ##OpenGL[22:56:45] *** LiQuiDninja has joined ##OpenGL[22:58:46] *** m4ggus has quit IRC[23:10:54] *** fargiolas has quit IRC[23:11:43] *** fargiolas has joined ##OpenGL[23:14:59] *** pfo_sushi is now known as pfo[23:15:03] *** neoneye2 has quit IRC[23:23:04] *** m4ggus has joined ##OpenGL[23:24:49] *** cupe has quit IRC[23:24:56] *** cupe has joined ##OpenGL[23:28:07] *** neoneurone has quit IRC[23:33:01] *** kaotrix has joined ##OpenGL[23:33:39] *** Dephyrial has joined ##opengl[23:33:39] *** Dephyrial is now known as Defty[23:33:41] <rutski> Are higher values for GL_PACK_ALIGNMENT always better for performance?[23:37:30] <kaotrix> rutski: Hey[23:37:34] <kaotrix> "The last argument to glPixelStorei(GL_PACK_ALIGNMENT,1); can be changed to higher values for increased performance on some platforms. It does often put restriction on the window size, that is, the window must be an integer multiple of the value specified in glPixelStorei()."[23:41:25] *** scy has left ##opengl[23:44:55] <rutski> wait... huh?[23:45:01] <rutski> do they mean viewport size?[23:45:28] *** korff has quit IRC[23:45:34] <dvoid_> hey , you guyes know of any texture related bugs in ati 8.4 drivers?[23:45:40] *** fargiolas has quit IRC[23:46:25] <dvoid_> im having som really strange problems with those drivers, and i read that ogre had some strange texture problems to[23:50:25] *** Xmas| has quit IRC[23:51:12] *** karabash has quit IRC[23:53:35] *** Encryption767 has joined ##OpenGL[23:56:06] *** reviver has quit IRC[23:57:21] *** tmccrary has quit IRC