January 12, 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 12, 2009 [00:00:18] *** cplusplus2 has joined ##OpenGL[00:03:13] *** HuntsMan has quit IRC[00:11:56] <emzic> thanks for the link, tmccrary[00:12:14] <emzic> i occasionally work on linux as well, but currently i am on windows[00:13:14] <emzic> but how do Bugle and gDebugger get the list of states? i guess they have it hardcoded?[00:15:18] <RTFM_FTW> you can query state[00:15:40] <RTFM_FTW> this can be done with the appropriate enum using glGet*[00:17:55] *** scai has left ##opengl[00:17:56] *** cplusplus3 has quit IRC[00:22:02] <tmccrary> emzic: My understanding is bugle interacts with the display server at a low level, which is probably what glIntercept does (based on the name anyway)[00:27:19] *** sparky_ has joined ##OpenGL[00:29:37] *** Amorphous has quit IRC[00:30:57] *** iion has joined ##OpenGL[00:31:05] *** AlastairLynn has joined ##opengl[00:31:26] *** iion has quit IRC[00:31:43] *** iion has joined ##OpenGL[00:31:50] <RTFM_FTW> well many profilers (at least the ones with support from the IHVs) will have dedicated hooks into the underlying GL driver for this[00:32:11] <RTFM_FTW> since that is significantly more flexible[00:33:08] <AlastairLynn> are the glu functions typically implemented entirely 'on top' of the gl functions? (i'm guessing yes but thought i ought to check)[00:33:27] <tmccrary> yeah[00:33:29] <GuShH> Yes[00:33:38] <tmccrary> They're just a bunch of utilities... hence GL "U"[00:33:43] <AlastairLynn> that's what i thought[00:33:51] <AlastairLynn> okay, thanks chaps[00:39:01] *** sparky has quit IRC[00:41:09] *** mm765 is now known as mm765^sleep[00:44:12] *** LtJax has quit IRC[00:46:37] *** Amorphous has joined ##opengl[00:55:37] *** NoLimitz has joined ##OpenGL[00:55:40] <NoLimitz> hey guys[00:56:47] <AlastairLynn> hai~~[00:57:20] <NoLimitz> i got a question i would like to ask[00:57:42] <NoLimitz> is there any 3d scene creator that can export a scene as opengl code[00:58:09] <AlastairLynn> not as far as i know, but that would be a bad idea anyway[00:58:10] <NoLimitz> i have this assignment and i need to create a whole 3d scene, and it would be nice if i could find one...:)[00:58:18] <NoLimitz> erm, why?[00:58:24] <MatthiasM> NoLimitz: read your scene from a data file[00:58:29] <NoLimitz> it would really shorten development time[00:58:31] <MatthiasM> data != code[00:58:32] <AlastairLynn> what MatthiasM said[00:59:16] <MatthiasM> NoLimitz: Wavefront/OBJ is easy to parse and can be imported and exported by nearly every tool - including Blender[00:59:31] <NoLimitz> ok...i'ma look into it on google[00:59:35] <AlastairLynn> yes indeed[01:00:22] *** b1010 has joined ##opengl[01:00:40] <NoLimitz> ideea is i'm looking for a simple tool which would export a static scene to opengl functions and stuff...that would be lovely :)[01:01:59] <MatthiasM> NoLimitz: don't do that[01:02:07] <rnx> there are some hackish .obj to opengl/C code converters floating around[01:02:13] *** beachsurfin has joined ##OpenGL[01:02:29] <beachsurfin> is opengl used primarily for animation? what other uses does it have?[01:02:35] <NoLimitz> rnx, thanks, good advice :)[01:03:15] <beachsurfin> what is opengl written in?[01:03:24] <MatthiasM> NoLimitz: again - 3d models/scenes are vdata - put them in a file or at most into a constant array and use code to render this data[01:03:33] <MatthiasM> beachsurfin: black magic[01:03:48] <beachsurfin> what cad prorams use it?[01:04:06] <MatthiasM> beachsurfin: wikipedia www.opengl.org[01:04:11] <NoLimitz> MatthiasM, so basically, i need to create a parser for this "file", right?[01:04:18] <MatthiasM> yes[01:04:31] *** k_t has left ##OpenGL[01:04:50] *** uster has joined ##OpenGL[01:04:50] <emzic> NoLimitz, chances are high, that an obj-loader/exporter for your language of choice already exists[01:05:11] <beachsurfin> oh, it's its own language[01:05:33] <NoLimitz> ok thanks alot emzic[01:05:41] <AlastairLynn> we don't do homework[01:05:53] <AlastairLynn> you have the internet available[01:05:54] <AlastairLynn> use it[01:06:35] *** macrocat has joined ##opengl[01:07:03] *** Kasu has quit IRC[01:08:21] <NoLimitz> AlastairLynn, i won't ask you to do homework for me...i'm just asking so i can do a little research[01:08:28] <NoLimitz> and then do my homework by myself[01:08:44] <AlastairLynn> i was actually addressing that tirade at beachsurfin my dear chap[01:08:52] <AlastairLynn> :)[01:09:07] <NoLimitz> well..ok[01:09:11] <beachsurfin> AlastairLynn: not homework, just curiosity[01:09:33] <beachsurfin> but i suppose that was you speaking theoretically[01:10:06] <AlastairLynn> i guess i jump to conclusions quickly[01:10:17] <AlastairLynn> they looked like homework assignment questions :)[01:11:19] *** Kasu has joined ##OpenGL[01:11:21] <AlastairLynn> opengl is used for all forms of 2D and 3D graphics rendering, it can be also be used for GPGPU although that's a bit of a hack, the language for the driver can be anything but that's irrelevant because all you see is the C API, and I believe AutoCAD uses OpenGL[01:11:27] <AlastairLynn> and OpenGL is not its own language, but it does contain a language for writing shaders called "GLSL"[01:13:21] <NoLimitz> hmm, that's funny, isn't Y the usual vertical axis?[01:14:46] *** pietia has quit IRC[01:15:22] *** neoneye has quit IRC[01:15:34] <meg> no[01:15:59] *** b0000 has quit IRC[01:22:45] *** mmmmmmm has joined ##opengl[01:25:27] <tmccrary> In opengl, yes[01:25:56] <tmccrary> some 3d apps use Z up, normals are usually defined in a Z up coordinate space[01:26:06] <tmccrary> normals in normal maps rather[01:26:16] <tmccrary> and anything to do with tangent space,[01:29:05] *** sparky has joined ##OpenGL[01:29:47] <NoLimitz> anyway, is libobj reliable to parse theese .obj files[01:30:00] <NoLimitz> ?[01:33:55] *** cplusplus has joined ##OpenGL[01:34:43] *** emzic has quit IRC[01:36:31] *** iammisc has quit IRC[01:37:30] *** HuntsMan has joined ##opengl[01:39:51] <NoLimitz> erm...can anybody name a free obj to c++ parser, i seem unable to find one :([01:39:58] <NoLimitz> (oh, for windows)[01:40:13] <MatthiasM> NoLimitz: write one[01:40:32] <NoLimitz> wow, would take alot of time :([01:40:44] <NoLimitz> ok, just one more question..., and sorry for wasting your time[01:41:16] <NoLimitz> i would like to have some HUD for my program...from what i understood, the only way of having such a thing[01:41:27] <NoLimitz> is drawing an object right in front of the camera[01:41:45] <MatthiasM> no - switch to ortho mode[01:42:29] <MatthiasM> eg - setup perspective, enable depth test/write, render 3d, switch to ortho, disable depth test/write, render HUD, repeat[01:43:21] *** mmmmmmm has quit IRC[01:44:12] <NoLimitz> wow thanks...i will seek a tutorial on that...[01:45:16] *** calav3ra has quit IRC[01:45:50] *** NoLimitz has quit IRC[01:46:40] *** sparky_ has quit IRC[01:48:25] *** twist__ has quit IRC[01:50:36] *** cplusplus2 has quit IRC[01:52:34] *** korff_home has quit IRC[01:54:01] *** msh07 has joined ##OpenGL[01:54:47] *** b1010 has quit IRC[01:56:10] *** johndoe has quit IRC[01:58:24] *** cplusplus has quit IRC[01:58:39] *** Nolimitz has joined ##OpenGL[01:59:34] *** cplusplus has joined ##OpenGL[01:59:36] <meg> anybody home?[02:01:22] <rnx> depends[02:01:39] *** greg101 has joined ##OpenGL[02:03:03] *** Xmas| has quit IRC[02:04:33] *** forrest`` has joined ##OpenGL[02:05:03] *** Nolimitz has quit IRC[02:05:34] *** meg has quit IRC[02:05:34] *** Walt has quit IRC[02:05:35] *** LordMetroid has quit IRC[02:05:35] *** troyyan has quit IRC[02:05:35] *** PluribusIMP has quit IRC[02:05:35] *** fftb has quit IRC[02:05:35] *** mattn2|home has quit IRC[02:05:35] *** GinoMan has quit IRC[02:05:35] *** MatthiasM has quit IRC[02:05:35] *** maxton has quit IRC[02:05:35] *** dv_ has quit IRC[02:05:35] *** hibread has quit IRC[02:05:35] *** exDM69 has quit IRC[02:05:36] *** Xantoz has quit IRC[02:05:36] *** Stevethe1irate has quit IRC[02:05:36] *** Icchan^ has quit IRC[02:05:36] *** quicksilver has quit IRC[02:05:36] *** memfr0b has quit IRC[02:05:36] *** Mazon has quit IRC[02:05:36] *** RTFM_FTW has quit IRC[02:05:36] *** aep has quit IRC[02:06:04] *** meg has joined ##OpenGL[02:06:04] *** Walt has joined ##OpenGL[02:06:04] *** troyyan has joined ##OpenGL[02:06:04] *** LordMetroid has joined ##OpenGL[02:06:04] *** PluribusIMP has joined ##OpenGL[02:06:04] *** fftb has joined ##OpenGL[02:06:04] *** hibread has joined ##OpenGL[02:06:04] *** mattn2|home has joined ##OpenGL[02:06:04] *** GinoMan has joined ##OpenGL[02:06:04] *** MatthiasM has joined ##OpenGL[02:06:04] *** maxton has joined ##OpenGL[02:06:04] *** dv_ has joined ##OpenGL[02:06:04] *** RTFM_FTW has joined ##OpenGL[02:06:04] *** Xantoz has joined ##OpenGL[02:06:04] *** Stevethe1irate has joined ##OpenGL[02:06:04] *** aep has joined ##OpenGL[02:06:04] *** Icchan^ has joined ##OpenGL[02:06:04] *** exDM69 has joined ##OpenGL[02:06:04] *** Mazon has joined ##OpenGL[02:06:04] *** quicksilver has joined ##OpenGL[02:06:04] *** memfr0b has joined ##OpenGL[02:06:08] *** hibread has quit IRC[02:06:11] *** hibread_ has joined ##opengl[02:08:53] *** greg_ has quit IRC[02:09:06] *** RTFM_FTW has left ##OpenGL[02:10:07] *** RTFM_FTW has joined ##OpenGL[02:11:51] *** AlastairLynn has quit IRC[02:12:00] *** msh07 has quit IRC[02:12:23] *** forrestv has quit IRC[02:18:13] *** Walt has quit IRC[02:18:29] *** synchris has quit IRC[02:18:43] *** synchris has joined ##opengl[02:18:55] *** `Wil has joined ##OpenGL[02:19:23] *** meg has quit IRC[02:23:48] *** NoLimitz has joined ##OpenGL[02:24:13] *** NotWil has quit IRC[02:24:48] *** dizekat has quit IRC[02:24:52] *** forrest`` has quit IRC[02:39:05] *** forrest`` has joined ##OpenGL[02:39:27] *** vade has quit IRC[02:40:45] *** vade has joined ##OpenGL[02:40:52] *** dv_ has quit IRC[02:43:14] *** tmccrary has quit IRC[02:45:29] *** fftb_ has joined ##OpenGL[02:47:30] *** dvoid_ has quit IRC[02:47:56] *** sparky_ has joined ##OpenGL[02:48:30] *** vade has quit IRC[02:50:53] *** Suprano has quit IRC[02:54:32] *** GinoMan has left ##OpenGL[02:55:51] *** oliveira1 has quit IRC[02:56:32] *** fftb has quit IRC[02:57:19] *** sparky has quit IRC[03:00:27] *** jfroy has joined ##OpenGL[03:02:55] *** Spkka has quit IRC[03:08:02] *** fftb_ has quit IRC[03:09:15] *** phrosty has joined ##opengl[03:09:17] *** cplusplus2 has joined ##OpenGL[03:09:34] *** cplusplus has quit IRC[03:22:08] *** PsiOmega has joined ##OpenGL[03:24:46] *** Kyuuketsuki has joined ##opengl[03:29:52] *** cplusplus2 has quit IRC[03:31:56] *** porridj has joined ##OpenGL[03:33:01] <porridj> hello... is there a method I can use to tint "everything i'm about to draw", which may include textured and non-textured geometry as well as geometry with or without vertex colors?[03:34:08] *** qeed has quit IRC[03:34:21] <porridj> say i have a model with a white texture and vertex colors that are all yellow, i'd like to be able to set a red tint and have the model render solid red, or a blue tint and have the model render as solid black[03:35:42] <Kyuuketsuki> Hokay. So. This is a bit difficult for me to explain, so I'm posting my full source for inspection: http://tinyurl.com/8lrb32 I am doing my best to port the camera example from NeHe's site (specific example seen at http://tinyurl.com/76hfqy) to use SDL so that I may use it on linux and macosx, and I figured that a good stepping stone would be to test the SDL on windows. I'm hitting a number of snags that I can't easily explain. Someti[03:35:52] <Kyuuketsuki> and when I zoom out (when it doesn't go black) I can see the terrain, but for whatever reason, it almost appears to be cropped. Any insight on the reason this is would be appreciated.[03:36:13] *** MatthiasM has quit IRC[03:36:20] *** MatthiasM has joined ##opengl[03:37:46] <Kyuuketsuki> wish I could just be more verbose on the problem, but frankly, I can't understand it in my head, let alone put it into concise words, so tell me if you need more info...[03:37:59] *** iion has quit IRC[03:38:11] *** NoLimitz has quit IRC[03:40:34] *** fusi has joined ##OpenGL[03:40:39] <porridj> Kyuuketsuki, is clipping of the scene the only problem you're seeing?[03:41:03] <porridj> Kyuuketsuki, if so, have you tried increasing your far plane distance?[03:41:17] <Kyuuketsuki> well, that's happening, i believe. it almost appears to be clipping the depth in respect to my camera[03:41:26] * Kyuuketsuki checks google[03:41:43] <porridj> Kyuuketsuki, are you calling glFrustum?[03:42:05] <Kyuuketsuki> i don't think so, let me search the project[03:42:19] <Kyuuketsuki> no[03:42:39] <rnx> be aware that the linux port of the tutorial there uses glut and likely works fine on all systems[03:43:18] <Kyuuketsuki> yeah, but I wrote half my code to work with SDL, and then this come along, which I need[03:43:41] <porridj> Kyuuketsuki, maybe you're using gluPerspective?[03:43:42] <Kyuuketsuki> i'm not certain, but I would have to guess that GLUT and SDL don't play nice[03:44:22] <Kyuuketsuki> porridj: only in the init code. would that do it?[03:45:55] <porridj> Kyuuketsuki, there's always a maximum depth in your scene, given that everything needs to convert to values in your depth buffer in the end. glFrustum and gluPerspective both take a "zFar" parameter to specify this maximum depth. try increasing it (say, to double) and see if that affects your problem[03:46:33] <porridj> Kyuuketsuki, on the other hand, the greater the difference between zNear and zFar, the less precision you have in your depth buffer... if you go too extreme, you'll get weird z-fighting problems[03:47:24] <Kyuuketsuki> oh man, that worked[03:47:31] <Kyuuketsuki> but it's uh[03:47:34] <Kyuuketsuki> a bit wierd[03:48:07] <Kyuuketsuki> see, I increased it from 100.0f, which NeHe uses, to a whooping 2000.0f and it's rendering less of the plane than the original code[03:49:31] <Kyuuketsuki> woo, i should read this a little more, i think that perhaps the height map is causing me grief as well[03:49:48] <Kyuuketsuki> there's a few sudden drops into oblivion[03:50:04] <porridj> Kyuuketsuki, i'd try reading the section on projection transforms here: http://www.glprogramming.com/red/chapter03.html#name3[03:50:21] <Kyuuketsuki> thanks, porridj[03:50:25] <porridj> np[04:02:00] *** LordMetroid has quit IRC[04:02:11] *** jfroy has quit IRC[04:08:00] *** JohnnyL has joined ##OpenGL[04:08:05] *** porridj has quit IRC[04:08:17] *** reprore_ has joined ##OpenGL[04:23:23] *** fusi has quit IRC[04:29:35] *** HuntsMan has quit IRC[04:40:44] *** threedee has joined ##OpenGL[04:41:30] *** Kyuuketsuki has quit IRC[04:42:14] <threedee> On Ubuntu, I type "apt-get install <what>" to get the EXT_texture_cube_map OpenGL extension? Thank you.[04:43:12] <RTFM_FTW> umm EXT_texture_cube_map is a OpenGL extension... as such it will be built into the underlying driver (assuming its supported)[04:43:28] <RTFM_FTW> so technically there is nothing to get[04:43:36] <threedee> OK[04:43:47] <threedee> I'm more lost that I thought then[04:44:15] <threedee> I was trying out a cubemap tutorial[04:45:43] *** macrocat has quit IRC[04:51:36] *** Aintaer has quit IRC[04:54:31] *** Kasu has quit IRC[04:59:43] *** servus_ has quit IRC[04:59:47] *** Aintaer has joined ##OpenGL[05:00:47] *** JohnnyL has quit IRC[05:03:08] *** mattn2|home has quit IRC[05:03:24] *** mattn2|home_ has joined ##OpenGL[05:09:36] *** forrest`` is now known as forrestv[05:14:12] *** NoLimitz has joined ##OpenGL[05:14:23] <NoLimitz> hey guys, i ran into another problem[05:14:39] <NoLimitz> i set the min clipping distance to 0, and everything blinks[05:14:45] <NoLimitz> and nothing displays correctly :([05:16:39] <rnx> rtfm: zNear must never be set to 0.[05:17:31] <NoLimitz> well, i don't know what to do[05:17:44] <NoLimitz> i mean, i want a very small clipping distance, as close to 0 as possible[05:17:50] <NoLimitz> 0.01f would do[05:17:59] *** servus_ has joined ##opengl[05:18:10] <rnx> i recommend you learn what a zbuffer is and how it works[05:18:21] <NoLimitz> ok[05:19:05] <NoLimitz> but even then, some quads are still clipped, even though they are at a distance of at least 2 or 3 units[05:20:08] *** greg101 has quit IRC[05:49:11] *** rutski has joined ##OpenGL[05:51:26] *** reprore_ has quit IRC[05:53:12] *** dag_ has joined ##OpenGL[05:59:54] *** msh07 has joined ##OpenGL[06:05:34] <dag_> Hi guys. I'm taking my first baby steps with ogl, and I've run into a problem with texturing. I think I've taken all necessary steps, but still I wind up with a big white quad. Could someone take a look at this code: http://cpp.ninjacodemonkeys.org/5017 ?[06:06:45] <RTFM_FTW> set your GL_MIN_FILTER, GL_MAG_FILTER to GL_NEAREST or GL_LINEAR respectively[06:06:56] *** rnx has left ##opengl[06:07:09] <RTFM_FTW> as mip-maps for 2D targets are enabled implicitly and you aren't generating any here[06:07:53] <RTFM_FTW> you can do that through glTexParameteri[06:08:03] <RTFM_FTW> man glTexParameter will tell you more[06:09:36] <dag_> Thanks, I tried that, but no luck. I probably should have posted my setup code as well. :o[06:10:06] *** beachsurfin has quit IRC[06:10:11] <RTFM_FTW> also verify that your GL_MODELVIEW, GL_PERSPECTIVE matrices are correct[06:10:32] <RTFM_FTW> and verify that your coordinates (i.e. vertex, texcoord, ...) are reasonably sane as well[06:11:18] <RTFM_FTW> furthermore it would be wise to look at GL_TEXTURE_WRAP_S, GL_TEXTURE_WRAP_T as well (which can also be set via glTexParameteri) to make sure that the defaults (i.e. GL_REPEAT) work for you[06:13:06] <RTFM_FTW> also verify that the texture in question is a power of two (concerning width, height and depth)[06:13:08] *** rutski has quit IRC[06:13:19] <RTFM_FTW> unless you have support for ARB_texture_non_power_of_two[06:14:30] <RTFM_FTW> and *if* you are targeting an embedded platform (i.e. GL | ES ) then stop using immediate mode OpenGL calls to draw your primitives[06:16:00] <dag_> Yup, it all seems good. I'm simply trying to get a texture onto a terrain-mesh, but wind up getting it solid white. Texture is 512x512, everything renders as intended (minus textures of course)[06:16:43] <RTFM_FTW> well your issue is undoubtedly something mentioned above[06:17:00] <RTFM_FTW> so go through your code and verify every thing I've listed thus far[06:17:28] *** eXtronuS_ has joined ##OpenGL[06:17:29] <dag_> Will do, and call back later. =)[06:23:33] *** NotWil has joined ##OpenGL[06:24:37] *** Rolenun has quit IRC[06:34:11] *** amz has quit IRC[06:34:53] *** elite01 has joined ##opengl[06:42:05] *** `Wil has quit IRC[06:59:07] *** elite01 has quit IRC[07:05:48] *** mikolalysenko has quit IRC[07:10:20] <NoLimitz> erm guys[07:10:34] <NoLimitz> is there any way i can let opengl auto-map a texture to a quad?[07:20:46] *** msh07 has quit IRC[07:24:18] <dag_> I'm back, and I've checked all the above mentioned. I'm not really sure what to look for but it all seems good to me.[07:25:18] <dag_> Filters: min, mag -> nearest, linear. Texcoords: in range (0, 0.5).[07:30:29] *** MatthiasM has quit IRC[07:30:36] *** MatthiasM has joined ##opengl[07:39:34] <dag_> RTFM_FTW: Seems you're gone, and so will I be in a second. Just want to thank you for your answers.[07:39:43] *** dag_ has quit IRC[07:42:05] *** neoneye has joined ##OpenGL[07:43:02] *** ata2 has joined ##OpenGL[07:45:14] <ata2> Hello everybody, suppose that you have to draw 3 overlapped (like in the clubs cards) GLU disks on the plane with the condition that these disks have to be transparent. If I draw them directly using alpha-blending in the overlapped areas you would see a darker color. Can you suggest a way in which I can force the renderer NOT to draw twice in the same area?[07:46:40] <MatthiasM> ata2: don't use gluDisk - use your own geometry[07:47:45] <ata2> it's not that I have to render a club[07:47:52] <ata2> I have to render a transparent point cloud[07:48:04] <ata2> where disk substitute geometry because they have position and orientation[07:48:12] <MatthiasM> try stencil[07:49:42] *** korff_home has joined ##OpenGL[07:50:58] *** vade has joined ##OpenGL[07:52:11] <Jupp3> ata2: You can use GL_POINTS too[07:52:30] <Jupp3> For which you can also set the size[07:52:40] <Jupp3> Which you can't do without stopping rendering[07:53:03] <MatthiasM> vertex shader[07:53:11] <MatthiasM> and ARB_point_sprite[07:53:19] <Jupp3> And as you use gluDisk, I assume you use direct mode in other places, which means you would need to glEnd() which is a heavy operation[07:53:30] <ata2> oh don't worry[07:53:35] <ata2> I am just preparing figures[07:53:36] *** NoLimitz has quit IRC[07:53:39] <MatthiasM> gluDisk itself will call glBegin()/glEnd()[07:53:42] <ata2> so It can be as slow as it wants[07:53:42] <Jupp3> MatthiasM: That seems rather heavy for someone still using glu geometry functions...[07:53:56] <Jupp3> MatthiasM: I know that[07:54:24] <Jupp3> ata2: Well, do it all in software then :)[07:54:51] <ata2> right...[07:56:00] <Jupp3> That way you can get as high quality as you want[07:56:08] <Jupp3> AND similar results on ANY hardware[07:58:22] *** NoLimitz has joined ##OpenGL[07:58:24] <NoLimitz> hey guys[07:58:30] <NoLimitz> ran into another weird problem[07:58:46] <NoLimitz> how many textures can opengl load at a time?[07:59:20] <Jupp3> unsigned int 0 -1?[07:59:23] <Jupp3> theoretically[07:59:32] <Jupp3> That's the OpenGL limit I guess[07:59:43] <NoLimitz> so that's 2 textures?[07:59:58] <Jupp3> Of course your hardware, OpenGL implementation can make additional restrictions[08:00:02] <Jupp3> But we won't start guessing that[08:00:14] <Jupp3> NoLimitz: You have pretty low unsigned int size then :P[08:00:25] <NoLimitz> hmm[08:00:32] <NoLimitz> i know unsigned int goes to like, 64k[08:00:41] <Jupp3> NoLimitz: What I meant is, "maximum value unsigned int can display"[08:00:53] <Jupp3> Well I guess it's 32bit one too[08:01:02] <Jupp3> NoLimitz: But yes, I guess that's the OpenGL limit[08:01:36] <Jupp3> Which is the only limit worth discussing with such minimal information anyway[08:01:37] <NoLimitz> well, ok, then i will investigate into the problem...for some weird reason, after i load 2 textures...when i load the third, the second is deleted[08:01:53] <Jupp3> Do you create new one before that?[08:02:06] <Jupp3> And what you mean with "is deleted" anyway...[08:02:42] <NoLimitz> well[08:02:45] <Jupp3> "3rd one is loaded to same ID as 2nd one" or?[08:02:54] <Jupp3> Do you bind the 3rd texture before loading it?[08:02:55] <NoLimitz> erm, don't think so[08:03:18] <Jupp3> Or do you give it texture ID that's different from the second one?[08:03:24] <NoLimitz> well[08:03:39] <NoLimitz> glGenTextures(1, &textureId); shouldnt this do the trick?[08:03:52] <Jupp3> Yes, that creates one[08:04:03] <Jupp3> Then you bind it, and upload the texture[08:04:11] <NoLimitz> i do[08:04:24] <NoLimitz> for 2 textures, it works perfectly, but when i load the third[08:04:29] <NoLimitz> the second won't display[08:04:32] <NoLimitz> all of the suddent[08:04:34] <NoLimitz> sudden*[08:05:04] <NoLimitz> i have double checked the code and it seems correct[08:05:23] <Jupp3> I wonder how you are using it... Probably that textureId is some temp value, that you asign to the more descriptive variable?[08:05:38] <NoLimitz> yes[08:05:55] <Jupp3> And you do check for errors with glGetError()?[08:06:02] <NoLimitz> erm, no[08:06:15] <NoLimitz> would it be better if i just created a global int variable[08:06:21] <NoLimitz> which i used as a counter?[08:06:27] <Jupp3> for what?[08:06:32] <NoLimitz> and each time i load the texture, i increment the counter[08:06:34] <Jupp3> manually giving texture id's?[08:06:38] <NoLimitz> yes[08:06:41] <NoLimitz> is it bad?[08:06:50] <Jupp3> Well of course that's perfectly acceptable way to do it[08:07:00] <Jupp3> But glGenTextures should work anyway[08:07:06] <NoLimitz> as long as it works with opengl, it's ok[08:07:07] <NoLimitz> well[08:07:19] <Jupp3> Try printing it each time you generate one to make sure you get different ones[08:07:23] <Jupp3> Which you should, unless there's some error[08:07:41] <NoLimitz> ok[08:07:46] <NoLimitz> 2 seconds let me check something[08:07:58] <Jupp3> What I meant to say, it's highly unlikely your problem was becouse of glGenTextures()[08:08:20] <Jupp3> Only reason it could affect, as I see it, is if you accidentally deleted the 2nd texture somewhere[08:08:55] <NoLimitz> glGetError doesn't return anything...[08:09:11] <NoLimitz> print*[08:09:34] <Jupp3> print?[08:09:41] <Jupp3> return or print?[08:09:50] <Jupp3> It most definitely shouldn't print anything, ever[08:10:06] <NoLimitz> my bad[08:10:13] <NoLimitz> it prints 0[08:10:18] <Jupp3> no it doesn't[08:10:24] <NoLimitz> so everything is all right[08:10:36] <Jupp3> it returns GL_NO_ERROR(==0) or some error value[08:10:48] <Jupp3> WHICH you can print, but it most definitely won't print it for you[08:10:54] <NoLimitz> i know[08:11:00] <NoLimitz> found out by myself[08:11:12] <NoLimitz> well, i'm really dizzy because it's like 9am here[08:11:18] <NoLimitz> and it's hard to concentrate[08:11:22] <Jupp3> Same here[08:11:25] <Jupp3> And was up late too[08:11:37] <Jupp3> But I won't start guessing what you might have or might have not written to your code[08:11:41] <Jupp3> I'll go to work...[08:12:02] <NoLimitz> ok[08:12:08] <NoLimitz> good luck at work[08:13:34] *** UUncia has joined ##OpenGL[08:14:38] *** LordHavoc has quit IRC[08:16:42] *** fargiola` has joined ##OpenGL[08:16:50] *** porridj has joined ##OpenGL[08:18:11] <NoLimitz> hmm, id's are different[08:18:12] <NoLimitz> :|[08:19:32] <MatthiasM> don't create IDs yourself - use glGenTextures[08:19:49] <MatthiasM> use an array or objects to remember the ID for each texture[08:19:57] *** druggy has joined ##opengl[08:20:07] <NoLimitz> i didn't, i just printed 2 of them[08:20:43] *** ata2 has quit IRC[08:22:49] <MatthiasM> NoLimitz: read the red book[08:23:42] <porridj> anybody know a way to tint a whole model if the model is untextured but has vertex colors? for example if some vert colors are white and some are blue, i want to "tint" it with yellow so that it draws in yellow and black[08:27:09] *** ectropy has joined ##OpenGL[08:29:02] <NoLimitz> MatthiasM, can you please take a look over this piece of code? http://cpp.ninjacodemonkeys.org/5018[08:30:47] *** suppahsrv has quit IRC[08:31:45] *** suppahsrv has joined ##OpenGL[08:32:16] *** fargiolas has quit IRC[08:35:31] *** druggy__ has quit IRC[08:36:19] *** porridj has quit IRC[08:36:26] *** UUncia has quit IRC[08:44:25] *** rabbit- has joined ##OpenGL[08:49:48] *** McLovin` has joined ##opengl[08:51:01] *** ectropy has quit IRC[08:51:48] *** davidc__ has quit IRC[08:53:06] *** davidc__ has joined ##opengl[08:53:19] *** zwiep` has quit IRC[08:54:33] *** davidc__ has quit IRC[08:54:37] *** davidc- has joined ##opengl[09:05:03] *** kenws has joined ##OpenGL[09:08:15] *** rutski has joined ##OpenGL[09:09:18] *** dolphin has quit IRC[09:09:54] *** Burga has joined ##OpenGL[09:13:18] *** dolphin has joined ##OpenGL[09:20:05] *** scai has joined ##opengl[09:24:26] *** groton has joined ##OpenGL[09:25:05] *** [AD]Turbo has joined ##OpenGL[09:25:45] <[AD]Turbo> yo[09:28:31] *** UUncia has joined ##OpenGL[09:31:20] *** NoLimitz has quit IRC[09:33:53] *** pietia has joined ##OpenGL[09:35:07] *** TiLex has joined ##opengl[09:38:45] *** calav3ra has joined ##opengl[09:40:01] *** predaeus has joined ##opengl[09:41:36] *** nicesj has joined ##OpenGL[09:41:40] <nicesj> hi[09:41:44] <nicesj> I'm newbie..[09:41:53] <nicesj> I have to work with OpenGL ES 2.0[09:42:03] <nicesj> It is very new to me T.T[09:42:43] *** pietia has quit IRC[09:43:11] *** pietia has joined ##OpenGL[09:43:35] *** pietia has quit IRC[09:44:06] *** pietia has joined ##OpenGL[09:46:36] <threedee> hi nice[09:48:41] *** LordHavoc has joined ##OpenGL[09:50:56] *** dizekat has joined ##OpenGL[09:52:23] *** dizekat has quit IRC[09:52:31] *** dizekat has joined ##OpenGL[09:54:06] *** Nescafe has joined ##OpenGL[09:54:54] *** stef has quit IRC[09:55:24] *** dolphin has quit IRC[09:58:14] *** TiLex has quit IRC[10:04:18] *** vade has quit IRC[10:04:23] *** pietia has quit IRC[10:04:36] *** sohail has quit IRC[10:07:16] *** dizekat has quit IRC[10:07:38] *** belou has joined ##OpenGL[10:08:29] *** pietia has joined ##OpenGL[10:12:17] *** sohail has joined ##OpenGL[10:16:45] *** stef has joined ##opengl[10:24:01] *** twist__ has joined ##OpenGL[10:26:53] *** threedee has left ##OpenGL[10:32:54] *** sohail has quit IRC[10:32:58] *** fargiola` is now known as fargiolas[10:40:57] *** maxton has quit IRC[10:41:08] *** maxton has joined ##OpenGL[10:41:19] *** fargiola` has joined ##OpenGL[10:43:06] *** scai has left ##opengl[10:47:46] *** sparky has joined ##OpenGL[10:53:31] *** Ingenu has joined ##OpenGL[10:56:45] *** twist__ has quit IRC[10:57:43] *** fargiolas has quit IRC[10:59:15] *** sparky_ has quit IRC[11:00:11] *** fargiola` has quit IRC[11:01:33] *** fargiolas has joined ##OpenGL[11:03:05] *** nicesj has quit IRC[11:03:42] *** dvoid_ has joined ##OpenGL[11:06:15] *** tokemonstah has joined ##OpenGL[11:10:46] *** davidc- has quit IRC[11:12:58] *** synchris has left ##OpenGL[11:15:29] *** bimbo has joined ##OpenGL[11:19:39] <bimbo> hello, I'm trying to overlap two polyhedrons I've created, however when rotating the image I notice lots of glitches where these two overlap, how can I avoid this?[11:20:45] *** Suprano has joined ##OpenGL[11:23:36] <quicksilver> what kind of glitches?[11:23:43] <quicksilver> are you using the depth buffer?[11:25:17] <bimbo> quicksilver: yes I am using it, I don't know how to describe them... something like lots of lines appearing and dissapearing where these two intersect[11:25:42] <bimbo> glEnable(GL.GL_DEPTH_TEST);[11:26:13] <quicksilver> can you take a couple of screenshots?[11:27:40] <bimbo> quicksilver: sure, give me a sec[11:32:24] <bimbo> quicksilver: http://img67.imageshack.us/my.php?image=pantallazobe5.png[11:32:24] <bimbo> http://img206.imageshack.us/my.php?image=pantallazo2aw5.png[11:32:24] <bimbo> notice does white lines[11:32:42] <bimbo> those get repeated every second and look horrible (like a glitch, I don't know if there's a better english word that describes that)[11:34:36] *** belou has quit IRC[11:35:25] *** cplusplus has joined ##OpenGL[11:37:04] *** belou has joined ##OpenGL[11:38:55] <bimbo> this one looks much better[11:38:55] <bimbo> http://img83.imageshack.us/my.php?image=pantallazo3pq8.png[11:39:27] *** equalizer has joined ##OpenGL[11:39:48] <quicksilver> yes.[11:39:55] *** equalizer has quit IRC[11:39:56] <quicksilver> looks like your depth buffer is failing[11:39:59] *** equalizer has joined ##OpenGL[11:40:03] <quicksilver> probably you don't have enough depth precision[11:40:09] <quicksilver> what's your projection matrix setup look like[11:40:54] <bimbo> using gluPerspective: gluPerspective(45.0f, width / height, 0.1f, 1000.0f);[11:41:11] <quicksilver> yes[11:41:19] <quicksilver> ration of 1/10,000 is much too high[11:41:31] <quicksilver> do you really have things 1000 Z coords deep?[11:41:41] <quicksilver> I would change the 1000.0f to 100[11:42:08] <bimbo> ok, let me try that, I was doing some tests while reading the red book using that value[11:42:41] <bimbo> changed that but the problem persists[11:43:05] <quicksilver> hmm[11:43:14] <quicksilver> you better paste the source code I think.[11:43:49] <bimbo> ok, give me a sec again[11:44:35] *** rutski has quit IRC[11:49:27] *** groton_ has joined ##OpenGL[11:49:54] *** groton_ has quit IRC[11:55:36] <bimbo> quicksilver: http://pastebin.ca/1306431[11:56:37] <bimbo> oh, please ignore those static GL calls[11:56:44] <bimbo> the code is ported from java (using jogl)[11:57:26] <quicksilver> I don't see how that could be the right code[11:57:35] <quicksilver> it doesn't change colour between blue and white[11:58:18] <bimbo> oh, sorry forgot to show that... that was encapsulated in a class[11:58:39] <bimbo> but the first hexahedron is the blue one[11:59:06] <bimbo> the glPushMatrix and glPopMatrix are useless here[11:59:11] <bimbo> forgot to delete those too...[12:00:37] <quicksilver> it would be simpler to just paste the actual code[12:00:49] <quicksilver> the probability to introducing an irrelevant bug or hiding the actual bug is almost 100%[12:00:57] <quicksilver> if you try to do a complex translation[12:01:35] <quicksilver> anyhow I notice you draw a lot of things at precise z = -1[12:01:38] <quicksilver> (and indeed z=1)[12:01:48] <quicksilver> precisely coplanar planes will not draw accurately.[12:01:56] <quicksilver> so that's probably the problem.[12:03:35] *** boghog has quit IRC[12:03:55] <bimbo> quicksilver: why shouldn't I draw things at z= 1 and z = -1? why won't coplanar planes draw accurately?[12:04:19] *** boghog has joined ##opengl[12:04:33] <quicksilver> bimbo: because of rounding errors in the depth buffer[12:05:52] <bimbo> hmm changing that to +/- 0.5, problem persist, I would love to share the actual code, but that implies several classes to be pasted[12:06:22] <bimbo> but the translation to C is almost the same, I didn't leave anything behind[12:06:37] <quicksilver> it's not just z=1[12:06:40] <quicksilver> it's any value.[12:06:46] <quicksilver> coplanar planes will no draw accurate.[12:07:01] <quicksilver> decide which one you want to be in front (or behind) and offset it by a non-trivial amount[12:07:06] <quicksilver> like 0.05 or so.[12:09:52] *** davidc__ has joined ##opengl[12:11:36] <bimbo> quicksilver: that made the trick[12:12:19] <bimbo> quicksilver: thanks a lot for your help[12:12:52] <quicksilver> ;)[12:12:56] <quicksilver> not at all.[12:14:45] <bimbo> I just started to use opengl 2 days ago, so far this has been the only problem I've encountered (and trying to model things in 3 dimensions, that's a real pain)[12:17:21] <quicksilver> blender ftw![12:17:40] <quicksilver> although it takes quite some time to get the hang of[12:17:40] <quicksilver> it's a great modeller[12:18:54] *** UUncia has quit IRC[12:19:59] *** Entelin has joined ##OpenGL[12:28:48] *** maxton has quit IRC[12:33:20] *** Burga has quit IRC[12:33:20] *** LordMetroid has joined ##OpenGL[12:34:57] <LordMetroid> Anyone know if whether I should download the release build of JOGL(1.1.1) or if the nightly build is preferable at this stage(1.1.2)?[12:45:59] <bimbo> quicksilver: thank you, will look at it later, right now I'm off to sleep, thanks again[12:46:34] <bimbo> LordMetroid: well, 1.1.1 is the stable release, and is at least what I'm using[12:47:14] <LordMetroid> ok, I'll use 1.1.1 then[12:47:17] *** ol1veira_ has joined ##OpenGL[12:48:21] *** troyyan has quit IRC[12:48:43] *** bimbo has left ##OpenGL[12:58:30] *** Spkka has joined ##OpenGL[13:06:29] *** ttuuxxx has joined ##OpenGL[13:08:21] *** xslr has joined ##OpenGL[13:09:40] <ttuuxxx> The thing with OpenGl is that it sucks, it depends on your graphics card and has a crap load of depends, Its really bloatware, and medusa is the same, maybe you might want to look at sdl and figure out how come its so small, and just works with every pc, smartin up already, OpenGl isn't the end of everything its a lost vista wanna bee,[13:09:45] *** ttuuxxx has left ##OpenGL[13:12:47] <exDM69> and the moron of the day award goes to...[13:20:28] *** maxton has joined ##OpenGL[13:24:09] <Weiss> hmm.. didn't even stay to see the results of his troll[13:25:23] <kbotnen> I guess it was the trollAway(c) spray that I used :)[13:28:47] *** xslr has quit IRC[13:30:09] <Weiss> hehe[13:40:15] *** Spkka has quit IRC[13:40:28] *** Spkka has joined ##OpenGL[13:42:50] *** zwiep` has joined ##opengl[13:43:55] *** nytejade__ has joined ##OpenGL[13:44:36] *** calav3ra has quit IRC[13:45:07] *** jcouture has joined ##OpenGL[13:45:56] *** pfo_ has joined ##OpenGL[13:46:29] *** McLovin` has quit IRC[13:46:29] *** hibread_ has quit IRC[13:46:29] *** pfo has quit IRC[13:46:29] *** TenOfTen has quit IRC[13:46:29] *** autonomy has quit IRC[13:46:29] *** urnotE` has quit IRC[13:46:32] *** hibread__ has joined ##opengl[13:47:38] *** TenOfTen has joined ##opengl[13:49:06] *** sparky_ has joined ##OpenGL[13:49:58] *** tokemonstah has quit IRC[13:50:20] *** jcazevedo has joined ##OpenGL[13:52:09] *** zommi has joined ##OpenGL[13:53:37] *** autonomy has joined ##OpenGL[13:59:10] *** sparky has quit IRC[14:02:26] <boghog> that was the lamest troll/flamebait i have ever seen :D[14:05:52] * Weiss was quite amused[14:08:07] *** UUncia has joined ##OpenGL[14:12:10] *** eXtronuS_ has quit IRC[14:13:48] *** eXtronuS_ has joined ##OpenGL[14:19:15] *** PsiOmega has quit IRC[14:19:35] *** sparky has joined ##OpenGL[14:20:20] <LordMetroid> lol, what a tard[14:21:25] *** PsiOmega has joined ##OpenGL[14:29:57] *** sparky_ has quit IRC[14:32:51] *** rabbit- has quit IRC[14:37:24] *** PsiOmega has quit IRC[14:45:59] *** UUncia has quit IRC[14:50:01] *** PsiOmega has joined ##OpenGL[14:56:53] *** pietia has quit IRC[14:56:56] *** NoLimitz has joined ##OpenGL[14:59:24] <NoLimitz> er, i don't want to annoy people here, but theese texture bugs really annoy me[14:59:42] *** NinZine has joined ##OpenGL[15:00:42] *** PsiOmegaDelta has joined ##OpenGL[15:01:05] <belou> Someone from seattle here ?[15:01:17] *** burak575 has joined ##OpenGL[15:09:23] *** PsiOmega has quit IRC[15:11:13] *** pietia has joined ##OpenGL[15:11:15] *** LordMetroid has quit IRC[15:11:42] <NoLimitz> how can i test if i can use a texture[15:12:01] <NoLimitz> seems like opengl is unable to load more than 2 textures at a time, for me[15:13:30] <belou> NoLimitz, ???[15:13:36] <belou> com'on dude[15:13:44] <belou> what is your VC ?[15:13:48] <NoLimitz> erm[15:13:50] <NoLimitz> lemme check[15:14:02] <belou> does it have been made before the nineties ?[15:14:09] <NoLimitz> Nvidia GeForce 6600[15:14:34] <belou> so[15:14:38] <NoLimitz> and yes, it was made a few years ago[15:14:42] <NoLimitz> well i don't know[15:14:44] <belou> do you use multi texturing ?[15:14:51] <NoLimitz> opengl exhibits a really strange behavious[15:14:52] <belou> or simple texturing ?[15:14:54] <NoLimitz> behaviour[15:15:04] <NoLimitz> erm, i don't know[15:15:07] <NoLimitz> how do i check/set?[15:15:13] *** lewymati has joined ##OpenGL[15:17:34] *** PsiOmega has joined ##OpenGL[15:17:49] <belou> well[15:17:55] <belou> it is your code[15:17:58] <NoLimitz> hmm, i used glGetIntegerv(GL_MAX_TEXTURE_SIZE, &texSize) and it displays 4096[15:18:10] <belou> yes....[15:18:30] <belou> where did your learn how to made a texture call ?[15:18:34] <NoLimitz> which would mean 64x64 textures[15:18:52] <NoLimitz> well, opengl faq, plus some tutorials on videotutorialsrock.c om[15:19:19] <NoLimitz> i think the problem is my textures are too big[15:19:27] <NoLimitz> i mean, i have 256x256 textures[15:19:46] <belou> 256*256 il ok[15:19:55] <belou> the max size is 4096*4096[15:20:39] <NoLimitz> still, i will try to scale down some of the textures[15:22:06] <belou> NoLimitz, ok ...[15:22:09] <kbotnen> what strange behaviour?[15:22:17] <kbotnen> you havent mentioned any strange yet.[15:22:20] *** LtJax has joined ##opengl[15:23:18] <NoLimitz> well, i can load 2 textures, it's ok[15:23:36] <NoLimitz> but as soon as i load the third, problems appear[15:23:55] <ol1veira_> NoLimitz: What problems?[15:24:00] <ol1veira_> How do you load textures?[15:24:19] <NoLimitz> erm[15:24:25] <NoLimitz> i kinda need to paste some code for that[15:24:28] <ol1veira_> Do you have code to paste? I mean it's pretty hard to tell[15:24:35] <ol1veira_> Excellent idea[15:24:50] <NoLimitz> http://cpp.ninjacodemonkeys.org/5018[15:25:16] <ol1veira_> NoLimitz: and what's the error?[15:25:42] <NoLimitz> well, as soon as i write the code to load the third texture, it starts misbehaving[15:26:23] <ol1veira_> NoLimitz: What about querying the GL for errors? Like glGetError?[15:26:27] *** PsiOmegaDelta has quit IRC[15:26:27] <kbotnen> does your image size powers of 2?[15:26:42] <kbotnen> have read somewhere that it should be squared size image fiels.[15:26:46] <kbotnen> *files.[15:26:49] <NoLimitz> yes[15:26:52] <NoLimitz> 256x256[15:26:59] <NoLimitz> 24bit files[15:27:06] <kbotnen> ah. ofc. hehe. you stated earlier.[15:28:07] <ol1veira_> I still don't know what's the misbehaviour is supposed to be[15:28:37] <NoLimitz> well, let's say i have a texture for the walls, one for the floor, one for the ceiling[15:29:47] <NoLimitz> pfff, never mind[15:29:55] <NoLimitz> i think it might be a c++ memory allocation problem[15:30:03] <ol1veira_> valgrind it[15:30:12] <NoLimitz> erm, i'm under windows :)[15:32:14] <NoLimitz> by the way, in order to use glGetTexLevelParameteriv(GL_PROXY_TEXTURE_2D, 0, GL_TEXTURE_WIDTH, &width); i have to enable textures and bind a texture, right?[15:32:44] *** LtJax has quit IRC[15:33:40] *** fargiola` has joined ##OpenGL[15:34:14] *** fargiolas has quit IRC[15:34:21] *** fargiola` is now known as fargiolas[15:35:18] *** Renderwahn has joined ##OpenGL[15:49:04] *** suppahsrv has quit IRC[16:03:14] *** NoLimitz has quit IRC[16:04:56] *** PsiOmega has quit IRC[16:08:10] *** PsiOmega has joined ##OpenGL[16:19:17] *** Gorgoroth has joined ##OpenGL[16:19:17] *** suppahsrv has joined ##OpenGL[16:19:18] *** Ingenu has quit IRC[16:20:22] *** itsmonkt1stic has joined ##opengl[16:21:20] *** mikolalysenko has joined ##OpenGL[16:22:46] *** simlan has joined ##OpenGL[16:29:03] *** calav3ra has joined ##opengl[16:29:45] *** vade has joined ##OpenGL[16:29:46] *** dv_ has joined ##opengl[16:29:50] *** GX has joined ##OpenGL[16:30:00] *** HuntsMan has joined ##opengl[16:33:34] *** Ingenu has joined ##OpenGL[16:36:55] <simlan> Maybe it's a bit offtopic, but what's a good way to make movies from opengl renderings? I'm on unix, so I can't use fraps.[16:36:58] *** ectropy has joined ##OpenGL[16:37:16] *** Jupp3 has quit IRC[16:38:08] <ol1veira_> simlan: xvidcap, gtkrecordmydesktop, etc[16:39:38] *** reprore_ has joined ##OpenGL[16:40:52] *** cplusplus2 has joined ##OpenGL[16:43:06] *** itsmonktastic has quit IRC[16:45:16] <pietia> do you know any good 'practical' tutorial of opengl when i can build simple 3d game?[16:45:48] <tmccrary1> http://www.cokeandcode.com/asteroidstutorial[16:46:02] <pietia> but not asteroids :D[16:46:11] <pietia> something in pure opengl[16:46:19] <pietia> not java/opengl[16:46:44] <replaced> nehe?[16:47:06] <pietia> nehe. is there simple app ?[16:47:08] <pietia> sample app[16:48:39] <quicksilver> you don't write games in opengl, you draw graphics in opengl.[16:48:52] <quicksilver> writing a game in opengl is no different from writing a game with any other graphics api[16:48:59] <quicksilver> that is, it is hard, and requires programming :P[16:53:38] <HuntsMan> i wonder what "pure OpenGL" is[16:55:15] *** HuntsMan has quit IRC[16:57:48] *** cplusplus has quit IRC[17:01:36] *** HuntsMan has joined ##opengl[17:07:19] *** sparky_ has joined ##OpenGL[17:12:59] *** kbotnen_ has joined ##OpenGL[17:14:10] *** sparky has quit IRC[17:21:10] *** LordMetroid has joined ##OpenGL[17:21:39] *** AlastairLynn has joined ##opengl[17:23:20] *** Yustme has joined ##OpenGL[17:27:57] *** kbotnen has quit IRC[17:31:03] *** rnx has joined ##opengl[17:34:26] <Orphis> Is it me, or visual studio 2008 has headers for OpenGL 1.1 only ?[17:34:40] <tmccrary1> Orphis: its you[17:35:40] <quicksilver> are there any nice blogs or rss feeds which talk about clever rendering tricks?[17:35:47] <quicksilver> the sort of stuff you find in siggraph, say[17:38:27] <aep> any idea if glXSwapBuffers can be made copiing the buffer instead of swapping?[17:38:33] <Orphis> There are a lot of constant missing in the gl.h bundled with my visual studio it seems[17:38:38] *** Gudy has quit IRC[17:39:15] <HuntsMan> Orphis: gl.h includes glext.h, check there[17:39:43] <Orphis> No it doesn't :p[17:39:57] <HuntsMan> mine does :P[17:40:24] <Orphis> gl\glext.h no found in include path[17:40:24] *** Gudy has joined ##OpenGL[17:42:12] *** cplusplus2 has quit IRC[17:42:26] <Orphis> Hmm, it's including gl.h from the Platform SDK 6.1[17:42:37] <Orphis> I should change the order of the include path[17:45:03] *** cplusplus has joined ##OpenGL[17:45:13] *** equalizer has quit IRC[17:48:53] *** colton_ has joined ##OpenGL[17:49:37] *** [AD]Turbo has quit IRC[17:50:30] <colton_> I have opengl and glut installed on ubuntu, however, When I try to compile my opengl application it seems to have difficulty finding lXmu, it gives me an error when I include it, and it works when I don't include it.[17:53:32] *** scai has joined ##opengl[17:53:46] <predaeus> aep, why would you want that?[17:54:45] *** LordMetroid has quit IRC[17:55:22] <aep> pragma_: to only redraw actual damaged parts[17:55:27] <aep> and copy the rest[17:55:42] <aep> copiing is less expensive then redrawing[17:55:45] <TheFlash> colton_: Well, then don't include it. If it works without it, you're not even using it![17:56:00] <predaeus> colton_, What do you mean with 'include'? add it to the linker flags? What is the question?[17:57:02] <Orphis> HuntsMan: could you tell me the path of your gl.h file ? It seems to be missing for me in the vc 9.0 directory[17:58:40] <predaeus> aep, swapping buffers has nothing to do with redrawing dirty window content. If you want X to only render those parts of your opengl scene that have changed, then this is not possible, as far as I know.[17:59:02] <aep> well it is, if you have a second buffer[17:59:16] <aep> i do have one, but it only works with nvidia[17:59:31] <aep> the intel gl apparantly cant draw on pixmaps[18:00:17] <aep> i hoped to abuse the visual double buffering :/[18:05:10] <predaeus> aep, ah, you have an application that only redraws on input I guess.[18:05:25] <aep> yes, sorry didnt mention[18:05:39] <aep> its a gui toolkit[18:06:13] <aep> and obviously those may not waste CPU or GPU with redrawing things that wont change anyway[18:07:43] *** ectropy has quit IRC[18:09:33] <predaeus> aep, you can set the source buffer when reading pixels and copy those to the front buffer I think (not sure). Another solution would be to render to texture or some other offscreen buffer and copy that content in or just render the texture to fullscreen quad when you need to refresh.[18:10:30] *** elite01 has joined ##opengl[18:10:47] <aep> cant see any api for 1). 2) doesnt work on intel. 3) i have no clue what you mean (i'm totaly new to opengl)[18:11:13] <aep> i guess you're saing i could render the things i have to a texture?[18:11:21] <aep> and then render that texture onto the window[18:11:28] <predaeus> yes, that is one approach.[18:11:34] <aep> that sounds very good[18:11:48] <aep> mind giving me some hints to google?[18:12:23] <quicksilver> aep: "FBO" "render-to-texture"[18:12:40] <quicksilver> it's probably faster just to redraw the whole buffer by the way[18:12:45] <aep> FBO is an extension i think. it was suggested multiple times[18:12:46] <quicksilver> unless you have very complex primitives.[18:12:56] <quicksilver> it is an extension, yes. It is the answer to your question.[18:13:16] <quicksilver> glReadPixels does not require an extension, but glReadPixels is actually 42,000 times slower than redrawing the entire buffer.[18:13:18] <aep> extensions are very hard to manage :/[18:13:27] <aep> ouch[18:13:29] <tmccrary1> O:[18:13:44] <predaeus> aep, use glew or something when on C/C++.[18:13:58] <aep> yes, but you have to handle a large amount of hardware[18:14:03] <aep> and implement fallbacks[18:14:26] <aep> and i only have 3 different machines to test, but you would need all of them[18:14:57] <aep> its already very painfull to handle X extensions :/[18:15:10] <quicksilver> aep: FBOs are very widely supported.[18:15:24] <quicksilver> the last 3? 4? generations of graphics cards.[18:15:31] *** neoneye has quit IRC[18:15:34] <aep> hm[18:15:46] <predaeus> aep, what is the lowest hardware you are targeting?[18:16:04] *** sohail has joined ##OpenGL[18:16:16] <aep> that i dont know yet. i guess anything that is capable of drawing a primitive with oepngl should work[18:16:25] <aep> even if its mesa[18:16:38] <aep> no mobile phones though[18:16:56] <aep> ie no opengl ES or whatever it is called[18:17:33] <quicksilver> opengl es supports FBOs just fine, by the way.[18:17:45] <aep> oh. interesting[18:18:20] <aep> btw, do you guys use the visuals double buffer?[18:18:28] <quicksilver> I always double buffer.[18:18:30] *** vade has quit IRC[18:18:38] <aep> profiling shows that glxSwapBuffers is extremly slow here[18:18:42] <aep> its actually using CPU[18:18:43] <aep> alot[18:18:49] <quicksilver> I don't think so.[18:18:54] <quicksilver> glxSwapBuffers is a sync point[18:18:59] <quicksilver> openGL is asynchronous[18:19:01] <aep> disabling it makes my test app drop form 30% cpu to 8[18:19:11] <quicksilver> glxSwapBuffers forces you to wait for the graphics card to finish.[18:19:16] <aep> aha[18:19:18] <quicksilver> so it appears to be slow[18:19:21] <quicksilver> because it's a sync point[18:19:22] <aep> and that shows up as cpu usage i guess[18:19:24] <quicksilver> it's not really slow.[18:19:42] <aep> but if you dont sync, you get glitches :/[18:19:48] <quicksilver> indeed.[18:19:53] <aep> i tried with my own framebuffer[18:20:05] <aep> without calling glFlush, it just copies unfinished garbage[18:20:17] *** reprore_ has quit IRC[18:20:31] *** kenws has quit IRC[18:20:38] <aep> maybe i should optimise the amount of redraws before optimising readraws itself[18:20:59] <aep> currently i got 10 redraws just for clciking a button[18:21:06] *** zommi has quit IRC[18:23:31] <quicksilver> that does sound like a mistake.[18:23:45] <quicksilver> you should limit redraws to some fixed amount (say, 60 fps)[18:23:47] <aep> it is.[18:23:52] <aep> oh that i cannot do[18:23:53] <quicksilver> and batch all redraws caused by one action.[18:24:30] <aep> that doesnt work for gui toolkits. you may never use CPu when idle[18:24:40] *** reprore_ has joined ##OpenGL[18:24:44] <aep> if gui toolkits would do that, it would be horrible[18:24:52] <aep> but yeah i need to batch them[18:25:10] <aep> propably by redrawing at the end of the event handlers[18:25:21] *** johndoe has joined ##opengl[18:27:06] <quicksilver> aep: eh?[18:27:14] <quicksilver> aep: nothing I said involved using the CPU when idle.[18:27:24] <quicksilver> You don't add unneeded redraws.[18:27:29] <quicksilver> You just limit the needed ones.[18:27:35] <quicksilver> so if your user types at 200 keys per second[18:27:50] <quicksilver> you only bother to redraw at 60fps[18:27:56] <aep> hm[18:27:59] <aep> makes sense[18:27:59] <quicksilver> (so you get around 3 keystrokes per frame)[18:28:05] <quicksilver> of course, nobody types at 200 keys per second[18:28:07] <quicksilver> but you see the point ;)[18:28:13] <aep> :D[18:28:28] <quicksilver> in particular if complex parts of your system try to redraw more often than 60fps, you cap it[18:28:28] <aep> is 60fps the defacto standard?[18:28:38] <quicksilver> well, it's the refresh rate of a middle of the range monitor[18:28:45] <quicksilver> and it's well beyond human perception[18:28:51] <aep> so i'm better of detecting the refresh rate?[18:28:58] <aep> ah[18:29:09] <quicksilver> if your OS gives you a way to link into VSYNC[18:29:15] <aep> why do games expect more FPS then?[18:29:18] <quicksilver> then you can draw directly on the screen refresh.[18:29:22] <quicksilver> aep: two reasons[18:29:27] *** reprore_ has quit IRC[18:29:38] <quicksilver> (1) because 180fps on "average" may only mean 40fps on a really busy moment[18:29:46] <quicksilver> (2) because game programmers are stupid idiots[18:29:53] <quicksilver> and link the physics model to the display FPS[18:30:06] <quicksilver> so a slower FPS is (in that case) actually a gameplay disadvantage.[18:30:09] *** reprore_ has joined ##OpenGL[18:30:11] <aep> means the faster it runs the more fluent ift feels[18:30:19] <aep> hm[18:30:31] <quicksilver> well some shooters may only process mouse clicks once per frame[18:30:45] <aep> ew[18:30:51] <quicksilver> so a client with a faster FPS may experience 'smoother' shooting or a 'faster rate of fire'[18:30:53] <aep> that would be fatal at 60FPS[18:31:03] <quicksilver> that's obviously bad programming[18:31:04] <aep> well actually it wouldnt[18:31:07] <quicksilver> but it may be a compromise.[18:31:08] <aep> i cant click faster then 60[18:31:14] <aep> actually,... 10FPS[18:31:15] <aep> anyway[18:31:21] *** AlastairLynn has quit IRC[18:31:25] <aep> i get the point[18:31:55] *** Jupp3 has joined ##OpenGL[18:31:58] <aep> thank you[18:33:57] *** cplusplus2 has joined ##OpenGL[18:34:37] <aep> well glew doesnt compile. any other suggestion?[18:36:44] <rnx> GLee[18:36:46] <tmccrary1> find out why glew doesn't compile[18:38:48] *** cplusplus has quit IRC[18:44:43] <jezek2> quicksilver: that's not entirelly true, you can get away with just 30fps without notice but you must have proper motion blur :)[18:45:09] *** Ingenu has quit IRC[18:45:36] <jezek2> quicksilver: from what I observed capping at 90 fps is ok, below it's noticeable, and there is also bigger input lag with lower fps :)[18:46:46] <tmccrary1> I wonder where the sweet spot is with that[18:47:28] <tmccrary1> What I mean is, where motion blur becomes worth it cost wise vs rendering way more frames[18:48:26] <tmccrary1> Motion blur @ 30 fps is probably more aesthetically pleasing than 200 crisply rendered frames[18:48:57] <tmccrary1> although I guess from a games standpoint, the blue could be annoying[18:49:09] <tmccrary1> err the blur[18:49:09] <jezek2> blue?[18:49:13] <jezek2> ah[18:49:57] <aep> i got an FBO example here but i cant find any code related to actually switching between the FBO and the actual window[18:50:10] *** Ingenu has joined ##OpenGL[18:50:19] <aep> /* Render to buffer */[18:50:19] <aep> glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);[18:50:22] <aep> makes no sense to me[18:50:36] <jezek2> tmccrary1: well it depends if it's done right, I've seen video from some game which had amazing motion blur (I can't remember name, but was something fantasy)[18:50:52] <tmccrary1> tf2 has a pretty nice motion blur effect[18:50:56] *** maxton has quit IRC[18:51:03] <tmccrary1> but I don't play it enough to know how it affects gameplay[18:51:09] <jezek2> tmccrary1: on the other hand other blurs such as depth of field are often very bad ... or bloom... argh ;)[18:51:27] <tmccrary1> yeah[18:53:16] *** ndutta has joined ##OpenGL[18:53:18] *** ndutta has left ##OpenGL[18:54:01] <jezek2> http://www.projectoffset.com/videos.php - there are videos with very good motion blur implementation :)[18:58:27] *** belou has quit IRC[18:58:44] *** arkx has quit IRC[18:58:44] *** cmang_ has quit IRC[18:58:44] *** rektide has quit IRC[18:59:19] *** rektide has joined ##OpenGL[18:59:19] *** cmang_ has joined ##OpenGL[18:59:19] *** arkx has joined ##OpenGL[18:59:57] *** arkx has quit IRC[18:59:57] *** cmang_ has quit IRC[18:59:57] *** rektide has quit IRC[19:00:04] *** arkx has joined ##OpenGL[19:00:05] *** cmang has joined ##OpenGL[19:00:06] *** rektide has joined ##OpenGL[19:06:16] *** XT95_ has joined ##OpenGL[19:07:21] *** reprore_ has quit IRC[19:09:33] *** groton has quit IRC[19:11:54] <GuShH> jezek2 : yep it's vector based motion blur[19:12:22] *** reprore_ has joined ##OpenGL[19:13:21] <GuShH> But you know what, project offset = vaporware[19:13:48] <GuShH> Specially since they haven't had an update in ages.[19:14:07] *** Nescafe has quit IRC[19:15:55] <predaeus> GuShH, they got bought by Intel, and do Larrabee stuff now.[19:16:26] <HuntsMan> Larabee sounds like vapoware to me ;)[19:16:33] *** burak575 has quit IRC[19:16:47] <GuShH> What could they be doing on Larrabee?[19:16:50] <GuShH> pretty demos?[19:17:26] *** vade has joined ##OpenGL[19:17:58] <predaeus> I guess Project Offset becomes that demo.[19:20:12] <GuShH> Heh if the Lua people sees they wrote "LUA" they'll be mad.[19:20:41] <GuShH> I almost got banned at their IRC channel for continuously saying "LUA" When in fact it's a portuguese word, not an accronym.[19:20:54] *** a-stray-cat has joined ##OpenGL[19:21:03] *** LordMetroid has joined ##OpenGL[19:26:04] *** barbar__conan has joined ##OpenGL[19:28:43] *** NevroPus has quit IRC[19:34:45] *** wisey has joined ##OpenGL[19:36:28] *** eXtronuS_ has quit IRC[19:41:57] *** dv_ has quit IRC[19:42:26] *** Entelin has quit IRC[19:43:23] *** Entelin has joined ##OpenGL[19:51:42] <aep> this FBO is very confusing[19:51:51] <aep> i really cant find any context switch[19:52:09] <HuntsMan> ah?[19:52:12] <aep> it looks like thise exmple code just draws to the main context[19:52:15] <HuntsMan> FBO's don't have their own context[19:52:21] <aep> oh[19:52:25] <MatthiasM> aep: that's the point of FBOs[19:52:28] <aep> err but..[19:52:35] <aep> how do you actually draw offscreen then?[19:52:50] <MatthiasM> glBindFRamebufferObject[19:53:09] <aep> yeah sure, but i cant find any code in the drawing function that does any switching[19:53:18] <aep> to the fbo and back[19:53:22] <HuntsMan> aep: when you bind the FBO, the draw buffer changes to attachment 0[19:53:30] <aep> from what i read, all drawing operations should end in the main window[19:53:37] <aep> hm[19:53:41] <MatthiasM> aep: read the FBO spec[19:53:58] <aep> you're not very patient, are you.[19:54:19] <HuntsMan> it's not patient, the spec was made to be readed :)[19:54:27] <MatthiasM> aep: why should we tell you the same thing several times ?[19:54:40] <HuntsMan> i'm right now reading the OpenCL spec to get ready when CL implementations are available[19:54:47] <MatthiasM> and there is no point in copy&pasting the spec into IRC[19:55:13] <aep> MatthiasM: i usually do even that[19:55:21] <aep> but thats a matter of how patient one is[19:56:12] <aep> the problem: there is no glBindFRamebufferObject call in the drawing code[19:56:24] <aep> there is only one in intiaislisation[19:56:31] <aep> which only happens once[19:56:44] <HuntsMan> aep: glBindFramebuffer[19:57:00] <aep> well or that. not any reference to anything like it[19:57:08] <aep> it just draws, resets the matrix, draws again[19:57:16] <aep> maybe that example is crap[19:57:36] <HuntsMan> yeah, is crap[19:57:44] <HuntsMan> if it doesn't have glBindFramebuffer, it isn't using FBO[19:57:52] <HuntsMan> unless it's using some utility classes or abstraction[19:58:00] <HuntsMan> http://www.gamedev.net/reference/articles/article2331.asp[19:58:00] <HuntsMan> read that[19:58:06] <MatthiasM> or maybe it blits from framebuffer to back buffer[19:58:12] <aep> thanks[20:03:03] *** Xmas| has joined ##OpenGL[20:03:23] <aep> wow thats a lot more code then the example i have :/[20:04:21] *** mattn2|home_ has quit IRC[20:04:36] *** barbar__conan has quit IRC[20:05:10] <aep> did i understand it correctly that you need one of these FBOs, then attach a texture to them and draw on that texture?[20:05:22] <MatthiasM> yep[20:06:05] <aep> thanks[20:08:07] *** m4ggus has joined ##opengl[20:10:10] *** Jophish has joined ##opengl[20:13:54] *** colton_ has quit IRC[20:19:15] <aep> complex. but i think i have a slight clue now what to do. thats alot for that link[20:20:26] *** fusi has joined ##OpenGL[20:21:08] <fusi> 1/win move 3[20:21:15] *** Goosey has quit IRC[20:21:59] *** Goosey has joined ##OpenGL[20:28:51] <fusi> interleaved arrays and vertex structs -> how is the potentially varying number of texture coords per vertex handled? or should a fixed number be used throughout (feels limited/wasteful)? perhaps the vertex struct doesnt exist at all and what should happen is the data array is written to directly with a dynamic texture coord count being specified?[20:30:10] <Xmas|> what do you mean by "potentially varying per vertex"?[20:30:12] <MatthiasM> fusi: use the stride parameter[20:30:34] <MatthiasM> and you can define more then one vertex structure[20:30:47] <fusi> sorry i worded that wrong[20:30:58] <fusi> like, different objects might have different nmubers of textures[20:31:18] <fusi> how to handle this texture count variance in the vertex struct[20:31:28] <Xmas|> use different structs[20:31:28] <MatthiasM> don't use a structure[20:31:31] <fusi> cos, the vertex struct has gotta satore coords for each unit right?[20:32:37] <fusi> http://www.opengl.org/wiki/index.php/Vertex_Arrays[20:32:48] <fusi> im coming from that angle[20:33:18] <fusi> in that sample they store 3 coord sets per vert[20:34:18] <fusi> ive read on various forums that this method of structuring the data is optimal over separate arrays[20:34:56] <MatthiasM> fusi: yes - but you don't need a C/C++ structure for this[20:35:24] <fusi> so you just write to the data array directly[20:35:49] <fusi> and stick in there as many coord values as you want and specify the count later[20:36:04] <fusi> yer hmmz[20:36:34] <MatthiasM> fusi: you can also access the data as arrays of "struct vector3f" etc like you set it up for GL[20:37:05] <MatthiasM> eg create a small wrapper this: "return reinterpret_cast<vector3f*>(basePtr + stride*idx);"[20:37:12] <MatthiasM> *like this[20:37:18] <fusi> ooh funky[20:37:47] <MatthiasM> eg - you could overload the [] operator[20:38:31] <fusi> yer[20:38:37] <fusi> nice idea that[20:39:05] <MatthiasM> and basePtr includes the offset you passed to glXYZPointer[20:39:21] <MatthiasM> and you could use this class also to let it call glXYZPointer :)[20:41:23] <fusi> col[20:41:28] <fusi> ok thanks MatthiasM[20:42:14] *** Viko2 has joined ##OpenGL[20:43:11] *** e_roder has joined ##OpenGL[20:44:11] <e_roder> hey[20:44:35] <e_roder> what advantages does using a shader language offer over a fixed function pipeline?[20:44:48] *** ol1veira_ has quit IRC[20:44:52] <e_roder> (for rendering)[20:45:23] *** ol1veira_ has joined ##OpenGL[20:45:58] <MatthiasM> e_roder: much more flexible - and easier to use[20:46:23] *** ol1veira_ has quit IRC[20:46:33] <e_roder> alright, would you recommend them then?[20:46:43] <e_roder> for say, writing a game[20:46:56] <MatthiasM> ofcourse[20:47:01] <e_roder> alright, thanks[20:50:00] *** NoLimitz has joined ##OpenGL[20:52:33] *** Viko2 has quit IRC[20:55:45] <aep> glGetString(GL_EXTENSIONS) returns 0. any ideas what i'm doing wrong?[20:56:19] <HuntsMan> you're not calling it with a context made current[20:56:26] <HuntsMan> or calling it inside glBegin/glEnd[20:56:42] <MatthiasM> aep: use GLEW to handle extensions[20:57:12] <aep> 1) glew doesnt compiler 2) it wont work either if glGetString doesnt work.[20:57:14] <aep> thanks HuntsMan[20:58:08] <MatthiasM> aep: 1) fix your compiler settings 2) it parses GL_EXTENSIONS for you[20:58:24] <MatthiasM> for both - read it's manual[20:58:30] <aep> my compiler isnt broken, i know how to handle it.[20:58:34] <aep> and i'm using glee now[20:58:48] *** cplusplus3 has joined ##OpenGL[20:58:48] <aep> it just failed becouse of the above problem[20:59:49] <MatthiasM> aep: then read the manual of GLee - you don't need to call glGetString(GL_EXTENSIONS)[21:00:06] <aep> will you please just ignore me?[21:00:08] <aep> i wasnt[21:00:46] <aep> i was obviously debugging glee...[21:00:46] <aep> not understanding why this specific call returns NULL[21:01:07] <aep> the question was answered, i know now what i did wrong and everything is good[21:04:48] *** eXtronuS_ has joined ##OpenGL[21:07:09] *** simlan has quit IRC[21:15:40] *** cplusplus2 has quit IRC[21:18:25] <e_roder> culling should be done prior to the vertex shader right?[21:20:29] <aep> is drawing a quad with a texture the way to go for basicly copying a 2D texture to the screen, or is there something like blit?[21:21:03] <e_roder> are you doing 3d?[21:21:39] <HuntsMan> aep: it's the way to go[21:21:46] <aep> thanks[21:21:51] <aep> e_roder: no[21:21:55] <e_roder> o[21:22:06] <e_roder> hm, well ok, what he said then[21:23:01] <aep> all i have to do is glBindTexture and then draw a quad, is it? becouse i'm getting a black box without any texture[21:23:13] <aep> but my texture might be broken, no clue how to debug that[21:23:25] <e_roder> well[21:23:37] <e_roder> you have to set up the texture too[21:24:04] <aep> yes of course, i have already drawn to it at that point[21:24:27] <e_roder> then maybe what you're drawing is black?[21:24:28] <HuntsMan> aep: http://www.opengl.org/wiki/index.php/Common_Mistakes#Creating_a_Texture[21:24:41] <aep> ah thanks![21:24:58] <e_roder> the page is blank?[21:25:12] <e_roder> ah my bad[21:26:30] <aep> well i dont know if its blank. going through that link[21:28:49] *** predaeus has quit IRC[21:29:29] <aep> hm i checked glCheckFramebufferStatusEXT, it says it is complete[21:38:21] <aep> i'm almost certain the problem is here, becouse thats the part least expmplained in the tutorials i read[21:38:22] <aep> http://codepad.org/3nazwnZw[21:38:37] <aep> actually none of the tutorials actually states how to use the texture[21:38:45] <aep> so i assumed glBindTexture is enough[21:40:21] *** calav3ra_ has joined ##opengl[21:43:12] *** Kasu has joined ##OpenGL[21:43:56] <NoLimitz> guys, can somebody look over this piece of code http://cpp.ninjacodemonkeys.org/5022 and tell me what is wrong with it[21:46:28] *** wisey has quit IRC[21:47:18] <aep> NoLimitz: its very long, whats the issue?[21:47:47] <HuntsMan> aep: yes, unbind the FBO and bind the texture[21:48:03] <aep> i did.[21:49:51] *** e_roder has quit IRC[21:50:26] <aep> 0ok i think usage is ok, but its really black[21:53:07] <NoLimitz> aep, i know..i just wanted to ask, are the quads and textures defined correct and stuff[21:53:16] <MatthiasM> does it work when you render without a texture ? eg only a solid color[21:53:22] <NoLimitz> yes[21:53:30] <aep> yes here too ;)[21:53:45] <NoLimitz> actually, i've addressed this problem earlier...[21:53:53] <aep> NoLimitz: i cant help, i'm exactly stuck with textures myself[21:53:54] <NoLimitz> i think i will ask on a c++ channel[21:54:07] <aep> but i reccomend showing a smaller code sample[21:54:07] <NoLimitz> aep, thanks for the intention anyway :)[21:54:16] <NoLimitz> i know...[21:55:37] <aep> i think i found the problem. the fbo is zero size[21:55:54] <aep> can i resize an fbo, or do i have to recreate it?[21:56:01] *** calav3ra has quit IRC[21:56:05] <HuntsMan> zero size?[21:56:13] <HuntsMan> you created a texture with zero size?[21:56:29] <aep> hm. actually... no that isnt it[21:56:36] <aep> the size doesnt fit, but its still 100x100[21:56:57] <HuntsMan> fit?[21:57:24] <aep> well the target is larger[21:57:59] <HuntsMan> did you setup glViewport accordingly?[21:58:07] <aep> no[21:58:26] <aep> glViewport and the texture size do not fit as well[21:58:31] <aep> i set a larger glViewport[21:59:24] <aep> fixing...[22:01:43] *** cplusplus has joined ##OpenGL[22:03:44] *** olive1ra_ has joined ##OpenGL[22:04:22] *** NevroPus has joined ##OpenGL[22:04:48] <fusi> whats that trick again for glGenerateMipmapEXT on ATI hw?[22:06:01] *** elite01 has quit IRC[22:07:10] <aep> this is extremly confusing[22:07:37] <aep> no matter how large of an area i paint on the buffer, it'll always be completly one color when i use it[22:08:04] <aep> if i have a 20x20 buffer and paint a green rect of 10x10, i'd expect the result to be a pattern at best[22:08:11] <aep> but its all green[22:08:16] <aep> even if i just paint a single pixel[22:09:20] <aep> oh horror[22:10:35] *** XT95__ has joined ##OpenGL[22:11:19] *** Yustme has quit IRC[22:11:27] *** XT95_ has quit IRC[22:11:39] <fusi> aep: bad texture coords (all zero?)?[22:12:05] <aep> i checked. it's 100x100[22:12:23] <HuntsMan> aep: better show some code[22:12:28] <aep> well thats what i passed to glTexImage2D at least[22:12:43] <aep> ok, will make a testcase, give me a minute to extract the gl code[22:16:55] <NoLimitz> whew[22:17:10] <NoLimitz> turns out, it was c++ memory management, i used another texture loading class[22:17:15] <NoLimitz> and it worked ...[22:17:27] <NoLimitz> the latter might have been more memory efficient[22:17:28] <NoLimitz> :)[22:17:56] <MatthiasM> NoLimitz: do you free the texture after uploading it with gltexImage2D ?[22:18:14] <NoLimitz> MatthiasM, yes, i did[22:18:27] <MatthiasM> strange - what lib where you using before ?[22:18:27] <NoLimitz> and i still do :)[22:18:31] *** tokemonstah has joined ##OpenGL[22:18:41] <NoLimitz> some example i found on videotutorialsrock.com[22:18:44] <MatthiasM> maybe it overwrote memory[22:18:48] <NoLimitz> probably[22:18:56] *** cplusplus3 has quit IRC[22:19:02] <MatthiasM> because it's highly unlikly that a two 256x256 textures exhaust your memory[22:19:15] <MatthiasM> even if you store each pixels as 4xdouble :)[22:19:23] <NoLimitz> yes:)[22:19:33] <NoLimitz> well, now i can focus on other problems...[22:19:52] <MatthiasM> btw - are you working on linux ?[22:19:53] <NoLimitz> i need to go read a lighting tutorial, so i can position some lights :)[22:19:56] <NoLimitz> no, windows[22:20:12] <MatthiasM> NoLimitz: try lighthouse3d[22:20:28] <NoLimitz> ok i shall[22:22:06] <aep> i hope this is good enough http://codepad.org/4iJ1txM7[22:22:21] <aep> if not i can propably make it actually run with glut[22:22:39] *** groton has joined ##OpenGL[22:23:03] <aep> thats extracted from a larger codebase. you can assume everything starting with d-> is properly defined.[22:23:10] <aep> (and just ignore it)[22:23:19] <MatthiasM> aep: you don't have texture coordinates when drawing your texture[22:23:29] <aep> erm, i dont even know what that is[22:23:35] <MatthiasM> and why do you switch the context ?[22:23:40] <MatthiasM> aep: gltexCoord[22:23:59] <MatthiasM> without it all your vertices have the same coord -> you get only one texel of your texture[22:24:01] <aep> becouse thats C++, and states have to bve per object[22:24:08] <aep> ow[22:24:20] <aep> that didnt apear in any tutorial[22:24:22] <HuntsMan> aep: states are what?[22:24:34] <MatthiasM> you should not call glXMakeCurrent when not needed - it's slow[22:24:47] <aep> i see, yeah i'll optimise it out when not needed[22:24:56] <aep> HuntsMan: like what you're currently drawing on[22:25:12] <MatthiasM> aep: a standard GL_TEXTURE_2D has coords 0...1 - read the red book for texture mapping examples[22:25:27] <aep> will do, thank you[22:26:46] *** twist__ has joined ##OpenGL[22:27:46] <NoLimitz> MatthiasM, one more quick question : can i have , let's say GL_LIGHT3 and GL_LIGHT4 active, but not 0,1,and 2?[22:27:58] <MatthiasM> NoLimitz: yesa[22:27:58] <NoLimitz> or is it mandatory to use them in ascending order?[22:27:58] *** b0000 has joined ##opengl[22:28:00] <NoLimitz> ok[22:28:01] <NoLimitz> thx[22:28:21] <MatthiasM> but lights can be changed per object - the max number of lights only apply per object[22:28:54] <MatthiasM> and try to keep the light count as low as possible - it can eat performance[22:29:13] <MatthiasM> *count of enabled lights[22:29:27] *** elite01 has joined ##opengl[22:36:38] *** wisey has joined ##OpenGL[22:37:53] *** matrium- has joined ##OpenGL[22:37:58] <matrium-> hi[22:38:12] <matrium-> I have a problem using my custom shader[22:38:15] <NoLimitz> erm, shouldn't enabling light with no light sources result in a very "dark" scene?[22:38:28] <aep> aaah! now i get it[22:38:42] <MatthiasM> NoLimitz: the red book has a very good explaination for FF lighting[22:38:46] <NoLimitz> ok[22:38:49] <matrium-> I'm linking glew32.lib, but my glCreateShader and glCreateShaderObjectARB are both null pointers[22:38:51] <NoLimitz> i shall read it[22:38:56] <NoLimitz> btw nice name...red book :)))[22:38:57] <aep> that all makes a lot more sense now.[22:39:11] <MatthiasM> matrium-: did you check if the extensions are supported ?[22:39:12] *** qeed has joined ##opengl[22:39:16] <aep> thanks again for your patience[22:39:42] <MatthiasM> matrium-: glew has global booleans which you can check[22:40:06] <matrium-> It's 9000 series nvidia card, so i guess it should[22:40:34] <MatthiasM> matrium-: did you initialize glew ?[22:40:41] *** mm765^sleep is now known as mm765[22:40:49] <matrium-> no, do I? ;-)[22:40:56] <MatthiasM> well ....[22:41:05] <matrium-> guess that's the problem[22:41:38] <matrium-> ahh, thanks alot[22:41:39] <MatthiasM> but you should always check if extensions are supported - and if your app doesn't work without an extension - then print an error and quit instead of crashing[22:41:41] <matrium-> works fine now[22:44:17] *** twist_ has joined ##OpenGL[22:44:24] <fusi> glGenerateMipmapEXT doesnt appear to be working for me[22:44:38] <MatthiasM> fusi: I had some issues with it too[22:44:49] <MatthiasM> fusi: try GL_GENERATE_MIPMAPS_SGI[22:46:52] <fusi> opengl::TexParameter(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE); works, but its not ideal[22:47:47] <MatthiasM> why not ?[22:48:08] <fusi> GL_GENERATE_MIPMAP automatically recalculates the mipmaps on dynamic textures[22:48:13] *** b0000 has quit IRC[22:48:21] *** b0000 has joined ##opengl[22:48:51] <fusi> (i dont want that)[22:49:27] <fusi> glGenerateMipmapEXT only calculates the mipmaps when you call it[22:49:35] <fusi> much nicer[22:49:52] *** davidc__ has quit IRC[22:50:06] *** Eforen has joined ##opengl[22:51:02] *** Ingenu has quit IRC[22:51:15] <aep> oh noes. implementing FBOs made performance drop significantly :([22:51:26] <aep> its 4 times slower[22:51:37] <fusi> ohnhoes[22:52:44] <MatthiasM> aep: with or without context switches ?[22:52:58] <aep> without[22:53:04] <aep> it uses memcpy? oO[22:53:06] <MatthiasM> and to what did you compare the performance ?[22:53:28] *** Renderwahn has quit IRC[22:53:33] <aep> to double buffering with glxSwapBuffers[22:53:51] <aep> wich was already 2 times slower then XCopyArea[22:53:59] <aep> but XCopyArea only works for nvidia cards[22:54:00] <MatthiasM> well - if you add additional rendering operations - it will get slower[22:54:34] <aep> actually callgrind says most abusive was memcpy[22:54:40] <MatthiasM> and double buffering is the fasted using glxSwapBuffers compared to manual buffering[22:54:48] <aep> 39000 calls for 2 repaints? uh oh[22:55:03] <MatthiasM> huh?[22:55:07] <MatthiasM> post the log[22:55:07] *** pietia has quit IRC[22:55:11] <aep> okay[22:55:19] <TheFlash> On on channel![22:55:21] *** amz has joined ##opengl[22:55:28] *** scai has left ##opengl[22:56:20] <matrium-> now I got another problem[22:56:29] <TheFlash> Why would glxSwapBuffers call memcpy?[22:56:42] <aep> no, fbos+[22:56:46] <TheFlash> Unless using SW rendering?[22:56:52] <aep> its direct[22:56:58] <aep> ie hardware[22:56:59] <aep> http://codepad.org/sqQtWNHc[22:57:04] <fusi> dma[22:57:04] <aep> thats the callgrind output[22:57:25] <aep> glxSwapBuffers doesnt, but something i have now with the FBO double buffer does[22:57:41] <aep> maybe i'm missreading that[22:57:46] *** twist_ has quit IRC[22:58:01] <matrium-> my vertex and fragment shaders compile, can be attached, the program can be linked, glIsProgram returns true, but glUseProgram failes with an "Unknown Error"[22:58:35] *** twist__ has quit IRC[22:58:53] *** lewymati has quit IRC[22:59:39] <MatthiasM> matrium-: check the info log[22:59:40] *** twist_ has joined ##OpenGL[22:59:55] <MatthiasM> aep: where do you see the memcpy calls ?[23:00:18] <TheFlash> I saw one, called by Freetype.[23:00:24] <aep> memset and memcpy. what viewer do you use? i use kcachegrind, its right on top of the list on the left[23:00:31] <aep> one?[23:00:45] <MatthiasM> it's only called by freetype[23:00:46] <aep> i see 50 million calls to memset[23:00:57] <aep> err wrong number[23:00:59] <aep> 17000[23:01:08] <MatthiasM> and memset only by XauDisposeAuth[23:01:14] <TheFlash> Memset is called by XauDisposeAuth[23:01:20] <aep> well what viewer do you use?[23:01:36] <aep> i see entry points into GlCore but no function names[23:01:36] <TheFlash> My web browser.[23:01:45] <aep> oh you can actually read that?[23:02:17] <MatthiasM> I see ne memset calls from any GL function[23:02:30] <aep> becouse you see no gl functions[23:02:40] <aep> there are none, its unresolved entry points[23:02:47] <aep> this is the nvidia binary driver[23:03:04] <MatthiasM> and memcpy is only called by freetype and your xlib[23:03:06] <aep> i have no clue were kcachegrind gets them from[23:03:32] <MatthiasM> I thjink you use the wrong debugging tool[23:03:47] <aep> wait[23:04:15] <aep> http://omploader.org/vMTRlZw[23:04:20] <TheFlash> Or you gave us wrong file.[23:04:24] *** HuntsMan has quit IRC[23:04:29] <MatthiasM> lol[23:04:52] <MatthiasM> well - I don't read the 2nd file - already spend time on the first[23:05:16] <aep> well i dont think i did[23:05:44] *** groton___ has quit IRC[23:06:21] <aep> but yeah i see what you mean..[23:06:23] <aep> weird[23:08:46] <aep> the gprof output makes even less sense[23:09:10] <MatthiasM> what are you trying to do anyway ?[23:09:16] <aep> double buffering[23:09:24] <MatthiasM> glxSwapBuffers[23:09:27] <aep> flickers[23:09:43] <aep> and you need to redraw the entire backbuffer each swap[23:09:50] <aep> there is no way to only swap parts[23:09:50] <MatthiasM> and?[23:09:58] <aep> thats expensive[23:10:05] <MatthiasM> every 3d app does it[23:10:11] <aep> yes, thats ok for them[23:10:30] <aep> becouse they run in the forground and users expect them to claim the entire machines resources[23:10:53] <aep> this is a gui toolkit that has an optional gl renderer (basicly becouse XRender sucks)[23:11:21] <aep> so it needs to be extremly low on resource usage[23:11:24] <MatthiasM> my UI toolkit uses simple double buffering[23:11:37] <aep> if a button click makes the app pop up in the cpu usage list, its already to much[23:12:06] *** davidc__ has joined ##opengl[23:12:34] <aep> which is one reason why it uses 100% CPU when idle i gues[23:12:50] <MatthiasM> no - that's bad drivers[23:12:58] <MatthiasM> on my system it uses 0%[23:13:02] <MatthiasM> because vsync works[23:13:15] <aep> sure, if i only had to work with nvidia i could just use glxpixmap[23:13:40] <aep> but thats might be a significant difference between our toolkits[23:13:42] *** wisey7 has joined ##OpenGL[23:14:14] <aep> meh, even xrender is faster then this now[23:14:21] *** matrium- has quit IRC[23:14:34] <aep> i must be doing something really wrong, but i fail to get gprof output and thats all i can read[23:15:00] <aep> oh this is an intel card btw[23:15:04] <aep> exteremly crap[23:15:18] <aep> but half life runs on it so users expect it to run a toolkit, dont they?[23:16:30] *** twist_ has quit IRC[23:16:51] *** reprore_ has quit IRC[23:17:07] *** GuShH has quit IRC[23:17:34] <aep> "runs"[23:17:35] <aep> hehe[23:17:44] *** wisey7 has quit IRC[23:18:45] <aep> yet, i'm almost sure this must be a problem with my own code. i cant belive opengl would waste so much CPU resources for nothing[23:20:52] *** Spkka` has joined ##OpenGL[23:22:50] *** Spkka` has quit IRC[23:24:17] *** macrocat has joined ##opengl[23:28:40] *** XT95__ has quit IRC[23:32:11] *** kbotnen_ has quit IRC[23:33:44] <aep> do i actually gain anything from drawing only parts of a texture, or is it just a waste of time?[23:36:49] *** wisey has quit IRC[23:38:33] *** GX has quit IRC[23:39:59] <NoLimitz> hmm, i wrote this piece of junk code[23:40:01] <NoLimitz> http://cpp.ninjacodemonkeys.org/5023[23:40:08] <NoLimitz> i think it should work...?:)[23:43:35] *** pietia has joined ##OpenGL[23:44:03] *** NoLimitz has quit IRC[23:44:27] *** NoLimitz has joined ##OpenGL[23:44:54] *** groton has quit IRC[23:45:36] *** Bollinger has quit IRC[23:47:10] <NoLimitz> erm, no comments :|[23:54:32] *** GuShH has joined ##OpenGL[23:56:06] *** cplusplus2 has joined ##OpenGL[23:57:27] *** eXtronuS_ has quit IRC