May 27, 2008 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
May 27, 2008 [00:00:19] <rsaltini> not really simple[00:00:43] <RTFM_FTW> and not at all worthwhile on a renderer incapable of depth texturing[00:01:30] *** TheLorax has quit IRC[00:02:12] <rsaltini> yes[00:02:18] <rsaltini> you are true[00:02:19] <MatthiasM> but it might work :DD[00:03:42] <RTFM_FTW> highly doubtful[00:03:59] <rsaltini> anyway, only for my obstinacy, not because it has some sense: is it possible to set up opengl for implementing via software all hardware lacks?[00:05:20] <MatthiasM> RTFM_FTW: stencil is part of GL 1.1 so it will work - iven if it's slow[00:05:34] *** enoex has joined ##OpenGL[00:07:04] <rsaltini> yes[00:07:28] <prophile> RTFM_FTW: GLSL or ARB_(vertex|fragment)_program?[00:08:56] <RTFM_FTW> yes its a part of GL 1.1 but I wouldn't consider this a viable path[00:09:12] <RTFM_FTW> prophile for what?[00:09:20] <rsaltini> ARB_vertex_program[00:09:28] <rsaltini> i have[00:09:31] <RTFM_FTW> not for anything I mentioned[00:09:44] *** stringfellow has quit IRC[00:09:57] <RTFM_FTW> shadow compare in the programmable pipeline doesn't occur in the vertex processing stage[00:10:47] <RTFM_FTW> hence you need ARB_fragment_program support for ARB_fragment_program_shadow (i.e. using the driver supplied shadow compare in shaders)[00:11:11] <RTFM_FTW> and you need support for FF fragment processing in order to do the shadow compare specified in ARB_shadow[00:12:10] <RTFM_FTW> EXT_shadow_funcs simply specified a more flexible set of comparison functions to ARB_shadow and ARB_shadow_ambient simply allows one to specify a shadow compare failure value (i.e. N != 0 which is the default case)[00:14:09] <rsaltini> thank you for all[00:14:51] <rsaltini> by now i give it up[00:15:41] <prophile> RTFM_FTW: material lighting on a 3D engine[00:15:50] <prophile> given the choice between the two, which would you use?[00:15:57] <MatthiasM> GLSL[00:16:43] <RTFM_FTW> considering that one modern hardware anything beyond the programmable pipeline is only an illusion I think the answer is clear[00:17:15] <prophile> GLSL then.[00:17:27] *** DaGypzie has joined ##OpenGL[00:18:30] *** Jupp3 has quit IRC[00:19:48] *** DaGypzie has left ##OpenGL[00:20:55] *** rsaltini has quit IRC[00:23:16] *** prophile has quit IRC[00:24:26] *** elite01 has quit IRC[00:28:19] *** replor has quit IRC[00:32:06] *** prophile has joined ##opengl[00:33:35] *** prophile has quit IRC[00:34:28] *** TheChuckster has quit IRC[00:38:13] *** thesquib has quit IRC[00:38:20] <KU0N> bye everybody[00:38:24] *** KU0N has quit IRC[00:39:13] *** Diagmato has joined ##OpenGL[00:40:03] *** korff_ has quit IRC[00:40:06] *** charlie5 is now known as charlie_zzz[00:40:44] *** neoneurone has quit IRC[00:41:44] *** mm765^away is now known as mm765[00:45:21] *** Walt has joined ##opengl[00:49:07] *** braahyan has quit IRC[00:49:47] *** m4ggus has quit IRC[00:51:55] *** m4ggus has joined ##OpenGL[00:54:58] *** braahyan has joined ##OpenGL[00:55:36] *** juanmabc has quit IRC[01:05:29] *** LtJax has quit IRC[01:14:59] *** LordMetroid has quit IRC[01:15:27] <deniz_> I'm drawing alot of vertices (using GL_LINE_STRIP) which makes my app go slow... How can I optimize it ?[01:15:54] <MatthiasM> draw triangles[01:17:14][01:17:36] <MatthiasM> how many lines do you draw ?[01:17:41] <deniz_> Alot.[01:17:48] <MatthiasM> 5?[01:17:54] <deniz_> store them in i std::list[01:18:08] <MatthiasM> use std::vector[01:18:28] <MatthiasM> std::list is one of the slowest containers[01:18:41] <deniz_> well, when drawing a line of the two points are to far from each other I fill the gap with extra vertices.. to get a smoother feeling[01:18:45] <deniz_> okey[01:18:49] <deniz_> I'll try[01:19:04] <MatthiasM> and use atleast VAs[01:21:09] <deniz_> too slow..[01:21:34] <deniz_> probably thousands of vertices..[01:21:53] *** HuntsMan has quit IRC[01:22:34] <MatthiasM> if you don't know how many you draw then don't complain[01:22:48] <deniz_> well, I did say I'm drawing alot[01:23:12] <MatthiasM> my app draw 700k triangles per frame - so what ?[01:23:20] <deniz_> it's a painting app, so could be alot of drawing.[01:27:07] <RTFM_FTW> how are you rendering these?[01:27:24] <RTFM_FTW> more specifically how are you submitting them?[01:28:49] <deniz_> hmm[01:29:18] <deniz_> just loop through and render using glBegin LINE_STRIP ...[01:29:23] <deniz_> nothing fancy...[01:29:24] <RTFM_FTW> for example look into using VBO[01:30:01] <RTFM_FTW> there is an example of that here -- http://web.cecs.pdx.edu/~feelgood/Source/FBO.c[01:30:19] <deniz_> ok, thanks[01:30:20] <deniz_> cheking.[01:30:37] <RTFM_FTW> a completely trivial example[01:31:14] <RTFM_FTW> you should be able to trivially adapt the example given above to your system w/o too much trouble[01:35:24] <deniz_> maybe it would be easiest to render everything on a texture..[01:36:11] *** MatthiasM has quit IRC[01:36:18] *** MatthiasM has joined ##opengl[01:36:24] <RTFM_FTW> yeah that too[01:37:29] <RTFM_FTW> the above example trivially illustrates this[01:40:56] *** Arc_ is now known as Arc[01:41:32] *** amz has joined ##opengl[01:46:40] *** Xmas| has joined ##OpenGL[01:47:19] *** rutski has quit IRC[01:49:13] *** m4ggus_ has joined ##opengl[01:58:30] *** Dew420 has quit IRC[01:58:46] *** m4ggus has quit IRC[01:59:13] *** m4ggus_ has quit IRC[01:59:28] *** dv_ has quit IRC[02:01:45] *** dvoid has quit IRC[02:03:01] *** Dew420 has joined ##OpenGL[02:04:25] *** m4ggus has joined ##opengl[02:10:26] *** m4ggus has quit IRC[02:17:11] *** ViRUS has quit IRC[02:18:57] *** m4ggus has joined ##opengl[02:23:00] *** bbeausej has quit IRC[02:24:15] <garou> I was just thinking about multiple and maybe recursive cameras. To have a camera in "the HUD" (being a rectangle mapped onto the screen, I forst render the scenery normally, then adjust the viewport and draw again with other model view transformations?[02:29:40] *** m4ggus has quit IRC[02:29:52] *** m4ggus has joined ##opengl[02:40:52] *** mm765 has quit IRC[02:44:32] *** Xmas| has quit IRC[02:45:29] *** Suprano has quit IRC[02:49:40] *** mm765 has joined ##opengl[02:59:13] *** TheLorax has joined ##opengl[02:59:40] *** Diagmato has quit IRC[03:09:28] *** rutski has joined ##OpenGL[03:10:48] *** NeoThermic has joined ##OpenGL[03:12:12] <NeoThermic> how best to handle the ability for players to "click" on objects in a 3D world? Currently I've got a player and a camera that follows the player (third person perspective). I just can't think of a decent way to allow the player to click on objects.[03:14:00] <NeoThermic> if it were first-person, I'd make a vector from the x,y of the mosue click with a z of 0 to x,y,z, where z is how far I'd like to check for objects. I'd then see if anything is colliding with that vector. However, mapping that into a third person camera doesn't work, since the players viewpoint is different from the camera viewpoint[03:19:33] *** ginoman has joined ##OpenGL[03:21:23] *** Amorphous has quit IRC[03:22:14] *** Amorphous has joined ##opengl[03:35:09] *** rnx has left ##opengl[03:42:31] *** hibread_ is now known as hibread[03:45:29] *** poseidon has quit IRC[03:51:04] *** bbeausej has joined ##OpenGL[04:02:12] <Ragnarok> isn't quake3 fre now?[04:03:16] *** servus_ has quit IRC[04:03:29] <jparishy> no[04:03:32] <jparishy> the source is free[04:03:46] <jparishy> but the assets aren't[04:03:54] <Ragnarok> wtf[04:04:06] <jparishy> but q3 is kick ass[04:04:23] <Nayena> the models and such[04:04:26] <Ragnarok> thats gay, its free but u can't have free access to the resources o_O[04:04:40] <Nayena> why?[04:05:09] <jparishy> I swear the iPhone will kill me. I can't get my textures which have transparent parts to draw transparent. They are just black on those parts[04:05:12] <jparishy> i have blending enabled[04:05:14] <jparishy> etc[04:06:02] <jparishy> yet a friend of mine says he has no problems[04:06:31] <jparishy> are there any glEnable() flags that conflict with GL_BLEND?[04:12:16] *** m4ggus has quit IRC[04:12:30] <NeoThermic> you've got GL_RGBA?[04:14:24] <RTFM_FTW> make sure you are using an alpha based internalFormat, format and type combination and that you are using a reasonable blending function[04:15:00] <RTFM_FTW> sA, 1 - sA for src, dst function for example[04:15:13] <jparishy> Oh, yeah, GL_RGBA yes[04:15:49] <Spark> when is deferred shading a good idea?[04:15:56] <jparishy> glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);[04:16:08] <jparishy> ^^ using that[04:17:00] <Spark> i've been playing close attention to the gta4 engine[04:17:20] <jparishy> I'm using SOIL so the loading is handled for me[04:18:52] <RTFM_FTW> make sure that you aren't sorting FTB and that you render opaque objects first and anything blended last[04:19:29] <RTFM_FTW> for TBDRs you don't need to bother with sorting by Z level[04:19:56] <RTFM_FTW> I'd imagine that most of this stuff is specified in Apple's iPhone documentation[04:21:04] <Spark> i've been wondering about how to fade things out at the edge of their rendering distance, how about depth sorting them, then from back to front, rendering them to a rtt (final colour and depth info) and then rendering that texture in the right place with alpha blending[04:21:33] <Spark> that way there would be no brokenness due to z buffering not working with alpha blending[04:22:19] <Spark> would that be inefficient?[04:23:22] <jparishy> Fixed, thanks RTFM_FTW, depth_test was enabled and it was screwing up the drawing order. all works now.[04:24:13] <RTFM_FTW> no problem[04:25:51] <RTFM_FTW> and yes depth testing will screw w/ your additive blending due to its performing hidden surface removal before fragment processing[04:26:34] <RTFM_FTW> that stage will occur (in the TBDR case) before texture sampling or fragment color[04:37:25] *** braahyan has quit IRC[04:43:19] *** braahyan has joined ##OpenGL[04:48:47] *** eggauah has quit IRC[04:54:08] *** TheLorax has quit IRC[05:02:38] *** Kasu has joined ##OpenGL[05:06:22] *** mattn2|home has quit IRC[05:07:11] *** jparishy has quit IRC[05:09:33] *** Kasu has quit IRC[05:33:44] *** braahyan has quit IRC[05:35:10] <NeoThermic> any further ideas on my problem?[05:42:33] *** lolage0 has quit IRC[05:44:05] *** mediogre has joined ##OpenGL[05:49:32] *** mattn2|home has joined ##OpenGL[05:52:47] *** nplus has quit IRC[05:54:10] *** bbeausej has quit IRC[05:54:45] <mm765> NeoThermic: the players viewpoint isnt different, the playercharacter's viewpoint is but that doesnt matter since its the player that clicks, not the character[05:56:21] <NeoThermic> hmm[05:57:51] *** ginoman has quit IRC[06:00:00] <NeoThermic> of course[06:00:08] <NeoThermic> that might just work perfectly[06:01:29] *** mediogre has quit IRC[06:06:59] *** BahamutZERO has quit IRC[06:07:47] *** BahamutZERO has joined ##OpenGL[06:08:46] *** BahamutZERO has quit IRC[06:18:07] *** Dew420 has quit IRC[06:43:26] *** amz has quit IRC[06:44:04] *** fragged has joined ##OpenGL[06:44:43] *** Inside has joined ##OpenGL[06:44:54] <Inside> komrades, I hurd you do graphics? :o[06:45:50] <Inside> Anyone have a good tutorial explaining what normals are and how to calculate them?[06:46:28] <fragged> G'day guys, I have a problem with a class I've written in Python/PyGame/PyOpenGL, the bug means that rotating or changing the color of one thing changes it to all (ie with two instances, setting the first's alpha to 0.5 will set the second's to 128 also) code is here http://www.pastebin.ca/1030740 - can anyone help?[06:51:23] * Inside peers at his code.[06:51:38] <Inside> Crud, I'm going to have to generate normals for each one of these vertices.. D:[06:52:32] *** ajww has joined ##OpenGL[06:52:43] *** HuntsMan has joined ##opengl[06:58:10] <fragged> Inside, could you see anything wrong? I'm new to OpenGL, I know its inside that code I just cannot find it, been looking for like 2 hours so I figure fresh, more experienced eyes will probably pick it out straight away :E[07:00:30] *** mm^away has joined ##opengl[07:00:32] <Inside> Me know OpenGL? D:[07:00:39] <Inside> I'm using Ogre3D myself[07:00:44] <Inside> PyOgre3d[07:01:51] *** braahyan has joined ##OpenGL[07:03:05] *** Dew420 has joined ##OpenGL[07:03:06] <Inside> um..[07:03:16] <Inside> Oh, you're setting the color of one object[07:03:22] <Inside> and then the object you draw directly after is the same color?[07:03:40] <Inside> you're not "resetting" the color to the default draw color after you draw the first object.[07:04:03] <Inside> at least I think that's what going on if I'm understanding your problem.[07:04:20] <Inside> since after you call glColor4fv() all calls that follow will use the value passed into that.[07:07:54] *** braahyan has quit IRC[07:11:09] <fragged> ah alright, thanks for the pointers; I'm new to OpenGL :)[07:14:02] *** braahyan has joined ##OpenGL[07:17:36] *** mm765 has quit IRC[07:22:55] *** braahyan has quit IRC[07:26:16] *** aalex has quit IRC[07:28:30] *** braahyan has joined ##OpenGL[07:37:33] *** braahyan has quit IRC[07:41:57] *** Tenac has joined ##OpenGL[07:43:02] <Tenac> glGetString(GL_VERSION) returned 1.3.0 - Build 4.14.10.4342, is that out of date?[07:43:33] *** braahyan has joined ##OpenGL[07:49:29] <dindinx> Tenac: only about 10 years[07:49:30] *** braahyan has quit IRC[07:49:44] <dindinx> Tenac: current OpenGL version is 2.1.x[07:51:18] <Tenac> Can I download anything or would i just need to go out and buy a new graphics card?[07:53:18] *** rsaltini has joined ##OpenGL[07:54:21] <dindinx> Tenac: download up to date drivers for your card.[07:55:29] *** braahyan has joined ##OpenGL[07:56:45] <rsaltini> i am on ubuntu 7.10, using mesa3d 7.0.1[07:57:16] <rsaltini> if I set option "Accel" my GL_VERSION is "1.3 Mesa 7.0.1"[07:58:13] <rsaltini> instead if i set option "NoAccel" i get "1.4 (2.1 Mesa 7.0.1)"[07:58:19] <rsaltini> why?[07:58:28] *** charlie55 has joined ##OpenGL[07:58:42] <dindinx> rsaltini: everything is explained![07:59:23] <dindinx> rsaltini: your hardware supports up to OpenGL 1.3, and Mesa can emulate 2.1 in software (not accelered)[08:00:09] <rsaltini> ok[08:00:26] <rsaltini> and what does 1.4 mean?[08:01:03] *** scy has joined ##opengl[08:01:28] <rsaltini> 1.4 (2.1 Mesa 7.0.1) what does it mean[08:01:29] <rsaltini> ?[08:01:43] <rsaltini> it emulates 1.4 or 2.1?[08:02:07] <dindinx> Mesa 7.0.1 emulates 2.1[08:02:52] <rsaltini> and that "1.4" what does it mean?[08:03:18] *** Tenac has left ##OpenGL[08:03:44] <dindinx> that with "NoAccel" your driver implements OpenGL 1.4[08:09:48] <rsaltini> and opengl emultes the remaining part?[08:12:02] *** charlie_zzz has quit IRC[08:14:27] *** Inside has quit IRC[08:14:53] <rsaltini> is it possible having opengl using both dri and software emulation?[08:14:56] *** charlie555 has joined ##OpenGL[08:15:06] *** charlie555 is now known as charlie_zzz[08:19:13] *** braahyan has quit IRC[08:24:10] *** mattn2|home has quit IRC[08:24:49] *** Roderic has joined ##OpenGL[08:24:50] *** Roderic is now known as Ingenu[08:25:01] *** braahyan has joined ##OpenGL[08:27:58] *** andikr has joined ##OpenGL[08:28:33] *** predaeus has joined ##opengl[08:29:23] *** charlie55 has quit IRC[08:31:30] *** rutski has quit IRC[08:31:47] *** rutski has joined ##OpenGL[08:43:56] *** scy has left ##opengl[08:46:22] *** rutski has quit IRC[08:47:03] *** DobosCake has quit IRC[08:57:36] *** blbmp has quit IRC[08:59:32] *** neoneye has joined ##OpenGL[09:22:38] *** [AD]Turbo has joined ##OpenGL[09:26:37] *** korff_ has joined ##OpenGL[09:27:24] *** nathan_ has joined ##OpenGL[09:28:21] <[AD]Turbo> yo[09:32:25] *** korff_ has quit IRC[09:33:35] *** groton has joined ##OpenGL[09:45:35] *** sohail has quit IRC[09:49:28] *** braahyan has quit IRC[09:55:28] *** braahyan has joined ##OpenGL[10:01:48] *** kenws has joined ##OpenGL[10:06:09] *** korff has joined ##OpenGL[10:17:59] *** belou has joined ##OpenGL[10:24:05] *** neoneye has quit IRC[10:24:15] *** Plagman has quit IRC[10:24:24] *** Plagman has joined ##OpenGL[10:34:01] *** charlie55 has joined ##OpenGL[10:40:43] *** braahyan has quit IRC[10:45:49] *** braahyan has joined ##OpenGL[10:47:29] *** charlie_zzz has quit IRC[10:54:32] *** karabash has joined ##OpenGL[10:54:33] *** braahyan has quit IRC[11:00:14] *** BahamutZERO has joined ##OpenGL[11:00:34] *** braahyan has joined ##OpenGL[11:03:31] *** braahyan has quit IRC[11:09:02] *** braahyan has joined ##OpenGL[11:10:41] *** neoneye2 has joined ##OpenGL[11:14:51] *** braahyan has quit IRC[11:18:38] *** kaotrix has joined ##OpenGL[11:21:09] *** braahyan has joined ##OpenGL[11:23:25] *** Rangar has quit IRC[11:23:26] *** braahyan has quit IRC[11:27:57] *** dvoid has joined ##OpenGL[11:28:47] *** prophile has joined ##opengl[11:29:36] *** braahyan has joined ##OpenGL[11:32:38] *** braahyan has quit IRC[11:37:17] *** huperniketes has quit IRC[11:37:44] *** braahyan has joined ##OpenGL[11:38:51] *** huperniketes has joined ##OpenGL[11:43:10] *** braahyan has quit IRC[11:48:02] *** groton has quit IRC[11:48:28] *** rsaltini has quit IRC[11:49:05] *** braahyan has joined ##OpenGL[11:50:45] *** groton has joined ##OpenGL[11:55:06] *** braahyan has quit IRC[11:56:36] *** rsaltini has joined ##OpenGL[11:58:27] *** Ademan has quit IRC[11:59:13] *** Ademan has joined ##OpenGL[12:00:32] *** braahyan has joined ##OpenGL[12:06:29] *** braahyan has quit IRC[12:08:20] <rsaltini> is it possible setting up opengl in this way: it uses direct rendering up to it can and emulate by software what hardware can't do?[12:09:25] <TenOfTen> yes[12:10:22] <TenOfTen> i know the old intel driver did that before x3000[12:11:37] *** braahyan has joined ##OpenGL[12:14:17] *** braahyan has quit IRC[12:19:17] <rsaltini> if I set option "accel" GL_VERSION returns to me "1.3 Mesa 7.0.1"[12:19:40] <rsaltini> if I set option "NoAccel" i get "1.4 (2.1 Mesa 7.0.1)"[12:19:44] *** braahyan has joined ##OpenGL[12:20:02] <rsaltini> but in the secondo case nothing is accelerated[12:20:19] <TenOfTen> but it is in the first case?[12:20:37] <TenOfTen> secondo, your italina shines thru ;)[12:23:47] *** nathan_ has quit IRC[12:25:39] *** nathan_ has joined ##OpenGL[12:31:33] *** Suprano has joined ##OpenGL[12:34:52] *** braahyan has quit IRC[12:39:16] *** servus has joined ##opengl[12:40:19] *** braahyan has joined ##OpenGL[12:43:19] *** braahyan has quit IRC[12:45:38] *** vasoq has quit IRC[12:48:36] *** gotan666 has joined ##OpenGL[12:48:50] *** braahyan has joined ##OpenGL[12:54:52] *** braahyan has quit IRC[13:00:52] *** braahyan has joined ##OpenGL[13:05:59] *** rsaltini has quit IRC[13:19:24] *** huperniketes has quit IRC[13:21:15] *** huperniketes has joined ##OpenGL[13:23:28] *** nathan__ has joined ##OpenGL[13:26:06] *** nathan__ has quit IRC[13:26:13] *** nathan_ has quit IRC[13:29:05] *** nathan_ has joined ##OpenGL[13:32:56] *** nathan_ has quit IRC[13:32:56] *** belou has quit IRC[13:34:57] *** gotan666 has quit IRC[13:36:43] *** scy has joined ##opengl[13:37:16] *** Jernej has joined ##OpenGL[13:41:10] *** JernejL has joined ##OpenGL[13:42:37] *** nplus has joined ##OpenGL[13:43:53] *** nplus has quit IRC[13:45:36] *** Diagmato has joined ##OpenGL[13:51:31] *** braahyan has quit IRC[13:53:00] *** kaotrix has quit IRC[13:54:01] *** belou has joined ##OpenGL[13:55:23] *** JernejL_ has quit IRC[13:57:13] *** braahyan has joined ##OpenGL[13:57:22] *** Jernej has quit IRC[13:58:15] *** elite01 has joined ##opengl[14:02:28] *** braahyan has quit IRC[14:04:43] *** huperniketes has quit IRC[14:05:04] *** pragma_ has quit IRC[14:05:30] <karabash> i dont know why i see both sides surface[14:05:39] <karabash> both are textured[14:05:59] <TenOfTen> youre not culling[14:06:02] <karabash> no[14:06:05] <karabash> for example[14:06:05] <TenOfTen> or you lack normals[14:06:33] <karabash> i can see hill from out and inside[14:06:51] <karabash> but when culling is on only objects are seen from inside[14:06:58] <karabash> terrain is still the same[14:07:15] <karabash> i do not calculate any normals for terrain[14:07:28] <TenOfTen> you cant cull without normals...[14:07:33] <karabash> ooo[14:07:40] <karabash> thanks, respect[14:08:17] <hibread> TenOfTen: culling is not achieved with normals[14:08:18] *** braahyan has joined ##OpenGL[14:08:21] <hibread> its the winding of the vertices[14:09:36] <TenOfTen> okay, so whats wrong?[14:09:47] <karabash> but gl somehow has to know which side to flip[14:09:51] <TenOfTen> i did software culling by checking normal direction from/to eye[14:10:15] <hibread> TenOfTen: if you glEnable( GL_CULL_FACE); and glCullFace( GL_BACK); and also use the default of glFrontFace( GL_CCW); and you seem to be culling the wrong side, it means that the object or model or what ever has a different winding[14:10:38] <TenOfTen> yes[14:10:40] <hibread> each triangles has 3 vertices (given obviously)[14:10:45] <karabash> hibread: i tried with ccw and cw and everything[14:10:57] <hibread> so the winding of those vertices defines the "facing" direction[14:10:59] <karabash> and there are always both sides of surface textured[14:11:24] <hibread> you definitely have glEnable( GL_CULL_FACE) ?[14:11:32] <hibread> and culling one of the sides?[14:11:43] <hibread> and it still wants to render both sides of each polygon?[14:12:41] <karabash> yep[14:12:47] <hibread> TenOfTen: yeah you could use the normal if you wanted to... but the fixed function portion of the hardware pipeline uses vertex winding for culling[14:12:50] <TenOfTen> that means gl culls in screen-space, right?[14:12:54] *** huperniketes has joined ##OpenGL[14:13:00] <karabash> any md2 model is working correctly but terrain is not[14:13:08] <karabash> i mean md2 renders one side[14:13:12] <hibread> yeah, it culls after modelviewmatrix is applied[14:13:17] <TenOfTen> ok[14:13:22] *** rnx has joined ##opengl[14:13:41] <TenOfTen> im sure i did culling in 3d before that transform :) ie pre-opengl[14:14:02] <hibread> karabash: well i can't think of anything else that would force a triangle to be rendered from either side if you have setup how i suggested[14:14:34] <karabash> glEnable(GL_CULL_FACE);[14:14:34] <karabash> glCullFace( GL_FRONT );[14:14:34] <karabash> glFrontFace(GL_CCW);[14:14:35] <hibread> TenOfTen: what happens if each vertex has a different normal? How do you cull triangles then?[14:14:36] <TenOfTen> karabash: some special terrain editing mode in that modeller which makes 2x the polygons for each side?[14:14:37] <karabash> nothing[14:14:49] <hibread> nothing?[14:14:50] <hibread> what do you mean?[14:14:58] <karabash> it draw both sides[14:15:00] <karabash> still[14:15:09] <karabash> texture visible from in-outside[14:15:10] <hibread> screenshot of "both" sides?[14:15:11] <TenOfTen> hibread: i culled based on the planes' normal, not vertex-"normals" (as in gourad)[14:16:20] <hibread> yep, well that would work fine. Its probably essentially the same thing. I'd gather the hardware would do a cross product or some such thing between 2 sets of vectors.. resulting in a similar test you are doing[14:16:45] <hibread> ill bbl[14:16:46] <TenOfTen> i did* :) this was long ago.[14:17:18] <karabash> http://img.wklej.org/v/83691904zrzutekranu.png[14:17:22] <karabash> as You can see[14:17:31] <karabash> all objects are flipped but terrain is not[14:17:53] <TenOfTen> that guy looks mean ;)[14:19:15] <karabash> becouse he is drawed from inside[14:19:22] <karabash> but terrain is not[14:20:26] <TenOfTen> probably bug in your code. move it around, see if it has culling in the wrong place[14:20:34] <karabash> problem is that terrain is covering everything when i am inside the hill and easier should be enable culling than detect collision camera with a terrain[14:21:34] <karabash> there are no actually culling for testing in a code[14:24:36] <TenOfTen> try using a debugger or gl inspector / perfhud[14:25:48] *** nytejade` has joined ##OpenGL[14:26:28] <karabash> maybe it doesnt work with triangle_Strip[14:30:46] <karabash> Why it doesnt work with trianglestrip[14:33:06] <TenOfTen> "Fortunately, OpenGL will automatically rearrange the vertices in a triangle strip to make all of the triangles in the strip consistently clockwise or counterclockwise, depending on the value of glFrontFace()."[14:33:36] <karabash> fortunately[14:33:49] <karabash> but it doesnt work[14:38:14] *** braahyan has quit IRC[14:42:54] *** LordMetroid has joined ##OpenGL[14:43:31] *** braahyan has joined ##OpenGL[14:43:35] *** nytejade has quit IRC[14:45:22] *** scy has left ##opengl[14:45:51] *** elite01 has quit IRC[14:48:08] *** ginoman has joined ##OpenGL[14:50:45] <WhitAnglAtWork> Hi.. I want to render hair (at least even crappily). Each strand is a list of vertices. Should I render a LINE_STRIP for each strand or is there a way to minimize the number of opengl instructions (to render several strands in the same time) ?[14:51:34] <hibread> vbo's with GL_LINES and an index list?[14:51:37] <WhitAnglAtWork> in fact, is there a way to tell opengl that a LINE_STRIP currently breaks ?[14:51:56] <WhitAnglAtWork> GL_LINES shouldn't be faster than line strips, is it ?[14:53:51] <hibread> just like there is no need to use triangle strips, the same would apply for lines[14:54:21] <hibread> lines with an index list should be the fastest implimentation on modern hardware assuming a reasonable "order"[14:54:35] <hibread> hmm although[14:54:36] <WhitAnglAtWork> but each strand is made of several vertices which would render fine with a line_strip[14:54:55] <WhitAnglAtWork> otherwise I'll need to duplicate my indices[14:55:07] <hibread> yeah there is no way to break a line strip another than to stop and start again with a new call[14:55:10] <hibread> as far as i know anyway[14:57:14] <hibread> so yeah... for one gl call to draw a whole heap of lines, i'd personally use GL_LINES with no rendundant vertex data with an index list[14:57:15] *** neoneye2 has quit IRC[14:57:21] <WhitAnglAtWork> and would it be faster to use glMultiDrawElements (or something like that, I don't remember the name) with multiple LINE_STRIPs, or one glRenderElements with lines (with duplicated indices)[14:57:58] *** huperniketes has quit IRC[14:57:59] <WhitAnglAtWork> but GL_LINES would requires redundant indices, isn't it ?[14:58:14] <hibread> yeah[14:58:51] <hibread> bandwidth and data storage shouldn't generally be the limiting factor over transformation though. The rasterization of lines i believe is also pretty dodgy. But i could be wrong on that[14:59:15] <WhitAnglAtWork> mm.. ok, so I might use lines instead of strips[14:59:31] *** huperniketes has joined ##OpenGL[14:59:38] <hibread> so assuming that the lines are sorted nicely, eac vertex will only need to be transformed once due to caching[14:59:48] <hibread> it would be easier too[14:59:55] <WhitAnglAtWork> yep.. I'll try to implement the dual scattering siggraph paper for Hairs :s[15:00:17] <hibread> with triangle strips, you can use degenerate triangles to help stop-start. With lines i can't see a way of doing that[15:00:23] <hibread> got a link?[15:00:34] *** Eforen has quit IRC[15:00:43] <WhitAnglAtWork> http://cg.cs.uni-bonn.de/project-pages/hairmodeling/[15:01:13] <WhitAnglAtWork> I'm just starting :s[15:02:07] <WhitAnglAtWork> brb[15:02:23] <hibread> millions of lines[15:02:56] <WhitAnglAtWork> yep[15:03:42] <hibread> so that is definitely using lines? and not some sort of "small" triangle?[15:04:19] <TenOfTen> nah, you do that with shaders and just a dozen of polygons for the whole head[15:04:48] <WhitAnglAtWork> I would say lines.. I seize their offline version but I didn't get exactly what they do on the gpu[15:05:15] <WhitAnglAtWork> TenOfTen: and you get crappy billboard like results ;)[15:05:41] <WhitAnglAtWork> you should take a look at the videos[15:05:42] <TenOfTen> no no. you can even get moving waves in the hair, just like grass[15:06:09] <WhitAnglAtWork> they wouldn't have been accepted this year to siggraph otherwise :p[15:10:04] *** PainBank has joined ##OpenGL[15:26:15] *** charlie555 has joined ##OpenGL[15:26:25] *** charlie555 is now known as charlie_zzz[15:31:21] *** [AD]Turbo has quit IRC[15:31:21] *** braahyan has quit IRC[15:32:14] *** abionnnn has joined ##OpenGL[15:37:13] *** braahyan has joined ##OpenGL[15:37:24] <alyawn> hi all, I'm a noob when it comes to opengl, so I need to be pointed in the right direction... I have 2 textures that I've loaded and[15:38:13] <alyawn> I have successfully gotten them to display blended using alpha[15:38:41] <alyawn> my question is, how can I remove everyother pixel row from the display output?[15:39:19] <TenOfTen> alyawn: using a stencil[15:39:38] <alyawn> I'd like to remove every-other row from my textures then combine them together and display as one image[15:39:45] *** charlie55 has quit IRC[15:40:03] <alyawn> TenOfTen: thanks I new there would be a mechanism for this[15:40:12] <hibread> alyawn: why are you doing this?[15:40:31] *** Walt has quit IRC[15:40:55] *** Suprano has quit IRC[15:40:56] *** m4ggus has joined ##opengl[15:40:59] <alyawn> it's an effect that I have been asked to produce for some specific hardware[15:41:47] <alyawn> it's important that the rows removed are from the finallized output and not from the (usually smaller) texture[15:42:55] <hibread> so you've blended 2 textures (using multi-texturing) and rendered them to the "Screen" (back buffer)?[15:43:52] *** korff has quit IRC[15:43:57] <alyawn> I've binded 2 textures... the first at 1.0 opacity and the other with 0.5[15:44:08] <alyawn> bound, I should say[15:44:31] <hibread> rendered straight to the whole screen to be displayed?[15:44:34] <Plagman_> I guess the more efficient way to do that would be to have a texture with one row opaque and one row fully translucent[15:44:41] <alyawn> this is 2D, btw[15:44:49] <Plagman_> that you would blend on top of your scene as a third step[15:44:53] <hibread> 2d, 3d, doesn't matter[15:44:57] <Plagman_> using the proper repeating pattern[15:45:04] <Plagman_> without texture filtering[15:45:12] <abionnnn> would bump mapping be the best way to reproduce this real life surface http://www.sxc.hu/pic/m/l/la/ladeon/117090_brushed_metal.jpg[15:45:19] <hibread> alyawn: so what ever you've done now, you want the odd lines to be "black" ?[15:45:35] <Plagman_> that or just have a fragment program that outputs black for odd lines[15:45:36] <Plagman_> or even lines[15:45:58] <hibread> Plagman_: yeah i was going to suggest that[15:46:09] <Plagman_> abionnnn: a very detailed bump/normal map and BRDF-rendering[15:46:12] <alyawn> Plagman: this was my first thought... load the first image, then apply opacity 0.0 to everyother row of the second texture[15:46:35] <alyawn> hibread: no, every-other row is from a different texture[15:46:42] <Plagman_> ah[15:46:57] <Plagman_> you want rows to be picked alternatively from one or the other?[15:47:09] <Plagman_> textures[15:47:30] <alyawn> right, but the "rows" in question need to be actual pixel rows in the resulting display, not necesarilly rows in the textures[15:47:35] <Plagman_> right[15:47:47] <hibread> id be using a fragment shader[15:47:51] <alyawn> so you think I can do a simple mask?[15:47:52] <Plagman_> what you really want then is a fragment shader[15:47:56] <Plagman_> it's the optimal way[15:48:13] <alyawn> fragment shader... sounds cool, I'll look it up[15:48:26] <Plagman_> if you want to go for the simpler to setup and less dependent on advanced GL capabilities you just draw lines in a stencil buffer[15:48:31] <alyawn> what versions of opengl do those exist?[15:48:32] <Plagman_> and render the second texture with stencil test enabled[15:49:19] <alyawn> Plagman_:that might be the first step (stencil), then I can get fancy with the fragment shader if it's supported[15:49:22] <Plagman_> alyawn: those are generally exposed through extensions but GL 2.1 is guaranteed to have fragment shader support[15:49:40] <Plagman_> if you're not worried about performance then go for stencil[15:49:52] <Plagman_> i.e. if you only have to do it once per redraw and not 120 times a second or something[15:49:57] <Plagman_> in fact[15:50:04] <abionnnn> Plagman_: That's the one! Thank you.[15:50:05] <alyawn> eventually, I will be worried about performance, but for now, I'd just like to see it work[15:50:21] <Plagman_> once your stencil buffer is full with your mask information you won't have to touch it anymore[15:50:25] <Plagman_> and performance will be optimal[15:50:35] <Plagman_> so what you really want to do is set the stencil op to stencil replace[15:50:37] *** huperniketes has quit IRC[15:50:42] <Plagman_> set the colormask to FALSE for every component[15:50:49] *** mm^away is now known as mm765[15:50:52] <Plagman_> draw a series of horizontal lines on the screen[15:51:04] <Plagman_> that will fill the stencil buffer with your scanline mask[15:51:09] <hibread> Plagman_: thats using your noggin[15:51:18] <Plagman_> sorry?[15:51:28] <hibread> thats using your scone[15:51:35] <Plagman_> sorry?[15:51:38] <alyawn> Plagman_: thanks for the info[15:51:44] <alyawn> I'll give it a shot[15:51:56] <hibread> Plagman_: Nice work, you've solved the problem using your brain....[15:52:00] <Plagman_> oh[15:52:01] <alyawn> again, I'm still learning, so it could take a while ;)[15:52:10] *** huperniketes has joined ##OpenGL[15:52:23] <Plagman_> sorry, first day of the week, 7AM and not enough coffee[15:52:45] <Plagman_> I'm not really acute right now :p[15:52:58] <hibread> well, acute enough to solve that problem, with performance in mind[15:53:07] <Plagman_> I guess[15:53:07] <hibread> stencil buffer tests should be nearly infinitely fast[15:53:14] <hibread> so it sounds like the perfect solution[15:53:25] *** abionnnn_ has joined ##OpenGL[15:53:33] <Plagman_> that's my job though so it's more like reflex than actually thinking ;)[15:53:35] <hibread> so he does want pure scanline mask?[15:53:40] <Plagman_> apparently[15:53:56] <hibread> only for a particular texture.. or all?[15:54:06] <Plagman_> if he doesn't, then filling a screen-sized texture with your mask as a preliminary setup stage would be the way[15:54:50] <Plagman_> I think what he wants to do is have every even row of the screen be one texture and every odd row be the other[15:55:02] <alyawn> yes, that's correct[15:55:23] <Plagman_> so doing a screen aligned quad of the first texture without stencil test, then doing another screen aligned quad with the stencil mask enabled on top of that should yield the satisfactory result[15:55:40] <Plagman_> (as long as you filled the stencil buffer with parallel horizontal lines beforehand)[15:55:47] <alyawn> right[15:56:16] * alyawn is reading about stencil buffers now[15:56:19] <hibread> Plagman_: here's a question for you as you seem pretty clued in. Ive implimented a SSAO algorithm but would like it to run a little faster :) I would like it to run on a 1/2 res normal/depth map version, then applying that to the final scene. But you get bleeding issues etc at depth/normal discontinuities. Is this something that could be fixed with "selective application"?[15:56:29] *** juanmabc has joined ##opengl[15:56:44] <Plagman_> aha[15:56:51] <Plagman_> that's a lot more involved :o[15:57:21] <hibread> my algorithm at 512x384 with 16 samples runs nicely (7800 GS)[15:57:52] <hibread> 1024x768 runs pretty bad[15:58:20] <hibread> the obvious thing to do would be to upgrade to a 9800 with all that shader grunt.. but yeah[15:58:43] <Plagman_> so your problem is that applying that to a fraction of your scene pixels causes ugliness when scaling the result back to scene resolution?[15:58:50] <Plagman_> i.e. ugly linear filtering[15:58:54] <hibread> its definitely shader speed limited atm. I can 1/2 or even 1/4 the memory speed and it hardly effects performance[15:59:06] <Plagman_> right, that's definitely going to be pretty shader bound[16:00:29] <Plagman_> I think the actual real-time SSAO implementations rely on selective application to actually work[16:00:35] <Plagman_> (and by that I mean Crysis)[16:00:53] <hibread> yeah that sort of thing. The other issue is that i have to use "nearest" filtering for the normal map and depth map. The normal map ive used a 4x8bit spherical polar coordinates( hence filtering is not going to work there).. and the depth texture is the standard 24bit integer depth attachment[16:01:11] <Plagman_> from what I read about it (don't remember where) their algorithm analyzes depth discrepencies and selectively blurs those parts[16:01:15] <hibread> if i had dx10 compatible hardware, i'd use 32bit float depth attachment[16:01:27] <hibread> and just use 3x16bit float texture for normals and forget the encoding[16:01:33] <Plagman_> right[16:01:37] *** speedy1 has joined ##OpenGL[16:02:09] <hibread> so you think crysis would use a cut down depth buffer to calculate SSAO?[16:02:19] <hibread> they use depth only.. im using normals also[16:02:25] <Plagman_> right[16:02:25] <hibread> but regardless[16:03:01] <hibread> so some sort of adaptive "blurring"?[16:03:02] <hibread> hmmmm[16:03:04] <Plagman_> I think it uses the full depth buffer but only applies SSAO to half of the pixels or so[16:03:13] <hibread> ah ok[16:03:19] <hibread> and applies a blur?[16:03:24] <Plagman_> in a random fashion[16:03:39] <Plagman_> yeah, there's definitely an additionnal blurring pass after that[16:03:53] <Plagman_> there's a paper floating around about that particular technique[16:03:53] <speedy1> hibread: you can take a look at crysis shaders?[16:04:04] <hibread> you can?[16:04:15] <speedy1> sure there are dumping tools AFAIK[16:04:39] <Plagman_> http://developer.download.nvidia.com/presentations/2008/GDC/GDC08_Ambient_Occlusion.pdf[16:04:44] <speedy1> either intercept the shader set calls or unpack them from their .pak files[16:04:45] <Plagman_> i.e. this mentions blurring[16:05:50] <hibread> Plagman_: yeah i did actually briefly look over that paper. Have you made any sense from the Horizon Split AO?[16:06:09] <Plagman_> also I'm compelled to point out that you can get pretty low-profile DX-10 compliant hardware to proof-of-concept your implementation using the proper paths for fifty bucks or so[16:06:34] <hibread> plus another 50 buck MB, and 50 buck ram? :)[16:06:48] <hibread> yeah i do plan to upgrade soon[16:06:49] <Plagman_> you mean you don't have a PCI-E port?[16:06:55] <hibread> waiting to see what the 9900 brings[16:07:02] <hibread> yes thats what i mean :)[16:07:04] <Plagman_> I see[16:07:07] <Plagman_> fair enough[16:07:22] <Plagman_> you might be waiting for a long time for that 9900 :p[16:07:27] <hibread> using an old amd64 3000... the 7900gs the only real nvidia option some time back[16:07:41] <hibread> july apparently. But we'll see[16:08:01] <hibread> The 8800 has been the benchmark for too long for me to upgrade now. Toward the end of a cycle[16:08:25] <speedy1> dunno if any of you guys have heard of Nvidia organised demo competition?[16:08:29] <Plagman_> but I didn't look in much detail at the horizon split occlusion yet[16:08:58] <Plagman_> so I can't really say anything about that, I just googled for ambient occlusion papers to see if they mentioned the selective blurring pass I read abuot[16:09:01] <Plagman_> about*[16:09:05] <Plagman_> speedy1: you mean NVISION?[16:09:08] <speedy1> yup[16:09:22] <Plagman_> well I'm going to attend[16:09:36] <speedy1> interestingly, some demo scene guys asked if using CUDA is allowed[16:10:00] <speedy1> ^^ wonder if it is possible to use CUDA in parallel to Ogl or DX?[16:10:10] <Plagman_> sure[16:10:25] *** neoneye2 has joined ##OpenGL[16:10:28] *** abionnnn has quit IRC[16:10:46] <speedy1> oh - i suppose it says in the docs how to use CUDA output as a texture? :)[16:12:07] <Plagman_> I don't really know about that, though[16:12:38] <speedy1> nevermind, can't use it for games as ATI is clearly lacking support for that one ;)[16:13:07] <Plagman_> I think there's no problem with having a CUDA-enabled application that also owns an OpenGL context but I don't know if there are any tools to make those two communicate[16:13:14] <higgsfett> bundle[16:13:46] <Plagman_> actually[16:13:49] <speedy1> that's why i asked - demo scene guys seem to be asking and positive answer has been included in NVISION rules :)[16:13:54] <Plagman_> http://developer.download.nvidia.com/compute/cuda/sdk/website/samples.html[16:14:02] <Plagman_> This page has lots of example of that[16:14:25] <higgsfett> but that's one of the arts of demo coding?[16:14:46] <speedy1> "texture fetching in CUDA, and CUDA interoperation with the OpenGL and Direct3D graphics APIS" <- :)[16:15:43] <higgsfett> the use of not obviously well documented features?[16:15:57] <Plagman_> speedy1: right[16:16:04] <speedy1> nah, this one seems to be well documented :)[16:16:06] <Hipo> OpenGL VBO can be mapped to CUDA memory so if one wants to transfer that stuff to texture, it must be done through VBO.[16:16:44] <higgsfett> it's not a problem to manipulate the memory with cuda, so ... ;)[16:16:57] <speedy1> yup, I'm thinking of testing character skinning using CUDA, just for fun of it[16:18:06] *** belou has quit IRC[16:18:21] *** bbeausej has joined ##OpenGL[16:18:29] *** belou has joined ##OpenGL[16:21:47] *** PainBank has quit IRC[16:22:30] *** PainBank has joined ##OpenGL[16:23:14] *** Lucine2 has quit IRC[16:23:22] *** pragma_ has joined ##opengl[16:23:49] *** Lucine2 has joined ##OpenGL[16:33:03] *** nplus has joined ##OpenGL[16:34:20] *** nplus has quit IRC[16:34:44] *** nplus has joined ##OpenGL[16:37:57] *** higgsfett_ has joined ##OpenGL[16:38:17] *** bagu has joined ##opengl[16:44:19] *** higgsfett_ has quit IRC[16:46:04] *** higgsfett_ has joined ##OpenGL[16:53:55] *** m4ggus has quit IRC[16:53:59] *** m4ggus_ has joined ##OpenGL[16:54:01] *** m4ggus_ is now known as m4ggus[16:54:08] *** higgsfett has quit IRC[17:04:09] *** [AD]Turbo has joined ##OpenGL[17:08:30] *** stringfellow has joined ##opengl[17:13:21] *** Ingenu has quit IRC[17:14:05] <alyawn> another newbie question... I'm attempting to draw lines into my stencil buffer and I'm having trouble wrapping my head around how the stencil test actually works[17:14:36] <alyawn> I clear my stencil buffer to 0 and then draw my lines in white[17:15:21] <alyawn> to ensure only the parts of the texture correlates to the white lines, how should I call glStencilFunc and glStencilOp?[17:16:09] *** enoex_ has joined ##OpenGL[17:17:17] *** Walt has joined ##opengl[17:28:21] *** ahelon has joined ##opengl[17:30:17] *** Jupp3 has joined ##OpenGL[17:30:55] *** speedy1 has quit IRC[17:33:00] *** enoex has quit IRC[17:39:25] *** Walt has quit IRC[17:47:11] <Plagman_> there's no notion of color in the stencil buffer[17:47:27] <Plagman_> what you do is tell the stencil buffer how to react when something gets drawn on the screen[17:47:54] <Plagman_> after clearing your stencil to all 0s and before drawing your lines, you want to tell the stencil to set the stencil value to 1 wherever you draw something[17:48:59] *** belou has quit IRC[17:50:00] <Plagman_> to do that, you'll want a stencilfunc that looks like this:[17:50:11] <Plagman_> glStencilFunc(GL_ALWAYS, 0, 0xffffffff);[17:50:24] <Plagman_> that means your lines will ALWAYS get drawn, regardless of the stencil value[17:50:24] <Ragnarok> opengl is complicated xD[17:50:27] <Plagman_> and the mask is all ones[17:50:43] <Plagman_> the mask is always all ones unless you need fancy stuff[17:51:13] <Plagman_> glStencilOp(GL_KEEP, GL_KEEP, GL_INCR);[17:51:16] <Plagman_> you'll want this Op[17:52:21] <Plagman_> it means, KEEP the current stencil value if stencil test fails (which won't happen since the stencil function is ALWAYS), KEEP the current value if z-test fails (you want it disabled for 2D rendering anyways), and INCREMENT it if pixels actually get drawn[17:52:38] <Plagman_> after doing that and glEnabling GL_STENCIL_TEST, draw your horizontal lines[17:52:49] *** sohail has joined ##OpenGL[17:53:19] <Plagman_> (make sure you have depth testing disabled so that it doesn't affect your drawing, and set the colormask to all zeros so that your lines don't actually appear on screen)[17:54:20] *** Suprano has joined ##OpenGL[17:55:11] <Plagman_> after your stencil buffer if set to 1s wherever you put your lines, set the stencil func to EQUALS 1 and the op to KEEP KEEP KEEP[17:55:39] <Plagman_> that means that your texture pixels will only get rendered on screen where the stencil EQUALS 1, and that the stencil contents will be unaffected whatever happens[17:55:42] <Plagman_> I hope this is clear enough[17:57:09] *** Grizzly` has joined ##OpenGL[17:57:25] * Grizzly` bows to the room[17:59:40] *** m4ggus has quit IRC[18:01:27] <Plagman_> hey[18:01:30] *** charlie_zzz has quit IRC[18:02:04] *** m4ggus has joined ##opengl[18:02:10] <Ragnarok> hiya[18:06:04] <alyawn> Plagman_: thanks for your explanation... opengl *is* complicated[18:06:13] <alyawn> I thinks I'm starting to come-around[18:06:45] <Plagman_> it's pretty straightforward when you get the logic behind the stencil buffer[18:06:50] <Plagman_> it's a pretty powerful tool :)[18:07:33] <Plagman_> if you feel like you've gone through all the motions and didn't get the results you were expecting, just post the relevant GL code on pastebin and link it here[18:07:46] <Plagman_> people will try to spot obvious mistakes to help you out[18:08:55] <alyawn> great... you guys(and gals) are awesome[18:09:35] <alyawn> do I need to explicitly set glStencilMask(0xffffffff) before drawing?[18:12:34] *** neoneye2 has quit IRC[18:13:47] *** gus4n0 has joined ##OpenGL[18:14:36] <Grizzly`> are displaylists deleted by glClear?[18:14:50] <Grizzly`> clearing GL_COLOR_BIT and GL_DEPTH_BIT?[18:15:34] <Plagman_> alyawn: no[18:16:03] <predaeus> Grizzly`, no, glClear only clears the framebuffer parts specified by the *_BIT mask.[18:16:06] <Plagman_> Grizzly`: glClear only clears the screen, it doesn't affect display lists or any other objects (i.e. texture objects etc)[18:17:02] <Plagman_> alyawn: the reason for this is that it defaults to all ones and that you already set it to all ones when calling StencilFunc anyway[18:17:14] <Grizzly`> strange. somehow my displaylist only works if i recompile it for every screen refresh. which is already an improvement to drawing the same figure a few dozend of times by polygon...[18:17:56] <Plagman_> you're probably doing something wrong[18:17:59] <Grizzly`> but since i feel that most cpu time is now used by compiling the list (it does not seem to matter greatly if i display it twice or 200 times per render once it is compiled)[18:18:11] <Plagman_> yeah[18:18:12] <Grizzly`> yeah, probably i'm doing something wrong :)[18:18:19] <Plagman_> compiling a list is a pretty intensive task[18:18:25] <Plagman_> you don't want to do that once per frame[18:18:32] <Grizzly`> I'd like to compile it once in the constructor of my gui class or wherever, and then onyl display it[18:18:33] <Plagman_> pastebin the relevant code[18:18:36] <Plagman_> right[18:18:54] *** [AD]Turbo has quit IRC[18:19:07] <Grizzly`> ugh.... I'll try to filter the relevant bits out... it's a 4 student colaboration, and the code is pretty wild... hold on[18:21:57] <Plagman_> if your list includes modelview and projection matrix information that changes every frame, it's possible that it's the reason for it not displaying correctly in the next frame[18:22:46] <Grizzly`> do i rather paste the compilefigure() or the redrawscreen() function?[18:22:59] <Plagman_> both[18:23:07] <Plagman_> put them both in a pastebin[18:25:51] *** LordMetroid has quit IRC[18:26:12] <Grizzly`> okay... part 1, the drawScreen and drawModel() functions: http://cpp.ninjacodemonkeys.org/4379 the compileFigure() that compiles the displaylist is coming soon[18:26:56] <Grizzly`> http://cpp.ninjacodemonkeys.org/4380 here goes[18:27:34] *** gusano has quit IRC[18:28:35] <Plagman_> I don't see the call to compileFigure[18:29:28] *** replor has joined ##OpenGL[18:30:23] <Grizzly`> oh, i deleted one line too much. it's the 3rd line in drawScreen() and misses right below the commented glRotate(), above the ObjVertex myPos; declaration[18:31:15] <Plagman_> and where do you call it when you want to only call it once?[18:31:16] <Grizzly`> corrected: http://cpp.ninjacodemonkeys.org/4381[18:31:27] <Plagman_> i.e. not for every frame but just from your setup function[18:31:43] <Grizzly`> if i call it only once i call it in the constructor of the HalmaGUI Class, wait, ...[18:31:54] <Plagman_> is the GL context initialized at that time?[18:33:27] <Grizzly`> yes. http://cpp.ninjacodemonkeys.org/4382[18:34:01] <Grizzly`> it comes right at the end of the initGL function which i call near the end of the constructor. oooooooooo[18:34:09] <Grizzly`> I think we're stupid[18:34:21] <Grizzly`> 4 people sitting around a monitor and nobody sees the obvious[18:35:22] <Plagman_> it's funny how making people isolate their problem code usually causes them to realize what's wrong with it during the same process :p[18:35:27] <Grizzly`> sorry, i think i solved it, but wait i moment while i check if it works now[18:35:58] <Grizzly`> indeed[18:35:59] <Grizzly`> it works[18:36:32] <Grizzly`> I would try and compile the displaylist before i even loaded the models vertex data from disk :/[18:36:39] *** LordMetroid has joined ##OpenGL[18:37:25] <Grizzly`> thanks a lot anyway. the next problem is already waiting around the corner :) (picking colors don't match)[18:37:28] *** andikr has quit IRC[18:39:27] *** LtJax has joined ##opengl[18:40:26] *** scy has joined ##opengl[18:41:11] *** notsonerdysunny has joined ##OpenGL[18:42:40] <Plagman_> sure[18:43:13] <notsonerdysunny> I am using qt and opengl. It runs fine on linux box.. I am not able to see the opengl graphics on my windows box. I am able to see the opegl graphics in the qt-opengl examples /demos. Is there something I need to watch out for while coding opengl..[18:43:36] <Plagman_> oh wow, I don't know[18:43:42] <Plagman_> if you're using Qt, you're on your own :P[18:43:55] <HuntsMan> no, you can ask in the qt-interest list[18:44:35] <notsonerdysunny> .. apart from qt... is there something from the opengl point of view alone?[18:44:49] <notsonerdysunny> that I need to watch out for?[18:45:03] <Plagman_> not particularly[18:45:12] *** predaeus has quit IRC[18:46:17] <notsonerdysunny> is there a good opengl-debugger ..?[18:46:43] <Plagman_> checking for glGetError() is a good start[18:46:56] <Plagman_> the rest is highly implementation dependant[18:47:26] <notsonerdysunny> hmmm...[18:49:26] *** ViRUS has joined ##opengl[18:49:57] *** replor has quit IRC[18:51:14] *** fargiolas has joined ##OpenGL[18:54:58] *** neoneurone has joined ##OpenGL[18:55:29] *** juanmabc has quit IRC[18:55:43] *** abionnnn_ is now known as abionnnn[18:56:20] *** huperniketes has quit IRC[18:56:24] *** predaeus has joined ##opengl[18:57:57] *** huperniketes has joined ##OpenGL[18:58:39] *** replor has joined ##OpenGL[18:59:24] *** Yustme has joined ##opengl[18:59:53] *** scrav has quit IRC[19:02:23] *** braahyan has quit IRC[19:03:45] *** notsonerdysunny_ has joined ##OpenGL[19:05:49] *** sohail has quit IRC[19:08:20] *** braahyan has joined ##OpenGL[19:12:38] *** m4ggus has quit IRC[19:14:11] *** sohail has joined ##OpenGL[19:15:16] *** m4ggus has joined ##OpenGL[19:15:59] *** LtJax has quit IRC[19:21:15] *** notsonerdysunny has quit IRC[19:28:45] *** abionnnn has quit IRC[19:33:02] *** bbeausej has quit IRC[19:38:54] *** Xmas| has joined ##OpenGL[19:39:28] *** predaeus has quit IRC[19:40:13] *** kenws has quit IRC[19:49:01] *** neoneye2 has joined ##OpenGL[19:57:20] *** braahyan has quit IRC[19:58:34] *** KU0N has joined ##OpenGL[19:59:21] <KU0N> hello[20:00:34] *** gotan666 has joined ##OpenGL[20:00:54] *** gotan666 has quit IRC[20:02:13] *** gotan666 has joined ##OpenGL[20:02:26] *** gotan666 has quit IRC[20:03:42] *** gotan666 has joined ##OpenGL[20:06:39] *** dolphin has joined ##OpenGL[20:06:52] *** neunon has joined ##OpenGL[20:07:18] *** PainBank has quit IRC[20:09:57] *** juanmabc has joined ##opengl[20:11:13] *** neunon_ has joined ##OpenGL[20:12:28] *** neunon has quit IRC[20:12:56] *** Foloex has joined ##OpenGL[20:12:59] <Foloex> hello[20:13:36] <Foloex> could someone help me with loading images into openGL textures using DevIL ?[20:13:42] *** notsonerdysunny_ has quit IRC[20:17:00] *** neunon has joined ##OpenGL[20:20:10] *** neunon_ has quit IRC[20:20:11] *** speedy1 has joined ##OpenGL[20:20:53] *** dolphin has quit IRC[20:23:22] *** adhv has joined ##OpenGL[20:25:57] *** charlie_zzz has joined ##OpenGL[20:27:50] *** korff has joined ##OpenGL[20:29:11] <Foloex> ok I got it working[20:29:24] *** Foloex has quit IRC[20:31:02] *** PainBank has joined ##OpenGL[20:31:08] *** mm765 is now known as mm765^away[20:31:51] *** charlie_zzz is now known as charlie555[20:31:53] *** charlie555 is now known as charlie5[20:32:09] <alyawn> hello again. does GL_BLEND have to be enabled to use the stencil buffer?[20:32:31] <speedy1> nope[20:33:06] <alyawn> is there anyway to tell if my stencil is being created successfully? I'm having trouble getting it to work[20:33:46] <speedy1> check the docs if readpixels() can read from the stencil[20:37:23] *** aalex_ has joined ##OpenGL[20:40:11] *** aalex_ has quit IRC[20:42:27] *** andikr has joined ##opengl[20:42:54] *** ginoman has quit IRC[20:44:57] *** loon_ has joined ##OpenGL[20:46:58] <loon_> Hi! I'm trying to creat a FBO, but I get the GL_FRAMEBUFFER_UNSUPPORTED_EXT error. I'm using this code http://rafb.net/p/Z5WPRb32.html . Anyone who knows what's wrong?[20:52:43] *** ginoman has joined ##OpenGL[20:53:08] <Plagman_> alyawn: glGetIntegerv(GL_STENCIL_BITS, &value)[20:53:13] <Plagman_> and check the value of value[20:53:20] <Plagman_> if it's zero, you're in trouble[20:54:50] *** rutski has joined ##OpenGL[20:57:01] <alyawn> it's zero[20:57:39] *** karabash has quit IRC[20:57:40] <alyawn> do I have to call glEnable(GL_STENCIL)?[20:58:48] <Plagman_> you have to glEnable(GL_STENCIL_TEST) whenever you want to do an operation that will either affect or be affected by the stencil contents[20:59:02] <garou> When I draw stuff, matrix transformations are applied immediately with their current state, right? So cameras have to be set up before the world is drawn?[20:59:04] <Plagman_> but the actual amount of stencil bits in your stenicl buffer is decided when creating the GL context[20:59:17] <Plagman_> you can't change it after initializing OpenGL[20:59:47] *** higgsfett_ is now known as higgsfett[21:01:30] <alyawn> in this case, I'm using an NSOpenGLView on os x[21:02:22] <alyawn> I've enabled the stencil buffer in the view to the "minimum" setting... other options include 8bit, 16bit and maximum[21:03:17] <speedy1> have you enabled depth test?[21:04:21] *** blbmp has joined ##OpenGL[21:04:41] <alyawn> no.. it's disabled[21:04:47] <speedy1> try enabling it ;)[21:10:19] <alyawn> depth testing didn't fix, I did, however discover that my view initialization was using the default pixel format which explains the stencil bits... now my stencil bits == 8[21:11:18] *** huperniketes has quit IRC[21:11:38] * alyawn is very happy...[21:12:01] <alyawn> thanks, Plagman_ & company I've officially used my first stencil!!!![21:12:21] <speedy1> cheers :)[21:13:10] *** huperniketes has joined ##OpenGL[21:14:12] <WhitAnglAtWork> hi, just a quick question: is there an operator[] to float3 in GLSL ? like can we do myVec[0] instead of myVec.x ?[21:14:50] <speedy1> yup AFAIK - note that its vec3 not float3 ;)[21:15:04] *** TheLorax has joined ##opengl[21:15:11] <WhitAnglAtWork> what is the difference between float3 and vec3 ?[21:15:20] <speedy1> vec3 is official GLSL[21:15:24] <speedy1> float3 is cg[21:15:43] <WhitAnglAtWork> mm..it seems to compile well with float3 anyway ;)[21:15:47] <speedy1> on nvidia[21:15:52] <WhitAnglAtWork> yep[21:16:01] <speedy1> ati will not like it[21:16:04] <WhitAnglAtWork> ok ;)[21:16:20] <WhitAnglAtWork> so I'm allowed to do myVec[0] anyway[21:16:32] <speedy1> yup[21:16:55] *** dv_ has joined ##OpenGL[21:17:02] <Hipo> But it might be faster to use .x instead of [0].[21:18:02] <WhitAnglAtWork> ok :)[21:18:12] <speedy1> faster to type only[21:18:51] <Hipo> If the compiler doesn't see that it's constant, it will be slower.[21:20:14] <speedy1> hipo: uhm, quite unlikely IMO[21:21:05] <Hipo> speedy1: It's not possible to do indexed access to registers.[21:21:55] <speedy1> there are no registers in GLSL per se[21:22:29] <Plagman_> alyawn: is the scanline stuff working at your convenience?[21:22:42] <Hipo> It will be compiled to stuff that has registers. :)[21:23:23] <speedy1> hipo: if you check the asm output, you'll see that compiler easily recognises such cases[21:24:49] *** neunon has quit IRC[21:24:56] <adhv> Here's my problem, I want to change the behavior of my cursor. For that, I need to change the coordinates of the cursor each time the mouse send a signal (of motion). To do so, I've tried using glutPassiveMotionFunc(void (*func)(int x, int y)) and glutWarpPointer. But as soon as the pointer's location is wraped, glutPassiveMotionFunc calls its function which wraps the pointer's location, etc... which creates an infinite loop. What I w[21:24:56] <adhv> ould wish is that the pointer's location wraping doesn't make glutPassiveMotionFunc call its function.[21:26:44] <Hipo> speedy1: That's why I say "might be faster". It's not always possible for compiler to see that it's not a real indexed access.[21:26:53] *** LtJax has joined ##opengl[21:27:11] *** Xmas__ has joined ##OpenGL[21:27:36] <loon_> Hi! I'm trying to creat a FBO, but I get the GL_FRAMEBUFFER_UNSUPPORTED_EXT error. I'm using this code http://rafb.net/p/Z5WPRb32.html . Anyone who knows what's wrong?[21:28:07] *** Jernej has joined ##OpenGL[21:28:12] <alyawn> Plagman_: yes.. it's working now... my chared context wasn't setting-up the stencil buffer at all[21:29:16] <LtJax> loon_, I kinda remember that for some strange reason GL_RGBA8 didn't work while GL_RGBA did[21:29:42] <alyawn> Plagman_: all of your suggestions worked great. now, I need to refactor and move the creation of the stencil out so that it will only change when the window is resized[21:29:43] <LtJax> might be totally wrong, it's actually likely, since RGBA8 is "better style" but worth trying anyways[21:30:15] <loon_> LtJax: It's still an error with RGBA :/[21:30:19] <Plagman_> alyawn: excellent. yeah, forgetting to ask nicely for stencil bits when setting the context up is a common mistake :p[21:30:37] <Plagman_> I've spend hours scratching my head wondering why I wasn't getting any kind of result before realizing that[21:30:42] <Plagman_> several times :p[21:30:45] <Plagman_> spent*[21:30:58] <LtJax> loon_, did you make sure mipmapping is disabled?[21:31:09] <alyawn> Plagman_: yes, and I'm using InterfaceBuilder on the mac and I had the buffer setup correctly there, just not in the code :P[21:31:13] <LtJax> oh no, wait - that'll give you incomplete, not unsupported[21:31:44] <Plagman_> keep in mind that unsupported is the result when failing with out of memory[21:31:52] *** JernejL_ has joined ##OpenGL[21:32:16] <loon_> humm, that's strange[21:32:25] *** neunon has joined ##OpenGL[21:32:27] <Plagman_> how much VRAM does your card have, how big are your textures (both depth and color) and do you have other FBOs bound?[21:32:43] <Plagman_> it's only one of the causes that can return unsupported though[21:32:55] <Plagman_> I wasn't implying it was the only conclusion[21:33:09] <loon_> 128. I only have one depth map and one texture. both 640x480[21:33:38] <Plagman_> yeah, that ought to be enough[21:33:41] <Plagman_> probably something else[21:33:53] <Plagman_> what's your driver/hardware combination?[21:35:06] <loon_> nvidia 8400 GS and 7.15.11.5655[21:37:29] <loon_> if i check GL_EXT_framebuffer_object its okey[21:40:36] *** gotan666 has quit IRC[21:40:53] <loon_> It works now :D If i add http://rafb.net/p/2r11T766.html. Why is that?[21:40:57] *** Xmas| has quit IRC[21:45:11] *** JernejL has quit IRC[21:47:50] *** Jernej has quit IRC[21:52:16] *** loon_ has quit IRC[21:53:16] *** nplus has quit IRC[21:59:22] *** prophile has quit IRC[22:11:01] *** Baba_ has joined ##OpenGL[22:12:06] *** PainBank1 has joined ##OpenGL[22:12:51] *** jparishy has joined ##OpenGL[22:16:14] *** scrav has joined ##OpenGL[22:19:40] *** NeoThermic_II has joined ##OpenGL[22:22:45] *** neunon has quit IRC[22:27:14] *** mastro has quit IRC[22:27:35] *** TheChuckster has joined ##OpenGL[22:27:57] *** baballama has quit IRC[22:28:47] *** NeoThermic has quit IRC[22:29:28] *** PainBank has quit IRC[22:30:47] *** bbeausej has joined ##OpenGL[22:33:25] *** TopoMorto has joined ##OpenGL[22:34:22] <TopoMorto> Hi people, could someone help me in installing JoGL (a java opengl implementation) with openjdk?[22:35:09] <MatthiasM> TopoMorto: put the dll in a folder in your path - or point -Djava.library.path= to it[22:35:26] <MatthiasM> put the JAR in your classpath (-cp)[22:35:43] <MatthiasM> or better yewt - use LWJGL #lwjgl[22:37:04] *** andikr has quit IRC[22:37:30] <TopoMorto> MatthiasM, i'll try an example with -cp option pointing to the just builded jar files :)[22:38:02] <MatthiasM> you also need the so/dynlib/dll files[22:38:17] *** fargiolas has quit IRC[22:39:02] <TopoMorto> MatthiasM, i own this files too :)), i must poit the classpath to tose files too?[22:39:08] <TopoMorto> +point[22:39:12] <TopoMorto> *point[22:39:14] *** KU0N has quit IRC[22:39:22] <MatthiasM> TopoMorto: read what I wrote above[22:39:47] <TopoMorto> ok :)[22:46:57] *** Yustme has quit IRC[22:52:30] *** DobosCake has joined ##OpenGL[22:54:04] *** braahyan has joined ##OpenGL[23:00:59] *** mm765^away is now known as mm765[23:05:39] *** neoneye2 has quit IRC[23:15:46] <TopoMorto> MatthiasM, Thank You!!! I resolved!!! :))[23:16:10] <MatthiasM> you should still try #lwjgl :)[23:28:40] <TopoMorto> MatthiasM, i'm just Tryng to build #LWJGL right now :)[23:28:57] *** nytejade` has quit IRC[23:29:15] <MatthiasM> why not download the latest binary - you get it for all OS[23:30:31] *** rnicolas has joined ##OpenGL[23:31:41] <TopoMorto> :))[23:33:01] <Makegho> does glsl have goto? :)[23:33:26] <MatthiasM> no[23:33:34] <MatthiasM> and why should it ?[23:33:42] <Makegho> Of course it should, goto is good.[23:33:49] <Makegho> But it should be used with care[23:33:52] <MatthiasM> go back to basic then :P[23:33:57] <Makegho> no way[23:33:59] <Grizzly`> commodore basic 7.0 does... and it can do graphics as well :P[23:34:36] <Makegho> goto is useful mainly for break<hint hint, another name for goto>'ing out of loops[23:35:02] <Makegho> it helps to keep the structure much simpler than annoying nested loops[23:35:10] <MatthiasM> break is a well defined control flow[23:35:50] <Makegho> many languages implement either "break 1" "break 2" or such, how many steps to break, or then they do it with a tag "break until this"[23:35:56] <MatthiasM> and some languages have labeled blocks/loops which you can target with a break or continue[23:36:12] <MatthiasM> and break with a count is a dangerous and stupid idea[23:37:08] <Makegho> Forcing the use of an additional variable and extra ifs for escaping from a deep loop is also a stupid idea :)[23:37:26] <MatthiasM> read what I wrote about labeled loops[23:37:42] <Makegho> I did read what you wrote about labeled loops.[23:38:06] <Makegho> But some languages have no such and also they have no goto or no good break. :)[23:38:17] <MatthiasM> then switch[23:38:21] <Makegho> just because some guy in the 70's saying "Goto is bad! Goto is bad!"[23:38:29] <Makegho> :P[23:38:43] <Makegho> switch, does it help in this?[23:38:52] <MatthiasM> ... to another language[23:39:00] <Makegho> ah[23:39:02] <Makegho> heh[23:39:48] <Makegho> One often used way of avoiding goto is to put the code in a function and then return; out of there, but I don't see why it would be any more clean[23:41:12] <MatthiasM> because the control flow is clearly defined - but some people prefer to only have a single return per function[23:41:27] <Makegho> That would be equivalent to "no goto" then[23:42:05] <Makegho> But okay, since GLSL doesn't have goto, does it have some other efficient means for the same result, or should additional variables be used?[23:42:43] <MatthiasM> you can use break[23:43:06] <Makegho> Can I break multiple layers with it or just one as in C/C++?[23:43:08] <MatthiasM> but remember that older cards have limited support for loops[23:43:13] <Makegho> oh[23:43:44] <MatthiasM> some can't loop at all - others only with constant iteration count -other only a limited number defined per uniform etc[23:44:31] <Makegho> I see[23:44:59] *** jparishy has quit IRC[23:45:28] <MatthiasM> and some cards can only branch for a group of fragments - so if the result is different per fragment then all code pathes are executed[23:46:06] <Makegho> I don't yet know much details about shaders. I'm writing a simple and fast raytracer for the CPU and I'm hoping that I could run it with GPU later[23:46:14] <Makegho> ok :)[23:47:17] *** Arc_ has joined ##OpenGL[23:47:46] *** Arc has quit IRC[23:52:05] *** Walt has joined ##opengl[23:52:17] <TopoMorto> MatthiasM, good performance of glgear demo under LWJGL , 1400 FPS :))))))) i will use it in my project :))[23:52:36] <TopoMorto> MatthiasM, Thanks Again :))[23:52:41] <MatthiasM> I have >5500 :)[23:52:56] <Makegho> what's lwjgl? :)[23:52:58] <MatthiasM> join us in #lwjgl :)[23:53:15] <MatthiasM> it's a OpenGL binding and windowing toolkit[23:53:19] *** Grizzly` has quit IRC[23:53:26] <TopoMorto> ok i will join this channel :))[23:53:28] <MatthiasM> plus extension handling, OpenAL etc[23:53:52] <Makegho> nice[23:54:27] *** neoneurone has quit IRC[23:54:51] *** Arc_ is now known as Arc[23:55:12] <Makegho> that's probably worth bookmarking, just in case I'll write another line of java some day.[23:56:17] <Makegho> that brings to my mind -- is it possible to do opengl es stuff with java in a portable way?[23:56:54] *** jparishy has joined ##OpenGL[23:59:48] *** kaotrix has joined ##OpenGL