January 21, 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 21, 2009 [00:01:39] *** ljungk has quit IRC[00:10:01] *** nettikkcah has joined ##opengl[00:10:24] *** boghog has quit IRC[00:11:05] *** hogbog has joined ##opengl[00:12:05] *** hogbog is now known as boghog[00:14:23] *** vampirefrog has quit IRC[00:15:26] *** hackkitten has quit IRC[00:18:16] *** linuxuz3r has joined ##OpenGL[00:26:02] *** Aintaer has quit IRC[00:28:00] *** mmmmmmm has joined ##opengl[00:37:30] *** Amorphous has quit IRC[00:38:25] *** reprore_ has joined ##OpenGL[00:38:33] *** JernejL has joined ##OpenGL[00:39:43] *** NevroPus has joined ##OpenGL[00:39:58] *** Spkka has joined ##OpenGL[00:41:08] *** aep has quit IRC[00:42:14] *** groton has quit IRC[00:43:12] *** Bollinger has quit IRC[00:43:56] *** Acry has left ##OpenGL[00:47:28] *** rnx has joined ##opengl[00:48:47] *** aep has joined ##OpenGL[00:49:50] <GNU\caust1c> how can i get a texture with lower resolution from an existing texture?[00:50:13] *** Amorphous has joined ##opengl[00:50:15] <MatthiasM> mipmapping[00:51:03] <GNU\caust1c> and how can i specify which detaillevel it should use?[00:51:28] <MatthiasM> read about mipmapping in the red book[00:51:36] <GNU\caust1c> i want to render to an fbo and get a downsampled version of that texture[00:52:05] <MatthiasM> read the fbo extension[00:52:26] <GNU\caust1c> hm, but i want to have both resolutions[00:53:09] <MatthiasM> reading is hard[00:53:32] *** iion has left ##OpenGL[00:54:28] *** b0000 has quit IRC[00:57:19] <GNU\caust1c> i know how i can generate the mipmapped textures, but i dont know how i can explicit specify which level i want to use when i bind the texture[00:57:24] <GNU\caust1c> and i dont know if its even possible[00:57:46] <MatthiasM> glTexParameter[00:58:13] *** LordMetroid has quit IRC[00:58:18] *** kbotnen has quit IRC[00:58:57] *** vade has quit IRC[00:59:07] <GNU\caust1c> okay, thanks :)[00:59:46] *** pietia has quit IRC[01:01:33] *** zacs7 has joined ##opengl[01:06:00] *** barbar__conan has quit IRC[01:08:03] *** Aintaer has joined ##OpenGL[01:08:31] *** mm765 is now known as mm765^sleep[01:11:37] *** rnx1 has joined ##opengl[01:11:47] *** rnx1 has left ##opengl[01:15:18] *** yno has quit IRC[01:18:27] *** rnx has quit IRC[01:21:41] *** reprore_ has quit IRC[01:22:44] *** eXtronuS_ has quit IRC[01:23:37] *** zwiep` has quit IRC[01:25:32] *** vade has joined ##OpenGL[01:35:18] *** reduz has joined ##OpenGL[01:35:23] <reduz> oops back[01:36:24] <reduz> question! do you guys think it may be a good idea to use deferred but instead of storing all the material properties in the fragment, storing a material index and then use uniform buffers to fetch the material parameters?[01:36:46] <HuntsMan> in the fragment?[01:37:05] <reduz> yeah instead of setting diffuse, ambient, specular, etc in the fragment[01:37:18] <reduz> just store an index[01:37:29] <reduz> and then fetch all that per material from an uniform buffer per fragment[01:37:37] <reduz> not sure how efficient that can be[01:37:39] *** Gorgoroth has quit IRC[01:38:28] <HuntsMan> what would be an uniform buffer?[01:38:33] <HuntsMan> an bindable uniform?[01:38:39] <reduz> err yeah[01:40:52] *** amz has joined ##opengl[01:42:11] <HuntsMan> sounds complicated :P[01:43:07] *** TheLorax has joined ##opengl[01:43:37] *** m4ggus has quit IRC[01:43:40] *** m4ggus_ has joined ##opengl[01:43:42] *** m4ggus_ is now known as m4ggus[01:46:26] *** rnx has joined ##opengl[01:52:28] *** Kasu- has quit IRC[02:03:14] *** pwned has quit IRC[02:04:26] *** neoneye has quit IRC[02:04:40] *** RTFM_FTW has quit IRC[02:05:49] *** johndoe has quit IRC[02:10:00] *** vade has quit IRC[02:11:42] *** korff_home has quit IRC[02:19:30] *** uster has joined ##OpenGL[02:31:26] *** RTFM_FTW has joined ##OpenGL[02:32:02] *** vade has joined ##OpenGL[02:32:17] *** dvoid has quit IRC[02:34:33] *** zwiep` has joined ##opengl[02:34:34] *** elite01 has quit IRC[02:44:06] *** tmccrary has joined ##OpenGL[02:45:03] *** vade has left ##OpenGL[02:49:44] *** ghenriks has joined ##opengl[02:51:55] <GNU\caust1c> hmm, im trying to use a fbo to render my stuff into a texture, but there seems to be a problem with the depthbuffer[02:53:12] <GNU\caust1c> http://rafb.net/p/Nljl0s15.html this is my setup code for the fbo[02:54:25] <HuntsMan> your FBO doesn't have a depth buffer[02:54:42] <RTFM_FTW> indeed[02:54:44] <GNU\caust1c> hm, i assumed it would use the default fbo[02:54:49] <RTFM_FTW> no[02:54:59] <RTFM_FTW> if you need a depth attachment you need to create one[02:55:20] <GNU\caust1c> so do i just need to add another texture as depthbuffer attachment?[02:55:21] <RTFM_FTW> either by binding a (depth) texture or by creating a (depth) render buffer[02:55:40] <GNU\caust1c> which solution would be the faster one?[02:56:11] <GNU\caust1c> and can i mix the the texture with the depth render buffer?[02:56:16] <RTFM_FTW> it all depends upon what you need[02:56:28] <GNU\caust1c> i dont need the depthbuffer information[02:57:45] <MatthiasM> then use a renderbuffer[02:58:07] *** fusi has quit IRC[02:58:13] <GNU\caust1c> can i mix both of them in one fbo?[02:58:41] <HuntsMan> yes[02:58:47] <GNU\caust1c> okay, thanks :)[02:58:52] <MatthiasM> GNU\caust1c: did you read the fbo spec ?[02:58:54] <RTFM_FTW> actually not in the way you are thinking :P[02:59:02] <MatthiasM> it has examples for such use cases[03:00:47] <GNU\caust1c> i didnt read the complete specs :/[03:01:04] <GNU\caust1c> must have scrolled over the examples :/[03:03:46] <RTFM_FTW> *always* read the fucking spec :D[03:04:06] <MatthiasM> but reading is sooo hard :P[03:05:08] <RTFM_FTW> uh huh :P[03:06:47] <GNU\caust1c> actually, reading the whole spec (-> understanding) is not that easy for me, being an opengl novice[03:07:38] <GNU\caust1c> and i really didnt know there were examples in it, i googled for some, but only found stuff that confused me more than it helped[03:08:12] <GNU\caust1c> i find it quite hard to judge if some method is the right way to use for the problem i want to solve[03:08:15] <RTFM_FTW> well you generally start with the core GL API specification[03:08:38] <RTFM_FTW> and from there (as needed) you branch off into the various extension specification(s) you might need to reference[03:09:09] <GNU\caust1c> yes, thats where i started, but really didnt see it between those glx specifications which i find not that interesting at all :)[03:09:16] <RTFM_FTW> since everything in a given extension specification is ultimately a branch off of the core (for version XYZ) GL API spec[03:09:42] <RTFM_FTW> in fact the spec authors even quote the section / sub-section differences (from core <-> extension) for you[03:09:53] <GNU\caust1c> anyways, i'll try with the example code[03:10:20] <RTFM_FTW> and as a developer you *really* need to have a strong grasp of the documentation[03:10:32] <RTFM_FTW> specifically the technical documentation we discuss here[03:11:24] *** davidc__ has joined ##opengl[03:17:06] *** georgia72 has joined ##OpenGL[03:18:33] *** Entelin has joined ##OpenGL[03:21:02] *** HuntsMan has quit IRC[03:27:55] <GNU\caust1c> how problematic are textures with dimensions which arent a power of 2?[03:28:26] <RTFM_FTW> that depends upon the target HW[03:28:30] <zacs7> not very / very[03:28:55] <RTFM_FTW> in other words (as I said above) "it depends" :P[03:28:58] <GNU\caust1c> so in which cases its problematic? :)[03:29:21] <RTFM_FTW> well I suppose its problematic on any target HW lacking NPOT support :P[03:29:27] <RTFM_FTW> heheh[03:29:45] <zacs7> hehe[03:30:09] <GNU\caust1c> okay :>[03:30:26] <RTFM_FTW> in any case you want support for (a) GL_ARB_texture_rectangle and / or (b) GL_ARB_texture_non_power_of_two[03:31:33] <RTFM_FTW> support for (a) has been around (in HW) since the original ATI Radeon (i.e. R1xx) and GeForce4 as I recall[03:32:03] <RTFM_FTW> complete support for (b) is only available on R6xx+ or G8x+[03:32:25] <RTFM_FTW> i.e. anything D3D10 compliant since Direct3D 10.x requires generalized NPOT support[03:32:37] <GNU\caust1c> okay, thanks :)[03:37:07] *** MatthiasM has quit IRC[03:37:14] *** MatthiasM has joined ##opengl[03:41:01] *** LtJax has quit IRC[03:47:29] *** vade has joined ##OpenGL[03:53:47] *** Spkka has quit IRC[03:56:43] *** qeed has quit IRC[04:01:35] *** davidc__ has quit IRC[04:19:10] *** Walt has quit IRC[04:24:15] *** GuShH is now known as peeman[04:25:18] *** peeman is now known as GuShH[04:25:54] *** tmccrary is now known as jessisamanz[04:27:51] *** HuntsMan has joined ##opengl[04:34:49] *** zacs7 has quit IRC[04:38:24] *** jessisamanz is now known as tmccrary[04:38:50] *** jfroy|work has quit IRC[04:55:48] *** m4ggus has quit IRC[04:58:41] *** TheLorax has quit IRC[04:58:43] *** m4ggus has joined ##opengl[04:59:29] *** djork has quit IRC[05:01:32] *** HuntsMan has quit IRC[05:03:33] *** jfroy has joined ##OpenGL[05:09:23] *** uster has quit IRC[05:15:50] *** stevosICBM has joined ##OpenGL[05:17:42] *** reprore_ has joined ##OpenGL[05:45:25] *** pwned has joined ##opengl[06:01:30] *** stevosICBM has quit IRC[06:17:12] *** linuxuz3r has quit IRC[06:19:07] *** davidc__ has joined ##opengl[06:20:34] *** davidc__ has quit IRC[06:26:44] *** dennda has quit IRC[06:34:04] *** GinoMan has quit IRC[06:39:22] *** korff_home has joined ##OpenGL[06:53:39] *** holigen has joined ##OpenGL[06:54:03] *** m4ggus has quit IRC[06:59:35] *** ixtli has quit IRC[07:02:24] *** ol1veira1 has joined ##OpenGL[07:05:22] *** amz has quit IRC[07:05:35] *** dennda has joined ##opengl[07:08:32] *** kker has joined ##OpenGL[07:10:29] <kker> Does anyone happen to know an example codebase which renders text using purely PyOpenGL? (No PIL)[07:13:53] *** predaeus has joined ##opengl[07:15:49] *** ol1veira_ has quit IRC[07:18:06] *** kker has quit IRC[07:18:50] *** ol1veira1 has quit IRC[07:39:24] *** GinoMan has joined ##OpenGL[07:40:51] *** loz has joined ##OpenGL[07:42:01] *** reprore_ has quit IRC[07:47:11] *** loz is now known as loz-[08:03:16] *** pietia has joined ##OpenGL[08:08:38] *** tmccrary has quit IRC[08:19:44] *** gusnan has joined ##OpenGL[08:26:48] *** zommi has joined ##OpenGL[08:30:46] *** loz- has quit IRC[08:30:52] *** Suprano has joined ##OpenGL[08:37:57] *** dean1012 has joined ##OpenGL[08:38:00] <dean1012> hi everyone[08:38:22] <dean1012> what's the best way to rotate an entire screen (IE, everything that is rendered on it or will be rendered on it)?[08:38:43] <dean1012> i'm developing on an iPhone and by default the screen dimensions are 480 high and 320 wide[08:38:56] <dean1012> i need to reverse this so that it is 320 high and 480 wide[08:38:58] *** davidc__ has joined ##opengl[08:39:04] <dean1012> does anyone have a clue?[08:39:10] <dean1012> i've tried glViewport changes and glRotatef[08:40:59] *** zacs7 has joined ##opengl[08:43:09] *** JernejL has quit IRC[08:50:37] *** gusnan has quit IRC[08:56:35] *** vade has quit IRC[08:58:47] *** Gorgoroth has joined ##OpenGL[09:01:27] *** nettikkcah is now known as hackkitten[09:17:30] *** Bollinger has joined ##OpenGL[09:20:21] *** [AD]Turbo has joined ##OpenGL[09:24:27] <[AD]Turbo> yo[09:25:39] *** zacs7 has quit IRC[09:29:24] *** sohail has quit IRC[09:31:54] *** georgia72 has quit IRC[09:31:59] *** scai has joined ##opengl[09:32:54] *** dean1012 has quit IRC[09:33:28] *** neoneye has joined ##OpenGL[09:34:54] *** ixtli has joined ##OpenGL[09:42:08] *** Nescafe has joined ##OpenGL[09:43:31] *** maxton has quit IRC[09:45:28] *** groton has joined ##OpenGL[09:46:40] *** kenws has joined ##OpenGL[09:48:47] <groton> hi kenws[09:53:55] *** kbotnen has joined ##OpenGL[10:00:33] *** ol1veira_ has joined ##OpenGL[10:06:39] *** dvoid has joined ##OpenGL[10:07:00] *** Ingenu has joined ##OpenGL[10:20:33] *** johndoe has joined ##opengl[10:41:14] *** kbotnen_ has joined ##OpenGL[10:44:50] *** rnx1 has joined ##opengl[10:45:28] *** rnx has quit IRC[10:46:04] *** belou has joined ##OpenGL[10:47:17] *** belou has quit IRC[10:50:45] *** belou has joined ##OpenGL[10:51:07] *** Entelin has quit IRC[10:51:38] *** kbotnen__ has joined ##OpenGL[10:54:43] *** Entelin has joined ##OpenGL[10:59:20] *** kbotnen has quit IRC[10:59:52] *** pietia has quit IRC[11:18:00] *** kbotnen_ has quit IRC[11:30:14] *** maxton has joined ##OpenGL[11:32:45] *** eXtronuS_ has joined ##OpenGL[11:41:45] *** LtJax has joined ##opengl[11:42:09] *** kbotnen__ has quit IRC[11:50:11] *** rabbit- has joined ##OpenGL[12:03:01] <quicksilver> brief experiments yesterday found that MSAA gave much worse results than LINE_SMOOTH, on some line primitives.[12:03:06] <quicksilver> possibly not enough samples.[12:05:27] <LtJax> you might wanna do line drawing yourself via quads[12:06:27] <quicksilver> that's one of the things I'm planning to try.[12:06:56] <quicksilver> and texture mapping to "trick" mipmapping into serving as AA.[12:07:34] <LtJax> mipmapping? you mean bilinear filtering?[12:08:06] <LtJax> http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter22.html[12:10:25] *** rabbit- has quit IRC[12:15:00] *** UUncia has joined ##OpenGL[12:17:08] <quicksilver> LtJax: yes, I did mean bilinear filtering[12:17:54] <quicksilver> LtJax: *nod* I read another version of the GPU Gems article yesterday.[12:18:04] <quicksilver> I think the pre-filtering risks looking blurred.[12:18:14] <quicksilver> but if you get the amount excatly right, it can work.[12:21:26] *** nytejade has quit IRC[12:21:51] *** nytejade has joined ##OpenGL[12:26:30] *** Suprano has quit IRC[12:27:10] *** rnx1 has left ##opengl[12:27:40] *** pietia has joined ##OpenGL[12:34:57] *** johndoe has quit IRC[12:35:03] *** dvoid has quit IRC[12:41:48] *** Suprano has joined ##OpenGL[12:44:34] *** Nescafe has quit IRC[12:45:54] *** Nescafe has joined ##OpenGL[12:53:15] *** Bollinger has quit IRC[12:53:44] *** Bollinger has joined ##OpenGL[13:13:20] *** DARKGuy has joined ##OpenGL[13:16:05] <DARKGuy> Hey people, when trying to load a non-power-of-two image file, what should I do? use an extension, do some work behind-the-scenes to resize the image, or what? I'm asking because I find it useless to have a 119x29 sprite that looks -really- bad when resized, or a 640x480 splash screen that looks low-quality in 512x512, but too blurry on 1024x1024.... get the point? =/... any ideas on the topic?[13:17:28] *** UUncia has quit IRC[13:20:20] <quicksilver> DARKGuy: use TEXTURE_RECTANGLE for the splash screen, certainly.[13:20:38] <GuShH> DARKGuy : use extensions when availabe, always have a fall-back method... your resizing could just do a nearest-neighbor as not to introduce any "blurring" into the image.[13:20:52] <quicksilver> DARKGuy: for the sprite it's perhaps more complex. Do you ever display the sprite at anything but its native size?[13:20:57] <DARKGuy> quicksilver: that works for small sprites too?[13:21:24] <quicksilver> TEXTURE_RECTANGLE works for everything, but its drawback is that it doesn't support mipmapping[13:21:37] <DARKGuy> GuShH: yeah that's what I'm doing, but I find it kinda silly to have around 200-300 pixels wasted on blanks because of resizing[13:21:37] <GuShH> take a look at point sprites[13:21:47] <DARKGuy> point sprites?[13:21:52] <GuShH> nv point sprite, etc.[13:22:20] <GuShH> well instead of wasting that area pack other data inside it[13:22:20] <DARKGuy> quicksilver: Well my idea is to display them at their native size... for scaled sprites and mipmapping it won't be like that[13:22:31] <GuShH> take an atlas approach for instance.[13:22:57] <quicksilver> DARKGuy: then TEXTURE_RECTANGLE should be fine.[13:23:08] <quicksilver> Although on the other hand you probably don't want to use lots and lots of small textures.[13:23:16] <quicksilver> better to have an atlas as GuShH is suggesting.[13:23:32] <DARKGuy> well look at this GuShH: http://omploader.org/vMTVscA/tyrian.shp.000000.png <- if I resize that to 256x256, the sprites look -baaaaad-. I can't crop, because if I crop, I'm still left with a non-power-of-two image that when resized, looks bad too, and so on.[13:23:42] <DARKGuy> quicksilver: why not?[13:24:38] <GuShH> just resize the image canvas to 256x256... the little blank space is not going to kill anyone.[13:24:42] <quicksilver> or don't.[13:24:46] <quicksilver> there's no need.[13:24:47] <GuShH> in fact it allows you to add more sprites in the future.[13:24:49] <quicksilver> just use texture_rect[13:24:59] <quicksilver> which works on all graphics cards from the last 500 years, easily.[13:25:04] <DARKGuy> I can't GuShH, I'm using a spritesheet approach so for an image I can have around 30 or more 32x32 sprites like that, so the space between sprites can't be non-equal[13:25:20] <quicksilver> if you really have people using 700 year old computers, then think again.[13:26:10] <DARKGuy> hm, I guess that'd work, just as long as it works on old geforce2 cards or intel 82815E, I think it's enough xD[13:26:18] <DARKGuy> j/k :P[13:27:12] *** pietia has quit IRC[13:29:45] <GuShH> I think you should worry about other aspects of whatever it is that you're developing, this shouldn't be a concern unless you're ridicoulusly tight on RAM or for some strange reason you happen to enjoy premature optimizations.[13:31:20] <DARKGuy> Well what I'm developing is aiming for systems as low as a P3 900Mhz with an integrated graphics board with basic opengl support or a GF2/4 card, that's why I'm using a fallback method too :P[13:34:43] <GuShH> I don't think 3584 bytes ( in the case of that sprite sheet ) are of any concern, should you resize it to 256x256 (assuming 4bytes per pixel)[13:37:04] <GuShH> I'd focus in other ways of saving RAM for instance avoiding PE resources such as icons, bitmaps, etc. If I were in such a tight spot.[13:39:47] <DARKGuy> Hmmm I think you're right[13:39:49] <GuShH> DARKGuy : you don't even have to resize the images in the case of your fallback method though, padding them will suffice, you just have to avoid displaying the padded portion.[13:39:58] <DARKGuy> still, with around 128-256Mb RAM, I shouldn't have to worry right?[13:40:17] <GuShH> audio will most likely be your main concern[13:40:40] <GuShH> unless you're using trackers/midi :p[13:41:04] <DARKGuy> yeah but I'm using an algorithm that takes the image and splits it in equal parts of X pixels width & tall, so padding it makes the algorithm grab also part of the neighbour sprite :P[13:41:19] <DARKGuy> huh, really sound is that memory-consuming? =/[13:41:23] <DARKGuy> I didn't expect that[13:41:23] <GuShH> I used to play Quake3 with 128MB of ram... in fact, with less. No problem, back in the day.[13:42:07] <GuShH> Well, unless you're streaming you'd have to decompress the samples into memory first.[13:42:36] <GuShH> "all of it"... but there are some good libraries out there[13:42:46] <quicksilver> the memory saved by trimming textures is GPU ram not main ram, of course[13:42:52] <GuShH> I just don't know why you're so worried about memory footprints at this stage though[13:43:22] * quicksilver agrees with GuShH[13:43:30] <quicksilver> Premature optimisation is the root of all evil.[13:43:48] <quicksilver> However it is *easier* to use TEXTURE_RECTANGE than manually pad your 640x480 splash screen to a power of two[13:43:53] <quicksilver> that's the main reason I use it[13:43:58] <quicksilver> programmer laziness :)[13:44:01] <GuShH> I think he wants to "make things right" I've had those moments... but it just makes you waste time over nothing really.[13:45:49] <GuShH> In this case though I think padding is a better idea than resizing the entire texture, for the fallback method.[13:48:44] <DARKGuy> yeah the fallback method does the padding and/or resizes the image... doesn't look great but it works at least[13:49:07] <DARKGuy> my question was more centered to mid-high end PCs that obviously have the capability to display non-power-of-two images[13:49:32] <DARKGuy> I've read that works in other systems but I hadn't it very clear yet[13:49:56] <DARKGuy> The method is the same though? just enable the extension and load the texture as usual ?[13:50:22] *** itewsh has joined ##OpenGL[13:50:26] <LtJax> TEXRECT gives your a new target[13:50:39] <GuShH> padding does not modify the image data, it means "allocate the nearest power of two and then just display the actual size instead"[13:50:43] <LtJax> if you got the generic npot extension, you can just ignore the POT restriction[13:50:53] <GuShH> your padded data could be either rubish or 0s, depending on your malloc...[13:51:29] <LtJax> why even use malloc for that? you can allocate the "canvas" with TexImage and then load your actual data with TexSubImage[13:51:46] <LtJax> that way you don't need to do any mem management at all[13:51:55] <DARKGuy> Hmm that's a good idea[13:52:20] <DARKGuy> I had forgotten you could "paste" a texture's content over another[13:52:44] <DARKGuy> :D[13:52:46] <LtJax> you can't. but you can upload to specific regions in a texture[13:53:06] <GuShH> Because data has to come from system RAM to go into video RAM ... malloc actually stands for memory allocator and he could be allocating in any way to load from disk, I don't even know which programming language or libraries hes using so it's a little stupid to assume things, really.[13:53:42] <DARKGuy> Ah, sorry for the lack of details XD. I'm actually using C++ and SDL_Image for the texture loading (and fallback method) :P[13:53:57] <DARKGuy> However I think I got all I needed to know (for the time being ^_^)[13:55:14] *** KU0N has joined ##opengl[13:57:23] *** ghenriks has quit IRC[14:02:26] *** itewsh has quit IRC[14:05:52] *** nitrotrigger has joined ##OpenGL[14:07:16] <nitrotrigger> I can render textures with OpenGL, but not basic polygons, can anyone help me?[14:08:34] <LtJax> nope, all hope is lost[14:09:00] *** DARKGuy has quit IRC[14:20:38] <quicksilver> http://research.microsoft.com/en-us/projects/gpu_rendering_curves_and_surfaces/default.aspx[14:20:42] <quicksilver> this is quite interesting.[14:22:48] *** Ingenu_ has joined ##OpenGL[14:23:12] <nitrotrigger> is it possible to render polygons and textures in the same time?[14:23:38] <nitrotrigger> or do I need to set something like glDisable(GL_TEXTURE_2D) ?[14:27:46] *** neoneye has quit IRC[14:30:46] <ol1veira_> nitrotrigger: you render textured polygons.[14:30:49] <Ingenu_> define "rendering polygons"[14:30:57] <ol1veira_> nitrotrigger: check out the redbook[14:33:46] <exDM69> quicksilver: nice article[14:34:16] <exDM69> quite different from the stencil-buffer based method[14:34:50] <quicksilver> exDM69: yeah, I thought you'd be interested.[14:35:15] <quicksilver> exDM69: I think there is similar content in GPU Gems 3 but this particular chapter isn't online yet[14:35:15] <exDM69> quicksilver: I had an idea of doing something similar[14:35:38] <exDM69> triangulate first and use the geometry shader to subdivide the triangles[14:36:11] <quicksilver> it's nice to be subdividing in screen space[14:36:19] <quicksilver> because you can get LOD effects automatically[14:36:21] <quicksilver> (well, in a sense)[14:37:16] *** Ingenu has quit IRC[14:40:41] *** Ingenu_ is now known as Ingenu[14:42:36] *** itewsh has joined ##OpenGL[14:42:46] <nitrotrigger> I can't find a solution from the red book[14:43:12] *** kbotnen has joined ##OpenGL[14:43:16] <quicksilver> nitrotrigger: I don't think any of us understood your question.[14:43:22] <quicksilver> rendering textures *is* rendering polygons.[14:43:27] <quicksilver> that's what you map the textures onto (polygons)[14:43:33] <quicksilver> can you explain better what you actually mean?[14:44:19] <nitrotrigger> I mean[14:44:32] <nitrotrigger> I want to draw polygons without a texture[14:44:44] <nitrotrigger> but my program also draws textured polygons[14:44:44] <quicksilver> then either unbind the texture, or disable texturing[14:44:55] <nitrotrigger> what's the difference?[14:45:24] <quicksilver> not sure. I believe both work.[14:45:46] *** GX has joined ##OpenGL[14:45:53] <nitrotrigger> ok, someone told me that unbinding a texture is slower[14:45:56] <Madsy> You can't unbind a texture. You can bind a null texture though.[14:46:08] <quicksilver> yes, binding 0 is what I meant by unbinding.[14:46:10] <nitrotrigger> Madsy: gotcha[14:46:19] *** x0rx0r has joined ##OpenGL[14:47:06] <Madsy> Afaik, it's not entirely the same as disabling the target, but binding texture name zero can be faster.[14:47:32] <Madsy> Especially if you just want to void one of several texture units.[14:48:54] <Madsy> With a texture target enabled, the texture environmental stage is also enabled, no matter whether which texture name is currently bound.[14:49:52] <nitrotrigger> so unbinding is slower...?[14:49:56] <Madsy> It doesn't apply if you have overridden the environmental stages with shaders, but that's self-explainatory, since shaders don't depend on targets being enabled in the first place.[14:50:28] <nitrotrigger> well I got it to work with glDisable(GL_TEXTURE_2D)[14:50:32] <nitrotrigger> thanks anyway[14:50:49] <Madsy> nitrotrigger: Nothing to worry about really. As "they" say, pre-optimization is the root of all evil.[14:52:09] *** NevroPus has quit IRC[14:54:28] *** NevroPus has joined ##OpenGL[14:57:13] *** x0rx0r has quit IRC[14:58:25] *** x0rx0r has joined ##OpenGL[15:03:28] *** elite01 has joined ##opengl[15:18:05] *** Weiss has quit IRC[15:19:18] *** Weiss has joined ##OpenGL[15:46:22] *** eXtronuS_ has quit IRC[15:46:31] *** eXtronuS_ has joined ##OpenGL[15:49:03] *** x0rx0r has quit IRC[15:51:47] *** HuntsMan has joined ##opengl[15:54:49] *** HuntsMan has quit IRC[15:58:21] *** XT95_ has joined ##OpenGL[16:00:06] *** itewsh has quit IRC[16:00:27] *** dvoid has joined ##OpenGL[16:06:33] *** yno has joined ##OpenGL[16:06:47] <yno> hi[16:07:40] *** loonysalmon has joined ##OpenGL[16:07:42] *** loonysalmon has left ##OpenGL[16:15:32] *** loonysalmon has joined ##OpenGL[16:15:34] *** loonysalmon has left ##OpenGL[16:17:06] *** doub has joined ##opengl[16:20:50] *** djork has joined ##opengl[16:24:42] *** [AD]Turbo has quit IRC[16:24:49] *** sparky has joined ##OpenGL[16:34:43] *** Goosey has joined ##OpenGL[16:38:41] *** groton_ has joined ##OpenGL[16:41:22] *** jcazevedo has joined ##OpenGL[16:44:21] *** XT95_ has quit IRC[16:44:26] *** XT95_ has joined ##OpenGL[16:45:59] *** groton___ has joined ##OpenGL[16:48:53] *** groton has quit IRC[16:52:26] *** groton___ has quit IRC[16:52:32] *** groton has joined ##OpenGL[16:53:17] *** groton___ has joined ##OpenGL[16:54:03] *** groton_ has quit IRC[16:59:21] *** loonysalmon has joined ##OpenGL[16:59:24] *** loonysalmon has left ##OpenGL[17:03:32] *** GX has quit IRC[17:04:52] *** XT95_ has quit IRC[17:04:55] *** sohail has joined ##OpenGL[17:05:08] *** XT95_ has joined ##OpenGL[17:06:46] *** m4ggus has joined ##opengl[17:07:45] *** dennda has quit IRC[17:07:48] *** dennda has joined ##opengl[17:08:52] *** geocalc has quit IRC[17:09:36] *** geocalc has joined ##opengl[17:11:00] *** Yustme has joined ##OpenGL[17:11:21] *** groton has quit IRC[17:19:39] *** HuntsMan has joined ##opengl[17:24:22] *** jfroy has quit IRC[17:24:36] *** kenws has quit IRC[17:25:24] *** vade has joined ##OpenGL[17:41:06] *** geocalc has quit IRC[17:41:41] *** geocalc has joined ##opengl[17:42:22] *** holigen has left ##OpenGL[17:42:36] *** zommi has quit IRC[17:49:43] *** NevroPus has quit IRC[17:53:28] *** Goosey has left ##OpenGL[17:57:06] *** jfroy|work has joined ##OpenGL[18:12:10] *** XT95_ has quit IRC[18:19:18] *** replaced has quit IRC[18:23:55] *** GinoMan has quit IRC[18:24:02] *** jcazevedo has quit IRC[18:24:47] *** XT95_ has joined ##OpenGL[18:29:29] *** GinoMan has joined ##OpenGL[18:30:26] *** XT95__ has joined ##OpenGL[18:36:10] *** XT95_ has quit IRC[18:39:01] *** m4ggus has quit IRC[18:39:36] *** doub has quit IRC[18:40:24] *** JernejL has joined ##OpenGL[18:49:19] *** XT95___ has joined ##OpenGL[18:51:45] *** ljungk has joined ##OpenGL[18:52:46] *** ljungk has quit IRC[18:52:55] *** ljungk has joined ##OpenGL[18:53:56] *** groton___ has quit IRC[18:53:58] *** GinoMan has quit IRC[18:54:04] *** GinoMan has joined ##OpenGL[18:59:40] *** elite01_ has joined ##opengl[18:59:55] *** elite01 has quit IRC[19:03:30] *** xkpe has joined ##OpenGL[19:05:06] <xkpe> hello[19:06:12] <xkpe> are maximun dimentions for the dimensions of a texture?[19:06:15] *** XT95__ has quit IRC[19:06:58] <tmccrary1> xkpe: query for it with glGet[19:06:58] <HuntsMan> ah?[19:07:58] <xkpe> i found GL_MAX_TEXTURE_SIZE but not for width or heiht[19:08:16] <HuntsMan> width = height = GL_MAX_TEXTURE_SIZE[19:08:31] <xkpe> oh thanks[19:10:57] *** ljungk has quit IRC[19:13:42] *** johndoe has joined ##opengl[19:17:09] *** Kasu has joined ##OpenGL[19:20:02] *** eXtronuS_ has left ##OpenGL[19:24:12] <Madsy> Or use the proxy target.[19:26:36] *** georgia72 has joined ##OpenGL[19:27:25] *** mmmmmmm has joined ##opengl[19:27:31] *** mmmmmmm is now known as mmmmmmm|away[19:30:16] *** predaeus has quit IRC[19:33:04] *** Walt has joined ##opengl[19:34:25] *** Walt has quit IRC[19:35:02] *** Walt has joined ##opengl[19:37:24] *** basy has joined ##OpenGL[19:38:16] *** bubu` has quit IRC[19:38:20] *** belou has quit IRC[19:38:57] *** bubu` has joined ##OpenGL[19:42:05] <basy> Hi, im looking for OpenGL forum with good support...[19:42:25] <Madsy> opengl.org[19:42:54] <basy> there is no forum[19:42:59] *** mm765^sleep is now known as mm765[19:43:58] <HuntsMan> yes, there is[19:44:21] <HuntsMan> http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=cfrm[19:44:37] <basy> thank you[19:46:05] *** gusnan has joined ##OpenGL[19:46:42] *** mmmmmmm|away has quit IRC[19:47:00] *** Nescafe has quit IRC[19:50:41] *** Walt has quit IRC[19:53:13] *** walt has joined ##OpenGL[19:54:40] <xkpe> glGetIntegerv(GL_MAX_LIGHTS, &FMaxLights);[19:54:41] *** XT95___ has quit IRC[19:54:42] *** XT95__ has joined ##OpenGL[19:54:52] <xkpe> is setting the variable to 1[19:56:00] <ville> and the type of FMaxLights is?[19:56:02] <xkpe> how is this possible?[19:56:10] <xkpe> int[19:57:41] <yno> does your gl context is activated before this call?[19:59:53] <xkpe> its returning 8 now, that could be it[20:00:01] <xkpe> im gonna make sure it is[20:04:09] *** Sos has joined ##opengl[20:05:28] *** GX has joined ##OpenGL[20:05:33] *** bijoo_osdev has joined ##opengl[20:05:34] *** bijoo_appdev has joined ##OpenGL[20:08:42] *** groton has joined ##OpenGL[20:08:51] <xkpe> how can i know if opengl supports non power of two textures?[20:10:48] <HuntsMan> if it's version 2.0 or the GL_ARB_texture_non_power_two extension is supported[20:11:17] <xkpe> thank you i couldnt find the extention name[20:12:04] *** pietia has joined ##OpenGL[20:22:40] <xkpe> the max dimensions for a fbo is the same as a texture?[20:23:52] <xkpe> nvm found MAX_RENDERBUFFER_SIZE_EXT[20:27:05] *** JernejL has quit IRC[20:27:40] <HuntsMan> that's for a renderbuffer[20:27:51] <HuntsMan> maximum texture sizes apply for attachments to textures[20:29:06] <xkpe> ok, so i have to take both in consideration right?[20:29:15] <xkpe> im using them to render and then usem them as texture[20:29:50] *** JernejL has joined ##OpenGL[20:30:08] <HuntsMan> unless you are creating extremely big FBOs, yes[20:35:51] *** gusnan has quit IRC[20:36:53] *** Jernej has joined ##OpenGL[20:38:18] *** Jernej has quit IRC[20:38:27] *** Jernej has joined ##OpenGL[20:40:03] *** eXtronuS_ has joined ##OpenGL[20:43:20] *** NevroPus has joined ##OpenGL[20:45:33] *** elite01 has joined ##opengl[20:47:23] *** elite01_ has quit IRC[20:51:31] *** basy has quit IRC[20:54:47] *** JernejL has quit IRC[21:05:36] *** xkpe has quit IRC[21:08:46] *** Spkka has joined ##OpenGL[21:15:29] *** ol1veira_ has quit IRC[21:17:01] *** jcazevedo has joined ##OpenGL[21:18:46] *** Kasu has quit IRC[21:22:17] *** Suprano has quit IRC[21:36:44] *** qeed has joined ##opengl[21:44:12] *** Codex_ has joined ##OpenGL[21:45:11] <Codex_> I wrote some blobs and it has bad looking drawing error? Is that caused by zbuffering or something: http://www.kotiposti.net/terop/blob.png :)[21:46:34] *** mm765 is now known as mm765^away[21:48:25] *** vampirefrog has joined ##OpenGL[21:48:45] *** vampirefrog has quit IRC[21:49:38] *** vampirefrog has joined ##OpenGL[21:49:41] *** tamlin has joined ##OpenGL[21:49:44] *** GX has quit IRC[22:09:44] *** XT95___ has joined ##OpenGL[22:09:50] *** |t4bz| has quit IRC[22:10:28] *** |t4bz| has joined ##OpenGL[22:11:02] *** deXM96 has quit IRC[22:12:19] *** tamlin has quit IRC[22:16:14] *** vampirefrog has quit IRC[22:18:46] *** b0000 has joined ##opengl[22:25:53] *** XT95__ has quit IRC[22:29:28] *** Quentarez has quit IRC[22:29:40] *** Quentarez has joined ##OpenGL[22:31:11] *** scai has left ##opengl[22:32:16] *** Nescafe has joined ##OpenGL[22:32:42] *** Suprano has joined ##OpenGL[22:32:50] *** Codex_ has left ##OpenGL[22:34:58] *** Yustme has quit IRC[22:44:39] *** eXtronuS_ has quit IRC[22:45:41] *** eXtronuS_ has joined ##OpenGL[22:47:56] *** HuntsMan has quit IRC[22:58:21] *** Sos has quit IRC[23:00:34] *** stevosICBM has joined ##OpenGL[23:03:54] *** nitrotrigger has quit IRC[23:07:07] *** groton has quit IRC[23:13:23] *** amz has joined ##opengl[23:16:28] *** reprore_ has joined ##OpenGL[23:17:55] *** xew has joined ##OpenGL[23:26:39] *** Bollinger has quit IRC[23:29:35] *** paul424 has joined ##OpenGL[23:31:35] <paul424> anyone here knock .... knock .......[23:32:37] <paul424> I recently think about some extension to my project of simple 3d lod algorithm ...........I think about adding some lights + something which would look like the sun[23:34:42] *** Ingenu_ has joined ##OpenGL[23:44:00] *** korff_home has quit IRC[23:47:58] *** elite01 has quit IRC[23:48:01] *** georgia72 has quit IRC[23:50:46] *** elite01 has joined ##opengl[23:54:32] *** Ingenu has quit IRC[23:54:33] *** Ingenu_ is now known as Ingenu[23:57:43] *** forrestv has quit IRC[23:58:33] *** forrestv has joined ##OpenGL