January 31, 2009 
< | 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 | >
January 31, 2009 [00:00:50] <shyam_k> i just wanted to know whether there has been a release of the 100% free software 3d graphics as seen here http://www.fsf.org/blogs/licensing or they are still on git..[00:01:16] <shyam_k> and whether those clear packages have been entered to ubuntu etc..[00:03:41] <shyam_k> still not making sense?[00:04:07] <shyam_k> hmm i am not complete clear either!;-)[00:13:15] *** FunkyJive has joined ##OpenGL[00:14:42] <FunkyJive> can anybody tell me how to make pointsprites get smaller as they get further away[00:16:41] <MatthiasM> point size attenuation[00:16:47] <MatthiasM> or use a vertex shader[00:17:10] <FunkyJive> ruight now im just using glPointSize(avgparticlesize);[00:17:23] <FunkyJive> so they saty the same size no matter how far away they are[00:18:34] *** dejai_ has quit IRC[00:19:26] *** a-stray-cat has joined ##OpenGL[00:20:29] *** amz has joined ##opengl[00:24:21] *** kbotnen has quit IRC[00:24:54] *** __doc__ has quit IRC[00:25:23] *** GuShH has joined ##OpenGL[00:38:15] *** gusnan has quit IRC[00:38:37] *** Bollinger has quit IRC[00:40:09] *** a-stray-cat has quit IRC[00:45:40] *** androoid has quit IRC[00:48:17] *** djork has joined ##opengl[00:49:52] *** scai has left ##opengl[00:50:45] *** rabbit- has joined ##OpenGL[00:51:10] *** djork has quit IRC[00:53:58] *** itewsh has quit IRC[00:57:23] *** alyawn has joined ##OpenGL[01:01:12] *** proteus has quit IRC[01:01:47] *** HuntsMan has joined ##opengl[01:01:52] *** zacs7 has joined ##opengl[01:04:50] *** rutski_ has joined ##OpenGL[01:05:38] *** maxton has quit IRC[01:17:21] *** GuShH has quit IRC[01:22:30] *** jli has joined ##OpenGL[01:23:21] *** HuntsMan has quit IRC[01:23:33] <jli> hmm, quite confusing. I'm using GL_LINE_LOOP to draw lines connecting points that get subdivided and progressively approximate a circle[01:24:30] <jli> when the number of points is < ~3072, everything seems fine. but after that, I start to see lines being drawn through the circle, from one side to another, instead of just on the edge[01:25:07] *** loonysalmon has joined ##OpenGL[01:25:10] *** loonysalmon has left ##OpenGL[01:25:11] <jli> when I use GL_LINE_STRIP and specify the first point at the end, everything is fine[01:28:39] <jli> also, the lines across the circle are not random. see: http://circularly.org/tmp/1.png[01:28:51] <jli> and then http://circularly.org/tmp/3.png and http://circularly.org/tmp/5.png[01:29:16] <jli> any ideas why this would happen?[01:43:21] <FunkyJive> can i see the rendering code[01:44:18] *** FunkyJive has left ##OpenGL[01:45:21] *** pietia has quit IRC[01:47:59] *** qeed has quit IRC[01:49:36] *** zacs7 has quit IRC[02:06:07] *** rabbit- has quit IRC[02:11:52] *** L-Spiro has joined ##OpenGL[02:12:52] <L-Spiro> #1: A good book for beginning OpenGL? #2: A good book showing how to make a game work with both OpenGL and DirectX?[02:16:23] *** Suprano has quit IRC[02:22:54] *** elite01 has joined ##opengl[02:26:27] *** v has quit IRC[02:31:24] *** Spkka has quit IRC[02:32:10] *** knightblade_ has joined ##opengl[02:33:58] *** knightblade_ has quit IRC[02:38:33] *** GuShH has joined ##OpenGL[02:40:22] *** rutski_ is now known as rutski[02:46:48] *** jfroy|work has quit IRC[02:47:54] *** cplusplus has quit IRC[03:03:41] *** LtJax has quit IRC[03:14:30] *** HuntsMan has joined ##opengl[03:23:40] *** elite01 has quit IRC[03:28:31] *** jfroy has joined ##OpenGL[03:37:10] *** MatthiasM has quit IRC[03:37:17] *** MatthiasM has joined ##opengl[03:40:23] *** e_roder has joined ##OpenGL[03:40:26] <e_roder> hey[03:40:49] <e_roder> when i click on a 3d scene, how can i figure out where on a plane i clicked?[03:41:00] *** Sos has quit IRC[03:43:24] <L-Spiro> I am pretty sure that has nothing to do with OpenGL.[03:43:36] <e_roder> nah[03:43:44] <e_roder> it's more of a general graphics problem[03:43:49] <e_roder> but i wasnt sure if anyone here knew[03:44:41] <L-Spiro> It is not really related to graohics at all.[03:45:00] <e_roder> well do you want to help me?[03:45:13] <L-Spiro> It depends.[03:45:28] <L-Spiro> Explaining the whole thing would take quite a while. How much speed do you need?[03:45:50] <e_roder> as fast as possible[03:45:55] <e_roder> i want to learn the most professional way[03:46:05] <e_roder> i know it's possible mathematically[03:46:13] <L-Spiro> For what purpose? A game engine?[03:46:16] <e_roder> yeah[03:46:21] <L-Spiro> Of what scale?[03:46:25] <e_roder> small[03:46:36] <e_roder> but the knowledge is more important than just this project[03:47:42] <L-Spiro> Have you implemented your BSP for fast searching?[03:47:52] <e_roder> nope[03:48:02] <e_roder> but the problem is simplified[03:48:04] <L-Spiro> Well I am not going to get into those details.[03:48:12] <e_roder> i don't need to select any object[03:48:15] <L-Spiro> And how do you store your plane?[03:48:18] <L-Spiro> And ray.[03:48:32] <e_roder> camera vector is pitch & yaw[03:48:45] <e_roder> plane is position and normal[03:49:04] *** HuntsMan has quit IRC[03:49:26] <L-Spiro> Erm, the camera really should be a look/right/up set of 3 vectors.[03:49:42] <e_roder> ah[03:50:02] <L-Spiro> With position of course.[03:50:07] <e_roder> well i know up will always be 0,1,0[03:50:15] *** HuntsMan has joined ##opengl[03:50:19] <e_roder> and there's no roll[03:50:29] <e_roder> so things are somewhat simplified[03:50:39] <L-Spiro> That just makes it even easier to store it in look/right/up format.[03:50:56] <L-Spiro> Which then makes all of this easier.[03:51:04] <e_roder> ok, but, it's possible to calculate those vectors[03:51:10] <e_roder> so suppose i have them[03:51:10] <L-Spiro> Converting euler to a look direction is a pain.[03:51:41] <L-Spiro> Format of your ray.[03:53:01] <e_roder> hm[03:53:06] <e_roder> well[03:53:12] <e_roder> if i know my initial look is 0,0,-1[03:53:18] <L-Spiro> I assume position + unit vector direction.[03:53:19] <e_roder> then i can rotate by pitch and yaw[03:53:30][03:53:50] <L-Spiro> Use a normal and distance, not position.[03:54:00] <e_roder> a b c d?[03:54:22] <L-Spiro> Huh? A normal XYZ and distance D.[03:54:33] <e_roder> ax + by + cz + d = ?[03:54:46] <e_roder> my linear algebra is a little rusty[03:55:01] <L-Spiro> Distance from center of the world. Length of position vector.[03:55:06] <e_roder> alright[03:55:41] <e_roder> so i've got my plane[03:55:51] <e_roder> abcd and my look vector[03:57:16][03:57:25] <L-Spiro> Why is your look vector 4 components?[03:57:35] <L-Spiro> W is always 1.[03:57:57] <e_roder> where did i say it was 4?[03:58:03] *** vade has joined ##OpenGL[03:58:05] <L-Spiro> Oh.[03:58:31] <e_roder> but, also, isn't W = 0 for vectors and W = 1 for points?[03:58:39] <L-Spiro> Opposite.[03:58:43] <e_roder> ah[03:58:44] <e_roder> ok[03:58:51] <e_roder> sorry, proceed[03:59:01] <L-Spiro> Or maybe my head is on backwards today.[03:59:21] <L-Spiro> Anyway, as you know, we can get the t value of intersection by substituting the parametric equation for X in the plane equation and solving for t.[03:59:53][04:00:04] <e_roder> ok[04:00:24][04:00:43] <e_roder> well, i can actually get a point plane intersection[04:00:56] <e_roder> the problem is going from screen coordinants to 3d coordinants[04:01:05][04:01:13] <L-Spiro> You can already intersect a ray with a plane?[04:01:16] <e_roder> yeah[04:01:24] <L-Spiro> Why didn't you say that?[04:01:33] <e_roder> when i click the center of the screen it works perfectly[04:01:44] <e_roder> the problem is if i click off-center[04:01:46] <e_roder> ah, sorry[04:02:23] <e_roder> the further i get from the center, the less accurate it becomes[04:02:38] <e_roder> because i'm using a projection transform (i believe?)[04:02:46] <L-Spiro> http://www.talisman.org/opengl-1.1/Reference/gluPickMatrix.html[04:03:20] <e_roder> right[04:03:23] <e_roder> i've seen that method[04:03:27] <e_roder> but it's not mathematical[04:03:49] <e_roder> if the polygons position is mathematically determined on the screen[04:03:54] <e_roder> i should be able to go backwards[04:04:13] <L-Spiro> http://www.thehazymind.com/directx/picking-objects-from-3d-space/[04:04:20] <e_roder> especially since the problem is simplified: i only want to hit a single plane[04:04:56] <L-Spiro> You will get nothing from that method. You want the mathematical approach.[04:05:12] <e_roder> from what method?[04:05:18] <L-Spiro> Going backwards.[04:05:38] <L-Spiro> Cast a ray from the center of the screen through the W/H of the screenas projected onto the near plane of your viewport.[04:05:39] <e_roder> i just mean that there is a mathematical way to do it[04:06:36] <L-Spiro> The last I posted is mathematical.[04:06:40] <e_roder> yeah[04:06:42] <L-Spiro> And shows the code for all you need to do.[04:06:45] <e_roder> ah[04:06:47] <e_roder> o the site[04:06:50] <e_roder> but it's really messy[04:07:03] <L-Spiro> Yes. That makes you work for the answer.[04:07:06] <e_roder> i'll try to check it out[04:07:19] <e_roder> what do you mean about casting a ray though?[04:07:31] <e_roder> how can i project the screen onto the near plane?[04:07:34] <L-Spiro> Create a ray centered on the camera pointing out in some direction.[04:07:43] <L-Spiro> Follow the code on the site.[04:07:46] <e_roder> ok[04:07:48] <e_roder> thanks[04:07:48] *** rabbit- has joined ##OpenGL[04:08:38] *** djork has joined ##opengl[04:08:40] <L-Spiro> By the way my head was on backwards since I just crawled out of bed. Points = 1, directions = 0.[04:08:50] <e_roder> ok[04:10:29] *** djork has quit IRC[04:10:50] <e_roder> myCamera.View is the view matrix?[04:11:01] <e_roder> defined by the camera's position?[04:11:17] *** slyf has joined ##OpenGL[04:11:19] <slyf> Hey, does anybody in here know what the kind of shadeing is called when you have two frames, and it shades them to make a smoother transition between the two[04:11:25] <L-Spiro> Hopefully not just the position.[04:11:34] <e_roder> position/rotation[04:11:38] <e_roder> or look[04:11:39] <L-Spiro> And scale.[04:11:54] <e_roder> scale is usually, 1, right?[04:11:57] <L-Spiro> Yes.[04:11:59] <e_roder> ok[04:12:12] <L-Spiro> But if you want the professional approach you should handle it anyway.[04:12:29] <e_roder> that's like for zoom (say a scope)?[04:12:47] <L-Spiro> No.[04:12:53] <L-Spiro> That is handled at projection time.[04:12:56] <slyf> anybody? I want to google around for an algoritm for it..but I forget what it is callled[04:13:31] <e_roder> hm, then what is it for?[04:14:13] <L-Spiro> Make the camera bigger or smaller.[04:14:25] <L-Spiro> In other words, scale the whole scene up or down.[04:14:43] <e_roder> literally, the size of what's being drawn?[04:14:53] <e_roder> so u could do like a split screen or something?[04:14:55] <L-Spiro> The sizes of the 3D objects.[04:15:17] <L-Spiro> No, that would be a change to the viewport.[04:15:24] <L-Spiro> Anyway forget the scaling. Even I have never used it.[04:15:28] <e_roder> ok[04:15:30] <e_roder> well thanks for the helpo[04:15:39] <L-Spiro> Nod.[04:27:13] *** m4ggus has joined ##opengl[04:33:05] *** m4ggus has quit IRC[04:47:36] *** caustic has joined ##OpenGL[04:47:49] <caustic> hi! :)[04:48:58] <caustic> i have a lot of short lines and i need to find out the smallest distance from a point to a line[04:49:12] <caustic> what algorithm should i look for?[04:49:29] <caustic> im using a very naive approach right now and its slow as hell :)[04:49:33] <e_roder> hey L-Spiro, what's the difference between the world, view, and perspective?[04:50:30] <e_roder> i mean...[04:50:36] <e_roder> i use model, view, projection, what is world?[05:08:41] <jli> world is the model, no?[05:08:51] <e_roder> that's what i thought[05:08:51] <e_roder> ok[05:09:03] *** e_roder has quit IRC[05:16:49] *** marque has quit IRC[05:37:47] *** GrigorTheOx has joined ##OpenGL[05:40:54] *** Sudi has quit IRC[05:44:34] <GrigorTheOx> I don't suppose this is the place to help me find out why every OpenGL app freezes my pc is it?[05:52:10] <sparky> no[05:53:46] *** eXtronuS has quit IRC[05:54:25] *** GrigorTheOx has left ##OpenGL[06:00:25] *** amz has quit IRC[06:01:36] *** amz has joined ##opengl[06:03:12] *** jli has left ##OpenGL[06:10:51] *** rnx has joined ##opengl[06:14:11] *** amz has quit IRC[06:34:58] *** djork has joined ##opengl[06:38:01] *** djork has quit IRC[07:03:35] *** shyam_k has quit IRC[07:20:02] *** L-Spiro has quit IRC[07:35:58] *** PainBank_Detroit has joined ##opengl[07:36:16] *** PainBank_Detroit has left ##opengl[08:00:15] *** mattn2|home has joined ##OpenGL[08:03:08] *** slyf has quit IRC[08:29:20] *** rutski__ has joined ##OpenGL[08:31:28] *** newb12345 has joined ##OpenGL[08:31:42] <newb12345> anyone have a good 3d model of a human? (not an anamatocailly correct one), more like a ragdoll model[08:52:54] *** __THEGOD_ has joined ##OpenGL[08:53:00] <__THEGOD_> PFNGLCREATEPROGRAMOBJECTARBPROC ?[08:53:10] <__THEGOD_> anyone knows wy this is undefined ?[08:53:35] <__THEGOD_> do anyoe knows where can i find this ?[08:53:46] <__THEGOD_> or can i find it ?[08:53:50] <__THEGOD_> do i need it ?[08:58:07] <__THEGOD_> ok.[08:58:12] <__THEGOD_> bye[08:58:16] <__THEGOD_> i found it[08:58:24] <__THEGOD_> ....[08:58:26] *** __THEGOD_ has left ##OpenGL[09:37:42] *** newb12345 has left ##OpenGL[09:39:25] *** itewsh has joined ##OpenGL[09:53:40] *** rutski has quit IRC[09:57:13] *** Bollinger has joined ##OpenGL[10:03:07] *** Eforen has joined ##opengl[10:06:38] *** scai has joined ##opengl[10:15:10] *** rnx has quit IRC[10:16:46] *** pragma_ has joined ##opengl[10:18:28] *** Ingenu has joined ##OpenGL[10:24:14] *** kbotnen has joined ##OpenGL[10:25:11] *** vade has quit IRC[10:31:20] *** Suprano has joined ##OpenGL[10:32:00] *** vade has joined ##OpenGL[10:36:37] *** scai_ has joined ##opengl[10:39:44] *** fargiolas has quit IRC[10:45:32] *** sparky_ has joined ##OpenGL[10:46:23] *** sparky has quit IRC[10:46:46] *** fargiolas has joined ##OpenGL[10:56:54] *** ol1veira1_ has joined ##OpenGL[10:58:34] *** JackBauer24 has joined ##OpenGL[10:59:01] <JackBauer24> Hola[11:00:28] *** JackBauer24 has quit IRC[11:05:06] *** Yustme has joined ##OpenGL[11:09:48] *** sparky has joined ##OpenGL[11:11:25] *** ol1veira__ has quit IRC[11:22:01] *** sparky_ has quit IRC[11:32:36] *** dizekat has joined ##OpenGL[11:50:37] *** _Rangar_ has joined ##OpenGL[12:01:14] *** itewsh has quit IRC[12:02:01] *** itewsh has joined ##OpenGL[12:06:50] *** pwned has quit IRC[12:07:33] *** Ademan has joined ##OpenGL[12:08:25] *** Rangar has quit IRC[12:13:18] *** sohail has quit IRC[12:13:39] *** pwned has joined ##opengl[12:15:19] *** m4ggus has joined ##opengl[12:18:57] *** jcazevedo has joined ##OpenGL[12:19:38] *** _Rangar_ is now known as Rangar[12:28:54] *** Sos has joined ##opengl[12:36:23] *** elite01 has joined ##opengl[12:36:51] *** McLovin` has joined ##opengl[12:41:26] *** Sudi has joined ##OpenGL[12:44:53] *** itewsh has quit IRC[12:47:33] *** Kasu has joined ##OpenGL[12:54:22] *** zwiep` has quit IRC[13:04:27] *** rnx has joined ##opengl[13:05:30] *** pwned has quit IRC[13:05:37] *** pwned_ has joined ##opengl[13:07:47] *** pietia has joined ##OpenGL[13:08:41] *** scai has left ##opengl[13:11:01] *** pwned_ has quit IRC[13:14:52] *** pwned has joined ##opengl[13:16:32] *** Kasu has quit IRC[13:22:07] *** pwned has quit IRC[13:22:14] *** pwned_ has joined ##opengl[13:26:19] *** LtJax has joined ##opengl[13:27:12] *** pwned has joined ##opengl[13:29:19] *** Sudi has quit IRC[13:32:25] *** NightVisio has joined ##OpenGL[13:35:01] *** GuShH has quit IRC[13:36:39] *** GuShH has joined ##OpenGL[13:43:53] *** pwned_ has quit IRC[13:48:36] *** b0000 has joined ##opengl[13:56:54] *** itewsh has joined ##OpenGL[13:57:03] *** rabbit- has quit IRC[14:04:37] *** NightVisio has quit IRC[14:11:04] *** Kasu has joined ##OpenGL[14:15:56] *** Eforen is now known as Eforen-Sleeping[14:32:09] *** dolphin has joined ##OpenGL[14:42:07] *** gusnan has joined ##OpenGL[14:45:02] *** djork has joined ##opengl[14:45:43] *** djork has left ##opengl[14:49:38] *** elite01 has quit IRC[14:51:52] *** elite01 has joined ##opengl[14:52:32] *** jcazevedo has quit IRC[14:54:23] *** qeed has joined ##opengl[15:03:01] *** Xmas| has joined ##OpenGL[15:45:26] *** itewsh has quit IRC[15:46:39] *** alyawn has left ##OpenGL[16:03:32] *** Dawgmatix has joined ##OpenGL[16:06:33] *** ToreTank has joined ##OpenGL[16:07:32] *** eu-prleu-peupeu has joined ##OpenGL[16:07:41] <eu-prleu-peupeu> hello[16:07:56] <hackkitten> hi[16:08:10] <eu-prleu-peupeu> the displaylist has been deprecated in ogl3 ?[16:09:10] <Ingenu> dunno[16:09:12] <LtJax> yes.[16:09:13] <Ingenu> nothing removed yet[16:09:14] <MatthiasM> yep[16:10:14] <eu-prleu-peupeu> hmm[16:10:30] <eu-prleu-peupeu> then how do i code opengl without it ?[16:11:27] <BombStrike> just google ... no wait, you can't, google is broken :D[16:11:31] <eu-prleu-peupeu> the workflow of trying to displaylist as much as possible doesn't quite fit into it since it is deprecated now[16:11:32] <eu-prleu-peupeu> ahah[16:11:33] <eu-prleu-peupeu> yes[16:11:41] <eu-prleu-peupeu> google is just pissing me off about malware or whatever[16:11:56] <LtJax> you use VBOs[16:12:21] <eu-prleu-peupeu> yes, but vbos aren't displaylists[16:12:29] <Ingenu> no really ?[16:12:34] <Ingenu> :p[16:12:59] <Ingenu> drivers guys didn't like when you were putting anything but vertex related data in DL anyway[16:13:28] <eu-prleu-peupeu> oh well[16:13:30] <kbotnen> If I have a position in space (I have a light there), I do a transform (thus moving the light), how can I get the new coordinates for the lights? Is there a way to multiply my old lightPosition[] with the new matrix / or transformation to get the lights new position?[16:13:44] <rnx> whiny driver folks[16:13:58] <Xmas|> it's more that the DL concept in GL is flawed[16:13:59] <MatthiasM> Ingenu: yeah - I but glClear in it and it crashed ATI drivers :DD[16:14:01] <eu-prleu-peupeu> it would be great to be able to spark just the parts i would want to be compiled[16:14:43] <Dawgmatix> google is broken ?[16:15:08] <Ingenu> yeah google is borked[16:15:15] <eu-prleu-peupeu> yeh[16:15:18] <Ingenu> it was a short while ago anyway[16:15:28] <MatthiasM> http://www.google.de/search?q=google&btnG=Google-Suche&meta= :)[16:15:35] <BombStrike> http://www.google.com/search?q=microsoft < just look :D[16:15:51] <MatthiasM> BombStrike: well - I see no error on that :)[16:15:58] <BombStrike> :D[16:16:10] <ToreTank> works again now, apparently[16:16:17] <Ingenu> not here yet[16:16:20] <ToreTank> didn't 2 minutes ago[16:16:21] <ToreTank> oh, ok[16:16:32] <MatthiasM> ToreTank: "this website can damage your computer" :DD[16:16:40] <BombStrike> it's about 1 / 4 still broken[16:16:43] <Dawgmatix> :D[16:16:48] <Dawgmatix> its true[16:16:51] <BombStrike> they're probably flushing the cache[16:17:08] <MatthiasM> looks like only a part of their servers are affects[16:17:14] <ToreTank> MatthiasM: yeah, I got that too, but not anymore[16:17:27] <MatthiasM> when you refresh offten enough it comes back :)[16:17:31] <ToreTank> oh :)[16:17:34] <ToreTank> heh[16:18:18] *** pa has joined ##OpenGL[16:22:57] *** slyf has joined ##OpenGL[16:25:30] *** Sos has quit IRC[16:29:00] <pa> if i want to use two different textures in my fragmentShader, can i also define two different texture mappings for the two textures?[16:31:07] <Xmas|> of course[16:32:24] <pa> how to specify the second?[16:32:44] <pa> i mean the default i get using glTexCoord[16:33:54] <RTFM_FTW> gl_TexCoord[unit].[stpq][16:34:18] <RTFM_FTW> or anything else you want to cram into a vec[2,3,4][16:34:22] <pa> no i mean[16:34:30] <RTFM_FTW> depending upon what texture fetch is being used :P[16:34:34] <pa> how do i specify it from my opengl code[16:34:44] <RTFM_FTW> GL_TEXTURE[unit][16:34:47] <pa> ah[16:34:58] <RTFM_FTW> glActiveTexture glBindTexture etc.[16:35:21] <pa> so basically for each vertex i have to specify the various texture mappings, right?[16:35:56] <pa> changing through the texture units[16:35:59] <pa> i try[16:36:00] <pa> thanks[16:38:54] <RTFM_FTW> "it would be great to be able to spark just the parts i would want to be compiled" ...umm how the hell would the vendors accomplish this?[16:39:13] <RTFM_FTW> heh DL compilation and execution is very much an all or nothing affair[16:39:32] *** joakim12 has quit IRC[16:40:01] <RTFM_FTW> furthermore the big problem with the DL concept is the fact that you can effectively shove anything into them (i.e. vertices, texture binds, texture uploads (!!!), state setting calls etc.)[16:40:54] <MrSunshine_> thats what makes them powerful ? :)[16:41:09] <MrSunshine_> then you can generate it from a config file if you want then you just render it .. no problem :)[16:41:16] <RTFM_FTW> and this makes the optimization step much more difficult than it would be if DLs were limited to either (a) state setting calls (i.e. making a DL just like a gigantic state setting block) *or* vertex / texture / normal / color coordinate data[16:41:33] <RTFM_FTW> which for the latter step can trivially be optimized into a static VBO on the server side[16:42:13] *** rnx has left ##opengl[16:42:19] *** pietia has quit IRC[16:42:21] <RTFM_FTW> MrSunshine_ no they would be powerful if the IHVs could predictably optimize for that case :P[16:42:38] <RTFM_FTW> being that no one really does I wouldn't say they are powerful at all :P[16:43:05] <RTFM_FTW> for nasty data like that you aren't getting anything better than plain immediate mode code[16:44:09] <RTFM_FTW> in fact the DL approach is worse since the server has to go through an additional optimization step (which quite possibly it will bail from due to inelegant data from the client)[16:44:14] *** pietia has joined ##OpenGL[16:44:26] *** pwned has quit IRC[16:44:33] *** pwned_ has joined ##opengl[16:54:14] * ToreTank is glad he doesn't have to write such drivers[16:56:00] <Ingenu> DL similar to DX11 command buffers ?[16:56:17] <RTFM_FTW> no they aren't :P[16:56:24] <RTFM_FTW> although they should be :P[16:56:34] *** eu-prleu-peupeu has left ##OpenGL[16:56:37] <Ingenu> ;)[16:56:50] <Ingenu> I knew that question would please you[16:56:58] <RTFM_FTW> quite honestly much of the GL API should mirror what exists in D3D[16:57:09] <Ingenu> indeed[16:57:23] <Ingenu> simple is beautiful, but so hard to achieve[16:57:23] <RTFM_FTW> Microsoft (not matter how much shit people give them) got a number of things right there[16:57:32] <Ingenu> after 9 tries ;)[16:57:33] <RTFM_FTW> err no matter[16:57:44] <Ingenu> (yeah yeah I know of the missing versions :p)[16:58:09] <Ingenu> but I said it and will again D3D10 is the first really good D3D API[16:58:47] <RTFM_FTW> widespread deprecation of { FF, IM, various state settings, ... } is a good thing[16:59:39] *** wey has joined ##opengl[16:59:48] <Ingenu> agreed[16:59:56] *** wey has quit IRC[16:59:57] <Ingenu> DX11 is a nice improvement[17:00:30] <RTFM_FTW> yep lots of stuff to like in that API[17:05:13] *** Kasu has quit IRC[17:06:30] <pa> so togheter with glActiveTexture should i also use glMultiTexCoord instead of glTexCoord?[17:07:30] <Ingenu> yes[17:07:42] <RTFM_FTW> for the IM GL cases yep[17:08:37] <RTFM_FTW> for the VA cases you have glClientActiveTexture and friends[17:09:43] *** predaeus has joined ##opengl[17:09:58] *** scai has joined ##opengl[17:13:47] *** pietia has quit IRC[17:14:16] <pa> what's IM GL?[17:14:40] <HuntsMan> immediate mode opengl[17:14:43] <HuntsMan> glBegin/glEnd[17:14:51] <pa> ah! ok: )[17:15:00] <RTFM_FTW> VA is vertex array[17:15:53] <pa> so if i use fragment shaders, i lose the ability of using the fixed pipeline multitexturing, but i can still specify texture mapping with glMultiTexCoord and use in the shader with gl_MultiTexCoord0,gl_MultiTexCoord1 and so on?[17:16:14] <RTFM_FTW> of course[17:16:26] <pa> thanks![17:16:37] <RTFM_FTW> fixed function multitexture doesn't get you much[17:17:56] <RTFM_FTW> vertex: ... gl_TexCoord[unit] = gl_MultiTexCoord[unit]; ... and fragment: ... = texture2D( ..., gl_TexCoord[unit].st ) ...[17:18:10] <RTFM_FTW> following the above format would be wise[17:20:57] <pa> yep i will do that thanks : )[17:21:02] <pa> one more question:[17:22:08] <pa> can i do in one display call something like the following: enter a for loop, and inside draw something, glFinish(), glReadPixel()[17:22:41] <RTFM_FTW> you read the FB via ReadPixels[17:22:48] <pa> yes[17:22:52] <RTFM_FTW> or via GetTexImage (for the texture side)[17:23:06] <RTFM_FTW> can you call either of these in a loop? ...of course you can[17:23:13] <RTFM_FTW> should you? ...probably not :P[17:23:29] <pa> maybe i left a glClear after the readpixel or before the drawing something[17:23:34] <RTFM_FTW> furthermore the use of glFinish before querying the FB data isn't needed[17:24:01] <RTFM_FTW> a FB read-back will implicitly synchronize the pipe before it grabs the data[17:24:15] *** pwned has joined ##opengl[17:24:19] <pa> i see[17:24:49] <pa> but in principle, if i want for example just to read each frame of an animation to memory (and then for example store to a file or so)[17:24:52] <RTFM_FTW> if you need to read-back dynamic content (you are constructing a video for example) then you would be *much* better off using PBO accelerated ReadPixels for this[17:25:01] <RTFM_FTW> not using the naive ReadPixels shown above[17:25:12] <pa> can i , into a single display call, render each frame, read it, clear the screen?[17:25:18] <RTFM_FTW> for that you can read the GL_ARB_pixel_buffer_object specification[17:25:29] <pa> i see[17:25:32] <pa> thanks![17:25:49] <RTFM_FTW> of course you can... the only question is whether or not you should :P[17:26:00] <pa> i will i think.. do you think anyways this first naive implementation should work (slowly)?[17:26:08] <RTFM_FTW> why do you need the data on the CPU side?[17:26:23] <RTFM_FTW> it will work very slowly[17:26:27] <pa> in my specific case to process it.. but migth be to save to a file[17:26:38] <pa> yes, it's very slow[17:26:38] <RTFM_FTW> performance will "suck ass" for lack of a better term[17:26:43] <pa> i noticed that readpixel sucks[17:27:12] <RTFM_FTW> if you require decent read-back performance you will have to go with an asynchronous approach[17:27:23] <pa> at some point i will have to go realtime, so i have to find something faster[17:27:23] <RTFM_FTW> PBO accelerated ReadPixels would be such an approach[17:28:11] <pa> thanks a lot anyways![17:28:13] <RTFM_FTW> once you do that you can look into proper buffering (and using multiple calls to DMA the content) to further optimize[17:28:19] *** L-Spiro has joined ##OpenGL[17:28:23] *** AndyCR has joined ##OpenGL[17:28:31] *** AndyCR has left ##OpenGL[17:32:53] *** sysRPL has joined ##OpenGL[17:32:56] <sysRPL> hello[17:33:19] <L-Spiro> What is the best book for showing how to work in DirectX and OpenGL together?[17:33:21] <sysRPL> hiere is something interesting about how microsoft drawing apis suck balls[17:33:39] <sysRPL> http://www.codebot.org/articles/?doc=9546 ... listen to the audio link at the bottom while reading example code above it[17:35:11] *** Lequ has joined ##OpenGL[17:36:10] *** wey has joined ##opengl[17:37:52] <HuntsMan> L-Spiro: why would be a book of both of them?[17:38:37] <L-Spiro> So that my engine can support them both.[17:38:46] <L-Spiro> It is quite common for games to have an option to switch between them.[17:39:03] <HuntsMan> between OpenGL and Direct3D you mean....[17:39:10] <RTFM_FTW> buy two books :P[17:39:11] <L-Spiro> Yes, I mean that.[17:39:18] <HuntsMan> sysRPL: LOL, WTF does D2D1 means....[17:39:30] *** pwned_ has quit IRC[17:39:56] <RTFM_FTW> meh if you want a decent 2D API I'll be the first to recommend using Quartz2D :D[17:40:02] <HuntsMan> L-Spiro: buy two books and abstract the graphics part[17:40:33] <L-Spiro> I will probably end up buying an OpenGL book but I have seen one that had both before (but OpenGL ES).[17:40:51] <L-Spiro> In that case, how about a book for beginning OpenGL?[17:42:44] <RTFM_FTW> I'd recommend the OpenGL Superbible and the OpenGL Programming Guide[17:42:59] <RTFM_FTW> and the two GL related texts to look at[17:42:59] <sysRPL> DirectD2 version1 i guess[17:43:02] <sysRPL> some funny shite[17:43:15] <L-Spiro> I think those are overkill.[17:43:24] <sysRPL> that's why i can't code in C++[17:43:34] <L-Spiro> For just setting it up and making vertex lists?[17:43:36] <sysRPL> or rather, refuse to code in C++[17:44:09] <L-Spiro> Damn it that book is hard to find in English in Tokyo.[17:44:35] <HuntsMan> sysRPL: for good coding practices in C++, look Qt 4.x[17:45:08] <sysRPL> HuntsMan: except i write programs for windows[17:45:29] <L-Spiro> C++ works fine for Windows applications.[17:45:41] <sysRPL> but i know qt recently allowed lgpl'ed their windows version[17:46:00] <sysRPL> L-Spiro: did you listen to that code walk through?[17:46:13] <L-Spiro> Nope.[17:46:26] <sysRPL> go ahead and come back to this discussion[17:46:31] <HuntsMan> sysRPL: so? GPL'ed about 3 years ago in Windows, LGPL'ed n one month for every platform[17:46:36] <sysRPL> be sure to follow along with the ms example[17:47:51] <sysRPL> HuntsMan: i prefer not to have all those macros ... you know like the smart pointer one in the d2d example, or the signal/slot macros needed to use qt[17:48:22] <sysRPL> HuntsMan: a simple reflection/rtti language mechanism to autowire events is something i expect[17:48:40] <HuntsMan> sysRPL: those are about 4 macros you need to use, besides those macros alreadly provide RTTI to QObject subclasses[17:48:56] <HuntsMan> and there's QPointer as smart pointers[17:49:07] <sysRPL> HuntsMan: you know, with a resource editor and designer to setup live instances of objects while writing code[17:49:23] <HuntsMan> sysRPL: Qt Designer / Qt Creator[17:49:26] <HuntsMan> anything more/[17:49:27] <HuntsMan> ?[17:49:41] <sysRPL> yes ... help refernces[17:49:51] <sysRPL> then i'd be set[17:50:34] <sysRPL> like i said ... i am aware wt recently lgpl'ed their library for windows ... i need to revisit it since their new licensing tersm[17:50:41] <sysRPL> wt = qt[17:52:05] <HuntsMan> doc.trolltech.com[17:52:18] <HuntsMan> wait, let'me see if that still works[17:52:29] <HuntsMan> with company renames and nokia buyout[17:52:49] <HuntsMan> http://doc.trolltech.com/4.4/index.html[17:56:30] <Jupp3> sysRPL: Well they didn't just "gpl their library for windows", but rather the whole thing[17:56:34] *** linnuxxy has joined ##OpenGL[17:56:49] <linnuxxy> which company have a better drivers for Linux ATI or nvidia? (open source and proprietary)[17:56:55] <HuntsMan> nvidia[17:57:02] <bobbens> ati for open source[17:57:34] <linnuxxy> so it is ATI for open source and nvidia for proprietary ?[17:57:38] <Jupp3> and I really wonder if that will turn out better for ati in the future[17:57:43] <Jupp3> linnuxxy: yes[17:57:54] <bobbens> wait until the gallium3d / dri2 stuff settles down[17:58:00] <Jupp3> open source nvidia drivers are very... "in development" :P[17:58:01] <bobbens> that shows promise[17:58:15] <Jupp3> lots to reverse engineer, cannot really blame the developers of that project[17:58:29] <bobbens> ati works quite well for r3xx, r4xx and r5xx[17:58:36] <bobbens> as long as you don't need more then opengl 1.4 :)[17:58:41] <Jupp3> well older too[17:58:46] <Jupp3> but that's obviously... older :)[17:58:50] <bobbens> older are junk though :)[17:59:19] <Jupp3> well it's not the fault of the drivers really[17:59:22] <Jupp3> well not all of it[17:59:26] <bobbens> yeah[17:59:29] <bobbens> like my i815 gpu[17:59:35] <bobbens> which is just a gigantic piece of crud :P[17:59:40] <Jupp3> isn't there still some issues with multiscreen using the open source drivers on older ati chipsets?[17:59:54] <bobbens> could be, but i only use r3xx and later[17:59:57] <Jupp3> which seemed to work on the propietary drivers[17:59:58] <bobbens> in fact i only use r3xx :P[18:00:07] <Jupp3> as long as they worked at all, that is :P[18:00:12] <bobbens> i didn't have trouble with multiscreen back in the day[18:00:14] <bobbens> like 3 years ago[18:00:17] <bobbens> with a 9600[18:00:20] <Jupp3> Which is "untill I once booted my system without the second screen connected"[18:00:29] <bobbens> xrandr is much more solid these days[18:01:01] <Jupp3> Well I had some problems setting it up, googled a bit and read some "doesn't work" comments, and gave up, as I really don't need it anyway[18:02:05] <linnuxxy> so is nvidia proprietary open source drivers is too far behind the ATI's one?[18:02:22] <linnuxxy> so is nvidia open source drivers is too far behind the ATI's one?[18:02:23] <linnuxxy> **[18:02:25] <bobbens> if you want opengl at all then open source isn't an option for nvidia[18:02:43] <Jupp3> linnuxxy: What are "propietary open source drivers"? :P[18:03:05] <Jupp3> Well I don't know if there's much differences between chipsets[18:03:07] <linnuxxy> Jupp3: the second line... open source drivers[18:03:12] <Jupp3> But in general they are not too good, I guess[18:03:47] <linnuxxy> what about intel chipsets?[18:04:13] <bobbens> they're decent, but i haven't tried later ones[18:04:27] <bobbens> they have some issues though, and aren't real competitors in terms of power with nvidia/ati[18:04:35] <RTFM_FTW> heh has the nouveau project even rendered their first (texture-mapped) primitive to screen yet[18:04:39] <RTFM_FTW> ?[18:04:49] <Jupp3> linnuxxy: intel chipsets are "all open"[18:04:50] <RTFM_FTW> AFAIK no[18:05:24] <Jupp3> bobbens: I guess they are "lower power" though, as they are really common in lower end / lightweight laptops[18:05:26] <linnuxxy> Jupp3: all open... and support OpenGL?[18:05:41] <Jupp3> linnuxxy: Well untill... 1.3 is it?[18:06:13] <Jupp3> linnuxxy: But in the past, there have been way too many problems for open source drivers[18:06:39] <Jupp3> linnuxxy: It's not even year ago, when my laptop would get totally stuck, whenever I ran my OpenGL program, which would draw LOTS of stuff[18:06:43] <Jupp3> Works now though[18:06:56] <Jupp3> at 5spf[18:07:08] <Jupp3> (to give you some idea of the complexcity)[18:07:34] <linnuxxy> what happen with same programs in ATI open drivers?[18:07:53] <Jupp3> linnuxxy: I guess they work, not sure if I ever tried on linux[18:08:15] <Jupp3> To be honest, haven't used ati on linux much lately[18:08:44] <linnuxxy> so the best way is to use nvidia with proprietary driver[18:08:48] <Jupp3> I have one system with ati card, but no linux on that[18:08:59] <Jupp3> linnuxxy: -best +only (well almost...)[18:09:15] <linnuxxy> :([18:09:20] <BombStrike> i don't like the ATI way... "we don't to do it ourselves... so here you go, some specs we found on an old windows share"[18:09:26] <BombStrike> *dont want[18:09:58] <bobbens> ATI are still working on fglrx[18:10:03] <Jupp3> BombStrike: Well I don't like the nvidia way, "okay, we will do drivers at least for now. See if they work, and hope they will also work in the future."[18:10:06] <bobbens> and they're doing a good job of releasing docs[18:10:22] *** sohail has joined ##OpenGL[18:10:22] <bobbens> imho ATI is doing a good job, it's just going to atake a while to give good results[18:10:41] <BombStrike> Intel is doing it the good way :D[18:10:53] <BombStrike> releasing tons of docs AND writing the drivers[18:11:08] <BombStrike> sometime too much doc...[18:11:08] <Jupp3> BombStrike: Doesn't ATI do the same?[18:11:12] <bobbens> ATI is paying some guys to work on the drivers[18:11:16] <Jupp3> Except for the drivers they write being closed[18:11:19] <bobbens> so is redhat, suse, etc...[18:11:25] <Jupp3> Or that's how it was[18:11:46] <bobbens> they have at least one guy working on the open sauce ones[18:11:55] <BombStrike> hmmm ok[18:12:02] <Jupp3> "at least one guy" doesn't really sound too good :)[18:12:13] <Jupp3> but better than the all too common "zero guys"[18:12:26] <bobbens> well i don't know who pays who[18:12:40] <bobbens> there's like 6-7 guys working on the radeon driver + some more on the radeonhd driver[18:12:50] <bobbens> they're being paid by like 4-5 different groups[18:12:52] <bobbens> it's confusing :)[18:13:41] * BombStrike remember the Intel Xorg driver problem on Ubuntu alpha :D[18:14:16] <bobbens> i am only sure about one, not sure if bridgman does coding, and not sure if there's more[18:14:31] <bobbens> but yeah, ati is doing a good job imho, it's just you can't expect immediate results[18:14:35] <bobbens> i'm in #radeon :)[18:14:44] <Jupp3> linnuxxy: Oh, that old (now fixed) intel crash wasn't only problem with my code, of course, also f.ex. Blender crashed often[18:15:08] <Jupp3> About those immediate results... I wonder how long have they been working?[18:15:12] <Jupp3> Compared to others[18:16:14] <RTFM_FTW> writing a modern OpenGL driver is a unbelievably complex process[18:16:16] <linnuxxy> is Linux out perform Windows in OpenGL with nvidia proprietary drivers?[18:17:17] <Jupp3> linnuxxy: At least if you don't install hardware accelerated drivers on windows :D[18:17:36] *** Xmas| has quit IRC[18:17:50] <RTFM_FTW> hell building a half-way reasonable shader compiler is a multi-year process AFAIC[18:18:10] <RTFM_FTW> the same goes for resource management in the kernel[18:18:42] <RTFM_FTW> and its far, far longer for developers w/o massive experience in these realms[18:19:30] <bobbens> they'lle get there eventually :)[18:19:38] <Jupp3> definitely[18:19:40] <bobbens> i'm hoping i'll have GLSL in a year or two :)[18:19:58] <RTFM_FTW> I'd give them 3 years[18:20:07] <Jupp3> But I mean, as there are older drivers, if the new hardware isn't too different, it should be way easier than "from scratch"[18:20:21] <RTFM_FTW> LOL "isn't too different"[18:20:41] <RTFM_FTW> umm the hardware between R5xx and R6xx changed massivelu[18:20:44] <RTFM_FTW> err massively[18:20:51] <Jupp3> ok[18:21:02] <RTFM_FTW> hell we went from D3D9 and friends right into D3D10[18:21:16] <RTFM_FTW> look at the differences between those two API versions[18:21:32] <RTFM_FTW> and you will get a brief glimpse of what might have been required[18:21:39] <fword> the api differences aren't necessarily a reflection of the underlying hardware, though[18:21:46] <RTFM_FTW> actually they are[18:21:51] <RTFM_FTW> quite a bit in fact[18:21:58] <fword> the object model could remain relavtively the same and the low level driver issues could be abstracted[18:22:16] <RTFM_FTW> the first big step is the fact that R6xx is entirely 3D engine based[18:22:22] <fword> a 3d vector is still a 3d vector no matter what kind of card you have[18:23:18] *** HuntsMan has quit IRC[18:23:41] <RTFM_FTW> a functional shader compiler and VRAM management are initial requirements for this[18:23:42] <Jupp3> Well there can still be differences, with f.ex. endianity, precision etc.[18:23:55] <Jupp3> But of course that isn't very "major"[18:25:45] *** pwned has quit IRC[18:25:49] <fword> i got a PM and had to look through all of the channel windows to get back here. anyway, they need super-abstracted 3d stuffs[18:26:44] <fword> so you can focus on the shapes and manipulating them versus reprogramming for the api or the new object model and then going back in and reinventing the wheel to do the same thing[18:26:46] *** LordMetroid has joined ##OpenGL[18:27:25] <RTFM_FTW> umm yeah we call that OpenGL or Direct3D :P[18:30:39] *** tmccrary1 has joined ##OpenGL[18:32:09] *** wey has quit IRC[18:33:49] *** tmccrary1 has quit IRC[18:41:27] *** fargiolas_ has joined ##OpenGL[18:46:00] *** msh07 has joined ##OpenGL[18:46:29] *** LtJax has quit IRC[18:47:01] *** msh07 has quit IRC[18:48:13] *** tmccrary1 has joined ##OpenGL[18:50:44] *** amz has joined ##opengl[18:52:18] *** sysRPL has quit IRC[18:53:24] *** mlucassmith has quit IRC[18:53:24] *** bagu has quit IRC[18:53:24] *** Adrinael has quit IRC[18:53:24] *** brutopia has quit IRC[18:53:25] *** jsvuorin has quit IRC[18:53:25] *** Tempoe has quit IRC[18:53:25] *** mm765^away has quit IRC[18:53:33] *** XT95_ has joined ##opengl[18:55:04] *** Tempoe has joined ##OpenGL[18:55:10] *** bagu has joined ##opengl[18:55:16] *** Adrinael has joined ##opengl[18:56:53] *** fargiolas has quit IRC[18:57:49] *** pwned has joined ##opengl[19:07:30] *** mm765^away has joined ##OpenGL[19:08:17] *** brutopia has joined ##OpenGL[19:09:21] *** dolphin has quit IRC[19:09:36] *** dolphin has joined ##OpenGL[19:09:39] *** mlucassmith has joined ##OpenGL[19:11:22] *** jsvuorin has joined ##OpenGL[19:13:43] *** fargiolas_ has quit IRC[19:14:13] *** eXtronuS has joined ##OpenGL[19:14:24] *** fargiolas has joined ##OpenGL[19:14:49] *** Gorgoroth has joined ##opengl[19:15:58] *** Amorphous has quit IRC[19:19:08] *** Amorphous has joined ##opengl[19:20:29] *** fargiolas has quit IRC[19:23:40] *** pietia has joined ##OpenGL[19:28:28] *** gusnan has quit IRC[19:30:27] *** dv_ has joined ##opengl[19:31:22] *** Lequ has quit IRC[19:40:35] *** fargiolas has joined ##OpenGL[19:50:07] *** predaeus has quit IRC[19:53:14] *** Dawgmatix has left ##OpenGL[20:06:49] *** Delta_Theta has joined ##opengl[20:07:43] *** Rolenun has quit IRC[20:07:59] <Delta_Theta> Sup all[20:09:21] <Delta_Theta> Such a lively group[20:09:22] <Delta_Theta> :)[20:10:13] *** NightVisio has joined ##OpenGL[20:11:44] *** Delta_Theta has left ##opengl[20:11:57] * NightVisio throw std::string( "NightVisio' come" );[20:16:54] *** eXtronuS has quit IRC[20:17:29] *** pietia has quit IRC[20:19:15] *** Kasu has joined ##OpenGL[20:19:28] *** e_roder has joined ##OpenGL[20:19:35] <e_roder> hey[20:19:51] <e_roder> im having trouble trying to trace a ray from the camera through a pixel on the screen[20:20:59] *** Kasu has quit IRC[20:21:08] *** jfroy has quit IRC[20:21:21] *** jfroy has joined ##OpenGL[20:22:38] *** scai has left ##opengl[20:23:04] *** scai has joined ##opengl[20:23:05] *** Kasu has joined ##OpenGL[20:24:00] <e_roder> can any body point me to a website?[20:24:16] <e_roder> or explain to me how to convert a 2d screen coordinant to a 3d ray?[20:26:21] <MatthiasM> e_roder: the process to convert a 3d coordinate into a 2d one is called projection[20:26:32] <e_roder> but i want to go backwards[20:26:37] <e_roder> inverse projection[20:26:37] <NightVisio> you can't[20:26:42] <NightVisio> you can't convert XY to XYZ[20:26:44] <MatthiasM> e_roder: http://www.opengl.org/sdk/ look for the relevant function in there[20:26:53] <e_roder> it's possible[20:27:02] <NightVisio> erhm[20:27:32] <MatthiasM> NightVisio: 2d to 3d ray works perfectly[20:27:32] <e_roder> someone gave me a website yesterday[20:27:42] <e_roder> it seems like[20:27:47] <NightVisio> MatthiasM, but how is this possible?[20:27:50] <e_roder> calculate x, y, let z = 1[20:27:51] <NightVisio> can't understand[20:27:59] <e_roder> the invert the view matrix and multiply it by that vector[20:28:12] <e_roder> but they multiply world * view, then invert[20:28:22] <MatthiasM> NightVisio: each point on the screen maps to an infinite amount of 3d points all on one ray[20:28:33] <e_roder> i wasn't sure what they were doing there[20:28:49] <e_roder> MatthiasM: can you explain to me how to get that ray a little bit?[20:28:54] <NightVisio> cool[20:29:05] <MatthiasM> e_roder: I gave you the link and the function name to look for[20:29:13] <NightVisio> thanks :-)[20:29:20] <e_roder> alright[20:29:38] <MatthiasM> it's in the glu package[20:29:41] <e_roder> what's the relevant function?[20:29:52] <e_roder> can't i do it manually?[20:29:57] <e_roder> i want to know how the math works[20:30:06] <MatthiasM> there are not many function - look through them - it explains also the math[20:30:30] <MatthiasM> if that is not enough - read the OpenGL spec to understand how a 3d point is transforfm to a 2d point on the screen[20:31:09] <e_roder> also[20:31:10] <MatthiasM> and yes, you can do it manually, as all glu* function are just helpers[20:31:15] <e_roder> i cant find the glu section in the sdk[20:31:30] <MatthiasM> e_roder: reference pages -> glu[20:31:48] <e_roder> found it thanks[20:32:13] <e_roder> im using Cg shaders though[20:32:24] <MatthiasM> doesn't matter[20:33:38] <e_roder> it says modelview matrix[20:33:58] <e_roder> what if there's no model?[20:34:16] <MatthiasM> do you know what the model view matrix is ?[20:34:20] <MatthiasM> if not read about it[20:34:25] <e_roder> i thought i did[20:35:02] <NightVisio> take a look at here:[20:35:03] <NightVisio> http://www.aras-p.info/texts/matrices.html[20:35:10] <e_roder> opengl mashes the model and view transforms into one matrix[20:35:16] <NightVisio> "In the matrix (Xx, Xy, Xz) is the X vector, (Yx, Yy, Yz) is the Y vector, (Zx, Zy, Zz) is the Z vector and (Ox, Oy, Oz) is the origin (position). One common convention is that X means "right side", Y means "up", Z means "forward" and position is, well, position. "[20:37:09] <e_roder> what's the viewport transform for?[20:37:12] <e_roder> split-screen?[20:37:36] <MatthiasM> that's one use-case[20:37:51] <e_roder> ok[20:37:53] <e_roder> and[20:37:56] <e_roder> the equation they give[20:38:02] <e_roder> has some odd symbols[20:38:10] <e_roder> objX objY objZ W = INV ? P ? M ? 2 ? winX - view ? 0 view ? 2 - 1 2 ? winY - view ? 1 view ? 3 - 1 2 ? winZ - 1 1[20:38:23] <e_roder> what are the ? supposed to be?[20:44:50] *** Gorgoroth has quit IRC[20:51:15] *** Ingenu has quit IRC[20:51:21] *** Ingenu has joined ##OpenGL[21:05:49] *** HuntsMan has joined ##opengl[21:07:00] *** fusi has joined ##opengl[21:08:26] *** gusnan has joined ##OpenGL[21:12:35] *** LtJax has joined ##opengl[21:13:01] *** Suprano has quit IRC[21:27:29] *** Jortuny has joined ##OpenGL[21:27:36] <Jortuny> anyone here have experience with pyopengl?[21:28:00] <Jortuny> i'm trying to use quadrics on mac os x and it's giving crazy errors[21:28:32] <RTFM_FTW> document the errors[21:28:51] <Jortuny> well, bus errors[21:30:03] <RTFM_FTW> well then your code is borked :D[21:30:22] <Jortuny> well[21:30:31] <Jortuny> i have it down to a one-line test case[21:30:48] <Jortuny> gluQuadricNormals(gluNewQuadric(), GLU_SMOOTH)[21:30:49] <RTFM_FTW> and that would be?[21:31:18] <Jortuny> (after from OpenGL.GLU import *)[21:31:54] *** Kasu- has joined ##OpenGL[21:32:14] <fusi> glu eh[21:32:51] <Jortuny> i'm pretty sure my usage is correct :/[21:33:41] <bubu`> are the OpenGL context created before your glu calls?[21:33:48] <RTFM_FTW> probably not[21:34:02] <bubu`> exactly my thought[21:34:30] <RTFM_FTW> goto [ well then your code is borked :D ][21:34:33] <RTFM_FTW> heheh[21:34:37] <Jortuny> you might be right :)[21:34:42] <RTFM_FTW> uh huh[21:34:46] <Jortuny> but this code works on my friends linux machine[21:34:52] <RTFM_FTW> doesn't matter[21:34:54] <bubu`> lucky he[21:35:03] <RTFM_FTW> the fact that it works AT ALL is luck[21:35:13] <Jortuny> and i'm pretty sure pyopengl creates the context for me?[21:35:24] <bubu`> I wouldn't be so sure[21:35:37] <bubu`> do you see window opening, when you run program?[21:35:43] <RTFM_FTW> executing GLU, GLUT, GL, ... commands w/o establishing a valid GL context has implementation dependent results[21:36:11] <RTFM_FTW> such that implementation dependent implies { crash, hard lock, machine catches on fire, ... }[21:36:44] <Jortuny> ah, interesting[21:36:48] <Jortuny> hm[21:37:02] <RTFM_FTW> on Mac OS X generally speaking this will directly lead to a crash[21:37:06] <RTFM_FTW> as it should[21:37:29] <RTFM_FTW> in fact it should immediately crash on *any* OS but unfortunately you cannot assume that to be the case[21:38:54] *** Kasu has quit IRC[21:41:20] *** mcc has joined ##OpenGL[21:42:38] <mcc> Hey... so, I've got an odd one. I am trying to do something where I am animating something in OpenGL, and I want each frame to be drawn on top of the previous one-- I don't want the screen to be cleared between frames.[21:42:45] *** vick has joined ##OpenGL[21:42:49] <mcc> At first I tried just not calling glClear, but then I ran into difficulty with double buffering[21:42:50] <vick> What is the homogenous transformation matrix for reflection about an arbitary plane in 3D ?[21:43:03] <mcc> So, I started doing this right after i swapped buffers: glReadBuffer (GL_FRONT); glCopyPixels (0,0, windowWidth, windowHeight, GL_COLOR);[21:43:09] <mcc> This worked fantastic on my macs[21:43:12] <mcc> but then i tried to run it on windows[21:43:18] <mcc> and it went slow as dirt![21:43:30] <mcc> like down to 1 fps-ish[21:43:37] <mcc> Do you know what could be wrong, is there anything unusual about this glCopyPixels operation?[21:44:46] *** _sana has joined ##OpenGL[21:45:08] *** Kasu- has quit IRC[21:47:15] *** Tibor__ has joined ##OpenGL[21:49:11] <HuntsMan> mcc: sure, you're killing performance, and practically emulating double-buffering[21:49:25] <mcc> Okay. Why didn't this cause a problem on the macintosh though?[21:50:05] <mcc> And is there a different way to get the same effect?[21:50:29] *** dolphin has quit IRC[21:50:30] <HuntsMan> why you need to not clear the back buffer?[21:50:43] *** dolphin has joined ##OpenGL[21:51:23] <mcc> for the visual effect... I'm trying to set it up where on each frame, the previous frame is still visible[21:51:33] <mcc> so that things leave behind trails, etc[21:51:50] *** qeed has quit IRC[21:52:01] <RTFM_FTW> render to texture[21:52:07] <HuntsMan> yes[21:52:14] <RTFM_FTW> RTT via FBO or GL_EXT_framebuffer_object[21:52:14] *** linnuxxy has quit IRC[21:52:31] <HuntsMan> RTFM_FTW: aren't those the same? :)[21:52:37] <RTFM_FTW> and CopyPixels isn't a optimal approach anywhere... this includes Mac OS X[21:53:01] <RTFM_FTW> yes they are but I figured I'd immediately clarify what "FBO" stands for before someone asks :P[21:53:12] <HuntsMan> :P[21:55:38] <Jortuny> RTFM_FTW: after much debugging, i found out that it was indeed the context not being created- there was a code path in which the function was called before proper initialization... thanks for insisting on that :)[21:56:06] <Jortuny> very strange that it would work in linux though[21:56:16] *** Shizen has joined ##OpenGL[21:56:29] *** marenz_ has joined ##OpenGL[21:56:42] <RTFM_FTW> no problem[21:56:48] <mcc> rtfm: FBOs don't work on all video cards do they though?[21:57:12] <RTFM_FTW> what GPUs are you looking to support?[21:57:49] <RTFM_FTW> in any case support for FBO goes all the way back to the GeForce FX (NV3x) and Radeon 95xx (R3xx) series[21:58:00] <RTFM_FTW> which is pretty far back[22:03:57] <mcc> I'm trying to support basically back to the stone age... I think we had a discussion about this at some point and I determined none of my dev machines have cards that support it :( Thus making it difficult for me to debug[22:04:01] <mcc> I guess I'll try it anyway[22:04:21] <mcc> It seems like I ought to be able to get this effect by just disabling double buffering and then not clearing between frames[22:04:41] <mcc> But it appears that disabling double buffering is not strictly possible? At least, it didn't seem to be in SDL, when I tried to do it.[22:05:16] <ol1veira1_> moc: there's SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 0 );[22:05:39] <mcc> *nods* I tried that and... hm, there was some sort of trouble with it; Let me try it again.[22:06:43] *** Spkka has joined ##OpenGL[22:11:45] <_sana> do you have experience with openscenegraph ?[22:12:49] *** sparky_ has joined ##OpenGL[22:14:07] *** amz has quit IRC[22:18:23] *** e_roder has quit IRC[22:22:13] *** sparky has quit IRC[22:27:11] *** UUncia has joined ##OpenGL[22:27:44] *** Spkka has quit IRC[22:28:00] *** Spkka has joined ##OpenGL[22:31:05] *** Spkka has joined ##OpenGL[22:38:07] *** LtJax has quit IRC[22:38:27] *** Spell has joined ##OpenGL[22:39:23] <Spell> eh how is the compilervar for opengl named (i mean something like SDLmain for SDL)[22:39:27] <Spell> ?[22:39:28] *** Codex_ has joined ##OpenGL[22:40:21] <mcc> spell, opengl is just a library. do you mean GLUT?[22:40:36] <Spell> no[22:40:53] <mcc> k sorry, i don't understand the question then[22:40:57] <Spell> i meant as parameter for the compiler to link[22:41:29] <MatthiasM> Spell: read the SDL docu[22:41:39] <MatthiasM> it should list how to compile/link[22:42:03] <Spell> >.<[22:42:41] <Spell> i meant something like -logl ...[22:43:20] <Spell> i know how to link sdl... but not how to link ogl ;)[22:43:27] *** brvstr has joined ##opengl[22:44:33] *** brvstr has quit IRC[22:44:35] * Codex_ wrote this: http://www.kotiposti.net/terop/randompolys.png[22:44:36] <mcc> ol1veira: Okay.. I went back and tested again. Here's what I found. Let's say I just don't clear between frames, with my hope being that each frame will stay visible like a slug trail. And let's say I run in an SDL window. Things work the way I expect. Then let's say that I run SDL fullscreen. All of a sudden, there's kind of a flickering-- as if the screen is switching back and forth between two buffers, and things leave slug trails but only[22:44:57] <mcc> Now let's say I turn off the SDL_GL_Attribute for double buffering. Now things look horrifying! I can see things being drawn, and for some reason my framerate drops significantly.[22:45:32] <mcc> what is the difference between SDL windowed and SDL fullscreen mode that is causing there to be only one "buffer", so to speak, if that question makes sense?[22:46:52] <mcc> and can i get that difference in place in fullscreen mode, so that the flickering goes away?[22:50:15] *** UUncia has quit IRC[22:50:57] <HuntsMan> enable double buffering to kill flicker[22:51:01] <HuntsMan> and draw to the back buffer[22:51:22] <forrestv> the color of some of my primitives changes to white sometimes depending on the camera movement. what could cause this?[22:52:02] <Codex_> forrestv: you have lights enabled?[22:52:06] <forrestv> Codex_, ya[22:52:33] *** eXtronuS has joined ##OpenGL[22:52:52] <mcc> oh, huh[22:52:53] <mcc> GL_FRONT_AND_BACK?[22:53:16] <mcc> glDrawBuffer refers to the "left and right" draw buffers. What are these?[22:53:49] <HuntsMan> they're used for stereo rendering[22:54:08] <HuntsMan> mcc: GL_BACK[22:54:20] <mcc> ok[22:57:32] *** Kasu has joined ##OpenGL[22:59:03] *** Eforen-Sleeping is now known as Eforen[23:02:04] <forrestv> Codex_, hehe, just realized that i had moved the light position, forgetting that it was affected by the matrix[23:02:58] <Codex_> forrestv: you got screenshots?[23:03:18] <forrestv> Codex_, of the problem? no, why?[23:03:42] *** eXtronuS_II has joined ##OpenGL[23:03:52] *** deylen has joined ##OpenGL[23:03:54] <Codex_> just interested what kind of stuffs other people are doing.[23:04:06] <forrestv> Codex_, http://im.forre.st/pyo.png[23:04:16] *** Jortuny has quit IRC[23:04:50] *** eXtronuS has quit IRC[23:05:00] <Codex_> pretty nice textures...[23:05:40] <forrestv> Codex_, are you joking? :P[23:06:08] <Codex_> well, I don't have textures at all. :)[23:06:49] <MatthiasM> Codex_: http://www.matthiasmann.de/java/worldscape/ufo.jnlp :)[23:07:32] <Codex_> jnlp?[23:07:44] <MatthiasM> java webstart[23:10:05] *** eXtronuS_II has quit IRC[23:11:08] *** Cultz has joined ##OpenGL[23:11:41] *** opr has joined ##OpenGL[23:11:49] <opr> hello, i have >>glClearColor(1.0f, 1.0f, 1.0f, 0.5f);<< however the background is still black :([23:13:00] *** XT95_ has quit IRC[23:13:27] *** reprore_ has joined ##OpenGL[23:13:43] <opr> hello, i have >>glClearColor(1.0f, 1.0f, 1.0f, 0.5f);<< however the background is still black :([23:13:59] <MatthiasM> opr: http://mikeash.com/getting_answers.html[23:16:36] <opr> i dont understand what you want me to ask[23:16:47] <opr> the background colour has not changed[23:17:01] <opr> even though i have made the RGB 255,255,255, effectively[23:18:53] *** reprore_ has quit IRC[23:19:09] *** reprore has joined ##OpenGL[23:20:27] *** alexfff has joined ##OpenGL[23:21:09] *** itewsh has joined ##OpenGL[23:24:11] <forrestv> opr, you have to glClear it[23:24:25] <opr> ok[23:25:57] *** _sana has left ##OpenGL[23:27:44] <opr> http://pastebin.com/m610ce13[23:27:51] <opr> look at line 17 and 27[23:28:00] *** Spkka has quit IRC[23:29:28] *** reprore has quit IRC[23:29:34] <forrestv> opr, init needs to be called after all the other init stuff[23:29:47] <forrestv> you hadn't even created a context yet i think :P[23:30:10] <opr> um[23:30:19] <opr> i copied off the nehe site[23:30:22] <opr> but it works now[23:30:24] <opr> cheers ;)[23:34:01] *** reprore_ has joined ##OpenGL[23:36:52] *** alexfff has left ##opengl[23:42:14] *** rutski__ has quit IRC[23:48:17] *** reprore_ has quit IRC[23:51:28] *** koalo has joined ##OpenGL[23:52:14] <koalo> hi - i have a problem with text and color[23:54:53] <koalo> http://cpp.ninjacodemonkeys.org/5089[23:55:13] <koalo> the polygon is green, but not the text[23:57:44] <Spell> perhaps because the color is saved within the Display Lists?[23:59:56] <koalo> dont seems so - i can change between black and white but not between colors