January 10, 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 10, 2009 [00:05:16] *** cplusplus has quit IRC[00:10:22] *** amz has joined ##opengl[00:15:10] *** dusted has quit IRC[00:20:43] *** dolphin has quit IRC[00:21:01] <emzic> hello, is it possible to get a value back from a GLSL shader?[00:22:06] *** AlastairLynn has quit IRC[00:22:25] *** qeed has quit IRC[00:22:39] *** AlastairLynn has joined ##opengl[00:24:06] *** cplusplus3 has joined ##OpenGL[00:25:35] *** dizekat has left ##OpenGL[00:27:05] *** scai has left ##opengl[00:28:19] <MatthiasM> emzic: only by rendering to screen (back buffer) or to a texture[00:33:36] *** Luc_le_Pro has left ##OpenGL[00:36:05] *** Walt has quit IRC[00:36:30] *** scai has joined ##opengl[00:37:56] *** yates has joined ##OpenGL[00:39:06] <yates> RTFM_FTM: you should get a copy of the latest IEEE Spectrum magazine. they have an article on Larrabee and compare it to nvidia's CUDA.[00:39:36] <yates> and they say Larrabee will come out on top[00:39:58] <emzic> matthiasm: thanks, so i cant put a uniform float in the shader, modify it there, and then read its value back to the application?[00:40:23] <MatthiasM> emzic: you can't modify a uniform in the shader[00:40:29] <emzic> right[00:40:34] *** Amorphous has quit IRC[00:40:38] <yates> s/RTFM_FTM/RTFM_FTW/[00:40:57] <MatthiasM> but you can compute something using this uniform and write it to the frame buffer[00:41:02] *** cplusplus2 has quit IRC[00:41:22][00:42:02] <MatthiasM> emzic: shaders are not useful to compute general stuff based on uniforms[00:42:16] <emzic> ok[00:42:32] <MatthiasM> use them to work with textures - to compute lots of different values at once (eg a rectangle)[00:42:40] <emzic> what's all this GPGPU computing all about?[00:42:58] <emzic> i thought they do general purpose computing using shaders?[00:43:05] <MatthiasM> emzic: read www.gpgpu.org[00:43:19] <emzic> ok[00:43:48] *** rabbit- has joined ##OpenGL[00:43:52] *** Amorphous has joined ##opengl[00:43:59] <emzic> thanks[00:45:22] *** Orphis has quit IRC[00:46:00] *** Orphis has joined ##opengl[00:47:47] *** yates has left ##opengl[00:52:31] *** Yustme has quit IRC[00:55:05] *** korff_home has quit IRC[00:55:21] *** phrosty has joined ##opengl[00:59:03] *** eXtronuS has quit IRC[00:59:10] *** groton has quit IRC[01:01:47] *** Diagmato has joined ##OpenGL[01:04:21] *** emzic has quit IRC[01:11:21] *** scai has left ##opengl[01:13:00] *** elite01 has quit IRC[01:18:22] *** kbotnen has quit IRC[01:19:47] *** twist_ has quit IRC[01:21:56] *** tmccrary has quit IRC[01:27:56] *** tmccrary has joined ##OpenGL[01:36:21] *** AlastairLynn has quit IRC[01:44:28] *** Ingenu has quit IRC[01:47:09] *** Suprano has quit IRC[01:49:11] *** cplusplus has joined ##OpenGL[01:54:17] *** davidc__ has quit IRC[02:01:47] *** rutski_ has quit IRC[02:04:38] *** cplusplus3 has quit IRC[02:11:44] *** Bollinger has quit IRC[02:12:40] *** groton___ has quit IRC[02:25:32] *** GuShH_ has joined ##OpenGL[02:29:29] *** jfroy|work has quit IRC[02:36:45] *** pietia has quit IRC[02:38:27] *** b0000 has quit IRC[02:38:40] *** b0000 has joined ##opengl[02:42:56] *** GuShH has quit IRC[02:43:34] *** Diagmato has quit IRC[02:50:36] *** mikolalysenko has quit IRC[02:51:56] *** cplusplus2 has joined ##OpenGL[03:05:03] *** mm765 is now known as mm765^sleep[03:08:04] *** cplusplus has quit IRC[03:12:10] *** reprore_ has joined ##OpenGL[03:21:59] *** jfroy has joined ##OpenGL[03:23:34] *** cplusplus2 has quit IRC[03:24:01] *** dv_ has quit IRC[03:26:20] *** amz has quit IRC[03:35:47] *** a-stray-cat has quit IRC[03:36:19] *** MatthiasM has quit IRC[03:36:21] <aep> hm i'm drawing some text with FGTL on something set with glOrtho. the text moves right every repaint[03:36:25] *** MatthiasM has joined ##opengl[03:43:47] *** elektr1k has joined ##opengl[03:47:33] *** LordMetroid has quit IRC[03:50:31] *** GuShH_ is now known as GuShH[03:52:14] *** b0000 has quit IRC[03:54:32] *** Nescafe has quit IRC[03:54:43] *** amz has joined ##opengl[03:54:53] *** reprore_ has quit IRC[03:54:54] <GuShH> aep : make sure you're handling the matrixes correctly. ie. pop what you've pushed, etc.[03:55:06] <GuShH> I suggest reading the redbook.[04:00:27] <rnx> check glGetError[04:01:19] *** mikolalysenko has joined ##OpenGL[04:02:36] <aep> well updating ftgl made the problem disapear :/[04:04:48] *** AndyCR has joined ##OpenGL[04:05:44] <AndyCR> I know this isn't strictly on-topic, and feel free to tell me to ask somewhere else, but I'm programming for a pocketpc using opengl es and am looking for opinions on what image loading library to use that plays well with opengl on mobile devices.[04:06:10] <AndyCR> I'd like to load JPEG's, as well as resize and save them for caching purposes[04:06:18] <AndyCR> And of course bind them to polygons[04:07:27] *** mattn2|home_ has joined ##OpenGL[04:09:58] <aep> actually eah i'm push/popping the matrix only once, and i cant see doing anythong wrong[04:10:04] <aep> must be a bug in the olf ftgl[04:12:09] <boghog> AndyCR, this might suit your needs: http://lonesock.net/soil.html[04:12:30] <boghog> I'ven ever used it though, ran into it a few days ago and bookmarked it for later investigation[04:12:35] <boghog> never*[04:13:14] <AndyCR> boghog: Thank you, I'll look into it[04:13:17] <boghog> hmm, it doesn't save JPG though :/[04:13:31] <AndyCR> B<P would be fine, though I may run out of storage[04:14:04] <AndyCR> I'm writing a music player, however, so the MP3's would be a much bigger issue than bitmaps would be[04:14:46] <AndyCR> I noticed that in the device they credit FreeImage. There must be a library for it somewhere on the device, but I have no idea if the interface would be normal or different[04:18:18] *** paul424 has joined ##OpenGL[04:19:24] <paul424> When I do use the vertex lists does the opengl optimilizes the vertex culling ....... I mean when it is known that the certain list is entirly out of the camera view it does not put it to the pipeline ?[04:23:40] *** tmccrary has quit IRC[04:24:00] *** mattn2|home__ has quit IRC[04:24:04] *** reprore_ has joined ##OpenGL[04:26:06] *** msh07 has quit IRC[04:26:38] *** msh07 has joined ##OpenGL[04:32:18] *** rabbit- has quit IRC[04:33:34] *** msh07 has quit IRC[04:33:48] *** msh07 has joined ##OpenGL[04:34:43] *** eXtronuS has joined ##OpenGL[04:36:53] <aep> any idea why ftgl is so extremly slow?[04:38:35] <aep> weird. only the first time after a resize[04:39:36] *** msh07 has quit IRC[04:39:36] <aep> it eats up all my cpu oO[04:39:38] *** msh07 has joined ##OpenGL[04:40:02] *** reprore_ has quit IRC[04:43:30] *** jfroy has quit IRC[04:46:45] <aep> ew. never mind.[04:53:41] *** calav3ra has quit IRC[05:21:44] *** Gorgoroth has joined ##OpenGL[05:33:53] *** reprore_ has joined ##OpenGL[05:33:56] *** rnx has left ##opengl[05:39:29] *** reprore_ has quit IRC[05:40:52] *** reprore_ has joined ##OpenGL[06:01:26] *** DeforMobile has quit IRC[06:14:57] *** stringfellow has joined ##opengl[06:18:22] *** amz has quit IRC[06:21:03] *** msh07 has quit IRC[06:34:29] *** m4ggus has joined ##opengl[06:36:32] *** m4ggus has quit IRC[06:36:35] *** m4ggus_ has joined ##opengl[06:36:37] *** m4ggus_ is now known as m4ggus[06:40:33] *** oliveira_ has quit IRC[06:41:21] *** paul424 has quit IRC[06:44:07] *** oliveira_ has joined ##OpenGL[06:46:57] *** eXtronuS has quit IRC[06:46:59] *** eXtronuS_ has joined ##OpenGL[06:50:17] *** |t4bz| has quit IRC[06:56:03] *** reprore_ has quit IRC[07:02:06] *** Aintaer has quit IRC[07:11:53] *** boghog has quit IRC[07:20:39] *** Ademan has joined ##OpenGL[07:24:53] *** jfroy has joined ##OpenGL[07:27:19] *** braden has quit IRC[07:49:49] *** AndyCR has quit IRC[08:06:11] *** k3t has quit IRC[08:17:25] *** msh07 has joined ##OpenGL[08:18:00] *** msh07 has quit IRC[08:22:58] *** k3t has joined ##OpenGL[08:24:58] *** zen_ has joined ##OpenGL[08:30:17] *** korff_home has joined ##OpenGL[08:49:18] *** korff_home has quit IRC[08:49:43] *** korff_home has joined ##OpenGL[08:58:12] *** braden has joined ##OpenGL[08:58:17] *** boghog has joined ##opengl[09:03:54] *** UUncia has joined ##OpenGL[09:10:10] *** korff_home has quit IRC[09:14:26] *** BenPa85 has joined ##opengl[09:15:20] *** KingGuru has joined ##OpenGL[09:15:51] <KingGuru> morning[09:21:34] *** Renderwahn has joined ##OpenGL[09:26:46] *** fargiola` has joined ##OpenGL[09:37:23] *** sohail has quit IRC[09:39:00] *** fargiolas has quit IRC[09:40:25] *** kbotnen has joined ##OpenGL[09:44:57] *** phrosty has quit IRC[09:55:55] *** scai has joined ##opengl[09:57:25] *** predaeus has joined ##opengl[09:58:18] *** phrosty has joined ##opengl[10:06:08] *** Zemyla has quit IRC[10:06:37] *** TiLex has joined ##opengl[10:09:44] *** dolphin has joined ##OpenGL[10:09:45] *** maxton has joined ##OpenGL[10:13:48] *** izike has joined ##OpenGL[10:14:48] <izike> hi, i am using glDrawPixels() but it doesnt draw anything to the screen, the weird thing is that even when i give the *pixels parameter NULL (or other invalid address) it doesnt crush..., how can it be?[10:15:02] *** TiLex has quit IRC[10:19:01] *** Yustme has joined ##OpenGL[10:25:20] *** zen_ has quit IRC[10:28:33] *** korff_home has joined ##OpenGL[10:35:17] *** pietia has joined ##OpenGL[10:43:21] *** Spkka has joined ##OpenGL[10:48:54] *** elite01 has joined ##opengl[11:04:54] *** hang3r has joined ##OpenGL[11:05:02] *** izike has quit IRC[11:11:27] *** groton___ has joined ##OpenGL[11:15:09] *** groton has joined ##OpenGL[11:15:46] *** geocalc has quit IRC[11:16:20] *** geocalc has joined ##opengl[11:18:46] *** groton has quit IRC[11:19:22] *** fargiola` is now known as fargiolas[11:20:25] *** groton has joined ##OpenGL[11:22:54] *** Ingenu has joined ##OpenGL[11:55:48] *** Bollinger has joined ##OpenGL[12:01:44] *** kornerr has joined ##OpenGL[12:01:49] <kornerr> hi[12:02:04] <kornerr> how many bits are necessary for depth buffer?[12:03:10] <LordHavoc> 16 or more[12:03:23] <kornerr> how do I know how many?[12:03:37] <LordHavoc> depending on the definition of it, 16, 24, or 32 are common[12:03:47] <LordHavoc> 32 usually referring to S8D24 (24bit depth, 8bit stencil)[12:04:01] <kornerr> so 24 is max?[12:04:01] <LordHavoc> but I'm not sure how a request for more than 24 is interpreted by each windowing system[12:04:15] <LordHavoc> since some video cards really do have 32bit depth available[12:04:18] <LordHavoc> (without stencil)[12:04:21] <LordHavoc> but that's not often used[12:05:15] <Jupp3> kornerr: I'd assume there's no max[12:05:36] <Jupp3> But there's a "maximum that makes any practical sense", sort of[12:09:54] <kornerr> hm[12:10:08] *** UUncia has quit IRC[12:11:00] *** positron2007 has quit IRC[12:11:01] *** cplusplus has joined ##OpenGL[12:16:05] <Jupp3> It also has to be able to return it in certain formats[12:36:54] *** Walt has joined ##opengl[12:37:50] *** HugoMaxx_ has quit IRC[12:46:05] *** b0000 has joined ##opengl[12:53:28] *** Burga__ has joined ##OpenGL[12:55:03] *** neoneye has joined ##OpenGL[12:55:29] *** Burga__ has quit IRC[12:55:45] *** Burga__ has joined ##OpenGL[12:56:38] *** Burga__ is now known as Burga[12:57:12] *** geocalc has quit IRC[12:58:05] *** geocalc has joined ##opengl[12:59:21] *** Yaniel has joined ##opengl[12:59:33] <Yaniel> problem:[12:59:52] *** MatthiasM has quit IRC[12:59:56] *** jm|earth has joined ##OpenGL[12:59:58] <Yaniel> glColor4f completely ignores the red value[12:59:58] *** MatthiasM has joined ##opengl[13:00:25] <Yaniel> (it is always zero)[13:02:32] *** Walt has quit IRC[13:02:32] *** predaeus has quit IRC[13:02:32] *** BenPa85 has quit IRC[13:02:32] *** jm|afk has quit IRC[13:02:32] *** RTFM_FTW has quit IRC[13:02:32] *** LordHavoc has quit IRC[13:02:33] *** Xantoz has quit IRC[13:02:33] *** Stevethe1irate has quit IRC[13:02:33] *** Icchan^ has quit IRC[13:02:33] *** exDM69 has quit IRC[13:02:33] *** Rolenun has quit IRC[13:02:33] *** TenOfTen has quit IRC[13:02:33] *** quicksilver has quit IRC[13:02:33] *** aep has quit IRC[13:02:33] *** Mazon has quit IRC[13:02:33] *** memfr0b has quit IRC[13:03:09] *** Walt has joined ##OpenGL[13:03:09] *** predaeus has joined ##OpenGL[13:03:09] *** BenPa85 has joined ##OpenGL[13:03:09] *** RTFM_FTW has joined ##OpenGL[13:03:09] *** LordHavoc has joined ##OpenGL[13:03:09] *** Xantoz has joined ##OpenGL[13:03:09] *** Stevethe1irate has joined ##OpenGL[13:03:09] *** Rolenun has joined ##OpenGL[13:03:09] *** aep has joined ##OpenGL[13:03:09] *** Icchan^ has joined ##OpenGL[13:03:09] *** TenOfTen has joined ##OpenGL[13:03:09] *** exDM69 has joined ##OpenGL[13:03:09] *** Mazon has joined ##OpenGL[13:03:09] *** quicksilver has joined ##OpenGL[13:03:09] *** memfr0b has joined ##OpenGL[13:03:27] *** mm765^sleep is now known as mm765[13:03:56] *** Walt has quit IRC[13:05:09] *** UUncia has joined ##OpenGL[13:05:15] <Yaniel> however, it works a few lines earlier[13:06:02] *** UUncia has quit IRC[13:07:00] *** UUncia has joined ##OpenGL[13:09:17] *** Tenac has quit IRC[13:09:39] <Yaniel> does someone know a reason for this?[13:12:24] <predaeus> Yaniel, can you post your question again, there was a net split and I only see it from 'however, it works a few lines...' onwards.[13:13:02] <Yaniel> the problem is: glColor4f completely ignores the red value[13:14:11] <predaeus> Yaniel, can you paste an example to a pastebin that shows us what you are trying to do?[13:14:49] <predaeus> I mean the code that doesn't work as expected.[13:15:40] <Yaniel> http://pastebin.com/d65c1d1c7[13:16:46] <predaeus> Yaniel, how do you do you set r, g, b, alpha?[13:16:58] <predaeus> and when[13:17:11] <Yaniel> by set functions and by the constructor[13:17:40] <predaeus> can you post the relevant code too please?[13:18:34] <Yaniel> http://pastebin.com/m5ebe216[13:18:38] *** LordMetroid has joined ##OpenGL[13:23:07] *** rutski_ has joined ##OpenGL[13:24:00] <predaeus> Yaniel, do you check for gl errors at least each frame? maybe something else is causing an error that causes this weird behaviour. If everything else is fine then you likely use something else that changes the color.[13:24:28] <predaeus> e.g. texturing, lighting, shaders, ...[13:25:29] <predaeus> Yaniel, do the green and blue components work?[13:27:23] *** b0000 has quit IRC[13:27:52] <Yaniel> no, I don't check errors after init, yes greeb, blue and alpha work[13:28:45] <GuShH> Are you coding in windows? try using glintercept to see what's obviously wrong to begin with...[13:29:54] <Yaniel> using ubuntu[13:30:22] <predaeus> Yaniel, does something like this http://pastebin.com/d2fddd561 each frame after rendering to check for errors.[13:30:25] <predaeus> *do[13:31:21] <GuShH> Well I don't know of any equivalent tools for linux[13:31:26] <GuShH> But you could look it up[13:31:29] <GuShH> They are helpful[13:32:35] <MatthiasM> Yaniel: do you have textures enabled ?[13:33:08] <MatthiasM> Yaniel: because the default GL_MODULO mode multiplies the specified color with the texture - and if the texture has r=0 then r will stay at 0[13:33:33] <MatthiasM> *G_MODULATE[13:34:57] <Yaniel> yes, textures are enabled, but this object should not have atexture[13:35:16] <MatthiasM> Yaniel: then disable texture for this object[13:35:28] <Yaniel> with glDisable()?[13:35:39] <MatthiasM> yep[13:37:06] *** groton_ has joined ##OpenGL[13:37:14] *** groton has quit IRC[13:37:25] <Yaniel> that helped, thanks![13:37:35] *** Yaniel has left ##opengl[13:52:15] *** Suprano has joined ##OpenGL[13:59:25] <KingGuru> anyone in here been working with cuda/openGL ?[14:03:10] *** twist_ has joined ##OpenGL[14:05:47] *** tokemonstah has joined ##OpenGL[14:08:50] *** NightVisio has joined ##OpenGL[14:11:36] <exDM69> does anyone know what is the direct3d 10 counterpart to opengl framebuffer blitting[14:13:38] *** Kasu has joined ##OpenGL[14:15:22] <KingGuru> sorry.. .. maybe look for a direct3d forum ?[14:16:29] *** rutski_ has quit IRC[14:17:23] *** rutski_ has joined ##OpenGL[14:18:08] *** AlastairLynn has joined ##opengl[14:21:34] *** m4ggus has quit IRC[14:23:51] *** sohail has joined ##OpenGL[14:37:55] *** pietia has quit IRC[14:48:55] *** BenPa85 has quit IRC[14:55:18] *** johndoe has joined ##opengl[14:56:41] *** Ingenu has quit IRC[14:57:12] *** pietia has joined ##OpenGL[14:57:58] *** mm765 is now known as mm765^away[14:58:04] *** LordMetroid has quit IRC[15:03:12] <MatthiasM> exDM69: EXT_frame_buffer_object has blit functions[15:11:42] *** Marin has joined ##OpenGL[15:11:59] <Marin> Does anyone know about bob's game[15:12:22] <MatthiasM> who is bob ?[15:12:30] *** aucahuasi__ has joined ##OpenGL[15:12:56] *** aucahuasi__ has quit IRC[15:13:02] <Marin> Some guy[15:13:14] <Marin> He was programming some game for NDS[15:13:21] <Marin> it took him 5 years[15:13:31] <Marin> it looks like he gone mad, he destroyed his whole room[15:13:37] <Marin> http://www.bobsgame.com/[15:13:45] <Marin> Take a look at camera MatthiasM[15:17:14] <MatthiasM> and?[15:17:25] <MatthiasM> how is this related to OpenGL ?[15:27:14] *** electrostatic has joined ##OpenGL[15:27:46] <electrostatic> meh, apple[15:29:01] <electrostatic> I have a radeon 9700, and on os x 10.4 GL_MAX_COLOR_ATTACHMENTS_EXT returned 1... Now on 10.5 it returns 4... But only the first one works[15:32:20] <MatthiasM> you sure that you use it correctly ?[15:33:47] <electrostatic> Well, considering GL_COLOR_ATTACHMENT0_EXT is working, I would hope so[15:34:13] <electrostatic> It's just that changing from 1 to 4 should make, say GL_COLOR_ATTACHMENT1_EXT work too[15:34:32] <MatthiasM> what is not working ? do you get any errors ?[15:34:50] <electrostatic> And it doesn't... (No huge deal considering I'm not used to it working, anyway...)[15:35:23] <electrostatic> Ya, Framebuffer shos as complete, just like with the working one, but I get a 0x0506 when I try to draw to it[15:36:22] *** Srecko_ has joined ##opengl[15:36:33] <Srecko_> llo, just dropped in to ask what's up with Opengl 3.0?[15:37:06] <MatthiasM> Srecko_: read www.opengl.org[15:37:09] <electrostatic> I think the main problem is that this is one of the oldest cards supported by Quartz Extreme, a 9700 mobility[15:37:11] *** jm|afk has joined ##OpenGL[15:37:17] <MatthiasM> electrostatic: what's 0x0506 ?!?[15:37:41] <electrostatic> Generic "GL_INVALID_FRAMEBUFFER_OPERATION_EXT" error[15:37:49] <Srecko_> MatthiasM: hm. :)[15:37:54] <electrostatic> (Something went wrong, go fish...)[15:38:16] <MatthiasM> electrostatic: maybe your shader doesn't match with the frame buffer[15:38:58] <electrostatic> No shader, and like I said, just changing it to GL_COLOR_ATTACHMENT0_EXT makes it work[15:39:16] <electrostatic> Everything already has to be the right size / depth for that to happen[15:39:25] <MatthiasM> did you tried aother MRT apps ?[15:39:59] <electrostatic> I wasn't trying MRT[15:40:15] <electrostatic> I was just testing to see if the "new" ext's worked[15:40:22] <electrostatic> Using a regular FBO[15:40:27] <MatthiasM> using attachment 1 means MRT[15:40:39] <electrostatic> REally?[15:41:36] <MatthiasM> yes 0+1 ==> 2 eg more then1 ==> multi[15:42:10] <MatthiasM> and I think you have to use shaders for that[15:42:29] <electrostatic> I have only heard the acronym MRT in reference to shaders[15:42:31] <MatthiasM> and the shader has to write to gl_FragData[][15:42:34] *** Srecko_ has left ##opengl[15:42:51] <electrostatic> But I could swear to god you don't have to bind an FBO to ext 0[15:43:03] <MatthiasM> huh?[15:43:20] <electrostatic> glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_RECTANGLE_ARB, compositeTexture[COMPOSITE_TEXTURE_7], 0);[15:43:23] <MatthiasM> "ext0" is an attachment point in an FBO[15:43:54] <electrostatic> I meant attach, sorry[15:44:03] <electrostatic> (6 am hear)[15:44:09] <MatthiasM> then go to sleep :)[15:44:15] <electrostatic> =P[15:44:50] <electrostatic> But when I try using ext 1 in the same manner, it gives me the invalid operation[15:45:25] <MatthiasM> electrostatic: I suggest that you read about MRT[15:47:11] *** MexxiTank has joined ##OpenGL[15:47:46] *** MexxiTank is now known as LiQuiDninja[15:47:47] <electrostatic> but im not trying to render to multiple targets[15:48:04] <MatthiasM> why are you then using attachment 1 ?!?[15:48:29] <electrostatic> I just want to have 2 different sized FBO's with out having to actually just have one that I destroy and create twice per cycle[15:49:07] <electrostatic> Unless you can somehow change it's size really quick[15:49:23] <MatthiasM> electrostatic: argh! if you want 2 FBOs then create 2 ![15:49:24] <electrostatic> (Which may be possible, but I've never seen it)[15:49:44] <electrostatic> MatthiasM: And attach them both to ext 0?[15:50:58] <MatthiasM> ofcourse[15:51:14] <MatthiasM> and read the spec[15:53:54] *** jm|earth has quit IRC[15:59:50] *** UUncia_ has joined ##OpenGL[16:05:01] *** johndoe has quit IRC[16:07:24] *** UUncia_ has quit IRC[16:08:56] *** calav3ra has joined ##opengl[16:11:28] *** itewsh has joined ##OpenGL[16:13:01] *** LiQuiDninja has quit IRC[16:16:08] *** amz has joined ##opengl[16:16:48] *** UUncia has quit IRC[16:20:30] <exDM69> MatthiasM: GL_EXT_framebuffer_blit has blits (not GL_EXT_framebuffer_object), GL_ARB_framebuffer_object has blitting too (with minor differences to the EXT-extension), which is also in opengl 3.0 core[16:20:54] <exDM69> MatthiasM: _but_ what is the counter part of framebuffer blits in Direct3D 10?[16:20:54] <MatthiasM> ohh sorry[16:21:10] <MatthiasM> no idea - never looked at D3D[16:21:34] <exDM69> I am looking for a way to use framebuffer blits in my rendering device abstraction[16:21:53] <MatthiasM> what functionality exactly ?[16:22:49] <exDM69> most of the time I look for D3D 10 for guidance on the design[16:23:20] <exDM69> MatthiasM: I want to do framebuffer blits[16:23:38] <MatthiasM> you said that about in every line you wrote[16:26:39] <exDM69> 17:22 < MatthiasM> what functionality exactly ? << -- what did you mean?[16:27:12] *** groton_ has quit IRC[16:27:14] <MatthiasM> you said "GL_EXT_framebuffer_blit" and "GL_ARB_framebuffer_object" has blitting - so just use them[16:28:22] <exDM69> yeah, the implementation is not the problem (already done and working), the interface design is[16:29:03] <exDM69> I am looking to D3D10 for ideas, but I havn't found the counterpart[16:29:52] *** bhagabhi has joined ##OpenGL[16:30:21] <exDM69> perhaps D3D10 can just do texture-to-texture blits and copies, without the need to create an FBO (a render target) to copy from/to[16:30:22] <MatthiasM> exDM69: argh! then be more clear on your questions[16:30:49] <MatthiasM> but I can't help you with D3D in any way[16:31:21] <exDM69> http://qaq4.kyla.fi/hg/goodenough/file/06d76178ac7f/test/framebuffer.cpp <<--- this is what I have currently[16:31:33] *** bhagabhi has quit IRC[16:31:50] <exDM69> but I am planning a major refactoring to the state management part[16:32:38] <exDM69> my idea was to use C++ RAII to do a stack-based state management scheme[16:33:00] *** gusnan has joined ##OpenGL[16:33:06] <exDM69> but I don't think that it was such a good idea after all[16:35:44] <exDM69> framebuffer blits concern me, because they don't quite fit in my d3d10-style scheme[16:38:05] *** electrostatic_ has joined ##OpenGL[16:38:46] *** electrostatic has quit IRC[16:39:00] <electrostatic_> test[16:39:44] <electrostatic_> Hmm, can you hear me?... (my connection just weirded out...)[16:40:00] <MatthiasM> electrostatic_: no - but I can see what you write[16:40:09] <electrostatic_> =P[16:41:24] <electrostatic_> MatthiasM: OK, I re-read the spec... and the "Change section 4.2.1, to read as follows:" does not seem to be what you were talking about, but I'll take your word for it if works in the real world (I was under the impression that each color attachment was linked to a single image, i.e texture or buffer..)[16:42:04] *** sohail has quit IRC[16:42:54] *** Jupp3 has quit IRC[16:47:23] <MatthiasM> electrostatic_: anyway - if you want different sizes - then create 2 FBOs - and use glBindFrameBufferObject[16:47:42] <electrostatic_> Ya, working on it.. thx[16:48:01] *** amz has quit IRC[16:49:49] *** qeed has joined ##opengl[16:51:17] *** NightVisio has quit IRC[16:53:36] <electrostatic_> MatthiasM: Seems to be working a lot better, thanks[16:53:58] *** dusted has joined ##OpenGL[16:54:36] *** Eforen-SleepTime is now known as Eforen[16:56:02] *** vocodork has joined ##OpenGL[16:56:04] *** vocodork has left ##OpenGL[16:57:59] *** rnx has joined ##opengl[17:00:49] *** reprore_ has joined ##OpenGL[17:02:16] <KingGuru> I'm trying to make a volume render, using raytracing in cuda. the dataset is in a raw file with a HMD header. I can load these into cuda, and do the raytracing magic.. well.. sortof.. because I then have to visualise the result using openGL. Anyone have an idea on what I should do here .. I can see that in cuda forums ppl are saying PBO. but I can't figure out how to get the appropiate data copied to a PBO[17:04:14] <MatthiasM> you map the PBO - and then use the returned pointer for cudsa[17:04:17] <MatthiasM> *cuda[17:05:06] <exDM69> cuda has special functions for opengl/directx compatibility[17:05:22] <exDM69> you can share a buffer (pbo) with cuda[17:05:23] <KingGuru> I shoot ray through the dataset, and when I get a value above some threshold, I map this point to a PBO .. or how does this work[17:07:11] <exDM69> KingGuru: you should check the cuda manual for the interop functions[17:08:12] <MatthiasM> KingGuru: you should think in terms of data values -[17:08:31] <MatthiasM> eg every ray you shoot corresponds to one pixel[17:08:41] <exDM69> you may be able to get a cude device memory pointer to a pbo[17:08:53] <exDM69> or at least copy data to the pbo[17:09:01] <MatthiasM> and your texture (or PBO) has many texels ==> same number of rays or more[17:10:12] <KingGuru> ok.. I'm lstening..[17:11:17] <KingGuru> exDM69 . I know the functions.. but I don't know how a PBO works.. or didn't[17:12:16] <exDM69> pbo is just a buffer of device side memory.[17:12:41] <exDM69> you can then memory map the pbo[17:13:20] <KingGuru> so I can find every voxel that I want to show, and map them to the PBO ?[17:13:24] <exDM69> I think that does the same as a cuda asynchronous copy (which requires special page locked memory)[17:14:26] *** efecto has joined ##opengl[17:15:54] *** Jupp3 has joined ##OpenGL[17:17:54] *** LtJax has joined ##opengl[17:22:24] *** groton_ has joined ##OpenGL[17:24:42] *** Walt has joined ##opengl[17:24:45] *** lewymati has joined ##OpenGL[17:27:59] *** Deformalite has joined ##opengl[17:30:11] *** korff_home has quit IRC[17:34:16] *** gusnan has quit IRC[17:35:27] *** sparky has joined ##OpenGL[17:35:42] <sparky> mornin[17:39:27] *** hang3r has quit IRC[17:41:47] *** essoe- has joined ##opengl[17:46:48] *** Rolenun has quit IRC[17:56:37] *** Rolenun has joined ##opengl[17:56:37] *** itewsh has quit IRC[17:58:18] *** essoe- has quit IRC[18:04:17] *** jm|afk has quit IRC[18:12:52] *** amz has joined ##opengl[18:18:33] *** groton__ has joined ##OpenGL[18:18:50] *** groton_ has quit IRC[18:23:43] *** electrostatic_ has quit IRC[18:30:40] *** cplusplus2 has joined ##OpenGL[18:33:54] *** AndyCR has joined ##OpenGL[18:34:14] *** Gorgoroth has quit IRC[18:34:30] *** Gorgoroth has joined ##OpenGL[18:35:41] *** Xmas| has joined ##OpenGL[18:47:12] <forrestv> given the rendering matrix and a screen position, how do i find the ray that goes through that pixel?[18:47:15] *** cplusplus has quit IRC[18:47:32] <forrestv> i'd think you'd have to invert the matrix and then just plug in the screen position, but it's singular ..[18:48:55] <MatthiasM> forrestv: look at glUnproject[18:49:03] <MatthiasM> *gluUnproject[18:49:26] <forrestv> hehe.[18:50:27] <forrestv> MatthiasM, i'm trying to do it without opengl calls though, but the math helps[18:50:37] <MatthiasM> the spec explains how it's done[18:50:41] <forrestv> yeah[18:52:58] *** WhatAHam has quit IRC[18:55:41] *** reprore_ has quit IRC[18:55:58] *** wisey has joined ##OpenGL[18:56:29] *** GuShH has quit IRC[18:57:58] <forrestv> MatthiasM, i still can't invert the P*M matrix ..[18:58:12] <MatthiasM> then you do something wrong[18:58:30] <forrestv> maybe i'm just supposed to invert the upper 3x3?[18:59:26] <MatthiasM> no[19:01:17] *** amz has quit IRC[19:12:24] *** Bollinger has quit IRC[19:12:41] *** scai has left ##opengl[19:15:50] *** Ingenu has joined ##OpenGL[19:17:44] *** reprore_ has joined ##OpenGL[19:18:50] *** amz has joined ##opengl[19:26:58] *** Kasu has quit IRC[19:28:48] *** Orphis has quit IRC[19:29:54] *** Orphis has joined ##opengl[19:30:26] <Plagman> forrestv: it's M*P, not P*M[19:31:30] <forrestv> Plagman, yeah, i realized i'm multiplying all the matrices in the wrong order[19:36:17] *** groton__ has quit IRC[19:56:37] *** ygi has joined ##OpenGL[19:56:51] <ygi> Image-Based Lighting (IBL) has become a frequently used technique to render[19:56:51] <ygi> a virtual object with illumination conditions that are consistent with those of a[19:56:51] <ygi> real scene given that the scene is distant[19:56:54] <ygi> What is meant by distant ?[19:57:15] *** NightVisio has joined ##OpenGL[19:57:46] *** groton has joined ##OpenGL[20:00:57] *** korff_home has joined ##OpenGL[20:00:58] *** HuntsMan has joined ##opengl[20:05:53] *** sohail has joined ##OpenGL[20:07:11] *** calav3ra has quit IRC[20:07:43] *** calav3ra has joined ##opengl[20:08:56] *** cplusplus2 has quit IRC[20:13:50] *** amz has quit IRC[20:14:56] *** predaeus has quit IRC[20:16:52] *** reprore_ has quit IRC[20:25:49] *** eXtronuS_ has quit IRC[20:26:47] *** vampirefrog has joined ##OpenGL[20:27:07] *** vampirefrog has quit IRC[20:27:45] *** vampirefrog has joined ##OpenGL[20:41:22] *** fargiola` has joined ##OpenGL[20:42:38] *** tmccrary has joined ##OpenGL[20:44:49] *** GinoMan has joined ##OpenGL[20:45:34] *** Shel2476 has joined ##OpenGL[20:45:43] *** Shel2476 has left ##OpenGL[20:46:22] *** GinoMan has quit IRC[20:46:33] *** GinoMan has joined ##OpenGL[20:47:26] *** b0000 has joined ##opengl[20:50:00] *** NightVisio has quit IRC[20:50:45] *** NoLimitz has joined ##OpenGL[20:51:16] *** NoLimitz has left ##OpenGL[20:51:25] *** NoLimitz has joined ##OpenGL[20:51:46] *** twist__ has joined ##OpenGL[20:54:08] *** fargiolas has quit IRC[20:54:17] *** Deformalite has quit IRC[20:54:17] *** Walt has quit IRC[20:54:18] *** AlastairLynn has quit IRC[20:54:18] *** rutski_ has quit IRC[20:54:18] *** tokemonstah has quit IRC[20:54:18] *** twist_ has quit IRC[20:54:18] *** Suprano has quit IRC[20:54:18] *** exDM69 has quit IRC[20:54:18] *** Xantoz has quit IRC[20:54:18] *** Stevethe1irate has quit IRC[20:54:18] *** Icchan^ has quit IRC[20:54:18] *** TenOfTen has quit IRC[20:54:19] *** quicksilver has quit IRC[20:54:19] *** memfr0b has quit IRC[20:54:19] *** LordHavoc has quit IRC[20:54:19] *** Mazon has quit IRC[20:54:19] *** RTFM_FTW has quit IRC[20:54:19] *** aep has quit IRC[20:55:22] *** Deformalite has joined ##OpenGL[20:55:22] *** Walt has joined ##OpenGL[20:55:22] *** AlastairLynn has joined ##OpenGL[20:55:22] *** rutski_ has joined ##OpenGL[20:55:22] *** tokemonstah has joined ##OpenGL[20:55:22] *** twist_ has joined ##OpenGL[20:55:22] *** Suprano has joined ##OpenGL[20:55:22] *** RTFM_FTW has joined ##OpenGL[20:55:22] *** LordHavoc has joined ##OpenGL[20:55:22] *** Xantoz has joined ##OpenGL[20:55:22] *** Stevethe1irate has joined ##OpenGL[20:55:22] *** aep has joined ##OpenGL[20:55:22] *** Icchan^ has joined ##OpenGL[20:55:22] *** TenOfTen has joined ##OpenGL[20:55:22] *** exDM69 has joined ##OpenGL[20:55:22] *** Mazon has joined ##OpenGL[20:55:22] *** quicksilver has joined ##OpenGL[20:55:22] *** memfr0b has joined ##OpenGL[20:57:13] *** AlastairLynn has quit IRC[20:57:22] *** AlastairLynn has joined ##opengl[20:59:18] *** paul424 has joined ##OpenGL[21:00:32] *** vade has joined ##OpenGL[21:07:21] *** MexxiTank has joined ##OpenGL[21:07:39] *** vampirefrog has quit IRC[21:12:32] *** twist_ has quit IRC[21:18:32] *** KingGuru has quit IRC[21:18:42] *** AndyCR has quit IRC[21:21:33] *** Walt has quit IRC[21:33:49] <aep> anyone got an idea how to get a list of fonts from X11 system to use with ftgl?[21:34:22] *** mm765^away is now known as mm765[21:34:29] <MatthiasM> either ask the X font manager - or search known locations[21:35:36] <aep> searching known locations sounds like a bad idea. going to google for the former[21:37:02] *** AlastairLynn has quit IRC[21:38:15] <paul424> why does opengl seems to use less memory when using the vertexLists ? How much memory it takes to store one vertex with color in glList when I do use glVertexf glColorf ?[21:38:58] <paul424> MatthiasM: ???[21:39:27] <Jupp3> vertexlists?[21:39:27] <Goran_> it can take any amount[21:39:35] <tmccrary> wtf is a vertex list?[21:39:38] <Goran_> the glList[21:39:42] <paul424> I mean glList yeah[21:39:45] *** Kasu has joined ##OpenGL[21:39:46] <Jupp3> sounds like a cross between display list and vertex array :)[21:40:03] <paul424> yeap cross breading you know :D[21:40:11] <MatthiasM> paul424: 1) use the correct term so that other can understand you 2) memory consumption by OpenGL itself is highly implementation dependant[21:40:14] <Jupp3> paul424: You shouldn't be using direct mode anyway[21:41:27] <MatthiasM> paul424: so - restate your question again using the correct terms[21:41:49] <paul424> I do not ... from reasons I want not to discuss hear I just wanted to store all the calculation of certain mesh in a separated array ..... And it came out that my env cannot declarate such a large arrays .......[21:42:22] <HuntsMan> what's your env?[21:42:32] <paul424> why does opengl seems to use less memory when using the display lists ? How much memory it takes to store one vertex in display list with color in glList when I do use glVertexf glColorf ?[21:42:53] <paul424> slackware 32 bit kernel + gcc ........[21:44:05] <HuntsMan> BTW what's a "large array"?[21:44:11] <MatthiasM> paul424: I assume that you talk about vertex arrays vs display list[21:45:26] *** XT95_ has joined ##OpenGL[21:45:36] *** t4bz has joined ##OpenGL[21:46:11] *** iammisc has joined ##OpenGL[21:46:31] <paul424> MatthiasM: not the vertex arrays I just wanted to declare array like this: float vertex_array [6000][6000][6] ;[21:46:47] <Jupp3> whoa...[21:46:52] <Jupp3> That's quite an array[21:47:00] <MatthiasM> 860MB[21:47:18] <Jupp3> Would make a nice binary indeed :)[21:47:28] <MatthiasM> paul424: it may be that you can allocate such a large array in one block[21:47:38] <MatthiasM> *can't[21:47:56] <paul424> :D so opengl compress it somehow when I do use the glList, right ?[21:47:58] <iammisc> I have a wavefront obj file and I need to calculate normals. Right now, I'm getting normals pointing in the wrong directions. I know that the proper normal has something to do with the vertex order as specified in the obj file. What's the proper method for calculating these normals?[21:48:49] <Jupp3> iammisc: 1) Calculate face normals[21:49:01] <Jupp3> iammisc: 2) Assign face normals to vertex normals, and see if it looks ok[21:49:09] <iammisc> Jupp3: that's the problem, the face normals are pointing the wrong way[21:49:28] <Jupp3> iammisc: 3) If it is ok, calculate vertex normals as average of all face normals, which use the vertex[21:49:54] <Jupp3> Are you using one sided faces?[21:50:05] <iammisc> I'm trying to show a simple cube[21:50:10] <iammisc> that's lighted[21:50:10] <Jupp3> That "vertex order in obj" was bit confusing[21:50:16] <tmccrary> make sure you're winding the polygons correctly[21:50:24] <Jupp3> I mean, if the order is wrong, the whole face should face the wrong way[21:50:43] <iammisc> according to sources on the internet, the vertex order as specified in an obj face affects the way the normal should be facing.[21:50:53] <Jupp3> iammisc: That's the worst possible object to create simple lighting for :D[21:50:53] <paul424> Jupp3: ???[21:51:06] <Jupp3> paul424: ???[21:51:14] <paul424> My question above[21:51:20] *** Walt has joined ##opengl[21:51:21] *** WhatAHam has joined ##OpenGL[21:51:27] <Jupp3> paul424: Still, what is glList?[21:51:36] <Jupp3> Some wrapper?[21:52:38] *** WhatAHam has left ##OpenGL[21:52:55] <paul424> I mean glNewList , glGenLists ............[21:53:04] *** WhatAHam has joined ##OpenGL[21:53:10] <Jupp3> paul424: Okay, then just say "display lists"[21:53:20] <paul424> ok[21:53:21] *** WhatAHam has left ##OpenGL[21:53:24] <Jupp3> So what are you comparing it againist?[21:53:26] *** WhatAHam has joined ##OpenGL[21:53:55] <Jupp3> I guess the "How OpenGL stores stuff internally, with or without compression" is left for the implementation to decide[21:54:44] <MatthiasM> paul424: it is very likely that you will be able to store such amounts of data if you use dynamic memory and pointers[21:55:10] <Jupp3> paul424: Anyway, read this and decide, if this is more comfortable way to do what you want: http://www.songho.ca/opengl/gl_vertexarray.html[21:55:27] *** Walt has quit IRC[21:55:48] <paul424> Jupp3: funny just googled that article a minute ago ..... thanks anyway ...........[21:56:28] <paul424> MatthiasM: ok thanks ......[21:56:45] *** TenOfTen has quit IRC[21:57:35] <Jupp3> paul424: Don't know if it matters for you, but direct mode (glBegin(), glVertex() etc.) and display lists aren't supported at all in OpenGL ES (OpenGL for mobile devices) and might be removed from "full" OpenGL in the future aswell[21:58:30] <paul424> ah, thanks the thing is this is going to be a lab's student excercise so I do not worry about portability[21:59:26] <Jupp3> paul424: Well vertex arrays are way better and easier in some cases[21:59:35] <MatthiasM> paul424: you could try to split your data into 6000 arrays of 6000*6 floats - and use new/malloc for the inner arrays[21:59:50] <Jupp3> Especially if you load model data from disk, and have to be able to modify it after loading between frames[21:59:53] <paul424> MatthiasM: yes that's what i thought[22:00:05] <MatthiasM> paul424: it's much more likly that such smaller chunks of memory are available compared to one 800MB block[22:03:01] <Jupp3> My second OpenGL program used sometimes a bit over 100MB of memory, and I thought it was much :-)[22:03:27] <Jupp3> Then I optimized it "a bit", and the same program with same data used less than half megabyte[22:07:40] *** lewymati has quit IRC[22:09:01] *** TenOfTen has joined ##opengl[22:15:23] *** MexxiTank has quit IRC[22:18:36] <MatthiasM> Jupp3: nice[22:20:40] *** TheLorax has joined ##opengl[22:21:16] *** GuShH has joined ##OpenGL[22:22:04] <Jupp3> Although that was definitely the worst case scenario[22:23:09] <Jupp3> MatthiasM: http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1080513 This model, first loaded so that every new instance of block is always loaded "inline"[22:23:31] <Jupp3> And in the optimized version, each block is loaded only once, and when refered later, it refers to the earlier loaded data[22:23:37] <MatthiasM> ahh - yeah - your lego renderer[22:23:51] <MatthiasM> btw - is the model solid ?[22:26:11] <Jupp3> I think so[22:26:22] <Jupp3> But just think of all the rounded surfaces[22:26:36] <Jupp3> And remember that also the inner parts of the blocks are rendered[22:31:52] *** dolphin has quit IRC[22:34:36] *** mikolalysenko has quit IRC[22:37:58] *** GX has joined ##OpenGL[22:39:17] *** NoLimitz has quit IRC[22:40:32] *** mikolalysenko has joined ##OpenGL[22:48:47] <iammisc> Turns out my normal generation code was generating normals just fine but I was visualizing them wrong( I accidentally typed x instead of z). Thanks for all your help Jupp3[22:53:30] *** TheLorax has quit IRC[22:55:11] <GX> I'm using opengl with 2D graphics and I have tiny 2D sprite with 1 pixel wide line and that thin line seems to fade in and out strangely when the sprite moves around the screen, could this be because of texture filtering?[22:55:39] <MatthiasM> GX: yes[22:55:54] <MatthiasM> if you move with sub pixel precision[22:56:00] <GX> yes[22:56:32] <GX> yeah, it seems to fade out every 0.5 pixels and back in when moved 1 full pixel :P[23:03:16] *** HuntsMan has quit IRC[23:06:39] <GX> Thanks, I took away sub pixel precision from rendering and now it works fine :)[23:17:06] *** sohail has quit IRC[23:33:28] *** k3t has quit IRC[23:41:31] *** davidc__ has joined ##opengl[23:45:17] *** dv_ has joined ##opengl