[00:00:48] *** Burga has quit IRC
[00:06:56] *** LordMetroid has quit IRC
[00:09:05] *** neoneurone has quit IRC
[00:24:19] *** juanmabc has quit IRC
[00:29:18] *** mm765^away is now known as mm765
[00:39:02] *** devurandom has quit IRC
[00:39:03] *** apple_ide has joined ##OpenGL
[00:39:25] *** prophile has quit IRC
[00:39:29] *** apple_ide has left ##OpenGL
[00:40:37] *** arrogant_troll has joined ##OpenGL
[00:40:47] *** LjL has joined ##opengl
[00:41:15] *** arrogant_troll has quit IRC
[00:41:16] *** aalex has quit IRC
[00:44:58] *** Sabman has joined ##openGL
[00:56:17] *** Suprano has quit IRC
[00:56:23] *** Maerz has joined ##OpenGL
[01:01:48] *** Jernej has joined ##OpenGL
[01:04:25] *** mastro has joined ##OpenGL
[01:06:00] *** JernejL_ has joined ##OpenGL
[01:18:53] *** darka has quit IRC
[01:19:37] *** JernejL has quit IRC
[01:21:06] *** Jernej has quit IRC
[01:21:47] *** karabash has quit IRC
[01:24:19] *** speedy1 has quit IRC
[01:34:57] *** DMINATOR has quit IRC
[01:36:48] *** Xmas| has quit IRC
[01:38:00] *** meteors has quit IRC
[01:38:25] *** Maerz has quit IRC
[01:44:54] *** m4ggus_ has joined ##opengl
[01:45:20] *** toxinide has joined ##OpenGL
[01:45:37] *** amz has joined ##opengl
[01:45:57] <toxinide> Hi people
[01:47:01] <toxinide> guys, anyone using collada here?
[01:49:21] *** _boto has quit IRC
[01:50:44] *** m4ggus has quit IRC
[01:50:50] *** m4ggus_ is now known as m4ggus
[01:51:34] <toxinide> anyone here?
[01:52:14] *** TheLorax has quit IRC
[01:52:27] <Madsy> At this hour? No.
[01:52:32] <toxinide> Oh hello
[01:52:55] <toxinide> true I suppose is a bit late in some places
[01:54:27] <toxinide> I am working on a project and I would like to know what in general people that are more experienced with OpenGL would recommend me to use as the best 3d models file format for interactive content?
[01:55:35] <toxinide> or one of the best / most used, collada etc.
[01:57:49] <rnx> collada is ok ... not quite there yet in terms of exporters etc.
[01:59:32] <toxinide> thanks rnx, yes that seems the main thing that holds me back really, would you suggest a similar although more popular format?
[01:59:35] <mm765> collada is an interchange format, you probably dont want to use that for interactive content
[02:00:24] <mm765> depends on your definition of "interactive content" of course
[02:00:37] <toxinide> mm765, sure although you can actually optimize it for your particular needs
[02:00:55] <toxinide> mm765 it's mainly for a tech-demo
[02:01:15] <toxinide> I have heard of others like fxv
[02:01:24] <toxinide> fxb? or dotXSI
[02:02:29] *** Niteon has quit IRC
[02:03:30] <mm765> tech-demo - now theres a very accurate description - i guess if you want to do one that demos reading xml files, collada would be perfect
[02:04:38] <toxinide> mm765: tech-demo in terms of an OpenGL tech-demo, it's for my final year thesis as part of a game programming course
[02:05:23] <mm765> then use an open source engine and use whatever format they support
[02:05:56] <mm765> engine as in graphics engine
[02:06:13] <toxinide> mm765: that's the main reason of the thesis, write my own engine, we are not allowed to use already made stuff really
[02:06:51] <mm765> great - typical academic stupidity - engine no. 5 billion :)
[02:07:14] <mm765> still, look at the engines, chose a format you like and use it
[02:07:37] <toxinide> hmm probably, although I suppose it's a good way to learn more about the inner workings of OpenGL if you build it from scratch
[02:08:36] <mm765> id say you would learn as much if not more if you would join an existing project and extend it - the people running the project would be able to explain the stuff to you you wouldnt have to make every mistake they already made and so on..
[02:10:03] <toxinide> yes that's also true - so about the format, is there anything you would suggest?
[02:10:51] <mm765> i am not unbiased on that, so any suggestion i would make would be bad, sry
[02:11:25] <toxinide> oh fair enough, thanks anyway
[02:13:28] <toxinide> oh great, I didn't think about looking it this way, sure I will have a look and see which is probably the most used format for loading 3d content, thanks ;)
[02:18:49] *** Walt has quit IRC
[02:19:12] *** dvoid_ has quit IRC
[02:20:46] *** toxinide has left ##OpenGL
[02:25:36] *** blbmp has quit IRC
[02:25:54] *** blbmp has joined ##OpenGL
[02:27:18] *** Walt has joined ##opengl
[02:31:04] *** vasoq has joined ##OpenGL
[02:31:43] <vasoq> should i learn opengl and glut together or is it worth it to learn opengl for a certain platform? i don't like the platform dependent thing and what's worse for practicality is that i'd be learning opengl for linux
[02:31:48] *** nathan__ has joined ##OpenGL
[02:42:50] <rnx> glut or sdl ... platformspecific is a waste of time
[02:44:46] *** enoex has joined ##OpenGL
[02:44:54] <vasoq> thanks
[02:49:40] <NightBird> why tie yourself to a platform if you can help it :P
[02:49:51] <NightBird> (excluding getting paid to do so)
[02:50:16] *** kaotrix has quit IRC
[02:50:21] <vasoq> my only concern is that something like glut or sdl might be too high level that i'm not learning anything, but i don't know anything yet so i have no clue
[02:50:50] <NightBird> oh, you'll use glut/sdl for dealing with the platform specific stuff, but then use OpenGL for all the graphics
[02:52:49] *** hibread has joined ##opengl
[02:56:53] *** enoex has quit IRC
[02:58:29] *** enoex_ has quit IRC
[02:58:53] <NightBird> but yeah, I typically use sdl for window management and input, OpenAL for audio, and OpenGL for graphics
[03:05:01] *** m4ggus has quit IRC
[03:07:26] *** bbeausej has quit IRC
[03:10:29] *** reduzio has joined ##OpenGL
[03:11:30] <reduzio> OK people, GLSL documenation and how to write for it, which cards support what, etc, is a huge mess. Could anyone please answer me some questions?
[03:13:00] <NightBird> uh... sure, what's up?
[03:14:12] <Lekane> red book, orange book, rendermonkey exemples
[03:14:22] *** meteors has joined ##OpenGL
[03:14:41] <reduzio> Lekane, already read 2 of those and it's not any help
[03:15:00] <NightBird> what is it you're trying to do?
[03:15:01] <reduzio> well, basically.. I don't understand how is GLSL supposed to be used. Like for example, I want to do skinning, so i wanted to pass the number of bones/weight arrays to process in the shader as an uniform
[03:15:18] <reduzio> (in a vertex program)
[03:15:26] <NightBird> okay
[03:15:36] <reduzio> but then, I'm told it's not good to that, because i'm not supposed to use uniforms in loops, and that loops must be static
[03:15:59] <reduzio> so what am i supposed to do? 8 different progrants for each amount of weight arrays? (1 to 8?)
[03:16:07] <reduzio> er, programs
[03:17:13] <NightBird> have you looked into attributes?
[03:17:30] <reduzio> same when processing loops, i wanted to check all the GL lights in the fragment program and compute per pixel lighting for each enabled light, using the gl light parameters.. but them i'm told again that it's not really possible because it requirees conditionals, and that those are not well supported either
[03:17:51] <Satan_Inside> actually they are supported quite well on newer renderer(s)
[03:18:10] <Satan_Inside> for example anything capable of supporting Shader Model 4 in hardware
[03:18:28] <NightBird> they're basically like uniforms in that you can pass chunks of data to shaders, however you can change them on a per vertex basis
[03:18:30] *** nathan__ has quit IRC
[03:18:35] <reduzio> Satan_Inside, well, i haven't found what hardware suppors what anywhere
[03:18:39] <Satan_Inside> which would be Nvidia's current generation (G8x, ... ) or ATI's current generation (R6xx, ... )
[03:18:50] *** nathan__ has joined ##OpenGL
[03:19:01] <Satan_Inside> furthermore look into EXT_bindable_uniform
[03:20:08] <Satan_Inside> which is also supported in HW by the above mentioned renderer(s)
[03:20:19] <NightBird> reduzio: you can specify a minimum shader level. I would suggest using shader level 2(which any dx9 card should support). Those support conditionals, and limited looping support(basically, if you can unroll the loop all the way at compile time, it's good to go)
[03:20:51] <reduzio> Satan_Inside, so basically, does that mean that if i want to make something that work in most cards out there, i can't use loops, for example?
[03:20:52] <NightBird> or is it shader level 3 is equivalent to dx9 shaders?
[03:21:03] <reduzio> i think level 3 is dx10
[03:21:06] *** reduzio is now known as reduz
[03:21:40] <Satan_Inside> no it isn't
[03:21:46] <NightBird> alright.. well, dx10 class cards don't have an issue with looping in glsl, and with dx9 class cards the driver will have to unroll the loop to use it
[03:21:51] <Satan_Inside> that would be Shader Model 4 which I also mentioned above
[03:21:58] <reduz> even with that though, how do i solve the problem with the bones? basically, a vertex array may have 1,2,3,5 .. 8 extra weigth arrays, how can I in a single shader process only a fixed amount of them?
[03:22:07] <Satan_Inside> SM3 == DX9.0(c), SM4 == DX10
[03:22:15] <reduz> oh
[03:22:24] <NightBird> alrighty
[03:22:59] <Satan_Inside> in any case a number of SM3 level GPUs also support full looping in the shader pipeline although its supported across the board by anything SM4 level
[03:23:24] <Satan_Inside> the same goes for conditional statements (i.e. if ... else or ? for example)
[03:23:43] <NightBird> I think sm3 required full conditional statements to work
[03:23:48] <NightBird> but not loops
[03:23:58] <Satan_Inside> and your "bone problem" gets to the next statement I made -- EXT_bindable_uniform
[03:24:03] <reduz> but that doesn't help me.. if i want to make a shader that works in as most cards as i can (say, gf5200+), then i simply can't use conditionals or loops?
[03:24:05] <Satan_Inside> read the spec I linked you to
[03:24:37] <Satan_Inside> and the GLSL runtime abstracts all of this for you
[03:24:40] <Satan_Inside> so you don'
[03:24:53] <Satan_Inside> err don't need to worry about the HW specific details
[03:25:32] <Satan_Inside> if you *do* exceed the limits of the renderer you happen to be executing on you *will* drop down to a slower (i.e. SW) path
[03:25:52] <Satan_Inside> but there isn't anything new on that front
[03:27:27] <reduz> Satan_Inside, isn't EXT_bindable_uniform is only nvidia and gf8+? I can't use it on a 5200, or ATI cards?
[03:28:37] <Satan_Inside> no there is nothing in the EXT_bindable_uniform specification specific to Nvidia
[03:29:17] <Satan_Inside> in any case query the extension (via gluCheckExtension(...)) at runtime for availability
[03:29:25] <reduz> I don't seem to have it
[03:29:34] *** meteors has quit IRC
[03:29:47] <reduz> and also, i don't want to use something not present in many cards
[03:30:47] <reduz> I can't find any single GLSL skinning example on the net
[03:31:35] *** aalex has joined ##OpenGL
[03:34:23] <NightBird> gpu gems 1 talks about doing skinning on the graphics card on dx9 hardware. specifically the "dawn" demo. Unfortunatly, the code is in hlsl/cg, but it may be a good place to get started at.
[03:35:16] <NightBird> at least for the basic idea. it will take some work to translate it from hlsl/cg and DirectX to glsl and OpenGL, but that will just make it that much more of a learning experience
[03:38:06] *** Sabman has quit IRC
[03:38:56] *** lubosz has joined ##OpenGL
[03:42:46] *** [this] has joined ##opengl
[03:42:55] <reduz> Ok, basically what i'm getting at is that shaders are still terrible with conditionals and loops after all these years in normal consumer cards (not gf8x), so i should avoid them and make a shader for every combination of params it may exist?
[03:43:17] <reduz> (i mean, compile one shader for every combination of parameters)
[03:44:28] <NightBird> that's not it at all
[03:45:03] <reduz> then i really don't get it..
[03:45:05] <NightBird> really old cards may have problems(we're talking nvidia maybe 6000's?), but anything more modern will be fine
[03:45:18] <NightBird> with conditionals
[03:45:24] <reduz> well, a lot of people still has such cards
[03:45:28] <reduz> i can't simply ignore them
[03:46:00] <Satan_Inside> let me give you guys the following bit of advice -- don't attempt to outsmart the compiler
[03:46:42] <Satan_Inside> modern (shader) compilers are very good... let them worry about those conditional(s) and loop(s)
[03:47:14] <reduz> Satan_Inside, but if i want my code to work on a gf6x, it will crawl if i let the shader worry about it
[03:47:22] <reduz> isn't it?
[03:47:30] <NightBird> reduz: not nessisarily
[03:47:31] <Satan_Inside> in fact this is one of the reasons why one would be targeting GLSL in the first place
[03:49:35] <reduz> guess i can try.. how can i pass GLSL a custom array btw? (or bind it to an attribute)
[03:51:41] <reduz> glGetVertexAttribPointerv?
[03:51:57] <NightBird> how are you handling the data normally?
[03:52:28] *** aalex has quit IRC
[03:52:38] <reduz> basically, i have vertex weights in separate arrays
[03:52:50] <reduz> an array for the weight of each bone
[03:54:18] *** blight_ has quit IRC
[03:54:21] <reduz> so i want to bind a few extra arrays for each bone with weights
[03:54:43] <NightBird> yeah
[03:55:03] *** aalex has joined ##OpenGL
[03:55:40] <NightBird> if you're using vertex arrays for the rest of your stuff, then go ahead and use glVertexAttribPointer
[03:57:55] <NightBird> if you're using stuff like glVertex3f, glColor, etc, then you'd probably want to use glVertexAttrib
[03:58:08] *** izprince has joined ##OpenGL
[03:58:50] *** lubosz has left ##OpenGL
[04:00:15] *** replor_ has joined ##OpenGL
[04:02:43] *** aalex has quit IRC
[04:07:14] <Andon> Does GLSL suffer the same attrib aliasing issues as ARB VP? (i.e., should attribs 0 - 6 still be avoided because certain implementations, mainly NVIDIA, alias diffuse color, normal, vertex pos, etc... to them)?
[04:07:59] <Andon> That's the only caveat that comes to mind implementing bone matrices w/ attrib pointers.
[04:08:19] <NightBird> um... he won't be directly modifying specific index of attributes
[04:08:59] <NightBird> he'll probably use glGetAttribLocation to find the names of the variables he declared in the shader
[04:10:33] <Andon> Ah, right. Nevermind then :)
[04:11:23] <NightBird> I'm not sure if you can directly access attributes in the shaders based off of their index in GLSL...
[04:12:58] <Satan_Inside> on suitable implementation(s) you can since the GLSL language / runtime itself doesn't specifically limit this feature
[04:13:24] <NightBird> but it's an implementation specific feature?
[04:14:11] <Satan_Inside> well every feature to some extent is implementation specific
[04:14:34] <NightBird> well, I meant as far as the standard is concerned
[04:14:59] * NightBird tends to program to the standard unless there is some specific feature I need
[04:15:39] <Satan_Inside> the GLSL language specification you should note is quite abstract
[04:16:37] <NightBird> eh, it specifies enough things for me to get what I want out of it
[04:16:50] <Satan_Inside> at least in the realm of feature(s) directly tied to hardware (i.e. integer support, loop and conditional statement implementation etc.)
[04:17:31] *** replor has quit IRC
[04:27:10] *** TheLorax has joined ##opengl
[04:35:32] *** aalex has joined ##OpenGL
[04:40:28] *** aalex has quit IRC
[04:49:55] <TheLorax> is there a page where I can get the latest news on ogl 3?
[05:08:42] *** TheLorax has quit IRC
[05:15:30] *** aalex has joined ##OpenGL
[05:17:09] *** tmccrary has joined ##OpenGL
[05:23:08] *** HuntsMan has quit IRC
[05:31:19] *** HuntsMan has joined ##opengl
[05:34:34] *** rnx has left ##opengl
[05:37:18] *** Shel2476 has joined ##OpenGL
[05:37:19] *** Shel2476 has left ##OpenGL
[05:40:57] *** Shel2476 has joined ##OpenGL
[05:40:58] *** Shel2476 has left ##OpenGL
[05:46:08] *** tmccrary has quit IRC
[05:49:19] *** Ademan has quit IRC
[05:50:14] *** Ademan has joined ##OpenGL
[05:50:32] *** LordHavoc has left ##OpenGL
[06:10:18] *** charlie_zzz is now known as charlie5
[06:10:32] *** mm765 is now known as mm765^sleep
[06:12:31] *** amz has quit IRC
[06:28:43] *** aalex has quit IRC
[06:42:17] *** dust has joined ##OpenGL
[06:42:35] <dust> is there a circle function in glu or somehow builtin?
[06:46:10] <Madsy> rtfm
[06:46:15] <Madsy> You have something called Quadrics
[06:47:14] <Madsy> Make a new Quadric object and call gluDisc
[06:47:33] <dust> thanks
[06:47:36] <Madsy> Though you get more freedom by making your own function.
[06:48:25] *** Shel2476 has joined ##OpenGL
[06:48:26] *** Shel2476 has left ##OpenGL
[06:48:42] <Madsy> Use gluNewQuadric and gluDeleteQuadric to make/destroy objects
[06:50:28] *** izprince has left ##OpenGL
[06:51:45] *** Shel2476 has joined ##OpenGL
[06:51:46] *** Shel2476 has left ##OpenGL
[06:53:39] *** Lemml has joined ##OpenGL
[07:00:26] *** mm^away has joined ##opengl
[07:14:58] *** BahamutZERO has quit IRC
[07:17:35] *** mm765^sleep has quit IRC
[07:37:53] *** Jupp3 has quit IRC
[07:38:17] *** ajww has quit IRC
[07:47:56] *** NeoThermic_II has joined ##OpenGL
[07:48:27] *** NeoThermic has quit IRC
[07:48:29] *** NeoThermic_II is now known as NeoThermic
[07:52:36] *** mattn2|home has quit IRC
[07:57:49] *** NeoServer has quit IRC
[07:57:58] *** NeoServer has joined ##OpenGL
[08:00:16] *** [this] has quit IRC
[08:07:39] *** Lemml has quit IRC
[08:19:01] *** dust has quit IRC
[08:30:36] *** Obfuscate has quit IRC
[08:32:25] *** scy has joined ##opengl
[08:41:54] *** Roderic has joined ##OpenGL
[08:41:55] *** Roderic is now known as Ingenu
[08:45:22] *** Burga has joined ##OpenGL
[08:46:06] *** scy has left ##opengl
[08:54:19] *** Bollinger has joined ##opengl
[08:57:20] *** Burga__ has joined ##OpenGL
[09:10:12] *** Burga has quit IRC
[09:11:48] *** cami has joined ##OpenGL
[09:13:33] *** nathan__ has quit IRC
[09:18:04] *** korff has joined ##OpenGL
[09:21:47] *** [AD]Turbo has joined ##OpenGL
[09:23:42] <[AD]Turbo> yo
[09:27:55] *** amalon has joined ##opengl
[09:31:23] *** Ademan has quit IRC
[09:31:33] *** groton has joined ##OpenGL
[09:40:07] *** LiQuiDninja has quit IRC
[09:58:53] *** ville has quit IRC
[10:17:07] *** Ademan has joined ##OpenGL
[10:20:48] *** blbmp has left ##OpenGL
[10:25:34] *** ville has joined ##opengl
[10:34:45] *** lea\ has quit IRC
[10:42:43] *** MrPrise has joined ##OpenGL
[10:42:50] <MrPrise> hello
[10:43:23] <MrPrise> is there a tutorial on Diablo like lights?
[10:44:46] *** neoneye has joined ##OpenGL
[10:49:12] <quicksilver> explains the basic technique fairly well
[10:53:58] <MrPrise> quicksilver: thanks, if I understand well that means I will have two textures for every faces? one is the real texture and the other is the calculated lightmap?
[10:57:06] <MrPrise> will that work if I need more lights? eg 16?
[11:00:14] *** BahamutZERO has joined ##OpenGL
[11:01:27] *** karabash has joined ##OpenGL
[11:02:13] <quicksilver> MrPrise: yes.
[11:02:35] <quicksilver> MrPrise: with multiple lights you normall take all the lights into account and build one lightmap texture
[11:02:42] <quicksilver> which has contributions from all the 'nearby' lights.
[11:02:48] <quicksilver> for some definition of 'nearby'
[11:03:45] <MrPrise> is not that calculations slow? it seems I have to create those lightmap textures on the fly
[11:05:36] *** dvoid_ has joined ##OpenGL
[11:08:18] <quicksilver> if your lights are moving then you have to create the lightmaps on the fly, yes.
[11:08:50] <quicksilver> this was always a challenge, I believe it was one of the things that used most of the CPU power on Diablo.
[11:09:28] <quicksilver> In a GLSL world you can do dynamic lighting with a shader instead.
[11:10:54] <MrPrise> I see. thanks
[11:11:44] <quicksilver> MrPrise: sometimes if you make simple assumptions you can just move the texture.
[11:11:49] <quicksilver> MrPrise: and change the scale
[11:11:57] <quicksilver> MrPrise: consider a single moving light
[11:12:10] *** WimLeers has joined ##OpenGL
[11:12:11] <quicksilver> MrPrise: you can use a simple circular (faded) lightmap, and just moving it along with the singe light
[11:12:19] <quicksilver> MrPrise: and scale it based on the distance from light to surface
[11:12:31] <quicksilver> I suspect that's how quake1 did the lights from rocket launchers.
[11:12:44] <quicksilver> when you have multiple lights tha becomes harder.
[11:12:47] <MrPrise> I need something like in Diabloe. so there will be more moving lights
[11:13:02] <quicksilver> I *think* diablo recalculated maps every frame but I'm not sure.
[11:13:58] *** MatthiasM has quit IRC
[11:14:06] *** MatthiasM has joined ##opengl
[11:14:24] <MrPrise> when I use lightmaps is it possible to change the light's intensity? maybe with the alpha value?
[11:15:14] <MrPrise> I think that does not give a good result
[11:33:50] *** cami has quit IRC
[11:36:00] <quicksilver> MrPrise: I think scaling is probably the best way to increase intensity
[11:36:07] <quicksilver> then the "strong center" becomes larger
[11:36:16] <quicksilver> but you could also play a bit with the alpha value.
[11:38:29] <MrPrise> I'm beginning to think lights is not a topic for a beginner like me in the OpenGL world
[11:39:38] <Adrinael> Lights is basic, dynamic lights (implemented with something else than builtin lights) is advanced
[11:39:58] <MrPrise> yes, but I need dynamic lights
[11:42:35] <quicksilver> how many lights do you need at a time, roughly?
[11:43:07] *** darka has joined ##opengl
[11:43:24] <MrPrise> maybe 15 max.
[11:43:46] <quicksilver> for just a couple you could actually try using openGL lights.
[11:43:53] <quicksilver> I'm not sure what the practical limits are there.
[11:44:30] *** replor_ has quit IRC
[11:44:58] <MrPrise> I read a post about how can I have more than 8 lights in opengl, but they wrote that could be CPU eater
[11:45:48] * quicksilver nods
[11:47:39] <MrPrise> they suggested to render the scene twice with the first 8 lights and then the other 8 lights for example
[11:47:59] <quicksilver> ah
[11:48:00] * quicksilver nods
[11:54:13] *** karabash has quit IRC
[11:58:47] *** ajww has joined ##OpenGL
[12:01:01] *** cami has joined ##OpenGL
[12:04:13] *** NeoThermic has quit IRC
[12:05:10] <quicksilver> MrPrise: that looks like a decent summary of the situation to me.
[12:06:37] <MrPrise> yes
[12:06:59] <quicksilver> maybe it's simplest to start by using openGL lights
[12:07:04] <quicksilver> and limit yourself to 8
[12:07:07] <quicksilver> and get some code running :)
[12:07:12] <quicksilver> then you can revist lightmaps later
[12:07:37] *** ajww has quit IRC
[12:08:00] <MrPrise> actually I'm over the 8 lights, I need to make the lights better already.
[12:08:50] *** NeoThermic has joined ##OpenGL
[12:10:44] *** groton_ has joined ##OpenGL
[12:13:37] <quicksilver> I would think if you draw each object only taking into account the 8 nearest that would work pretty well.
[12:14:25] <MrPrise> my main problem is I use quads for the tiles. (I'm working on a 2d tile based game). most of the examples are using a big texture as the floor, they don't care more than one faces. maybe I should render my tiles into a texture and then just display that?
[12:15:29] <MrPrise> so my whole screen would be a one quad and that would make the lightmap calculation easier
[12:15:37] <MrPrise> and probably faster
[12:16:59] <MrPrise> hm, maybe with this even the basic 8 OpenGL lights would work well. what do you think? I'm playing with OpenGL for a few weeks so I have no idea ;-)
[12:17:13] *** lea\ has joined ##OpenGL
[12:17:56] <MrPrise> how big could be a texture?
[12:20:32] *** WimLeers has quit IRC
[12:25:54] <NeoThermic> MrPrise: texture sizes are limited by the card
[12:27:58] *** groton has quit IRC
[12:32:52] <MrPrise> it seems 25 x 1280x1024 32 bit image takes around 125mb. so the memory should not be a problem.
[12:33:53] *** groton_ is now known as groton
[12:44:37] <quicksilver> MrPrise: there is no particular advnatage to rendering the tiles as one big texture, that I can see.
[12:44:44] <quicksilver> you can have the tiles being lots of little textures
[12:44:48] <quicksilver> and still the lightmap as one big texture
[12:44:53] <quicksilver> there is no conflict between those two
[12:45:07] <quicksilver> each tile just uses a small portion of the lightmap texture (using texCoord)
[12:47:42] <MrPrise> I see. I have problem with this part. how to calculate these texture coordinates
[12:48:08] <MrPrise> meanwhile I realized I can not use big textures anyway, because I have animated tiles too
[12:48:19] *** Sabman has joined ##openGL
[12:48:31] <quicksilver> calculating the texture coordinates is just a bit of basic math
[12:52:15] <MrPrise> but I have to know which tiles are affected by the light(s)
[12:53:04] <quicksilver> well you draw the lightmap "big"
[12:53:12] <quicksilver> store a bounding box perhaps
[12:53:19] <quicksilver> but you could just assume it applies to all tiles
[12:53:30] <quicksilver> if it doesn't really they're just going to pick up transparency so it won't matter
[12:54:58] <MrPrise> ah, ok
[12:56:36] *** meteors has joined ##OpenGL
[12:57:44] *** cami has quit IRC
[13:00:07] <quicksilver> of course it's wasted time to blend in transparency
[13:00:11] <quicksilver> but it's not very slow
[13:00:17] <quicksilver> and if were you I'd want to get *something* working
[13:00:27] <quicksilver> and then worry about ways to optimise it :)
[13:01:00] *** Ingenu has quit IRC
[13:03:38] *** WimLeers has joined ##OpenGL
[13:04:44] <MrPrise> yes ;-) thanks
[13:05:17] *** t4bz has quit IRC
[13:06:30] *** Roderic has joined ##OpenGL
[13:06:31] *** Roderic is now known as Ingenu
[13:11:50] *** t4bz has joined ##OpenGL
[13:14:45] *** Ademan has quit IRC
[13:15:41] *** Ademan has joined ##OpenGL
[13:19:33] *** oogaw has quit IRC
[13:21:02] *** Baba has quit IRC
[13:24:32] *** LtJax has joined ##OpenGL
[13:24:36] *** Baba has joined ##OpenGL
[13:28:14] *** Burga__ has quit IRC
[13:28:38] *** cami has joined ##OpenGL
[13:29:03] *** Sabman has quit IRC
[13:29:28] *** MrPrise has left ##OpenGL
[13:33:26] *** enoex has joined ##OpenGL
[13:40:59] *** Walt has quit IRC
[13:43:30] *** Wagoo has joined ##opengl
[13:43:54] *** cami has quit IRC
[13:59:36] *** mm^away is now known as mm765
[14:18:05] *** rnx has joined ##opengl
[14:22:48] *** NeoThermic has quit IRC
[14:27:45] *** NeoThermic has joined ##OpenGL
[14:39:48] *** LordMetroid has joined ##OpenGL
[14:43:11] *** blight_ has joined ##opengl
[14:43:29] *** ajww has joined ##OpenGL
[15:01:53] *** Bollinger has quit IRC
[15:03:25] *** Castigador has joined ##Opengl
[15:20:22] *** m4ggus has joined ##opengl
[15:21:26] *** _Rangar_ has joined ##OpenGL
[15:21:28] *** Rangar has quit IRC
[15:32:16] *** m4ggus_ has joined ##opengl
[15:34:19] *** wouter227 has joined ##OpenGL
[15:34:47] <wouter227> hi
[15:35:51] *** LtJax has quit IRC
[15:36:50] <wouter227> does anyone know if there's an opengl based library that allows you to use 3d dialog windows? like rendered on an opengl surface?
[15:36:59] <Adrinael> CEgui
[15:37:09] <Adrinael> Perhaps
[15:38:33] <wouter227> i'll take a look at it :)
[15:38:56] <hibread> Qt
[15:39:07] *** m4ggus__ has joined ##opengl
[15:39:15] <hibread> but its not an opengl based library
[15:41:44] <NightBird> glut has support for some basic dialog windows... you may want to check freeglut specifically, theirs may have better support
[15:42:23] <wouter227> i need to be able to position the dialog in 3d space, like an actual 3d object
[15:44:44] *** m4ggus has quit IRC
[15:45:29] *** rnx has quit IRC
[15:45:38] *** MrPrise has joined ##OpenGL
[15:45:42] <MrPrise> re
[15:46:21] *** m4ggus__ is now known as m4ggus
[15:47:04] <wouter227> cegui and glow both seem to be using 2D overlays
[15:48:10] *** rnx has joined ##opengl
[15:48:32] <MrPrise> finally I was able to implement a light with lightmap. it is not clear how can I have more lights. I have a lightmap texture, I use that as the second texture for the tiles with texture coordinates.
[15:50:58] *** m4ggus_ has quit IRC
[15:51:05] *** aalex has joined ##OpenGL
[15:51:59] <NightBird> MrPrise: just add the extra light points to the lightmap?
[15:52:42] <MrPrise> NightBird: these are dynamic lights.
[15:53:18] <NightBird> I think lightmaps are mainly used for static lights...
[15:53:21] *** vjoe has joined ##OpenGL
[15:53:28] <NightBird> I may be completely wrong of course
[15:54:05] <MrPrise> I suppose I need a texture for every faces which will hold the lightmaps for any given face. all I need to create those lightmap textures. I can add to them more lightmap.png
[15:54:15] <hibread> MrPrise: you dont generally use light maps for dynamic lights
[15:54:31] *** HuntsMan has quit IRC
[15:55:04] <MrPrise> hibread: ok, but how can I have eg 15 lights?
[15:55:22] <hibread> MrPrise: what are you attemping to do for starters?
[15:55:33] <hibread> whats the scene you're trying to light and for what reason
[15:56:20] <quicksilver> tile based game with lots of dynamic lights
[15:56:24] <quicksilver> think diablo :)
[15:56:25] <quicksilver> I gather.
[15:56:31] <MrPrise> quicksilver: thanks ;-)
[15:56:45] <quicksilver> lots of dragons breathing fire and moving fireballs and glowing monkeys
[15:56:47] <quicksilver> you know the drill.
[15:56:56] <quicksilver> 85 glowing monkeys onscreen at one time!
[15:57:02] <MrPrise> ;-)
[15:57:06] <NightBird> ah yes, the glowing monkeys problem
[15:57:15] <hibread> well in that case use deferred shading :) for the 85 monkeys
[15:57:37] <NightBird> a classical problem that nearly all graphics programmers will have to answer at one point or another
[15:58:33] <hibread> and seriously MrPrise, if you don't pass the glowing monkeys problem now, there isn't much hope for you
[15:58:34] <MrPrise> I'm absolutely beginner ;-)
[15:58:53] <MrPrise> hibread: I'm working on it ;-)
[15:58:58] <NightBird> MrPrise: are the lights very spread apart?
[15:59:55] <MrPrise> NightBird: no, they could cover each other. if that was your thought
[16:00:16] <hibread> MrPrise: this tiled game... using 3d concepts still? Err.. you're not just moving around tiles representing "light" ....
[16:00:42] <hibread> im seriously thinking deferred lighting here... but maybe a bit to advanced if you think you're a beginner
[16:00:48] <MrPrise> hibread: I want to move tiles around as lights if that give a reasonable result
[16:01:07] <MrPrise> hibread: what is the deferred lighting?
[16:01:22] <hibread> So "good looking" graphics is not a prerequisit?
[16:01:47] <MrPrise> hibread: no, it is not. I just need light radius around things.
[16:01:54] *** wouter227 has quit IRC
[16:02:04] <NightBird> MrPrise: well, I was going to suggest if they were, to cluster lights together, that way you can artificially increase the number of lights in any given scene. any objects you render would enable the closest/most impact lights, then render as normal. That way you get most of the effects of the lights even without hardware support....
[16:02:37] <hibread> MrPrise: so the characters are totally flat? Just pictures on a tile?
[16:03:02] <hibread> so you have 3d models?
[16:03:06] <MrPrise> hibread: yes, just a plane what I constructed from quads, one quad is a tile
[16:03:27] <hibread> hmmm
[16:03:28] <NightBird> ah
[16:04:00] <MrPrise> it is not isometric like Diablo.
[16:04:12] <MrPrise> I think that is not matter
[16:04:25] <hibread> i cannot picture how you'd do lighting with tiles
[16:04:27] <MrPrise> for the lights on the floor
[16:04:34] <NightBird> hibread: you fake it
[16:04:47] *** bbeausej has joined ##OpenGL
[16:04:48] <MrPrise> hibread: my first idea was to draw lights as tiles above the floor
[16:05:02] <hibread> MrPrise: so just "lighten up" the area?
[16:05:13] <MrPrise> hibread: yes, I want to achieve that
[16:05:21] <hibread> draw a transparent light shaped item over the top/
[16:05:22] <hibread> ?
[16:05:25] <NightBird> yeah, I would suggest having a multi-layerd tile map, and have at least part of one of those layers can include lights
[16:05:36] <MrPrise> hibread: yes, I tried that
[16:05:39] <quicksilver> transparent light shaped item is rather like a lightmap, really.
[16:05:46] <quicksilver> just a slight variation on the technique.
[16:06:02] <MrPrise> quicksilver: well, a real lightmap uses multitexturing, that is not
[16:06:14] <MrPrise> much easier for me ;-)
[16:06:17] <hibread> Id personally scrap tile based game and go for a 3d top down game where items move as if they were tiles
[16:06:39] <MrPrise> hibread: why would this make easier the lighting?
[16:06:42] <hibread> atleast then you can ahve real dynamic lights
[16:06:44] *** Castigador has quit IRC
[16:06:53] <hibread> lighting is a piece of cake really
[16:07:16] <hibread> if yu ahve the models, and those models contain normals... its almost too easy
[16:07:18] <NightBird> chocolate cake?
[16:07:35] <hibread> which ever you prefer. Just make sure its not fruit cake
[16:07:52] <NightBird> hm... what about cheese cake? can it be a nice cheese cake? :P
[16:08:03] <hibread> yeah cheese cake ranks quite highly
[16:08:11] <hibread> as long as its not lemon flavoured..
[16:08:17] <NightBird> strawberry
[16:08:24] <MrPrise> hibread: I can not see this yet ;-) basically I have a plane build from quads on the screen, I would have more lights above them. how do you do this easily? I really would like to see a demo or tutorial
[16:08:29] <hibread> never tried it, but i'd assume thats nice
[16:08:44] <MrPrise> ah and those lights should be dynamic lights
[16:09:40] *** black_Nightmare_ has joined ##OpenGL
[16:10:13] *** Castigador has joined ##Opengl
[16:10:50] <NightBird> okay, time for me to get ready for work
[16:10:56] <MrPrise> hibread: if you can do this easily please make a little demo for me.
[16:11:05] * NightBird hopes that animation job I started last night actually managed to finish..
[16:11:13] <MrPrise> NightBird: ;-)
[16:11:29] <NightBird> or, at least, is still processing
[16:11:32] <hibread> MrPrise: easy doesn't necessarily mean quick :)
[16:11:39] <MrPrise> hibread: ah ;-)
[16:12:19] <MrPrise> I have read a lots of lighting stuff in the last few days, I have not seen any good tutorial. all of them was old, does not compile with recent compiler, etc.
[16:13:21] <hibread> MrPrise: i still dont really know what you're trying to achieve out of all this. My idea was just to impliment a top down 3D (orthographic or perspective projection) game using a similar engine to move the actors around as you would with a tile based game
[16:13:53] <MrPrise> hibread: I use ortho projection already.
[16:14:05] <vjoe> I am a Linux user and I would like to learn OpenGL, what do you recommend?
[16:14:15] <vjoe> I would prefer to use C or C++ as the programming language
[16:14:19] <hibread> yep, and you just render quads as your tiles? correct
[16:14:25] <MrPrise> hibread: yes
[16:14:50] <MrPrise> hibread: so I suppose I can use real dynamic lights. I just need to know how ;-)
[16:15:21] <MrPrise> I read about the vertex shaders. I don't know if that would be the ultimate solution or not for me
[16:15:25] <hibread> I dont think dynamic lighting with a game as such has really been done... I can only picture placing anothe tile over the top (transparent as i said before) which resembles a light "glow"
[16:16:30] <vjoe> hello?
[16:16:31] <MrPrise> hibread: it would be ok that, but I tried that and that does not lighten up the floor.
[16:16:42] <hibread> vjoe: learning OpenGL would be done by some good reference (ie the Red Book). And then pick your poison as far as the library to help you set up the window (GLUT, SDL, GLFW, etc etc)
[16:16:44] *** karabash has joined ##OpenGL
[16:17:13] <hibread> what do you mean by lighten up?
[16:17:18] <vjoe> I was intending to learn from nehe
[16:17:32] <hibread> vjoe: how serious is your want to learn?
[16:17:38] <hibread> just a passing hobby?
[16:18:43] <MrPrise> hibread: I must draw the tiles using black color with glColor3f(0,0,0). when I draw my "lights" above them, everything was black only the area covered by the light bitmap was visible, I can not see the floor below it.
[16:18:44] <vjoe> yes
[16:18:47] <vjoe> just the basics
[16:18:50] *** cami has joined ##OpenGL
[16:18:58] <hibread> if its just a phase you're going through, then by all means learn from NeHe
[16:18:59] <vjoe> if I like it, I will buy a book for further learning of course
[16:19:40] <MrPrise> if I don't use black for the floor, they would be visible without the "lights"
[16:20:04] <hibread> MrPrise: so you want the floor to be totally black unless there is a light?
[16:20:15] <quicksilver> MrPrise: well that just means you need to learn about blending modes :)
[16:20:28] <quicksilver> MrPrise: tehre are solutions along those general lines which will work.
[16:20:31] <MrPrise> hibread: yes, maybe I should use a big lights for a base dim
[16:20:37] <quicksilver> including drawing the floor first in full
[16:20:42] <quicksilver> but then drawing black over them
[16:20:45] <quicksilver> in the dark parts :)
[16:20:56] <quicksilver> so your light texture is fully transparent in the lightest bits
[16:21:01] <quicksilver> and completely black at the edges
[16:21:05] <quicksilver> so it hides the floor over there.
[16:21:29] <quicksilver> for more interesting effects you can colour the light and play with blending
[16:22:25] <MrPrise> quicksilver: that means I have to render twice my scene?
[16:22:44] <hibread> just use real 3D :)
[16:22:51] <MrPrise> hibread: ok, how? ;-)
[16:23:20] <quicksilver> no, you're only rendering the scene once
[16:23:22] <quicksilver> render floor
[16:23:24] <quicksilver> render lights on top
[16:23:33] <quicksilver> the "lights on top" layer contains black portions
[16:23:42] <quicksilver> which completely erase the floor in the dark areas
[16:23:44] <MrPrise> quicksilver: you wrote "then drawing black over them"
[16:23:47] <quicksilver> yes
[16:23:52] <quicksilver> that's still only rendering the scene once
[16:23:57] <hibread> MrPrise: there is no one liner to explain how to write a basic 3d engine :)
[16:24:00] <quicksilver> it's just rendering two things on top of each other
[16:24:12] <MrPrise> hibread: I just need the light parts from it ;-)
[16:24:18] <quicksilver> almost all openGL scenes have at least some cases where one thing is rendered on top of another.
[16:24:26] <quicksilver> that's not rendering the scene twice.
[16:24:38] <MrPrise> quicksilver: ok.
[16:24:39] <quicksilver> rendering the scene twice is when you draw every single model more than once, for some special effect or other.
[16:24:48] <Ingenu> that's overdraw
[16:24:53] <hibread> the lights part of a 3d scene requires that the scene you have is described in 3d dimensions with all the relevant info (vertices, normals etc etc)(
[16:24:53] <quicksilver> (like the 8-16 light hack we discussed earlier)
[16:25:17] *** LjL has quit IRC
[16:25:18] <MrPrise> hibread: I suppose I can calculate these for single quads
[16:26:06] <hibread> yeah you could light the flat floor with real per pixel lighting.. but when it comes to lighting the models too.. i dunno i guess you could just light the quad...
[16:26:44] *** blight_ has quit IRC
[16:27:07] <MrPrise> hibread: there are not any 3d model. they are just tiles, textures
[16:27:54] <MrPrise> I really need lights on the floor only
[16:28:02] <hibread> yeah. You could light the tiles with normal "3D lighting"..
[16:28:09] <hibread> floor only hey?
[16:28:19] *** smiler has quit IRC
[16:28:24] <MrPrise> hibread: since there is only a floor
[16:28:36] <MrPrise> hibread: that is the map for the game.
[16:28:47] <hibread> sounds like a great game. Attack of the floors? :)
[16:28:58] *** blight_ has joined ##opengl
[16:29:47] <hibread> well, all you need to do is supply a normal with vertex of each quad. That normal would point out of the screen
[16:29:48] *** smiler has joined ##OpenGL
[16:29:49] <MrPrise> hibread: ;-) imagine it as the uridium. it has more layers, but there is only one layer where the enemies and the players are moving. I need lights only there
[16:30:00] <hibread> err thats horrible english sorry
[16:30:22] <hibread> so you do need to light the enemies and players too
[16:31:31] <MrPrise> hibread: no, because the lights will be on the enemies or on the players or missiles etc.
[16:31:46] <MrPrise> they are just bright
[16:32:04] <hibread> got a screenie of what you've got so far?
[16:32:56] <MrPrise> one moment. and sorry for my English. it is even worse when I try to write quickly ;-)
[16:36:12] <MrPrise> that is the result when I draw two lights as regular textures
[16:36:14] <hibread> whats the red and green?
[16:36:22] <MrPrise> those would be the lights ;-)
[16:36:23] <hibread> ok
[16:36:30] <MrPrise> at max intensity
[16:36:37] <hibread> play around with different blending
[16:36:43] <hibread> as another user suggested
[16:36:48] <MrPrise> there are only 3 of them, no?
[16:36:51] *** odietsch has joined ##OpenGL
[16:36:57] <hibread> thats just src_alpha, one on src alpha?
[16:37:10] *** sanjin has joined ##OpenGL
[16:37:17] <hibread> mountains of blending options
[16:38:01] *** sanjin has quit IRC
[16:38:40] <MrPrise> ah I think I mixed with glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
[16:38:41] *** korff has quit IRC
[16:39:27] *** DobosCake has quit IRC
[16:39:30] <hibread> I haven't messed much with blending. But there shuld be an adequate solution there somewhere
[16:40:36] * NightBird goes to work
[16:45:22] *** mm765 is now known as mm765^away
[16:45:46] *** karabash has quit IRC
[16:48:38] <WimLeers> I'm doing displayID = glGenLists(1); then glNewList(displayID, GL_COMPILE), then opengl commandos and then glEndList(). Finally, I render everything using glCallList((displayID). But nothing is rendered. Any thoughts?
[16:52:00] *** dv__ has joined ##opengl
[16:52:25] *** dv__ is now known as dv_
[16:52:46] <dv_> hmm
[16:52:49] <dv_> say,
[16:52:56] <dv_> how much does a state proxy really pay off?
[16:53:23] <dv_> I mean, I dont doubt the usefulness of state proxies for texture, shader, and FBO binds
[16:53:52] <dv_> but the glEnable/glDisable stuff? DepthMask, DepthFunc, BlendFunc etc.?
[16:53:58] <Ingenu> state proxy ? you mean keeping track of states not to issue redundant one ?
[16:54:03] <dv_> yes
[16:54:20] <Ingenu> never benchmarked
[16:54:22] <rnx> WimLeers: check for opengl errors, post a testcase
[16:54:25] <Ingenu> I would assume the drivers does it too
[16:54:30] <dv_> IIRC the GL internally sends only state batches anyway
[16:55:21] <WimLeers> rnx: how do you check for opengl errors? I'm getting _NSAUtoreleaseNoPool() errors, but I suppose that's due to Mac OS X. Note that I'm using OpenGL from within Qt btw.
[16:56:18] *** aalex has quit IRC
[16:57:11] <rnx> glGetError() gluErrorString()
[16:58:26] <WimLeers> rnx: thx
[17:02:23] <WimLeers> rnx: after a while, while repainting the exact same scene, the stack overflow error starts occurring
[17:05:17] <WimLeers> rnx: ok found the cause for that, was only pushing the projection matrix. However, the display list is *still* not displaying…
[17:07:10] <rnx> then post the code
[17:08:04] *** BramBonne has joined ##OpenGL
[17:09:10] <WimLeers> rnx: ok… but I convert the contents of an XML file to opengl commands… so it's not easily reviewable.
[17:11:55] <MrPrise> hibread: are you here?
[17:12:10] <WimLeers> rnx: and I just do glCallList(<id that's set by Parser::loadDisplayListFromFile>)
[17:12:17] <hibread> MrPrise: you called
[17:12:48] <MrPrise> hibread: you started to tell me how can I have real dynamic lights. do you know a goog tutorial on this topic?
[17:13:11] <MrPrise> hibread: it seems I will ned 50-100 lights on the screen
[17:13:32] *** BramBonne has quit IRC
[17:13:41] <hibread> MrPrise: any opengl lighting tutorial will bound to explain dynamic lighting
[17:13:57] <hibread> well.. hmmm
[17:14:01] *** cami has quit IRC
[17:14:19] <WimLeers> rnx: have to go now, if you feel like going through that code, feel free to mail me at mail at wimleers dot com
[17:14:26] <WimLeers> rnx: thanks for your help!
[17:14:27] *** WimLeers has quit IRC
[17:14:50] <hibread> with "real" dynamic lighting, you really need to do some scene managment
[17:15:04] <hibread> you dont want to be rendering everything on the screen with 50-100 lights
[17:16:27] <MrPrise> hibread: all the lighting tutorial I found uses GL_LIGHTING
[17:16:44] <hibread> well thats right. Thats what we're talking about
[17:16:48] <hibread> or atleast one form of it
[17:17:14] <MrPrise> ok, but I read that it slow and I can have only 8 lights without tricks
[17:17:53] <hibread> for the scope of your project, stick with what you've got. Just use a different blending function
[17:18:18] <hibread> you'd want to use the same function thats used with light maps in 3d scenes
[17:18:35] <MrPrise> ok.
[17:20:30] <MrPrise> hibread: yes, I read that.
[17:22:43] <MrPrise> hibread: you can see the lights does not affect the floor below
[17:22:58] <hibread> what blendfunc() are you using?
[17:23:16] <MrPrise> glBlendFunc ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
[17:23:21] <hibread> its the way the light and what ever is already in the frame buffer is combined that is making it look that way
[17:23:36] <hibread> thats right, you're using a transparency style blend. YOu need an additive maybe?
[17:23:44] <hibread> something along those lines anyway
[17:25:05] <MrPrise> I don't know
[17:25:08] <hibread> been a while since ive used blending. I'd have to look into it
[17:26:03] *** BahamutZERO has quit IRC
[17:27:39] <hibread> yeah that does. What'd you do?
[17:28:23] <MrPrise> I just changed to glBlendFunc ( GL_SRC_ALPHA, GL_DST_ALPHA);
[17:28:45] <MrPrise> however if I draw the floor with completely black I can not see anything except the lights
[17:29:00] <MrPrise> so they don't light it
[17:29:09] <hibread> wel yeah. That'll be the limitation of this method. You can't get information out of black :)
[17:30:23] <MrPrise> I think that would be ok for a while
[17:30:35] <MrPrise> thank you for your help
[17:30:57] <hibread> I think for more perfect results, you need to actually do proper lighting whilst drawing the floor
[17:31:15] <hibread> which would require some scene managment if you have 50-100 lights in any one scene
[17:31:25] *** MrPrise has left ##OpenGL
[17:31:31] *** MrPrise has joined ##OpenGL
[17:31:35] <MrPrise> hops, sorr
[17:31:36] <MrPrise> y
[17:31:52] <hibread> or, deferred shading/rendering/lighting would simplify this scene management
[17:32:04] <MrPrise> I wish I know what are these ;-)
[17:32:56] <hibread> If you dont know how opengl lighting works, then describing how deferred lighting works might be difficult
[17:33:45] *** prophile has joined ##opengl
[17:33:52] <MrPrise> I will use google
[17:35:10] *** BahamutZERO has joined ##OpenGL
[17:38:35] <MrPrise> hibread: thanks. interesting
[17:44:18] *** charlie5 is now known as charlie_zzz
[17:44:49] *** blight_ has quit IRC
[17:45:10] *** blight_ has joined ##opengl
[17:46:51] *** hibread has quit IRC
[17:47:05] *** dust has joined ##OpenGL
[17:47:09] *** hibread has joined ##opengl
[17:51:08] *** cami has joined ##OpenGL
[17:52:05] *** [AD]Turbo is now known as TurboAWAY
[17:54:27] *** taortan has quit IRC
[18:05:31] *** Walt has joined ##opengl
[18:12:00] *** DMINATOR has joined ##OpenGL
[18:15:12] <hibread> occlusion query tests are pretty dang fast (assuming all writes are off). I just tested rendering 10 full screen quads each frame without any noticable slow down (to the eye)
[18:15:29] *** Castigador has quit IRC
[18:16:14] <hibread> 50 fullscreen quads and the frame rate might have dropped from 60hz to 30hz
[18:20:07] *** groton has quit IRC
[18:20:45] *** gotan666 has joined ##OpenGL
[18:20:51] <hibread> actally thats a lie.. still seems to ahve no frame rate drop... something can't be right. Its reporting many millions of pixels though
[18:20:53] *** black_Nightmare_ has left ##OpenGL
[18:22:27] *** Lemml has joined ##OpenGL
[18:22:57] <MrPrise> hm. maybe I should just use a 3d engine like Ogre
[18:23:25] <MrPrise> I think that would be an overkill
[18:26:35] *** Yustme has joined ##opengl
[18:33:02] *** HuntsMan has joined ##opengl
[18:37:39] *** cami has quit IRC
[18:39:12] <quicksilver> MrPrise: using a 3D engine like ogre or crystal can be very handy
[18:39:18] <quicksilver> but on the other hand, it's a whole lot more to learn
[18:39:36] <quicksilver> and, in some cases, it can be hard to understand unless you have at least a basic grasp of how stuff underneath works.
[18:39:51] <meteors> hi all, another question
[18:40:22] <meteors> My sphere (as you may recall) has a pixmap wrapped around. The pixmap is a star field, and the space between the stars is alpha transparent.
[18:40:50] <meteors> I want to be able to see the stars from behond the pixmap as well, for a full transparent effect.
[18:41:10] <meteors> Is there an easy way to do this, or do I need to have two spheres, with different winding?
[18:42:47] <MrPrise> quicksilver: yes, you are right.
[18:44:16] <quicksilver> meteors: you mean you want to be able to see both faces of the sphere?
[18:44:27] <quicksilver> meteors: looking through it from outside?
[18:44:52] <meteors> yes, and from inside
[18:44:53] <quicksilver> MrPrise: I have found learning openGL quite instructive, if not always easy
[18:45:01] <quicksilver> meteors: from inside surely you can only ever see one face?
[18:45:17] *** Lucine_AFK is now known as Lucine
[18:45:24] <meteors> I want the face of the pixmap to be visible from inside as well as outside of the sphere
[18:45:37] <meteors> The pixmap is alpha transp;arent, with white dots for stars.
[18:45:56] <meteors> I can't see the dots on the far side of the sphere due to it not being visible from inside the sphere.
[18:45:59] <meteors> Does that make sense?
[18:46:31] <odietsch> Yes, it makes sense. Disable culling
[18:46:40] <meteors> I tried that, it didn't work.
[18:46:47] <meteors> unless I missed something
[18:47:11] <meteors> So, a pixmap should be visible from the opposite side of a textured object, as long as culling is disabled?
[18:47:33] <odietsch> the zbuffer may discard the far fragments
[18:47:48] <meteors> You mean due to depth testing?
[18:47:55] <odietsch> Yup
[18:48:07] <meteors> It will help if I upload a screenshot of my app.
[18:48:10] <meteors> doing that now
[18:48:55] <quicksilver> turn off depth testing is the answer form outside
[18:49:00] <quicksilver> and culling indeed, if you're using that
[18:49:08] <quicksilver> from inside I'm confused.
[18:49:18] <quicksilver> when you're on the inside the pixmap should be visible.
[18:49:23] <meteors> I'll try turning off depth testing
[18:49:30] <meteors> I did not try that.
[18:49:45] <quicksilver> it's the depth test which stops drawing hte back face when there is already a front face.
[18:50:02] <quicksilver> but if you're using the glut primitive for a sphere I have a feeling it does vertex culling as well.
[18:50:06] <quicksilver> not sure though.
[18:50:40] <meteors> I'm not using glut
[18:51:10] *** scy has joined ##opengl
[18:51:58] <meteors> That works perfectly.
[18:51:59] <meteors> Thanks :-)
[18:52:02] <quicksilver> sorry, not glut, GLUT
[18:52:03] <quicksilver> GLU
[18:52:06] <quicksilver> damn muscle memory
[18:52:14] <quicksilver> it wants to type the T after GLU
[18:52:19] <quicksilver> 'gluSphere'
[18:52:24] <meteors> I didn't think GLU even had a sphere
[18:52:42] <meteors> strange as that sounds, I remember looking for it but not finding it
[18:52:46] <quicksilver> it does, it's called gluSphere
[18:52:49] <quicksilver> strangely enough :)
[18:52:50] <meteors> cool
[18:52:57] <quicksilver> but if you've worked out how to render your own spehre, all the better
[18:53:03] <meteors> I know there's a teapot function :-)
[18:53:04] <quicksilver> the GLU primitves are mostly useful for quick hacks.
[18:56:19] *** rodietze has joined ##opengl
[18:58:35] *** rodietze is now known as Niteon
[18:59:57] *** Lemml_ has joined ##OpenGL
[19:00:31] *** Niteon is now known as rodietze
[19:00:42] *** Lukas_the_kid has joined ##OpenGL
[19:01:21] *** rodietze is now known as niteon
[19:01:48] *** Lukas_the_kid has left ##OpenGL
[19:01:51] *** Lukas_the_kid has joined ##OpenGL
[19:02:23] *** Lukas_the_kid has left ##OpenGL
[19:09:11] <dv_> hmhm
[19:09:50] <dv_> glVertexAttribPointer accepts GL_BYTE, GL_UNSIGNED_BYTE, GL_SHORT, GL_UNSIGNED_SHORT, GL_INT, GL_UNSIGNED_INT, GL_FLOAT, GL_DOUBLE as types
[19:10:19] <dv_> but are integer or bool vertex members supported at all in current hardware?
[19:10:27] <dv_> (and double)
[19:10:48] <HuntsMan> G80 has full support for integers
[19:10:54] <HuntsMan> doubles, i wouldn't think so
[19:11:37] <Ingenu> forget about doubles
[19:11:53] <Ingenu> you don't need that anyway
[19:12:51] <Ingenu> float prefered
[19:12:56] <dv_> ok, so supporting integers is reasonable
[19:13:03] <dv_> (in the code I mean)
[19:13:06] <dv_> bool?
[19:13:06] <HuntsMan> yeah
[19:13:14] <HuntsMan> there's a GL_BOOL?
[19:13:20] <dv_> ah wait, bool = uchar in gl
[19:13:28] <dv_> err ubyte
[19:13:29] <Ingenu> yep
[19:13:30] <HuntsMan> yep
[19:13:36] <Ingenu> prooly int in GGPU
[19:13:39] <dv_> okay, I'll add these
[19:13:42] <Ingenu> oo=ll
[19:14:24] <Ingenu> alternatively you could read D3D10 manual ;)
[19:14:39] <Ingenu> they only chose fast path data types
[19:14:41] <dv_> well I know that gl3 will kick double
[19:15:06] <dv_> at least, thats what the press release says.
[19:15:09] <Ingenu> na it's just to know the hardware fast path
[19:15:24] <dv_> fast path = float I guess
[19:15:25] <Ingenu> you don't care about the API, just the supported types
[19:15:42] <dv_> and maybe unsigned int
[19:16:41] <Ingenu> think you'll need that extra bit of precision ?
[19:17:19] <dv_> sometimes
[19:17:30] <dv_> well not in vertices
[19:18:17] <dv_> hmm ok for most operations, a bunch of vertex attribs with float as type is sufficient
[19:18:26] *** dolphin has joined ##OpenGL
[19:19:50] <vasoq> do any of you know of "real time rendering" and if i can use another book/resource as substitute?
[19:20:29] <HuntsMan> dv_: G80 also supports unsigned 32 bit integers :)
[19:23:23] <Ingenu> real-time rendering is a pretty good book
[19:23:45] *** Lemml has quit IRC
[19:23:48] <Ingenu> not sure what you could use instead
[19:24:08] <Ingenu> prolly the book i'd recommend to someone wanting to know about 3D (programming)
[19:24:20] <Ingenu> well more like general knowledge/algorithms
[19:25:23] <Ingenu> I know some other resources, but none that good, it covers many things, in details when it's important, quickly when there are lots of resources on the topic
[19:25:30] <Ingenu> it's easy to follow and read
[19:25:58] <Ingenu> I could point you to older books, rather complete covering the basics
[19:26:11] <Ingenu> but expensive, big, and loaded with things you prolly don't care atm
[19:27:58] *** Jupp3 has joined ##OpenGL
[19:28:08] *** _boto has joined ##opengl
[19:32:45] *** dust has quit IRC
[19:33:25] *** Suprano has joined ##OpenGL
[19:35:33] *** rnx has quit IRC
[19:37:21] *** TheLorax has joined ##opengl
[19:42:49] *** rnx has joined ##opengl
[19:44:23] *** TheLorax has quit IRC
[19:52:42] *** replor has joined ##OpenGL
[19:59:07] *** aalex has joined ##OpenGL
[20:00:16] *** Xmas| has joined ##OpenGL
[20:01:17] *** dolphin has quit IRC
[20:02:37] *** TheLorax has joined ##opengl
[20:07:12] *** TheLorax has quit IRC
[20:09:52] *** aalex has quit IRC
[20:11:56] *** kebeku-jin has joined ##OpenGL
[20:12:30] <kebeku-jin> I have a question regarding glut, is this the good place to ask about it?
[20:13:47] <HuntsMan> sure
[20:13:56] <kebeku-jin> ok great!
[20:15:00] <kebeku-jin> I'd like to know if its possible to get something like key-up key-down events, instead of only key-press with the glutKeyboardFunc....
[20:15:14] <kebeku-jin> to get more fluid movements in my game...
[20:16:14] *** aalex has joined ##OpenGL
[20:23:37] <DMINATOR> doesn't glut has something like key up and down events ?
[20:23:54] <hibread> kebeku-jin: i dont use glut, but it seems with the glutMouseFunc callback you have a state parameter
[20:24:05] *** juanmabc has joined ##opengl
[20:24:06] <hibread> which is either GLUT_UP or GLUT_DOWN
[20:28:10] *** WimLeers has joined ##OpenGL
[20:29:01] *** dv_ has quit IRC
[20:29:57] <kebeku-jin> Ok so DMINATOR, your telling me that there are other callback that I can hook for this purpous...? That would be great!
[20:30:06] <kebeku-jin> Ill check for that
[20:30:36] <kebeku-jin> hibread, ok but Im more interested in keyboard input
[20:30:38] <WimLeers> can you start a display list and build its contents within *another* function? I.e. something like
[20:30:39] <WimLeers> displayID = glGenLists(1);
[20:30:39] <WimLeers> glNewList(displayID, GL_COMPILE);
[20:30:39] <WimLeers> parse(root);
[20:30:39] <WimLeers> glEndList();
[20:30:51] <HuntsMan> of course you can
[20:31:10] <hibread> oh sorry
[20:31:11] <WimLeers> right, that's what I thought too. It just won't work. But that's at least one possible cause eliminated! Thanks ;)
[20:31:54] <DMINATOR> no sorry I am not fammiliar with glut I thought in some examples I saw something like that :)
[20:32:42] <DMINATOR> and it would be pretty strange if there wasn't such functionality
[20:33:11] <hibread> kebeku-jin: looks like glut is pretty crap and i wouldn't use it
[20:33:14] <hibread> try out sdl :)
[20:33:48] <DMINATOR> i would also suggest sdl its pretty easy to get familiar with and its really cool !
[20:35:25] *** eidolon has joined ##OpenGL
[20:36:09] <eidolon> hi folks, could someone help me out with some performance tuning? I'm seeing very slow glxgears performance - or what i see as slow - on a Pentium 4 2.4gig machine. glxgears is showing 800-850 fps. GeForce 6200. 'nv' kernel module is loaded.
[20:36:26] <DMINATOR> ok i have found some example in book. There is GLUT_KEY_UP
[20:36:34] <DMINATOR> you need to check if with your key
[20:36:44] <DMINATOR> then you would find is it up or down
[20:37:09] <DMINATOR> you can define a function like void SpecialKeys(int key, int x, int y)
[20:37:41] <DMINATOR> then add it to glut in main() via glutSpecialFunc(SpecialKeys);
[20:37:41] <WimLeers> HuntsMan: ok, suppose you've got a display list that won't render. How would you start looking for the cause? No opengl errors are occurring…
[20:38:02] *** LordMetroid has quit IRC
[20:38:35] <MatthiasM> DMINATOR: wrong - key_up is a key on the keyboard
[20:38:40] <DMINATOR> hmm yes :(
[20:38:44] <DMINATOR> I just realised that :)
[20:38:55] <DMINATOR> sorry my bad :(
[20:41:32] *** aalex has quit IRC
[20:43:56] <HuntsMan> WimLeers: show the code that the display list contains
[20:44:31] *** hibread has quit IRC
[20:44:59] *** Jorachim has quit IRC
[20:45:29] <WimLeers> HuntsMan: impossible, it's parsed from a .xml file :P I can show you a really simple xml file and the parser (only 100 lines of very simple code, it reads like a knife cuts butter), but not sure if you're willing to do that. I'll post the code anyway, sec.
[20:45:36] *** Jorachim has joined ##OpenGL
[20:47:56] *** Ingenu has quit IRC
[20:48:02] <WimLeers> HuntsMan: which proves it's working properly
[20:48:33] *** odietsch^ has joined ##OpenGL
[20:48:54] <HuntsMan> WimLeers: does it draw correctly if you don't use a display list?
[20:49:10] <WimLeers> HuntsMan: yep
[20:49:18] <HuntsMan> mmm
[20:49:25] <HuntsMan> don't use doubles
[20:49:30] <HuntsMan> glVertex3d(x, y, z);
[20:49:33] <HuntsMan> don't do that :)
[20:50:31] <HuntsMan> the same for colors
[20:50:38] <HuntsMan> as double isn't a native type for any actual GPU
[20:50:54] <bobbens> using doubles isn't inherently bad :)
[20:51:27] <HuntsMan> for performance it is
[20:51:39] <HuntsMan> and some implementations might reject display list containing non-native data
[20:51:46] <bobbens> actually, I believe that there's some cpus that actually do better with doubles
[20:51:49] <WimLeers> well, this isn't exactly a performance-critical app :P
[20:51:50] <bobbens> just takes more memory though :P
[20:52:06] <WimLeers> (screenshot of that thing)
[20:52:12] <WimLeers> (when written in code)
[20:58:57] *** karabash has joined ##OpenGL
[21:02:45] *** adampetrone has quit IRC
[21:03:03] *** odietsch has quit IRC
[21:03:34] *** WimLeers is now known as WimLeers|school
[21:04:17] *** dust has joined ##OpenGL
[21:05:26] *** Lucine has quit IRC
[21:07:58] *** Walt_ has joined ##opengl
[21:11:50] *** Walt has quit IRC
[21:12:27] *** WimLeers|school is now known as WimLeers
[21:12:37] <WimLeers> HuntsMan: no other ideas?
[21:15:21] *** karabash has quit IRC
[21:20:35] *** Lemml has joined ##OpenGL
[21:21:42] *** TheLorax has joined ##opengl
[21:23:16] <WimLeers> is 0 a valid display id?
[21:23:33] <HuntsMan> display list id?
[21:23:40] <WimLeers> yeah
[21:23:51] <HuntsMan> no idea, i would say no
[21:23:58] <HuntsMan> are you generating your own display list id's?
[21:24:02] <WimLeers> that's what I'd say too
[21:24:02] <WimLeers> no
[21:24:23] <WimLeers> the thing is, when I generate a new DL inside my parser function, I always get 0
[21:24:58] <MatthiasM> WimLeers: you can't start to record a list or generate an id if you are already compiling a list
[21:24:59] <WimLeers> however, if I don't do that call and I create a DL inside my "normal" code, I always get 1 as the first display id
[21:25:00] <HuntsMan> you probably don't have a context
[21:25:16] <WimLeers> that's what I think too, something context-ish missing
[21:25:28] <WimLeers> HuntsMan: but… how does one get context?
[21:25:52] <MatthiasM> WimLeers: it's not context related - otherwise it wouldn't render without the list
[21:25:53] <WimLeers> HuntsMan: is it possible that I lose the context because my parser is a static function?
[21:26:04] <HuntsMan> no, the context is "global"
[21:26:05] <WimLeers> MatthiasM: but it *won't* render…
[21:26:12] <MatthiasM> WimLeers: and again - your programming language has nothing to do with OpenGL
[21:26:33] <WimLeers> ok
[21:27:03] <WimLeers> but that doens't help me. How is it possible that I'm getting bad display list ids then?
[21:27:14] <HuntsMan> no idea, show more code :)
[21:27:16] <MatthiasM> did you check for gl errors ?
[21:27:32] <WimLeers> HuntsMan: you saw all code already… see those pastebin links
[21:27:38] <WimLeers> MatthiasM: yes, 0 errors
[21:27:52] <MatthiasM> glGetError !
[21:28:16] <WimLeers> qDebug() << (char *) gluErrorString(glGetError());
[21:28:21] <WimLeers> "no error" as output
[21:28:37] *** Lucine2 has joined ##OpenGL
[21:28:49] *** DobosCake has joined ##OpenGL
[21:28:55] <HuntsMan> WimLeers: yeah, but i never saw OpenGL init code and where you call the loadDisplayListFromFile function.
[21:29:45] <WimLeers> GLuint displayID = glGenLists(1);
[21:29:45] <WimLeers> qDebug() << "is DL" << glIsList(displayID);
[21:29:49] <WimLeers> outputs 0
[21:29:54] <WimLeers> so that's the cause
[21:30:24] *** groton has joined ##OpenGL
[21:30:36] <HuntsMan> sure, so, where do you create a context?
[21:31:51] <WimLeers> I *don't*? I haven't seen that anywhere
[21:32:10] <HuntsMan> do it in initializeGL()
[21:32:22] <HuntsMan> not in the constructor
[21:32:34] <HuntsMan> The initialization of OpenGL rendering state, etc. should be done by overriding the initializeGL() function, rather than in the constructor of your QGLWidget subclass.
[21:32:42] <HuntsMan> :)
[21:33:18] <WimLeers> O M G
[21:33:23] <WimLeers> I *HAD* IT THERE
[21:33:33] <WimLeers> I'm going to bitch slap my colleague all day long tomorrow
[21:33:35] <WimLeers> he moved it around
[21:33:39] <WimLeers> ARGH
[21:33:49] <WimLeers> HuntsMan: of course. Thanks.
[21:34:20] <WimLeers> HuntsMan: if you're around Hasselt, Belgium sometime, ping me, I'll buy you a beer :P
[21:34:36] <HuntsMan> lol, sure :D
[21:34:44] <WimLeers> mehhhhhhhhhhhhhhhhhhhhh
[21:35:08] <HuntsMan> i only have got to Graz, Austria btw
[21:37:11] <WimLeers> heh ok, only 600 kms or so away
[21:37:26] <HuntsMan> yeah, but that was a work travel
[21:37:42] <HuntsMan> i hope to be there someday this year again
[21:37:55] *** prophile has quit IRC
[21:38:35] *** Lemml_ has quit IRC
[21:42:11] *** aalex has joined ##OpenGL
[21:46:18] *** Lemml_ has joined ##OpenGL
[21:47:55] *** Suprano has quit IRC
[21:51:56] *** mm765^away is now known as mm765
[21:51:56] *** Stonuuq has joined ##OpenGL
[21:53:02] <kebeku-jin> hibread, ok, what would you suggest instead of glut as a portable openGL gui toolkit?
[21:53:09] <HuntsMan> SDL
[21:53:20] <kebeku-jin> hmm
[21:53:41] <kebeku-jin> ok, ill think about using that instead...
[21:53:46] <kebeku-jin> thx guys!
[21:56:08] *** kebeku-jin has left ##OpenGL
[21:57:12] *** WimLeers has quit IRC
[22:00:17] *** Suprano has joined ##OpenGL
[22:01:01] *** groton has quit IRC
[22:03:34] *** Stonuuq has left ##OpenGL
[22:05:53] *** Lemml has quit IRC
[22:06:10] *** fargiolas has joined ##OpenGL
[22:09:43] *** neoneye has quit IRC
[22:10:46] <TheLorax> SDL has gui functionality?
[22:16:56] <phrosty> nai
[22:19:02] *** reviver has joined ##OpenGL
[22:23:10] *** TheLorax has quit IRC
[22:23:40] *** odietsch^ has quit IRC
[22:24:28] *** lolage0 has joined ##OpenGL
[22:26:32] *** qsheets has joined ##OpenGL
[22:26:49] *** dust has quit IRC
[22:27:26] * qsheets needs opinions...
[22:29:32] *** dust has joined ##OpenGL
[22:30:30] <phrosty> define better
[22:31:27] <qsheets> most people would rather see/enjoy it than the other
[22:32:13] <qsheets> aka... more appealing to the eye
[22:33:07] <phrosty> 2 seems more happy
[22:33:19] <phrosty> smiles
[22:33:24] <qsheets> kk
[22:33:46] <qsheets> thx
[22:35:56] *** qsheets has left ##OpenGL
[22:38:53] *** gotan666 has quit IRC
[22:40:55] *** MrPrise has left ##OpenGL
[22:48:13] *** [this] has joined ##opengl
[22:48:56] *** [this] has quit IRC
[23:01:53] *** Lemml_ has quit IRC
[23:07:07] *** dust has quit IRC
[23:09:17] *** filthpig has joined ##OpenGL
[23:10:41] <filthpig> you've prolly heard this question a gazillion times, but here goes: Does anyone know anything about the release of OGL3?
[23:11:43] <Xmas|> yes
[23:11:47] <Xmas|> the ARB does
[23:12:00] <Xmas|> anyone in Khronos who is interested in OpenGL does
[23:12:07] *** neoneurone has joined ##OpenGL
[23:13:05] *** reviver has quit IRC
[23:18:50] *** Yustme has quit IRC
[23:19:42] *** fargiolas has quit IRC
[23:24:20] *** filthpig has quit IRC
[23:24:41] *** blbmp has joined ##OpenGL
[23:25:19] *** bbeausej has quit IRC
[23:29:13] *** Suprano has quit IRC
[23:30:06] *** Suprano has joined ##OpenGL
[23:38:34] *** cami has joined ##OpenGL
[23:38:52] *** cami has quit IRC
[23:42:02] *** neoneurone has quit IRC
[23:48:34] *** WimLeers has joined ##OpenGL
[23:50:36] *** noteventime has joined ##OpenGL
[23:51:12] *** NeoThermic has quit IRC
[23:52:11] *** prophile has joined ##opengl
[23:53:36] *** Latheesan has joined ##opengl
[23:54:25]
<Latheesan> hi, can someone help me workout how to do 2D rotation on a circle? I draw my circle like this : http://pastebin.ca/1011127
[23:54:54] <Latheesan> how can i add a simple 2D rotation to it?
[23:55:35] <HuntsMan> using glRotatef()
[23:55:55] <Latheesan> hmm i think i tried that
[23:56:10] <Latheesan> got a sec, have a look at this screenshot
[23:56:30] <Latheesan> see my cannon? it rotates around that red circle (its invisible btw)
[23:56:52] <Latheesan> i wanted to be able to add a similar functionality to the cannon ball, so as the cannon is being rotated by a certain degree
[23:56:59] *** m4ggus_ has joined ##opengl
[23:57:01] <Latheesan> so does the ball, so the ball stays in the mouth
[23:58:30] <HuntsMan> well can you just google for glRotatef?
[23:58:30] <Latheesan> rotate works fine with that, same trick doesnt work with the circle cannon ball
[23:59:35] *** brutopia has quit IRC
[23:59:46] <Latheesan> void glRotatef(
[23:59:46] <Latheesan> GLfloat angle,
[23:59:46] <Latheesan> GLfloat x,
[23:59:46] <Latheesan> GLfloat y,
[23:59:46] <Latheesan> GLfloat z)
[23:59:47] <Latheesan> like this?