May 9, 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 9, 2008 [00:05:10] *** LtJax has quit IRC[00:17:26] *** magnet_ has quit IRC[00:25:01] *** LiQuiDninja has joined ##OpenGL[00:29:12] *** Burga has quit IRC[00:52:25] *** ced117 has quit IRC[00:53:29] *** jOpu1 has joined ##OpenGL[00:53:42] *** jOpus has quit IRC[00:56:22] *** Jorachim has joined ##openGL[01:03:46] *** Jernej has joined ##OpenGL[01:05:46] *** Jorachim has quit IRC[01:07:54] *** mastro has joined ##OpenGL[01:11:33] *** Ralith has joined ##OpenGL[01:13:36] *** magnet has joined ##OpenGL[01:17:58] *** MatthiasM has quit IRC[01:18:40] <Ralith> Can someone point me at a good tutorial for using OpenGL for 2d graphics?[01:22:31] *** JernejL_ has quit IRC[01:33:57] *** bolides has quit IRC[01:34:19] *** m4ggus_ has joined ##opengl[01:37:52] *** LordMetroid has joined ##OpenGL[01:39:22] *** amz has joined ##opengl[01:39:39] *** darka has quit IRC[01:40:57] <cupe> Ralith: one of the nehe tutorials describes 2d[01:42:43] *** CNU has quit IRC[01:43:11] <Ralith> cupe: I think I've got the basics-- I'm supposed to redraw everything from scratch each frame?[01:43:24] <Ralith> nehe's down[01:44:03] <Satan_Inside> yep you will (normally speaking) regenerate the scene for every render submission[01:44:23] <Ralith> kk[01:44:24] <Satan_Inside> just as one would do in the 3D case[01:47:20] <Ralith> also, I've enabled GL_POLYGON_SMOOTH and set a blend func, and lines (with GL_LINE_SMOOTH enabled) are drawing smooth, but triangles are still badly aliased[01:48:34] <cupe> you'll have to paint your stuff on quads instead of using the builtin lines etc[01:49:23] <cupe> they suck[01:49:40] <Ralith> huh?[01:49:43] <Ralith> k[01:49:56] *** CNU has joined ##opengl[01:49:57] <cupe> i tried really hard, once[01:50:32] <cupe> on some hardware the lines were antialiased, on other they were not, on a third machine there were no lines at all[01:50:37] <Ralith> quads are covered by GL_POLYGON_SMOOTH?[01:50:59] *** m4ggus has quit IRC[01:52:32] *** KU0N has quit IRC[01:53:05] *** amalon has quit IRC[01:53:09] <cupe> yes, there are no different kinds of polygons, just different ways to make them. but since quads are split into two triangles it may look strange with aa at that seam. in that case googling will help[01:53:33] <Ralith> googling tells me that GL_POLYGON_SMOOTH is unsupported on modern hardware.[01:53:38] *** rodietze has joined ##opengl[01:54:08] <cupe> oh :)[01:54:28] *** rodietze is now known as niteon[01:56:29] *** prophile has quit IRC[01:57:55] <Satan_Inside> Ralith not so much "unsupported" as "frequently emulated through the programmable pipeline rather than using dedicated hardware"[01:58:24] <Ralith> Satan_Inside: all I know is it doesn't work.[01:58:35] <Satan_Inside> on older ASICs this GL_*_SMOOTH was done via dedicated logic... this is no longer the case generally speaking[01:58:39] *** speedy1 has quit IRC[02:03:35] *** peda_ has joined ##OpenGL[02:04:04] *** MatthiasM has joined ##opengl[02:07:30] *** |t4bz| has joined ##OpenGL[02:21:18] *** peda__ has quit IRC[02:23:48] *** t4bz has quit IRC[02:26:24] *** TheLorax has quit IRC[02:29:37] *** Maerz has quit IRC[02:30:14] *** noteventime has quit IRC[02:41:11] *** LiQuiDninja has quit IRC[02:46:20] *** domino14 has joined ##OpenGL[02:46:30] <domino14> is there any reason why a call to glCallList should take like 3 seconds to execute[02:46:39] <domino14> and other times it executes in "0" milliseconds??[02:51:22] *** LordMetroid has quit IRC[02:53:48] *** jOpu1 has quit IRC[03:08:53] <domino14> is there any reason why a call to glCallList should take like 3 seconds to execute[03:09:12] <domino14> or anywhere between 0 and 3 seconds randomly[03:11:42] *** roaet has joined ##opengl[03:14:34] *** dvoid_ has quit IRC[03:14:43] *** blight_ has quit IRC[03:15:53] *** bsod2_ has joined ##OpenGL[03:25:00] *** TheLorax has joined ##opengl[03:27:51] *** bsod2 has quit IRC[03:30:58] <domino14> ARHG[03:31:00] <domino14> please![03:33:30] *** domino14 has quit IRC[03:41:15] *** hibread has joined ##opengl[03:42:59] *** roaet has quit IRC[03:43:44] *** odietsch^ has quit IRC[04:11:18] *** LiraNuna has quit IRC[04:19:11] *** niteon has quit IRC[04:19:29] *** m4ggus_ has quit IRC[04:30:32] *** kiras has quit IRC[04:40:35] *** rutski has quit IRC[05:06:52] *** HuntsMan has joined ##opengl[05:12:48] *** TheLorax has quit IRC[05:25:12] *** hibread has quit IRC[05:25:19] *** BahamutZERO has quit IRC[05:35:37] *** dust-- has joined ##OpenGL[05:36:19] <dust--> can OSG display text in 2D only as textures or also as (flat) vector based truetype fonts[05:36:47] *** rnx has left ##opengl[05:37:20] *** Latheesan has joined ##opengl[05:37:28] <Latheesan> hey guys, what does this error means?[05:37:28] <Latheesan> Error 2 error C2259: 'Ball' : cannot instantiate abstract class c:\Gibraltar Invasion\main.cpp 40[05:37:44] *** Walt has quit IRC[05:37:56] <smiler> that you have an abstract class and you're trying to make an object of it?[05:38:11] <Latheesan> i dont think my class is abstract[05:38:21] <smiler> the compiler seems to think so[05:38:31] <Latheesan> *kicks compiler*[05:38:37] <Latheesan> hmm[05:39:00] <smiler> do you have any virtuals in it?[05:39:06] <Latheesan> nope[05:39:10] <smiler> odd[05:39:13] <Latheesan> one sec, i can show u the code[05:39:16] <Latheesan> its fairly small[05:39:38] <smiler> hurry, I must catch my cab to the airterminal :)[05:39:44] <Latheesan> will do[05:39:55] <Latheesan> pastebin is being exceptionally slow with me today[05:40:15] <smiler> its always slow :P[05:40:26] <Latheesan> lol[05:40:33] <Latheesan> takes so long to save a few lines of text[05:40:37] <Latheesan> http://pastebin.ca/1012372[05:40:40] <Latheesan> there[05:41:01] <Latheesan> on my main, the line that is causing the error is :[05:41:08] <Latheesan> Ball cannonBall;[05:41:19] <smiler> I like http://cpp.ninjacodemonkeys.org/[05:42:05] <Latheesan> http://pastebin.ca/1012375[05:42:07] <Latheesan> this is my header[05:42:23] <smiler> odd[05:42:29] <smiler> crapy I gotta rush, Im really sorry[05:42:44] <Latheesan> ah no probs[05:43:00] <dust--> probably the problem is in NewtonianObject[05:43:00] <Latheesan> anyone free to take a look at this please?[05:43:08] <Latheesan> oh[05:43:35] <HuntsMan> and NewtonianObject is abstract?[05:44:01] <Latheesan> i think so[05:44:04] <Latheesan> im fairly new to this[05:44:11] <Latheesan> this is my newtonianobject[05:44:13] <Latheesan> http://pastebin.ca/1012378 (header)[05:44:20] <Latheesan> http://pastebin.ca/1012377 (cpp_[05:44:24] <Latheesan> )*[05:44:24] <HuntsMan> well it is[05:44:28] <HuntsMan> virtual void Update(float deltaTime) = 0;[05:44:33] <HuntsMan> pure virtual function -> abstract class[05:44:40] <Latheesan> ah[05:44:41] <dust--> see Update()[05:44:48] <dust--> needs to be implemented[05:44:51] <HuntsMan> yep[05:45:01] <Latheesan> its already implemented[05:45:04] <Latheesan> maybe on the wrong page[05:45:09] <Latheesan> file*[05:45:11] <dust--> but the wrong number of arguments[05:45:14] *** Walt has joined ##opengl[05:45:18] <Latheesan> ah crap[05:45:21] <HuntsMan> yeah, wrong number of arguments[05:45:22] <Latheesan> now i see[05:45:38] <Latheesan> yey fixed it[05:45:43] <Latheesan> thanks allot guys :) much appreciated[05:45:43] <dust--> cool[05:45:46] <dust--> np[05:45:55] <Latheesan> i shud probably move all my methods[05:46:04] <Latheesan> from the Ball.cpp to NewtonianObject.cpp[05:46:12] <Latheesan> so it can be inherited[05:47:11] <dust--> is osg 2d text always bitmaps? i would like to have zoomable 2d text[05:47:59] *** TheLorax has joined ##opengl[05:49:00] *** Latheesan has quit IRC[05:55:37] *** kaotrix has quit IRC[06:01:19] <bgilb> can a graphics card support HLSL and not GLSL?[06:04:58] <dust--> depends on the driver i assume[06:05:08] *** Isityou has joined ##OpenGL[06:05:22] <Isityou> Does OpenGL come with GCC?[06:06:20] <dust--> i think the question is rather does it come with your linux distibution[06:06:46] <Isityou> So I can like YUM OpenGL?[06:06:57] <Isityou> or some package getter with install it for me?[06:07:12] <dust--> node idea, try ##linux[06:07:22] <dust--> lol no[06:07:25] <dust--> not node[06:08:27] <bgilb> i wanted to learn GLSL but now its impossible :[[06:14:50] *** amz has quit IRC[06:20:24] *** Latheesan has joined ##opengl[06:20:38] <Latheesan> is there a better way to implement gravity?[06:20:49] <Latheesan> this is how i do it right now : http://pastebin.ca/1012396[06:21:09] <Latheesan> its a little sloppy, i was wondering if there is a "better" or even a "propper" way to do this[06:26:38] *** vasoq has quit IRC[06:35:30] <Ralith> Latheesan: yes; using a physics engine[06:39:37] <HuntsMan> bgilb: why it is impossible?[06:42:51] <HuntsMan> Isityou: OpenGL is part of your graphics drivers, what card do you have?[06:42:52] <Latheesan> Ralith, any tips on how?[06:43:23] *** NeoThermic has quit IRC[06:43:24] <Isityou> HuntsMan: Radeon 9800, so that means all I need are the include files?[06:43:45] <HuntsMan> yep[06:44:02] <HuntsMan> well mesa provides that, so you should install the mesa packages ending with "-devel"[06:45:28] <Ralith> Latheesan: you probably don't need one if all you have to simulate is a cannon ball[06:45:53] <Latheesan> ah =/[06:46:33] *** NeoThermic has joined ##OpenGL[06:48:04] *** Lemml has joined ##OpenGL[06:49:55] *** TheLorax has quit IRC[06:50:59] *** karabash has joined ##OpenGL[06:56:22] <Isityou> HuntsMan: Do you have any good tutorials? I have Mesa installed[06:59:37] <HuntsMan> for what?[06:59:54] <sohail> Isityou, google for opengl redbook[07:00:06] <Isityou> I know about the red book[07:00:22] <Isityou> So once I install Mesa i just include the GL headers like any other mingw compiler?[07:00:25] *** mm^away has joined ##opengl[07:00:48] <sohail> Isityou, google for mingw manual[07:00:54] <Isityou> I'm on gcc[07:01:32] <sohail> Isityou, google for gcc manual[07:01:49] <Isityou> What does the gcc manual have to do with OpenGL?[07:01:55] <HuntsMan> Isityou: yep[07:01:58] <HuntsMan> #include <GL/gl.h> and such[07:02:05] <HuntsMan> make sure you have the headers at /usr/include/GL[07:02:18] *** Suprano has joined ##OpenGL[07:02:40] <Isityou> HuntsMan: sweet, its all there, thanks for the help![07:10:25] *** HuntsMan has quit IRC[07:11:05] <sohail> I just don't understand how you "know about the red book" but yet you don't know you have to do #include <GL/gl.h>[07:12:30] *** HuntsMan has joined ##opengl[07:17:20] *** mm765 has quit IRC[07:38:35] *** mm^away is now known as mm765[07:46:38] *** Suprano has quit IRC[08:06:46] *** Lemml has quit IRC[08:23:01] *** charlie_zzz is now known as charlie5[08:38:38] *** blbmp has quit IRC[08:42:14] *** Latheesan has quit IRC[08:43:20] *** sohail has quit IRC[08:50:34] *** karabash has quit IRC[08:57:42] *** TenOfTen has quit IRC[08:58:53] *** TenOfTen has joined ##opengl[09:04:55] *** Baba_ has quit IRC[09:05:05] *** Baba__ has joined ##OpenGL[09:07:21] *** Lemml has joined ##OpenGL[09:16:58] *** groton has joined ##OpenGL[09:17:15] *** Roderic has joined ##OpenGL[09:17:16] *** Roderic is now known as Ingenu[09:19:42] *** TenOfTen has quit IRC[09:19:52] *** TenOfTen has joined ##opengl[09:35:12] *** amalon has joined ##opengl[09:44:10] *** neoneye2 has joined ##OpenGL[09:49:36] *** dust-- has quit IRC[09:54:16] *** pragma_ has joined ##opengl[10:09:10] *** Castigador has joined ##Opengl[10:16:35] *** stuckie has quit IRC[10:22:41] *** Suprano has joined ##OpenGL[10:23:17] *** Bollinger has joined ##opengl[10:27:53] *** Jupp3 has quit IRC[10:36:42] *** TurboAWAY is now known as [AD]Turbo[10:43:38] *** Ahmed has joined ##OpenGL[10:44:13] *** Jupp3 has joined ##OpenGL[10:45:27] *** Lemml has quit IRC[10:50:54] *** Burga has joined ##OpenGL[10:51:46] *** servus has quit IRC[10:58:57] *** Suprano has quit IRC[11:00:14] *** BahamutZERO has joined ##OpenGL[11:13:07] *** Suprano has joined ##OpenGL[11:13:34] *** pascsaq has joined ##OpenGL[11:22:05] *** dispraekailo has quit IRC[11:27:00] *** dvoid has joined ##OpenGL[11:30:04] *** dispraekailo has joined ##OpenGL[11:31:14] *** gian has joined ##OpenGL[11:32:13] *** servus has joined ##opengl[11:38:38] *** gotan666 has joined ##OpenGL[11:44:05] *** Ahmed has quit IRC[11:50:17] *** Ralith has quit IRC[11:51:11] *** pq has joined ##opengl[11:55:01] *** fargiolas has joined ##OpenGL[12:00:19] *** groton has quit IRC[12:00:39] *** groton has joined ##OpenGL[12:07:38] *** hypernewbie has joined ##OpenGL[12:09:19] *** fargiolas_ has joined ##OpenGL[12:14:15] *** pascsaq has quit IRC[12:15:06] *** magnet_ has joined ##OpenGL[12:28:18] *** magnet has quit IRC[12:31:46] *** fargiolas has quit IRC[12:31:57] *** fargiolas_ is now known as fargiolas[12:36:05] *** mm765 is now known as mm765^sleep[12:39:21] *** MrPrise has joined ##OpenGL[12:39:26] <MrPrise> hello[12:39:40] <MrPrise> how can I render into a texture? do I need an extension for this?[12:42:51] *** Castigador has quit IRC[12:43:44] <Adrinael> With framebuffer objects[12:44:57] *** Castigador has joined ##Opengl[12:46:11] <quicksilver> or with glCopyTexImage[12:46:21] <quicksilver> if you don't have FBOs / don't know how to use them ;)[12:49:19] *** Walt has quit IRC[12:53:55] <MrPrise> quicksilver: good assumption ;-)[12:54:02] <MrPrise> actually it is true ;-)[12:56:31] *** bgilb has quit IRC[12:56:45] <pq> glXMakeCurrent has the drawable argument, and I'm going to have several threads, each with their own GL context, doing rendering to separate FBOs and one rendering to the X window. Can I pass the same window to all glXMakeCurrent calls in the threads, or will I get into trouble?[13:00:33] <Ingenu> your hardware being sequential, what do you want to parallelize ?[13:03:07] <pq> one thread is running video-framerate speed preprocessing for live video input, one thread is doing video analysis, and one is displaying the resulting model. The threads are not locked, but run asychronously. And I'm relying on the nvidia hardware context switching for serializing the rendering in different contexts for a single GPU.[13:04:57] <pq> each thread can do some of its work in opengl, and different opengl tasks are not related nor usually synchronized[13:05:29] <pq> Ingenu, did I answer your question?[13:07:34] <Ingenu> yes[13:07:54] <Ingenu> nvidia hardware context switching it limited to only one GPU AFAIR though[13:08:25] <pq> I only have one, currently, or what do you mean?[13:08:41] <Ingenu> it will work on only G8x[13:09:13] <Ingenu> other nvidia GPU don't have that feature[13:09:29] <pq> now I'm puzzled, all nvidia cards from nv20 upwards support automatic hw context switching[13:09:46] *** blight_ has joined ##opengl[13:09:55] <Ingenu> they have ?[13:10:05] <Ingenu> that's news to me, I wasn't aware of that fact at all[13:10:16] <pq> card before nv20 issue an interrupt and the kernel driver switches the context[13:11:06] <Ingenu> how expensive is a context switch then ? does it have to empty the pipeline before switching ?[13:12:23] <pq> good question, I'm not sure what is considered into the "state"... I guess it should be fast.[13:13:54] <pq> but my original question is, can I theoretically have more than one GL context targetting the same window simultaneously, or does the API/implementation trigger some safety check or deny this, even when only one context is actually drawing into the window?[13:15:03] <pq> marcheu, hey, you can answer the context switch speed question :-)[13:15:30] <pq> afk for a moment[13:17:22] <Ingenu> I have no idea, I do only basic stuff with OpenGL you know, like games...[13:17:30] <marcheu> pq: ?[13:18:18] <marcheu> yeah nvidia context switches are cheap, no flus[13:18:49] <marcheu> one context is interrupted, the state is switched by the gpu (so no stall) and things move on in another context[13:20:28] <marcheu> and even on nv4 you have irq assisted context switches, which are very fast too (again no pipeline flush there)[13:21:56] *** fargiolas_ has joined ##OpenGL[13:22:28] *** Vixus has joined ##OpenGL[13:23:02] <Ingenu> I see[13:23:12] <Vixus> Hey, I know it's a common problem but has anyone worked out some way of getting proper fullscreen on Gnome/Ubuntu with (free)glut?[13:25:24] <hypernewbie> solution: dont use glut[13:25:32] <hypernewbie> gluts a joke[13:26:05] <Vixus> What are the alternatives?[13:26:07] <hypernewbie> glfw[13:28:27] <marcheu> pq: btw I don't think you'll run into issues on nvidia hw/drivers. but other combinations might not work[13:29:17] <marcheu> pq: and creating multiple dumb (even not visible so you don't clutter your screen) windows is quite simple ?[13:31:57] <marcheu> pq: actually you'll have issues on glx calls I think[13:33:14] *** darka has joined ##opengl[13:35:23] <Vixus> hypernewbie: can you recommend any image loading libraries that would go well with glfw?[13:36:07] <hypernewbie> Vixius: sorry, im a bmp person(dont kill me)[13:36:36] <hypernewbie> Vixius: but i think you got al lur libpngs and libjpegs and whatnot, or you could use some tga loading code stole noff some tutorial[13:36:37] <Vixus> no worries, I've used bmps plenty.[13:36:59] <Vixus> anyway the glfw site is pretty good, it's got links to useful libs.[13:37:24] <hypernewbie> glftw![13:38:24] <Vixus> i better get it compiled and working first..[13:40:38] <Vixus> hmm, what dev libraries do I need to compile it?[13:41:54] <hypernewbie> hmm?[13:42:16] <hypernewbie> the package should come with g++ binaries and .h and stuff[13:42:46] <Vixus> ok, i think it went well.. can't really tell.[13:43:17] *** fargiolas has quit IRC[13:48:58] <pq> marcheu, hmm, right. So I'll just create a hidden dummy window for each context.[13:50:12] <marcheu> yeah the only reason I'd share a X window is to be able to share a glx context (which doesn't seem useful to you) ?[13:50:21] <pq> umm...[13:50:58] <pq> I need a little bit of sharing between the GL contexts, I'd like to able to e.g. create BOs in one thread and pass then to the other[13:51:24] <marcheu> yeah, if you share the glx context, you can do that without a copy to system ram & back[13:52:01] <pq> but are we talking about using the same GL context in two threads, or two GL contexts with sharing enabled? I was thinking the latter.[13:52:18] <marcheu> yup the latter[13:52:30] <marcheu> with 2 threads you're going to do copies yourself[13:53:07] <marcheu> really my point is: either share everything (including glx context) or nothing. intermediate has no purpose[13:53:14] <pq> I don't really need copies, object ownership is transferred[13:55:20] <pq> the sharing would be between the slow analysis thread and the mostly-sleeping-but-fast user interface thread - it's not the end of the world if the UI is stalled while analysis is working, but that would make a rather bad user experience[13:56:23] <pq> in other words, are you saying that the share_list argument of glXCreateContext should not be used?[13:57:22] <marcheu> I've never tried it from 2 separate X windows[13:57:32] <marcheu> but that might work, yeah[13:58:13] <pq> okay, well.. it things fall back to making a copy in my app, that should not be intolerable[13:58:58] *** oxmoz has left ##opengl[13:59:10] <Vixus> hypernewbie, ace.. just compiled a program.. glfw worked without any config..[13:59:26] <marcheu> pq: anyway, gotta go, but tll me how it goes, I'm interested[13:59:33] <marcheu> tell*[13:59:57] <pq> marcheu, cool. But it will take time for me to get things together :-)[14:00:57] <hypernewbie> Vixus: yeah, glfw is everything glut claims to be, but unlike glut glfw doesnt EPIC FAIL[14:02:49] <Vixus> the ultimate test.. will it go fullscreen for me[14:03:19] <Vixus> i'm in awe[14:04:38] <Vixus> cheers dude, i wouldn't have ever known glfw existed.[14:08:31] <hypernewbie> yeah, glut gets a lot worse[14:08:58] <hypernewbie> the smartarses at glut thought it would be funny not to include ctrl, alt, and shift keys as events[14:09:43] <hypernewbie> they also thought that alt+key should generate a different key event code[14:09:50] <hypernewbie> rather than calling twice for alt and key[14:10:07] <hypernewbie> in fact[14:10:16] <Vixus> ugh[14:10:30] <hypernewbie> actuall, i better stop glut rat, its an opengl channel :P[14:10:36] <hypernewbie> rant*[14:12:22] <Vixus> you're not insulting opengl though, just one of its toolkits. :D[14:14:13] <Vixus> anyway, it's got a really understandable setup.[14:14:51] <Vixus> thanks again, see you later mebbe.[14:14:55] *** Vixus has quit IRC[14:16:16] *** odietsch has joined ##OpenGL[14:25:33] *** dvoid has quit IRC[14:29:01] <quicksilver> So. accurate shadows onto a single plain from many moving light sources.[14:29:04] <quicksilver> Accumulation buffer?[14:31:02] *** m4ggus has joined ##opengl[14:42:29] *** hibread has joined ##opengl[14:44:42] *** fargiolas_ is now known as fargiolas[14:53:15] *** Walt has joined ##opengl[14:54:51] <Adrinael> quicksilver, accumulation buffers are so 90s. Framebuffer objects with 12-bit floating point color channels is the key today.[14:55:06] <quicksilver> Adrinael: my graphics cards are from the 90s though :P[14:55:39] <Adrinael> Well, you need a hardcore non-gaming graphics card from the 90s to have decent accumbuffer performance[14:55:42] *** Castigador has quit IRC[14:55:44] <quicksilver> Adrinael: actually reading around I wonder if I shouldn't render a version of the scene with the viewpoint set to each light, in turn[14:55:52] <Adrinael> Or a Matrox G400, it's fast there for some silly reason[14:55:55] <quicksilver> with the viewport set to my plane[14:56:03] <quicksilver> and copy that from the backbuffer to a texture.[14:56:16] <Adrinael> Do you mean accurate shadows as in sharp shadow edges?[14:56:29] <quicksilver> I have many moving point sources of light[14:56:40] <quicksilver> I want the shadows to 'flicker around' as the light sources move[14:57:11] <quicksilver> fortunately the plane that the shadows need to fall onto is a planar rectangle.[14:57:14] <quicksilver> indeed, it's a square.[14:58:09] <quicksilver> Adrinael: graphics card is a radeon 9250 if that informs you anything :)[14:58:28] <Adrinael> It's too new and too desktop to have fast accumbuffers =)[14:59:47] <quicksilver> it doesn't have FBOs either though.[15:00:02] <quicksilver> at the moment I'm doing render-to-texture by rendering to the back buffer and then going glCopyTexImage2D[15:03:11] *** Jorachim has joined ##OpenGL[15:14:26] *** gotan666 has quit IRC[15:17:08] *** rnx has joined ##opengl[15:18:28] *** hypernewbie has quit IRC[15:21:30] *** ajww has joined ##OpenGL[15:27:51] *** LordMetroid has joined ##OpenGL[15:29:55] *** joakim__ has joined ##OpenGL[15:33:48] *** kenws has joined ##OpenGL[15:46:21] *** joakim_ has quit IRC[15:52:22] *** ajww has quit IRC[15:53:04] *** ajww has joined ##OpenGL[15:54:27] *** Jorachim has quit IRC[15:55:31] <hibread> quicksilver: you seriously just need to upgrade and have more fun with much more reasonable support[15:57:20] *** Satan_Inside has quit IRC[15:57:55] *** Satan_Inside has joined ##OpenGL[16:00:38] <quicksilver> hibread: cards with TV out which work on linux with open source drivers and connect via PCI aren't 2-a-penny.[16:00:48] <quicksilver> hibread: I'm reluctant to change until I have a good reason :)[16:01:10] <hibread> so stuffing around with accum buffers, or copytexblahblah is fun for you? :)[16:01:19] <hibread> to me, that is very very good reason[16:02:02] <hibread> if you're into graphics then i find it hard to believe that near on bleeding edge tech (features and speed) is something that you wouldn't want to take bite out of[16:02:05] <hibread> :)[16:02:58] <hibread> "and connect via PCI"... you dont mean pci express do you?[16:03:51] <tmccrary> Out of curiosity.... for you, why are closed source drivers a deal breaker? Idealogical reasons?[16:05:07] *** ced117 has joined ##OpenGL[16:07:58] <meteors> Is there any way to render to a texture by using OpenGL commands, without using fbos?\[16:08:17] <meteors> I don't need to render constantly, just once as the app is initializing.[16:08:19] <hibread> you mean a direct way?[16:08:28] <hibread> err[16:08:29] <meteors> I'd like to use OGL commands.[16:08:39] <hibread> yeah render to frame buffer and copy the data[16:08:48] <meteors> ok, hmm[16:08:49] <hibread> glCopyTexImage2D[16:08:51] *** prophile has joined ##opengl[16:09:00] <meteors> cheers[16:09:13] <quicksilver> tmccrary: closed source drivers invariably bit rot.[16:09:21] <quicksilver> tmccrary: a new kernel version or x org version adn they break.[16:09:27] <quicksilver> hibread: I mean PCI.[16:09:39] <hibread> quicksilver: i was fearing that[16:09:41] <quicksilver> hibread: it's a ca. 3 year old socket 939 board.[16:09:47] <tmccrary> quicksilver: ah the practical issue[16:09:55] <hibread> ca?[16:10:00] <tmccrary> circa?[16:10:05] * quicksilver nods[16:10:23] <hibread> 3 years ago we pciE... and agp[16:10:36] <quicksilver> I was looking for the cheapest mythtv box I could build, basically.[16:10:40] <quicksilver> it didn't need power or AGP.[16:10:45] <quicksilver> it needed to be able to drive the TV ;)[16:11:26] <hibread> you could actually buy a motherboard back then without agp? (Shows my naiveity obviously...)[16:11:44] <quicksilver> yes.[16:12:00] <quicksilver> I have a vague memory I was specifically searching for one because the video card which supported TV out was PCI.[16:12:04] <quicksilver> I'm not sure :)[16:12:09] <quicksilver> I can't remember the reasons for all my decisions.[16:12:16] <hibread> well, you're paying the price now :) Check out ebay for a cheap rig thats a couple years old.. maybe with a geforce 6800 or something :)[16:12:25] *** replor has quit IRC[16:13:25] *** Jorachim has joined ##OpenGL[16:19:03] *** kaotrix has joined ##OpenGL[16:20:21] *** Isityou has quit IRC[16:21:34] <hibread> quicksilver: sorry.. you'll want an ATi rig.. for the OS drivers[16:21:59] * quicksilver nods[16:22:10] <quicksilver> the ATI drivers have leapt and bounded ahead in the last six months[16:22:19] <quicksilver> as you'll know if you follow that kind of stuff of the intarwebs.[16:22:21] <tmccrary> Its funny with the nvidia cards[16:22:26] <quicksilver> ATI released a bunch more docs.[16:22:33] <tmccrary> a slow 8 series card is cheaper than any of the 6's[16:22:42] *** Isityou has joined ##OpenGL[16:23:04] <tmccrary> Personally, I doubt ATI hardware will be viable before 2-3 years[16:24:23] <hibread> tmccrary: i ment for a 2nd hand PC off of ebay thats a few years old.. get for a sixpence[16:27:35] *** eidolon has left ##OpenGL[16:29:08] <quicksilver> tmccrary: well depends what you mean by "viable"[16:29:15] <quicksilver> it may be perfectly viable for me :)[16:29:26] *** rnx has quit IRC[16:30:10] <tmccrary> I guess, for me, viable means usable without a lot of crashes/problems/visual errors/etc[16:30:42] <tmccrary> Having OSS drivers helps a lot of that, if they're done right. So I'm looking forward to the ATI project maturing, so I can switch :)[16:30:57] <tmccrary> I'm primarily on Nvidia at the moment[16:33:32] *** Baba has joined ##OpenGL[16:34:35] *** folays_ has joined ##opengl[16:36:14] *** gotan666 has joined ##OpenGL[16:38:27] *** TheLorax has joined ##opengl[16:45:22] *** TheLorax has quit IRC[16:45:25] *** rutski has joined ##OpenGL[16:45:55] <rutski> I never realized what a difficult problem UI Toolkit design is, especially when you throw font rendering into the mix[16:46:02] *** amz has joined ##opengl[16:46:28] <ville> cegui doesn't cut it for you?[16:49:53] <tmccrary> yeah gui development is a bitch[16:51:04] <rutski> ville: nope; I'm interesting in learning how to design widget toolkits[16:51:19] *** Baba__ has quit IRC[16:51:29] <ville> rutski: oh well, it's nothing really special to it. More about the grunt work.[16:52:07] <rutski> the hardest problem I'm having now is that I intend to render the 2D UI widgets in this otherwise 3D OpenGL app into a 2D ortho graphic space going from -1 to 1 on both the X and Y axis[16:52:10] *** folays has quit IRC[16:52:40] <rutski> given that floating point space running from -1.0 to 1.0, I'm having a hard time figuring out how to render fonts[16:52:41] *** sohail has joined ##OpenGL[16:53:22] <rutski> or rather, I know that I can easily translate a floating point space from -1.0->1.0 into pixel based window coordinates by just doing some math with the view port dimensions; so that's not hard[16:53:48] <rutski> the hard part is that I'm not sure how I should specify the size of the fonts to be rendered[16:54:11] <rutski> if I specify a box for a font to be rendered in, what if the string doesn't fit into the box horizontally?[16:54:25] <rutski> what if the designer put some of the font's glyphs outside of the EM square, what do I do then?[16:54:29] <rutski> etc.. etc...[16:54:33] <tmccrary> well you should have access to glyph's bounding info[16:54:49] <tmccrary> so you should be able to write a simple function to test if the string will fit[16:55:25] <ville> rutski: clip the text or wrap it to a new line. usually that is left upto the container holding the text.[16:55:49] <rutski> right, and that's fine; if the text doesn't fit horizontally then I can just clip off a few letters[16:56:41] <rutski> but when someone says "draw me some text in the rect P1(100, 100), P2(200, 110)", (p1 being the upper left point, p2 begin the lower right), then what exactly does that mean?[16:56:59] <rutski> does that mean that the height of the target rect is intended to be the height of the EM square?[16:57:11] <rutski> or does it mean that the bottom/top of the rect are to be the descent/ascent?[16:57:24] <rutski> or is it yet some third thing that I haven't considered yet[16:57:31] *** Isityou has quit IRC[16:57:52] <tmccrary> well, with our gui stuff, you just specify a point size, not a bounding area for the entire string[16:58:00] <rutski> I had thought that the bottom/top of the EM square literally define the descent and ascent, but apparently that's not so.[16:58:00] <tmccrary> size + position[16:58:30] <tmccrary> although I'm not sure if you're talking about a container for text OR drawing the text itself[16:58:42] <rutski> container for text, I think[16:59:03] <rutski> like if I have a button, and I need text to go inside of it, with some space still left around the text so it looks nice[16:59:25] <rutski> then the best thing to do would be to specify a bounding area for the text that's inside of the button, right?[17:00:41] <tmccrary> I use the bounding area to determine what point size to use[17:01:06] <tmccrary> and then adjust the position to make it centered after I know what size fits best[17:01:17] <rutski> right, that's exactly what I want to do[17:01:22] <rutski> but I don't know how to do it[17:01:32] <rutski> because I don't know what the bounding area is supposed to mean[17:01:36] <quicksilver> I try multiple times at different point sizes[17:01:41] <quicksilver> withing a given width[17:01:50] <rutski> does it's height correspond to the height of the EM square?[17:01:59] <quicksilver> so I measure the font at e.g. 48 points, if that doesn't fit, measure 2 lines at 36 pts[17:02:01] <rutski> or does it's top/bottom define the ascent/descent[17:02:05] <quicksilver> the line breaking logic is fiddly.[17:02:12] <rutski> or is it some third option I haven't considered[17:02:13] <quicksilver> not hard, but fiddly.[17:03:55] *** Ingenu has quit IRC[17:08:56] *** TheLorax has joined ##opengl[17:13:14] <rutski> perhaps I'm thinking about this backwards[17:13:28] <rutski> maybe I should be choosing the widget dimensions based on the text[17:13:33] <rutski> and not the other way around[17:15:05] *** replor has joined ##OpenGL[17:17:57] *** meteors has quit IRC[17:19:07] *** amz has quit IRC[17:32:10] *** kenws has quit IRC[17:35:48] <quicksilver> rutski: both directions make perfect sense.[17:35:57] <quicksilver> depending on the goals of your toolkit :)[17:36:02] <rutski> yea, good point[17:36:26] <rutski> although just now I realized that perhaps I shouldn't be designing my widgets in a floating point space between -1.0-1.0 at all[17:36:31] <rutski> but instead be using raster graphics for them[17:37:15] *** rnx has joined ##opengl[17:39:32] <quicksilver> rutski: I use both of those approachs, sometimes.[17:39:40] <quicksilver> sometimes I use ortho2D with screen pixel coords[17:39:44] <quicksilver> sometimes with +/-1[17:39:52] <quicksilver> different appraoches suit different problems.[17:42:50] *** Jorachim has quit IRC[17:46:18] *** karabash has joined ##OpenGL[17:49:52] *** Jorachim has joined ##OpenGL[17:51:30] *** [AD]Turbo is now known as TurboAWAY[17:53:10] <uchitoru> hi all. bit of a problem. glm is included but when i try to open a file like: GLMmodel *m1 = glmReadOBJ("myobject.obj"); it doesn't show any error and it doesn't open the visualisation window.[17:54:00] <uchitoru> im trying to load a .obj in the scene[17:54:14] <uchitoru> any ideas on that?[17:55:33] *** Jorachim has quit IRC[17:55:38] <tmccrary> its like magic[17:55:50] <tmccrary> it only works if you believe[17:56:07] <uchitoru> i guess my faith is ok ;)[17:56:46] <uchitoru> it realy looks like magic cause the window splash screens and disapear quickly[17:57:47] <rnx> why would readobj show a window[17:57:49] <tmccrary> I know nothing about GLM, sorry[17:58:13] <uchitoru> ok tmccrary, thnks anyway[17:58:42] *** HuntsMan has quit IRC[17:58:47] <uchitoru> rnx i have a scene with other objects, im just reading it[18:00:45] <rnx> the usual stuff ... check for gl errors ... post code of a minimal failing example[18:00:52] *** enoex has quit IRC[18:01:31] <hibread> guys... I has'd a problems[18:01:43] <hibread> some background info...[18:01:48] <uchitoru> i just followed this example -> http://www.d.umn.edu/~ddunham/cs5721f07/schedule/resources/lab_opengl07.html to make sure i was not makin it wrong my self[18:01:53] <uchitoru> and i was the same[18:02:00] <hibread> my renderer uses a deferred approach[18:02:12] <uchitoru> it* was the same..[18:02:48] <hibread> err that info you didn't really need to know, but im implementing a screen space ambient occlusion pass[18:03:04] <hibread> so have a depth buffer which im using and a normal buffer[18:03:32] <hibread> anywho... i know how to recreate the XYZ coordinates of a pixel from the depth buffer[18:03:42] <hibread> but[18:04:26] <hibread> during the pass i need to find the XYZ coordinates of a sample of pixels inclose proximity to the subject pixel[18:04:59] *** ahelon has joined ##opengl[18:05:15] <hibread> currently im passing a varying variable describing the XYZ location of the "object". For example a spot light it'll be a sphere... and in this case just a simple quad over the entire screen[18:05:32] <hibread> the current pixel that is.. not the entire object[18:06:07] <hibread> so its pretty easy to generate the XYZ of a fragment from the depth value in this case... but what would be a good method to gernerate the XYZ value for pixels around the subject pixel?[18:08:39] *** gotan666 has quit IRC[18:11:54] <hibread> no ideas guys? Don't follow my desciption of the problem? :)[18:16:05] *** neoneye2 has quit IRC[18:24:22] *** groton has quit IRC[18:25:09] <pq> marcheu, it works :-)[18:26:29] <marcheu> terrific :)[18:26:46] <pq> marcheu, I have two threads with their own GL contexts, one creates BOs and the other draws them, producer/consumer thing. More threads and contexts coming next week. Or week after that.[18:29:08] <pq> and I'm using a dummy window for the non-display thread, it was quite simple.[18:33:34] *** Suprano has quit IRC[18:33:37] *** marenz_ has joined ##OpenGL[18:34:07] *** Maerz has joined ##OpenGL[18:35:00] *** Yustme has joined ##opengl[18:36:27] *** Jorachim has joined ##OpenGL[18:38:49] *** folays_ has quit IRC[18:42:08] *** pq has left ##opengl[18:55:17] *** hibread has quit IRC[19:03:36] *** Skarab has joined ##OpenGL[19:07:10] <Skarab> yo[19:10:22] *** Lemml has joined ##OpenGL[19:12:08] *** LordMetroid has quit IRC[19:12:31] *** Walt has quit IRC[19:20:15] *** HuntsMan has joined ##opengl[19:23:00] *** _boto has joined ##opengl[19:23:14] *** filmor has joined ##OpenGL[19:23:16] *** marenz_ has quit IRC[19:25:23] *** mm765^sleep is now known as mm765[19:28:41] *** MrPrise has left ##OpenGL[19:28:47] *** rnx has quit IRC[19:33:15] *** rnx has joined ##opengl[19:35:04] *** _boto2 has joined ##opengl[19:36:30] *** Walt has joined ##opengl[19:40:40] *** Xmas| has joined ##OpenGL[19:41:30] *** Jorachim is now known as Jorachim-Away[19:46:01] *** fargiolas has quit IRC[19:46:31] *** charlie5 is now known as charlie_zzz[19:46:52] *** fargiolas has joined ##OpenGL[19:47:15] *** Jorachim-Away is now known as Jorachim[19:50:28] *** _boto has quit IRC[19:55:19] *** magnet__ has joined ##OpenGL[20:00:20] *** rodietze has joined ##opengl[20:01:11] *** rodietze is now known as niteon[20:04:20] *** fargiolas is now known as fargiolas|afk[20:07:20] *** blbmp has joined ##OpenGL[20:08:07] *** magnet_ has quit IRC[20:11:47] *** Skarab has quit IRC[20:16:41] *** Jorachim has quit IRC[20:17:10] *** Jorachim has joined ##OpenGL[20:24:30] *** _boto has joined ##opengl[20:29:24] *** _boto3 has joined ##opengl[20:31:40] *** domino14 has joined ##OpenGL[20:31:48] <domino14> glCallList is taking like 3 seconds to execute[20:31:55] <domino14> it has a gluNurbsSurface in it[20:32:08] <domino14> why would it take so long? sometimes it does it immediately, sometimes it takes forever[20:32:22] <domino14> i dont even know how to debug it line by line since it's a compiled list[20:36:09] *** speedy1 has joined ##OpenGL[20:38:16] *** Xmas| has quit IRC[20:39:14] *** _boto2 has quit IRC[20:39:43] *** Walt has quit IRC[20:44:37] *** _boto has quit IRC[20:46:50] <Jupp3> domino14: Don't know for sure, but perhaps it's not necessarily executed the moment you call it?[20:47:28] <Jupp3> As with f.ex. with direct mode, there's no guarantee that f.ex. glVertex() is executed, except after calling glFlush(); glFinish(); or swapbuffers[20:48:39] <domino14> i call glFlush[20:48:43] <domino14> the call itself takes forever[20:48:48] <domino14> but only sometimes[20:48:57] <domino14> the call to glCallList that is[20:50:17] *** _boto3 is now known as _boto[20:53:50] <Jupp3> Maybe the polycount just is too high?[20:54:02] <Jupp3> Well, I wouldn't use gluNurbsSurface anyway, so I wouldn't know[20:54:35] <Jupp3> But if you f.ex. draw static spheres with gluSphere(), that's "A Really Bad Idea(tm)"[21:01:33] <domino14> how come?[21:02:06] <domino14> the polycount isnt that high - again, it's perfectly fine one time, and if i load another model it takes forever[21:03:59] <domino14> and then i load another model and it's fine again[21:04:02] <domino14> it can even be the same model[21:04:11] <domino14> and sometimes the surface looks nice and smooth, sometimes jagged[21:14:46] <domino14> i think i'm tracking down the bug -- i have it showing all the polygons, and the call takes forever when the model inexplicably gets generated with way too many polygons[21:15:08] <domino14> it makes sense that it's slower with that many polygons, but why does it draw like 30 polygons sometimes, and sometimes like 30,000[21:15:15] *** DarkUranium has joined ##OpenGL[21:15:22] <DarkUranium> hi[21:15:22] *** sohail has quit IRC[21:15:28] <domino14> hi <3[21:15:49] <DarkUranium> what's up?[21:18:05] <DarkUranium> BTW, anyone new to OGL here?[21:18:08] <DarkUranium> just wondering[21:18:30] <Makegho> how new?[21:18:34] <Makegho> and why?[21:18:43] *** sohail has joined ##OpenGL[21:19:23] <DarkUranium> old enough to get past the "OMGWTFIMGONNADIE" stage ;)[21:19:34] <DarkUranium> s/get/have gotten/[21:19:50] <DarkUranium> s/ to/, that you/[21:20:48] <tmccrary> domino14: what kind of hardware are you using?[21:21:28] <domino14> are you actually using sed expressions in this chat?[21:21:52] <domino14> is there a way to put an upper limit on the number of polygons that glunurbssurface generates?[21:22:28] <domino14> nvidia quadro fx 500/600 PCI[21:23:24] <Makegho> DarkUranium: I'd suppose almost everyone if not everyone here can create at least simple opengl software -- why? :)[21:24:02] <DarkUranium> I've been looking for someone to help me with my problem, and new guys are usually more willing to help :P[21:24:06] <DarkUranium> oops[21:24:07] <DarkUranium> I meant project[21:24:08] <DarkUranium> not problem[21:24:46] <tmccrary> Is it an RPG?[21:24:54] <Makegho> heh[21:24:59] <DarkUranium> no, why?[21:25:19] <DarkUranium> there is another (unrelated) RTS project in planning...[21:25:26] <DarkUranium> I could use a modeller if you can make models :)[21:25:29] <Makegho> in my experience, usually when someone has asked people to join their project, it has been an rpg[21:25:34] <DarkUranium> :P[21:25:39] <DarkUranium> a MMO?[21:25:43] <tmccrary> Even better[21:25:57] <DarkUranium> people tend to try and make one of their first games MMOs in some communities[21:26:02] <DarkUranium> they fail.[21:26:07] <Makegho> that massive-part requires lots of money to advertising[21:26:14] <DarkUranium> yeah[21:26:18] <DarkUranium> that's not the reason though[21:26:29] <DarkUranium> the games never get created :)[21:26:44] <DarkUranium> now that I think of it, there's actually 2 projects that I'd need help on[21:26:47] <DarkUranium> another one is a game-making program[21:26:54] <tmccrary> it requires such a large team of artists and scripter/programmers[21:26:55] <DarkUranium> it uses (or rather: will use) OGL for graphics[21:27:03] <tmccrary> Don't use OpenGL for your graphics[21:27:08] <DarkUranium> why not[21:27:24] <tmccrary> Because you should abstract your rendering code, its easy to do and so much fun[21:27:27] *** LordMetroid has joined ##OpenGL[21:27:49] <tmccrary> What language/platform are you developing on?[21:27:50] <DarkUranium> well, the rendering won't be done with direct OpenGL functions[21:27:53] <DarkUranium> I'm gonna make a wrapper[21:28:00] <DarkUranium> Win/Linux and later Mac[21:28:11] <DarkUranium> can't find any Mac users to help code and beta test yet[21:28:23] *** Jorachim has quit IRC[21:28:33] <DarkUranium> the games are gonna be ran on a virtual machine[21:28:40] *** Suprano has joined ##OpenGL[21:28:41] <DarkUranium> not Java (too damn slow for one), a custom one[21:28:43] <Makegho> In my experience it's very hard to find anyone to help in projects. Unless you have money of course.[21:28:49] <DarkUranium> of course.[21:28:57] <DarkUranium> or unless you're Linus :)[21:28:58] <tmccrary> The java virtual machine is the fastest one out there[21:28:59] <Makegho> Most people have their own projects anyway. :)[21:29:01] *** _boto has quit IRC[21:29:06] <DarkUranium> tmccrary: lies[21:29:09] <tmccrary> Have you ever seen benchmarks?[21:29:19] <DarkUranium> Java is slow[21:29:25] <tmccrary> Sun's hotspot stuff just destroys everything else[21:29:38] <tmccrary> The only thing faster is actually precompiled native code and even that loses to hotspot sometimes (rarely)[21:29:58] <DarkUranium> well, my implementation isn't far from native code[21:30:03] <DarkUranium> there are actually very few commands[21:30:03] <tmccrary> What is this "fast" virtual machine you're using?[21:30:07] <DarkUranium> a custom-made one[21:30:10] <tmccrary> LOL[21:30:20] <tmccrary> You should make an MMO while you're at it[21:30:24] <DarkUranium> actually[21:30:25] <DarkUranium> it's done[21:30:26] <Makegho> I'd say that java in itself isn't very slot but it's easy to write slow code with it? I might be wrong, but at least many big java projects are so slow compared to native ones[21:30:27] <tmccrary> It sounds like it would fit the project plan[21:30:31] <Makegho> *slow[21:30:33] <DarkUranium> I'm just waiting for the compiler[21:30:47] <DarkUranium> got a guy who agreed to help with that[21:30:53] <DarkUranium> I just need to give him the specs (working on them)[21:31:19] <DarkUranium> interpreter is just missing one thing right now (apart from functions to run) - runtime dynamic linking[21:31:29] <DarkUranium> I'm going to support dll, so and ddl[21:31:32] <tmccrary> Java has a reputation for being slow because Swing is a pig. Swing is java's window toolkit.[21:31:33] <DarkUranium> probably ddl[21:31:53] <tmccrary> Since most users only interact with the gui, they assume java is slow because Swing (the gui) sucks[21:32:08] <DarkUranium> believe what you will[21:32:15] <DarkUranium> I'm not here to argue about Java[21:32:16] <Makegho> How about the other gui tools of java?[21:32:17] <tmccrary> You can build fast Swing applications, but it is tricky[21:32:18] *** filmor has quit IRC[21:32:29] <DarkUranium> SWT?[21:32:30] <tmccrary> SWT is pretty nice, it uses native widgets so it fits your platform[21:32:40] <tmccrary> Yeah, its the toolkit that Eclipse uses[21:33:00] <Makegho> Why do people use swing then?[21:33:07] <tmccrary> Its built into Java[21:33:07] <DarkUranium> why do people use AOL?[21:33:09] <Makegho> Well ok... I take it back. Why do people use GTK and so on[21:33:13] <tmccrary> Maybe Sun pays them[21:33:19] <tmccrary> I dunno, it has a decent API[21:33:39] *** juanmabc has joined ##opengl[21:33:50] <tmccrary> SWT uses GTK[21:33:54] <Makegho> ouch.[21:34:02] <tmccrary> on a platform that uses GTK[21:34:10] <tmccrary> on Windows it uses GDI/Win32 stuff[21:34:18] <tmccrary> on a mac... it uses carbon for some stupid reason[21:34:45] <tmccrary> They can't create a SWT/QT implementation because of licensing issues[21:35:00] <tmccrary> QT is GPL, SWT is most like BSD[21:35:41] <Makegho> oh my.. :/[21:35:50] <DarkUranium> damn GPL[21:35:51] <DarkUranium> <_<[21:36:05] <DarkUranium> I know of SWT because of D[21:36:09] <DarkUranium> DWT is a D port of SWT[21:37:05] *** |t4bz| has quit IRC[21:37:06] <tmccrary> oh boy, it looks like Trolltech added a clause that will let SWT use QT[21:37:11] <tmccrary> that will be cool[21:37:17] <Makegho> GPL is so "you're with us or you're against us"[21:37:18] <tmccrary> GTK is kind of slow, although its way better than it used to be[21:37:41] <tmccrary> GPL is good for businesses to release code[21:37:45] <DarkUranium> I got Gimp on both Linux and Windows and I must say that it performs fine on both[21:37:58] <DarkUranium> yeah, GPL is good for that, I guess[21:37:59] <tmccrary> It lets everyone access it, but no one can fork the release and use it against them[21:38:09] <DarkUranium> I prefer BSD myself tho[21:39:15] <DarkUranium> aanyways, does anyone want to help with some 2D stuff? :P[21:39:35] <DarkUranium> it'll probably make use of GLSL and/or Cg (in later implementations)[21:39:53] *** karabash has quit IRC[21:40:49] <Makegho> GLSL is something I should study but my current computer (one year old laptop with intel's graphics adapter) doesn't support it too well. It has something like software emulation of shaders.[21:40:58] <DarkUranium> ouch[21:41:03] <DarkUranium> new GPU here[21:41:15] <DarkUranium> well, the first implementations are gonna be CPU-powered (apart from rendering, of course)[21:43:04] *** t4bz has joined ##OpenGL[21:55:49] *** m4ggus has quit IRC[21:57:55] *** Lemml has quit IRC[21:58:46] *** rutski has quit IRC[22:02:29] *** gaffa has joined ##opengl[22:02:53] *** Satan_Inside has quit IRC[22:03:26] *** Satan_Inside has joined ##OpenGL[22:07:26] *** fargiolas|afk is now known as fargiolas[22:09:44] *** Jorachim has joined ##OpenGL[22:11:45] <domino14> i built a mmo[22:11:57] <domino14> it has 10 players a day[22:12:02] <domino14> well, its not really a mmo[22:12:03] <DarkUranium> nice[22:12:07] <domino14> it's a scrabble word study program[22:13:04] <domino14> back in the 90s this guy adapted mud code to a scrabble server[22:13:24] <domino14> so people would log in and go into a house of some sort where there were rooms with people playing scrabble[22:13:25] <domino14> how neat[22:13:43] <DarkUranium> :P[22:14:18] *** mastro has quit IRC[22:14:46] *** _boto has joined ##opengl[22:17:23] *** _boto has quit IRC[22:17:53] *** speedy1 has quit IRC[22:19:07] *** DMINATOR has joined ##OpenGL[22:21:30] *** meteors has joined ##OpenGL[22:27:59] *** Lemml has joined ##OpenGL[22:30:14] *** TheLorax has quit IRC[22:31:27] *** IJs\laptop has joined ##OpenGL[22:32:36] *** dv____ has joined ##OpenGL[22:33:05] *** uchitoru has quit IRC[22:33:21] *** dv____ is now known as dv_[22:36:43] *** Jorachim has quit IRC[22:38:34] *** Lemml has quit IRC[22:38:56] *** Jorachim has joined ##OpenGL[22:42:45] *** magnet__ has quit IRC[22:42:50] <tmccrary> would you classify glRotate/glTranslate/glScale part of the immediate mode functions?[22:43:00] <tmccrary> *as part of the immediate mode functions[22:43:27] <HuntsMan> no[22:43:40] *** fargiolas has quit IRC[22:43:46] <HuntsMan> you can call them outside of glBegin/glEnd[22:44:12] <tmccrary> That's true, but I almost never use them, preferring to update the matrices myself with my own mechanisms[22:44:18] <tmccrary> I kind of see them as "old" I guess[22:44:43] *** IJs\laptop has quit IRC[22:44:49] <tmccrary> And they're slower[22:45:05] *** IJs\laptop has joined ##OpenGL[22:45:10] <tmccrary> although you probably wouldn't take the same kind of performance hit vs stuff like glVertex3f, etc[22:45:43] *** smiler has quit IRC[22:50:24] *** Walt has joined ##opengl[22:57:22] *** noteventime has joined ##OpenGL[23:04:55] *** inoxor has joined ##OpenGL[23:13:07] <prophile> wait[23:13:08] <prophile> what[23:13:37] <prophile> tmccrary: for a straight translate/rotate/scale, glTranslate/glRotate,glScale should have equivalent or even better performance than a glMultMatrix[23:13:51] <prophile> which reminds me[23:14:01] <tmccrary> I don't believe that's the case[23:14:08] <prophile> benchmark it[23:14:15] <prophile> so i was talking to this bloke who claims to be an OpenGL expert the other day[23:14:30] *** Suprano has quit IRC[23:14:33] <prophile> talking about rendering techniques for one very specific case in the FFP[23:14:38] <prophile> he said that display lists would be faster[23:14:46] <prophile> and then gave me his full method[23:14:57] <prophile> I said the opposite, that vertex arrays would have greater performance[23:15:05] <tmccrary> You'd be wrong[23:15:06] <prophile> we wagered a drink on it[23:15:11] <prophile> and i was damn right[23:15:16] <tmccrary> Display lists are like immutable VBO's[23:15:23] <prophile> not with his method[23:15:28] <prophile> it was basically 300 pretty much identical objects[23:15:34] <prophile> he wanted to render one in immediate mode into a display list[23:15:35] *** Suprano has joined ##OpenGL[23:15:43] <prophile> and then apply a transform and call the list for each one[23:15:52] <prophile> i just mashed all the data for ALL of them into one vertex array[23:15:55] <prophile> batch, batch, batch[23:16:02] <prophile> much better performance[23:16:12] <prophile> then I did a VBO implementation which had better performance still[23:16:29] <prophile> so he now owes me a drink[23:16:48] <prophile> and I have a long memory, NeoThermic[23:16:55] <prophile> don't think you can get away with it![23:17:02] *** Walt_ has joined ##opengl[23:17:20] <prophile> actually, that's a total lie, i don't remember where I am half the time[23:19:07] *** Bollinger has quit IRC[23:23:26] <Makegho> how much faster, as a rule of thumb, are vbo's compared to plain glbegin-glvertexblahblahblah-glend?[23:23:45] <tmccrary> a library of congress[23:24:17] <tmccrary> no, seriously VBO's are much, much, much faster than immediate mode[23:24:20] *** DarkUranium has left ##OpenGL[23:24:33] <tmccrary> You're talking one command (VBO) vs thousands at render[23:24:44] <tmccrary> You use most CPU resources, due to all the function calls[23:24:51] <domino14> glGetError is returning 0x505[23:24:53] <domino14> what does this mean?[23:25:01] <Makegho> yup, but is the speedup more like hundreds, dozens or single percents?[23:25:02] <tmccrary> You use more bandwidth sending the vertex data over and over again[23:25:10] <Makegho> yep[23:25:14] <tmccrary> it depends on the scene really[23:25:17] <Makegho> of course[23:25:20] <tmccrary> and what you're doing[23:26:16] <domino14> why would i get a GL_OUT_OF_MEMORY error??[23:26:21] <domino14> boy gluNurbsSurface sucks butt[23:26:38] <domino14> it's generating like a million polygons for this surface[23:26:45] <domino14> how do i limit it[23:28:11] <tmccrary> well at least you found your performance problem ;)[23:28:15] *** tmccrary has quit IRC[23:29:36] <domino14> yep yep[23:29:46] *** Walt has quit IRC[23:32:26] <domino14> i love this new weezer song[23:32:29] *** domino14 has quit IRC[23:42:18] *** LtJax has joined ##OpenGL[23:43:49] *** Suprano has quit IRC[23:49:31] *** DMINATOR has quit IRC[23:58:43] *** LordMetroid has quit IRC[23:58:54] *** LordMetroid has joined ##OpenGL[23:59:42] *** Jorachim has quit IRC