[08:44:00] *** echelog has joined ##OpenGL
[08:47:02] *** ToreTank has quit IRC
[08:51:32] *** rabbit- has joined ##OpenGL
[08:52:38] *** sohail has quit IRC
[08:57:09] *** duzt has quit IRC
[08:58:29] *** fargiolas has joined ##OpenGL
[09:04:56] *** povman has joined ##OpenGL
[09:06:09] *** povman has quit IRC
[09:06:16] *** povman has joined ##OpenGL
[09:07:17] *** Bollinger has joined ##OpenGL
[09:10:44] *** rnx has joined ##opengl
[09:15:34] *** [AD]Turbo has joined ##OpenGL
[09:17:52] *** WildCaterpillar has quit IRC
[09:20:39] *** kenws has joined ##OpenGL
[09:30:11] <[AD]Turbo> hi all
[09:30:55] *** ToreTank has joined ##OpenGL
[09:50:24] *** rabbit- has quit IRC
[09:53:46] *** UUncia has quit IRC
[09:57:41] *** povman has quit IRC
[09:57:49] *** Ingenu has joined ##OpenGL
[10:02:33] *** twist has joined ##opengl
[10:02:45] *** twist has quit IRC
[10:03:36] *** Nescafe has joined ##OpenGL
[10:03:57] *** povman has joined ##OpenGL
[10:11:12] *** belou has joined ##OpenGL
[10:12:09] *** JernejL has quit IRC
[10:13:35] *** Gorgoroth has quit IRC
[10:15:40] *** kenws has quit IRC
[10:18:58] *** kbotnen has joined ##OpenGL
[10:25:03] *** povman has quit IRC
[10:25:49] *** povman has joined ##OpenGL
[10:26:09] *** Entelin has quit IRC
[10:26:32] *** Entelin has joined ##OpenGL
[10:26:56] *** povman has quit IRC
[10:29:05] *** aib42 has joined ##opengl
[10:33:02] *** MrSunshine_ has joined ##OpenGL
[10:33:36] <MrSunshine_> humm, what is the modern way of drawing these days? .. Vertex Buffer Objects for vertices .. but colors, normals etc? . using AttribArrays ?
[10:33:41] <MrSunshine_> and a shader .. or ?
[10:39:50] <quicksilver> MrSunshine_: you can put anything in a VBO
[10:39:57] <quicksilver> MrSunshine_: colours normals texture coords
[10:40:04] <quicksilver> and whatever customer stuff your shader might choose.
[10:40:08] <quicksilver> custom stuff.
[10:40:14] <MrSunshine_> ohh
[10:40:27] * MrSunshine_ is very confused over modern use of opengl
[10:40:33] <MrSunshine_> im used to glVertex3f etc :)
[10:44:34] <quicksilver> well considering vertex arrays were introduced in opengl1.1
[10:44:49] <quicksilver> which is over 10 years old ;)
[10:45:04] <zacs7> quicksilver: hey don't bag half life ;)
[10:45:05] <quicksilver> you should have been considering moving away from glVertex3f a long time ago.
[10:45:15] <MrSunshine_> hehe ... but there is very little info on the more powerfull usages of the newer stuff on the net imo
[10:45:26] <MrSunshine_> all i can find if i search VBO array is how they put vertices in one and render it ...
[10:45:31] <MrSunshine_> nothing about the stuff you said ... :)
[10:46:15] <quicksilver> opengl
[10:46:20] <quicksilver> oops copy paste fail
[10:46:21] * quicksilver tries again
[10:46:25] <quicksilver> http://www.opengl.org/documentation/specs/version1.1/glspec1.1/node21.html
[10:46:40] <quicksilver> not just vertex pointer, but also tex coord pointer, color pointer, normal pointer, etc.
[10:46:44] <MrSunshine_> ahh there nehe has one that shows how to use texcoords in a vbo also :)
[10:46:47] <quicksilver> VBOs are just like VAs in this sense.
[10:46:55] <MrSunshine_> VA?
[10:46:59] <MrSunshine_> vertexarray
[10:46:59] <MrSunshine_> :P
[10:47:27] <MrSunshine_> so the glTexCoordPointer etc is still very much relevant? :)
[10:47:31] <quicksilver> yes.
[10:47:33] <MrSunshine_> ok :)
[10:47:38] <quicksilver> you use glTexCoordPointer with VBOs too.
[10:47:39] <MrSunshine_> was someone who said they were old stuff ... :P
[10:47:50] <quicksilver> well, in a sense they are, yes.
[10:47:51] * MrSunshine_ is very confused man ;)
[10:47:59] <quicksilver> because when you write your own shader, you can do whatever you want.
[10:48:00] <MrSunshine_> ahh .. what is the most modern stuff then ? :)
[10:48:07] <MrSunshine_> ahh
[10:48:13] <MrSunshine_> but then there will have to be a shader for everything ?
[10:48:26] <quicksilver> there always is a shader for everything
[10:48:35] <quicksilver> it's just a question of a built-in one, or one you wrote.
[10:49:28] <MrSunshine_> but glAttribArray etc confuses me even more :) can you bind them to say gl_Normal in a program or do you have to make own attributes for everything in every program ? :)
[10:54:10] <quicksilver> http://www.opengl.org/sdk/docs/man/xhtml/glBindAttribLocation.xml
[10:54:22] <quicksilver> you set up which attributes correspond to which shader variables
[10:54:34] <quicksilver> you can completely ignore the standard ones if you like
[10:54:52] <quicksilver> although I have a feeling that some opengl drivers don't let you re-use the standard indices.
[10:56:55] *** ol1veira__ has joined ##OpenGL
[10:57:02] <MrSunshine_>  confusing .. )
[10:57:03] <MrSunshine_> :)
[10:59:08] <MrSunshine_> GL_INVALID_OPERATION is generated if
[10:59:08] <MrSunshine_> 	name starts with the reserved prefix
[10:59:08] <MrSunshine_> 	"gl_".
[10:59:12] <MrSunshine_> ops .. sorry for spam :)
[10:59:18] <MrSunshine_> i guess gl_Normal etc isnt permitted then :)
[10:59:51] <quicksilver> you don't need to bind gl_Normal
[10:59:54] <quicksilver> that one is auto-bound
[11:00:28] <quicksilver> to some low index like 2 or 3 although I don't think it's part of the spec to say which index it is.
[11:01:55] <MrSunshine_> Note: Index 0 is reserved for gl_Vertex when enabling GL_VERTEX_ARRAY
[11:02:04] <MrSunshine_> is the only one i find .. then they bind 1 2 3 4 etc to their own stuff
[11:03:04] <MrSunshine_> ahh there :)
[11:03:05] <MrSunshine_> found a list
[11:03:44] <quicksilver> I think it's driver specific. I think you're *supposed* to be able to use any of the other vertices, but I also think I have read about bugs in some drivers if you try to use the low numbers.
[11:03:48] * quicksilver shrugs.
[11:03:51] <quicksilver> I could be wrong.
[11:04:57] *** kenws has joined ##OpenGL
[11:05:24] *** Entelin has quit IRC
[11:05:28] <aib42> so, there are 1) glVertex loops, 2) display lists 3) Vertex arrays 4) VBOs?
[11:05:53] <zacs7> vertex loops ftw
[11:05:59] * zacs7 is stuck in the past
[11:06:36] * aib42 compiles zacs7 into a display list and shouts "display lists ftw"
[11:06:37] <quicksilver> display lists are somewhat unrelated.
[11:06:52] <quicksilver> all those thigns can be used inside display lists
[11:06:57] <quicksilver> and display lists can contain other state changes
[11:07:17] <aib42> hmm
[11:07:20] * zacs7 suspects quicksilver is not a quake2 engine fan ;)
[11:07:59] <quicksilver> the quake2 engine is backend independent.
[11:08:06] <quicksilver> it has a software backend as well as an opengl backend.
[11:08:12] <quicksilver> IIRC.
[11:08:25] <aib42> I've only ever used them to make glBegin~End lists. but you're right.
[11:08:35] <zacs7> quicksilver: yes but I was talking about the gl renderer for it :-)
[11:08:48] <quicksilver> display lists are a great idea, it's a shame they got deprecated.
[11:08:53] <quicksilver> But they're hard work for the driver authors
[11:09:03] <aib42> they did? what replaced them?
[11:09:09] *** ol1veira_ has quit IRC
[11:09:15] <quicksilver> nothing.
[11:09:21] <quicksilver> "do the work yourself"
[11:09:24] <aib42> ouch
[11:09:28] <MrSunshine_> so i can just call glVertexAttribPointer(2, 3, GL_FLOAT, GL_FALSE, 0, &nyNormals); and they will be present in my shader after that? :)
[11:09:49] <quicksilver> MrSunshine_: if you're using normals, just you glNormalPointer. IMO.
[11:10:06] <quicksilver> I don't think there is much point using a custom attribute for the sake of it.
[11:10:09] <MrSunshine_> quicksilver, well just trying to understand the glVertexAttrib stuff :)
[11:10:46] * quicksilver nods
[11:11:33] <MrSunshine_> but if i did it that way that would be my normals inside gl_Normal inside the program after that? :)
[11:11:45] <aib42> what will openGL 3.0 be like?
[11:11:53] <MrSunshine_> upgraded gl 2.1 :P
[11:11:59] <MrSunshine_> as they didnt do what they promised
[11:12:40] <aib42> ah hold on, it was already released
[11:12:45] <MrSunshine_> yes
[11:12:52] <aib42> is
[11:12:56] <MrSunshine_> 3.1 its said they will do the new stuff in but .. dunno if i trust them :P
[11:13:00] <quicksilver> opengl 3.0 declares the path they plan to take by deprecating shedloads of stuff
[11:13:05] <MrSunshine_> aib42, requires dx10 hw tho
[11:14:01] <aib42> I hate it when they rate hardware over DX versions
[11:14:12] <MrSunshine_> hehe :)
[11:14:12] <MrSunshine_> ye
[11:14:13] *** pietia has quit IRC
[11:14:41] <MrSunshine_> aib42, think it is cause hw vendors seem to tend to upgrade drivers etc to dx versions very fast and slack on gl versions :P
[11:14:54] <MrSunshine_> they are microsoft ****s all of them
[11:15:16] <MrSunshine_> "ohh a new dx version .. lets implement it!" .. "ohh .. opengl3 ... why should we?"
[11:15:30] *** UUncia has joined ##OpenGL
[11:21:12] *** Entelin has joined ##OpenGL
[11:23:03] <aib42> MrSunshine_: and they what, put the exact number of registers on the processor that the DX model requires?
[11:23:21] <MrSunshine_> dunno :P
[11:23:37] <MrSunshine_> feels like they are are MS lovers tho :)
[11:24:13] <quicksilver> they work hard on the things that make them the most money.
[11:24:16] <quicksilver> Like pretty much any company.
[11:24:44] <quicksilver> game developers use DX, MS are good at getting new DX versions out pretty quickly, the hardware guys produce the drivers quickly.
[11:25:11] *** Nescafe has quit IRC
[11:25:37] <[Peter]> quicksilver: wow, it's the hw guys that build the drivers? that explains a few things..
[11:25:39] <aib42> of course.
[11:26:16] <quicksilver> well, not actually the same human beings, in most cases
[11:26:19] <quicksilver> but the same compny.
[11:26:28] <[Peter]> :)
[11:26:30] <quicksilver> ATI designs chips, chipsets, and wwrite drivers.
[11:26:39] <quicksilver> on windows, of course.
[11:26:42] <zacs7> not very good drivers either ;)
[11:26:54] <MrSunshine_> well they have for linux also quicksilver so :)
[11:26:58] <MrSunshine_> both ati and nv
[11:27:04] <quicksilver> on linux the drivers are a mixture of vendor code and community code
[11:27:07] <MrSunshine_> atleast ati has released their specs :)
[11:27:12] <quicksilver> with various advantages and disadvantages
[11:27:24] <quicksilver> and on the mac, there is a mixture of vendor code and apple code.
[11:27:35] <zacs7> sigh for apple
[11:38:23] *** johndoe has joined ##opengl
[11:42:21] *** Entelin has quit IRC
[11:43:51] *** zacs7 has quit IRC
[11:58:21] *** Entelin has joined ##OpenGL
[12:00:00] *** rabbit- has joined ##OpenGL
[12:06:45] *** Nescafe has joined ##OpenGL
[12:07:35] *** LtJax has joined ##opengl
[12:18:59] *** marque has joined ##OpenGL
[12:21:48] <marque> hello, why are these two piece of code not equivalent ? : <http://pastebin.com/m1b5e698d>
[12:23:25] <quicksilver> marque: because to use drawArrays you must have one normal per vertex
[12:23:32] <quicksilver> and you're trying to use one normal per 3 vertices
[12:23:43] <marque> ok, thank you :)
[12:24:09] <marque> but... which normal should I choose for a vertex ?
[12:24:11] <MrSunshine_> feels strange to have a vertex size of 9 ?
[12:24:29] <MrSunshine_> 3, GL_FLOAT ... not 9, GL_FLOAT right ? :)
[12:24:41] <MrSunshine_> and do you realy have to do 3 * num_triangles? :)
[12:24:57] <MrSunshine_> ohh its 3 steps :P
[12:25:01] <MrSunshine_> sorry nm me :)
[12:25:07] <marque> :)
[12:25:48] <quicksilver> marque: you can duplicate it 3 times
[12:25:53] <quicksilver> if you want 'flat looking' faces
[12:25:58] <quicksilver> but you need to have the same number.
[13:05:24] *** burak575 has joined ##OpenGL
[13:07:24] *** Z has joined ##OpenGL
[13:07:33] *** Z is now known as Guest28611
[13:07:43] <Guest28611> anyone knows the bounce sample ?
[13:07:51] <Guest28611> and which is written in c
[13:08:04] <Guest28611> i need its c++ implementation
[13:08:18] <Guest28611> do anyone knows where can i find one
[13:08:30] <Guest28611> or can anyone convert it for me .
[13:08:49] * Guest28611 wonders if is possible ;P
[13:08:51] <Guest28611> blah
[13:08:57] <Guest28611> whatewer..
[13:09:55] <Guest28611> how can i compile /use  c code as c++ code  ?
[13:10:55] <[Peter]> ?
[13:11:15] <Guest28611> will that extern "language_name" declaration ; things going to work ?
[13:11:27] <Guest28611> do i hawe to try it ?
[13:12:18] <Guest28611> i mean if i move code inside a  extern "C"  {  } functionic thing will it work ?
[13:12:43] <[Peter]> most C code will compile just fine as C++ code. you might need to add some explicit type casting though.
[13:12:51] <[Peter]> extern "C" is only for symbol names
[13:13:45] <Guest28611> hm.. thanks .. .
[13:13:54] <Guest28611> that gives some cluses.
[13:13:54] <[Peter]> http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html that might help you
[13:15:05] *** LtJax has quit IRC
[13:15:06] *** Nescafe has quit IRC
[13:17:34] *** Nescafe has joined ##OpenGL
[13:21:10] *** Sudi has joined ##OpenGL
[13:24:21] *** predaeus has joined ##opengl
[13:32:01] *** djork has joined ##opengl
[13:39:56] *** gusnan has joined ##OpenGL
[13:43:42] *** GuShH has quit IRC
[13:49:36] *** rutski has quit IRC
[13:49:47] *** djork has quit IRC
[13:52:48] *** __THEGOD_ has joined ##OpenGL
[13:54:34] <__THEGOD_> knoppix 6 looks too slow for me when i tryed it first time later.
[13:54:54] <__THEGOD_> it looks like last cool linux is knoppix 5.3
[13:55:40] <__THEGOD_> and knoppix 6 does not hawe qemu neither vine
[13:56:21] <TheFlash> __THEGOD_: It's: "have" and "wine". And knoppix is not a relevant subject here.
[14:05:20] *** Guest28611 has quit IRC
[14:11:12] *** __THEGOD_ has left ##OpenGL
[14:34:59] *** burak575 has quit IRC
[14:36:00] *** rabbit- has quit IRC
[14:44:06] *** hibread has left ##opengl
[14:45:42] *** povman has joined ##OpenGL
[14:55:05] <jimi_hendrix> if i am using openGL, how would i make the screen "scroll"
[14:55:17] <marque> I have plane built with triangle strip like that : <http://ns27638.ovh.net/mlasson/wireframe.png> and when I colorize it with a mipmap I get <http://ns27638.ovh.net/mlasson/plane.png> with this ugly lines, can you guess what I did wrong ?
[14:55:52] <marque> *these
[14:56:45] <marque> the mipmap is just one grey pixel
[14:58:23] *** Sos has joined ##opengl
[14:58:34] <Sos> hi
[15:00:23] *** pietia has joined ##OpenGL
[15:04:58] <quicksilver> jimi_hendrix: change the modelview matrix.
[15:05:09] <jimi_hendrix> easy?
[15:05:17] <jimi_hendrix> quicksilver, ^^
[15:05:25] <quicksilver> yes.
[15:05:33] <quicksilver> marque: "colorize it with a mipmap" ?
[15:06:03] <quicksilver> marque: the difference between those two is that one is drawing lines and one is drawing triangles.
[15:06:15] <quicksilver> it's not clear to me you're using textures at all.
[15:07:28] <marque> I gave "wireframe.png" so as you can see which primitive I used
[15:07:52] <marque> I applied a one pixel texture, but I can't put a bigger one if you want
[15:08:17] <quicksilver> too many possible ways to get that effect
[15:08:21] <quicksilver> you might be colouring your vertices
[15:08:28] <quicksilver> you might be blending with a pixel border
[15:08:33] <quicksilver> you might have lighting turned on
[15:08:36] <quicksilver> and have funny normals...
[15:08:49] <marque> you can see the normals on the wireframe actually
[15:08:56] <marque> (light is turned on)
[15:09:39] <marque> I plotted them for debugging
[15:09:42] <quicksilver> looks to me like you're assigning per-vertex colours
[15:09:47] <quicksilver> or your textures isn't what you think it is.
[15:11:35] *** dv_ has quit IRC
[15:12:05] <marque> I plot the strip glDrawArrays without enabling GL_COLOR_ARRAY
[15:14:19] <marque> +using
[15:21:34] <quicksilver> marque: to give you useful help I will have to see your code
[15:23:19] <marque> oh, thanks
[15:25:06] <marque> <http://ns27638.ovh.net/mlasson/pack.tar.gz>
[15:26:06] <marque> It should compile under linux and mac os (I don't know windows, sorry)
[15:28:39] <marque> I do apologize for all the uglyness :/
[15:29:18] <marque> "make test" should make it work on an example
[15:32:53] <marque> do you manage to make it "work" ?
[15:47:02] <quicksilver> heh.
[15:47:11] <quicksilver> I only expected you to paste the source to a pastebin
[15:47:13] <quicksilver> but I'llt ake a look
[15:48:56] *** zommi has quit IRC
[15:51:59] <marque> I think it's a normal problem
[15:52:15] <quicksilver> so do I ;)
[15:52:58] <marque> but it's strange, when the plane is horizontal, all the normal are set to (0.,0.,1.0) and I do have the same problem
[15:53:22] <marque> TRIANGLE_STRIP is hard to use
[15:53:28] *** Xantoz has quit IRC
[15:55:00] <quicksilver> by the way, you bind a texture but you don't set any texture coords
[15:55:08] <quicksilver> so I'm sure your texture is not part of the problem here.
[15:59:30] <quicksilver> apparently I don't have a working libjpeg so I can't compile your code.
[15:59:34] *** scai has joined ##opengl
[15:59:43] *** mattn2|home has joined ##OpenGL
[15:59:44] <quicksilver> but I'm guessing the problem is in cptNormal
[16:00:26] <marque> what ?
[16:00:39] <marque> no, I don't think so
[16:01:23] <marque> if you succeed compiling it you can press F5 during the execution and it will show you the normals
[16:02:07] <quicksilver> yes but each point exists in six triangles
[16:02:13] <quicksilver> so there are six normals at each point
[16:02:20] <quicksilver> it's easy for one to be right and the others to be wrong
[16:02:26] <quicksilver> and it to be hard to see what's going on, isn't it?
[16:02:26] <marque> hum
[16:02:38] <marque> it is :)
[16:02:41] <quicksilver> for example, one of the normals coul dbe "lying flat"
[16:02:50] <quicksilver> and you wouldn't see it clearly
[16:02:59] *** povman_ has joined ##OpenGL
[16:06:12] *** UUncia has quit IRC
[16:07:56] *** TiLex has joined ##opengl
[16:08:21] *** johndoe has quit IRC
[16:09:43] <quicksilver> I think the way you calculate normals is odd
[16:09:49] <quicksilver> it's just based on 'the next vertex in the array'
[16:09:57] <quicksilver> not 'the other two vertices of this triangle'
[16:10:15] <quicksilver> also, if you're not consistent about your winding direction, some vertices will come up downawards
[16:10:23] <quicksilver> which would give the kind of effect you're seeing
[16:11:02] *** nofxx has quit IRC
[16:11:02] *** TenOfTen has quit IRC
[16:11:03] *** LiraNuna has quit IRC
[16:13:17] *** LiraNuna has joined ##OpenGL
[16:13:54] <marque> Quentarez, ok, thanks, I'll try to sort that out
[16:14:10] *** TenOfTen has joined ##opengl
[16:15:06] <predaeus> marque, I did not follow the conversation, but I'd try to render it with triangles first and then optimize to strips later.
[16:18:02] <quicksilver> he is actually using triangles.
[16:18:10] <quicksilver> I thnk the strips comment was an aside.
[16:18:42] <quicksilver> glNormalPointer(GL_FLOAT, 0, triangles_normal); glVertexPointer(3, GL_FLOAT, 0, triangles); glDrawArrays(GL_TRIANGLES, 0, 3 * num_triangles);
[16:19:00] <quicksilver> which looks fine to me. It's just the way the normals are calculated which looks wrong.
[16:20:14] *** povman has quit IRC
[16:23:08] *** bstock has quit IRC
[16:26:44] *** nofxx has joined ##OpenGL
[16:30:15] *** povman_ has quit IRC
[16:38:19] *** TheLorax has joined ##opengl
[16:40:05] *** pietia has quit IRC
[16:41:44] *** Sos has quit IRC
[16:46:55] *** predaeus has quit IRC
[16:51:49] *** pietia has joined ##OpenGL
[16:52:34] *** scai has left ##opengl
[16:59:48] *** vade has joined ##OpenGL
[17:00:06] *** Sudi has quit IRC
[17:06:27] <aib42> wow, they've deprecated glBegin()
[17:06:52] *** Sudi has joined ##OpenGL
[17:08:14] <aib42> wow, they've deprecated fixed-function vertex processing. Is everything to be done using shaders, in the future?
[17:10:16] <dindinx> yeah, that's the idea
[17:10:41] *** HuntsMan has joined ##opengl
[17:12:54] *** alyawn has joined ##OpenGL
[17:13:45] <RTFM_FTW> everything (FF wise) has been done via shaders for the last several generations
[17:13:47] *** kenws has quit IRC
[17:13:55] <aib42> not to sound like a troll, but what good is openGL without the MV matrix?
[17:14:02] <RTFM_FTW> at least concerning FF TexEnv, LIGHTING, ...
[17:14:19] <RTFM_FTW> the MV matrix is an illusion
[17:15:04] <RTFM_FTW> you can generate your own matrices on the client side and pass them into the programmable pipeline
[17:15:19] <RTFM_FTW> which is exactly what the driver does
[17:15:30] <aib42> certainly. but what will openGL become then except a GLSL compiler?
[17:16:19] <RTFM_FTW> umm the GL driver isn't much more than a wrapper around a shader compiler and (kernel side) resource manager
[17:16:42] <RTFM_FTW> this has been the case for several generations now
[17:16:44] *** sohail has joined ##OpenGL
[17:16:55] <aib42> yea sorry I'm a bit behind
[17:17:32] <aib42> so in summary, the graphics libraries are becoming lightweight wrappers around the ever-growing gfx hardware?
[17:18:26] <RTFM_FTW> well the "wrapper" I was hinting at isn't necessarily lightweight (at least in terms of LOC)... although it tries to be WRT performance
[17:20:41] <aib42> ok, humor me for one more second. vertex array passing is not deprecated. so while creating various objects using vertex arrays, what will render them in different positions on the scene? e.g. will each array have a seperate identifier which the shader will recognize and apply a MV transformation to, or, say will a different shader modifying the 'current' MV matrix be run in between array calls?
[17:21:34] <quicksilver> aib42: that's entirely up to you
[17:21:44] <quicksilver> aib42: you can pass a modelview matrix in as a uniform
[17:21:45] <RTFM_FTW> you can pass (local, environment, ...) parameters directly into the programmable pipeline
[17:21:49] <RTFM_FTW> this was my point
[17:21:54] <quicksilver> if you wish to do something 'like' the old FF way
[17:21:58] <quicksilver> or you can do something different.
[17:22:09] <quicksilver> You can pass in some other representation of the scene parameters
[17:22:20] <quicksilver> and do something entirely different in your vertex shader.
[17:22:33] <quicksilver> YOu don't have to put "position in world space" into the VBOs, either.
[17:22:37] <RTFM_FTW> uniform(s) are effectively local parameters
[17:22:46] <quicksilver> You can put any old bytes you want in the VBOs.
[17:22:48] <aib42> I see.
[17:22:55] <quicksilver> you might put in parameters which you feed to a function inside the shader
[17:23:07] <quicksilver> thus - procedurally generated geometry
[17:23:39] <quicksilver> or you might have basic position in one attribute, and bone information in other attributes
[17:23:44] <quicksilver> to do animation in your vertex shader.
[17:23:44] <quicksilver> etc.
[17:24:56] <aib42> Thanks
[17:26:55] *** vade has quit IRC
[17:28:42] *** Sudi has quit IRC
[17:32:12] *** jfroy has quit IRC
[17:35:39] *** reprore_ has joined ##OpenGL
[17:36:21] *** wey has joined ##opengl
[17:39:15] *** Xantoz has joined ##OpenGL
[17:40:52] *** mattn2|home has quit IRC
[17:47:16] *** [AD]Turbo has quit IRC
[17:49:56] *** johndoe has joined ##opengl
[17:54:04] *** jfroy|work has joined ##opengl
[17:54:28] *** itewsh has joined ##OpenGL
[17:54:47] *** GuShH has joined ##OpenGL
[17:58:54] *** reprore_ has quit IRC
[18:02:38] *** hjpark has joined ##OpenGL
[18:05:54] *** Sudi has joined ##OpenGL
[18:12:53] *** NightVisio has joined ##OpenGL
[18:13:28] *** TheLorax has quit IRC
[18:16:35] *** reprore_ has joined ##OpenGL
[18:24:54] *** JernejL has joined ##OpenGL
[18:27:27] *** _sana has joined ##OpenGL
[18:29:03] <_sana> hello, there is a 3D graphical library based on openGL with higher level graphical primitives ? i want to make a platform for visualizing the execution of any user defined algorithm. Also, if there is such a platform, let me know please :)
[18:31:20] <quicksilver> openscenegraph, perhaps
[18:31:31] <quicksilver> OGRE3D maybe (game oriented)
[18:34:38] *** fargiolas has quit IRC
[18:40:46] *** a-stray-cat has joined ##OpenGL
[18:41:43] *** ToreTank has quit IRC
[18:44:32] *** doub has quit IRC
[18:47:21] *** GuShH has quit IRC
[18:49:31] *** androoid has joined ##OpenGL
[18:57:54] *** Sudi has quit IRC
[18:58:57] *** XT95_ has joined ##opengl
[19:04:07] *** belou has quit IRC
[19:04:13] <NightVisio> what the*
[19:04:44] <NightVisio> glLoadMatrix works only with untransposed matrix :-/
[19:04:56] <NightVisio> a.k.a. "DirectX matrix"
[19:05:16] <NightVisio> and when I try to transpose it - it doesn't work
[19:05:22] <HuntsMan> what about glLoadTranspose?
[19:06:12] <NightVisio> what?!
[19:06:38] <NightVisio> I passed a "standard matrix" and it works
[19:06:40] <NightVisio> why?
[19:08:54] *** mm765^sleep is now known as mm765
[19:15:16] *** Amorphous has quit IRC
[19:15:54] <HuntsMan> you passed a DirectX matrix and it worked?
[19:17:31] <NightVisio> yes
[19:17:54] <HuntsMan> actually i read that's normal
[19:18:02] *** Sos has joined ##opengl
[19:18:07] <HuntsMan> because DX matrices are row-ordered and transposed with respect to GL
[19:18:13] <HuntsMan> so, in memory, they're the same
[19:18:32] *** Amorphous has joined ##opengl
[19:18:43] <NightVisio> but transposed doesn't work
[19:19:02] <NightVisio> (I can't see anything in the spacwe)
[19:19:04] <NightVisio> space*
[19:22:57] <HuntsMan> yeah
[19:23:14] <HuntsMan> the memory layout of both of them is the same, so transposing screws up
[19:30:15] *** Walt has joined ##opengl
[19:34:59] *** scai has joined ##opengl
[19:42:30] *** wey has quit IRC
[19:43:30] *** NightVisio has quit IRC
[19:51:57] *** predaeus has joined ##opengl
[19:54:56] *** ixtli has quit IRC
[19:58:42] *** FunkyJive has joined ##OpenGL
[19:59:07] *** x0rx0r has joined ##OpenGL
[19:59:12] *** ixtli has joined ##OpenGL
[19:59:43] *** hjpark has quit IRC
[20:01:05] *** FunkyJive has left ##OpenGL
[20:05:32] *** loonysalmon has joined ##OpenGL
[20:05:34] *** loonysalmon has left ##OpenGL
[20:09:34] *** predaeus has quit IRC
[20:14:52] *** Walt has quit IRC
[20:18:17] *** LtJax has joined ##opengl
[20:19:36] *** Xantoz has quit IRC
[20:25:15] *** Xantoz has joined ##OpenGL
[20:27:51] *** Walt has joined ##opengl
[20:41:24] *** johndoe has quit IRC
[20:41:31] *** Codex_ has joined ##OpenGL
[20:42:54] *** Walt has quit IRC
[20:43:14] <Codex_> How can you easily generate lots of polygons?
[20:43:19] *** Nescafe has quit IRC
[20:45:17] <ville> Well you just need one tri and randomize its position?
[20:46:46] *** Walt has joined ##opengl
[20:48:03] *** TiLex has quit IRC
[20:49:31] <Codex_> hmm, sure, that's one way to do it. I was thinking of random + boolean test if the random polygon is inside a sphere for example, so can generate random polygons in shape of a sphere.
[20:50:45] <quicksilver> monte carlo method!
[20:50:55] *** stringfellow has quit IRC
[20:52:50] *** GlossyBRDF has joined ##OpenGL
[20:56:11] <Codex_> I keep getting low number of polygons: http://www.kotiposti.net/terop/disks.png and have a little difficulty generating large enough meshes to get it look nice. :(
[21:02:55] *** gusnan has quit IRC
[21:05:47] *** alyawn has quit IRC
[21:06:04] *** rnx has left ##opengl
[21:12:46] *** vade has joined ##OpenGL
[21:16:37] *** Walt has quit IRC
[21:20:03] *** XT95__ has joined ##opengl
[21:22:44] *** XT95_ has quit IRC
[21:24:21] *** Yustme has joined ##OpenGL
[21:31:50] *** reprore_ has quit IRC
[21:33:52] *** __doc__ has joined ##OpenGL
[21:35:34] <__doc__> hi. a blending question. How to I archieve a blending effect of a translucent primitive as in a photographic filter? I noticed that glBlendFunc(GL_SRC_ALPHA, GL_SRC_COLOR) kind of does it, except now alpha means luminosity and transparency is in the color values.
[21:38:00] <HuntsMan> color keying?
[21:38:29] <__doc__> HuntsMan: hm?
[21:38:45] *** Spkka has joined ##OpenGL
[21:39:58] <HuntsMan> transparency is in the color values, what does it mean?
[21:40:03] <HuntsMan> you have a color considered "transparent"?
[21:40:50] <__doc__> HuntsMan: no, it's like, when you think of translucency you think of a color tinted filter
[21:41:09] <__doc__> HuntsMan: where the colors would specify the tint, and the alpha would specify how much light would get trough
[21:41:35] <HuntsMan> so it's another completely different color space?
[21:42:01] <__doc__> HuntsMan: well, how do you specify a filter?
[21:42:27] <HuntsMan> a filter? such as?
[21:43:42] <__doc__> HuntsMan: such as something like this http://www.company7.com/baader/graphics/ColorFil6&Eypc500321.jpg
[21:44:27] <HuntsMan> no idea, that's a photographic filter
[21:44:34] <HuntsMan> OpenGL knows about mathematical filters
[21:44:35] <__doc__> HuntsMan: that's what I mean
[21:44:49] <__doc__> HuntsMan: ok. suppose you had a pure cyan surface
[21:45:01] *** x0rx0r has quit IRC
[21:45:06] <__doc__> HuntsMan: if you where tu hold a pure red filter over that, the result should be black
[21:46:03] <__doc__> HuntsMan: additionally any component of the red channel (if it wasn't pure cyan) would be scaled by the transparency of the filter
[21:46:59] <__doc__> HuntsMan: I can get that sort of with glBlendFunc(GL_SRC_ALPHA, GL_DST_COLOR)
[21:47:09] <__doc__> HuntsMan: except that it's backwards.
[21:48:37] <HuntsMan> switch the parameters then :)
[21:48:39] <__doc__> HuntsMan: so what I'm asking is, is there any technique to aproximate actual real world translucent objects with opengl better then glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA), which is a weird kind of calculation that gives nice looking but totally irrealistic results
[21:49:32] <aib42> __doc__: you want to AND or multiply the color with your filter color?
[21:50:23] <aib42> __doc__: i.e. green color + red filter = black, right ?
[21:51:02] <__doc__> aib42: sort of, well the underlying thing I'm trying to do is to calculate light source luminosity trough a translucent obstacle
[21:51:40] <vade> an OpenGL is typically linear RGB colorspace right?
[21:51:46] <vade> er an OpenGL context
[21:53:38] <HuntsMan> __doc__: yes, i would use shaders for that
[21:53:41] <__doc__> aib42: for instance, suppose I wanted to calculate the luminosity of the sun in opengl. obviously that's kind of impossible since opengl only has a maximum white of 255
[21:54:16] <HuntsMan> __doc__: you can use floating point textures, which aren't clamped to the [0, 1] range
[21:54:17] <__doc__> aib42: so my idea was to scale the scenes luminosity say by 255
[21:54:19] <HuntsMan> and allow HDR rendering
[21:54:32] <__doc__> HuntsMan: is that efficient?
[21:54:53] <__doc__> HuntsMan: how'd I do that?
[21:54:55] <aib42> __doc__: for the filter thing... dst is filter and src is the light source, no?
[21:55:33] <__doc__> aib42: if src means what's in the framebuffer before I render the filter, yes
[21:56:03] <aib42> try (x, GL_ONE_MINUS_SRC_COLOR)
[21:56:20] <__doc__> aib42: x?
[21:56:28] <aib42> GL_SRC_COLOR, I think. not sure.
[21:56:35] <aib42> x=
[21:56:55] <aib42> no hold on
[21:57:35] <JernejL> intel has some weird drivers
[21:57:40] <aib42> try (GL_DST_COLOR, GL_SRC_ALPHA)
[21:57:51] <JernejL> glcolor3f(0, 0, 1) -> BROKEN, it gives white color o_O but glcolor4f(0, 0, 1, 1) works (blue color) !
[21:58:46] <__doc__> aib42: that renders black everything
[21:58:59] <aib42> __doc__: sorry, (GL_DST_COLOR, GL_DST_ALPHA)
[21:59:36] <HuntsMan> __doc__: yes, very efficient, learn about GLSL
[21:59:48] <__doc__> HuntsMan: ic
[21:59:51] *** reprore_ has joined ##OpenGL
[22:00:23] <__doc__> aib42: that's all black too
[22:00:40] <__doc__> HuntsMan: a particular chapter of the GLSL book you want to point out?
[22:00:50] <aib42> __doc__: what color is your filter?
[22:01:15] <__doc__> aib42: 1.0, 0.0, 0.0, 0.5
[22:01:48] * Codex_ didn't like glsl too much. strange restrictions about size of the program. (add few lines more and it fails to link etc.:)
[22:01:51] <__doc__> aib42: the object behind is white, so the outcome should be 0.5 red
[22:02:47] *** Walt has joined ##opengl
[22:04:01] <HuntsMan> __doc__: everything? it's a new language, from the orange book there's a chapter on image processing that would be useful to you
[22:04:02] *** Ingenu has quit IRC
[22:04:19] <aib42> __doc__: I think you need two stages for that. one to calculate the color based on filter color + filter alpha, then one to scale everything by filter alpha
[22:04:27] *** _sana has quit IRC
[22:04:52] <aib42> what does GL_ONE_MINUS_DST_ALPHA, GL_DST_ALPHA look like?
[22:05:43] <__doc__> aib42: all black
[22:06:08] <aib42> am I confusing src with dst?
[22:06:57] <aib42> __doc__: may I /msg?
[22:07:22] <__doc__> aib42: sure
[22:10:02] *** reprore_ has quit IRC
[22:13:57] *** fargiolas has joined ##OpenGL
[22:15:46] *** Codex_ has left ##OpenGL
[22:22:01] *** jimi_hendrix has quit IRC
[22:22:32] *** b0000 has joined ##opengl
[22:24:20] *** XT95___ has joined ##opengl
[22:25:12] *** XT95__ has quit IRC
[22:29:29] *** XT95___ has quit IRC
[22:40:05] *** itewsh has quit IRC
[22:40:51] *** itewsh has joined ##OpenGL
[22:44:07] *** gusnan has joined ##OpenGL
[22:45:16] *** qeed has joined ##opengl
[22:50:00] *** PsiOmegaDelta has quit IRC
[22:50:55] *** PsiOmega has joined ##OpenGL
[22:58:01] *** Spkka has quit IRC
[22:58:28] *** vade has quit IRC
[23:05:24] *** `Wil has quit IRC
[23:06:01] *** Yustme has quit IRC
[23:06:02] *** aib42 has quit IRC
[23:06:02] *** Suprano has quit IRC
[23:06:02] *** GinoMan has quit IRC
[23:06:02] *** Yasumoto has quit IRC
[23:06:02] *** dizekat has quit IRC
[23:06:02] *** nytejade has quit IRC
[23:06:02] *** RTFM_FTW has quit IRC
[23:06:06] *** Yustme has joined ##OpenGL
[23:06:06] *** aib42 has joined ##OpenGL
[23:06:06] *** Suprano has joined ##OpenGL
[23:06:06] *** GinoMan has joined ##OpenGL
[23:06:06] *** Yasumoto has joined ##OpenGL
[23:06:06] *** dizekat has joined ##OpenGL
[23:06:06] *** nytejade has joined ##OpenGL
[23:06:06] *** RTFM_FTW has joined ##OpenGL
[23:10:06] *** HuntsMan has quit IRC
[23:12:40] *** Spkka has joined ##OpenGL
[23:14:17] *** dejai_ has joined ##OpenGL
[23:16:19] *** Sudi has joined ##OpenGL
[23:23:28] *** dejai has quit IRC
[23:30:22] *** forrestv` has joined ##OpenGL
[23:30:27] *** forrestv has quit IRC
[23:31:54] *** forrestv` is now known as forrestv
[23:38:34] *** mm765 is now known as mm765^away
[23:39:11] *** a-stray-cat has quit IRC
[23:39:19] *** b0000 has quit IRC
[23:40:59] *** shyam_k has joined ##OpenGL
[23:42:03] *** Rolenun has joined ##opengl
[23:44:30] *** Yustme has quit IRC
[23:47:36] *** Wil has joined ##OpenGL
[23:49:57] *** cplusplus has joined ##OpenGL
[23:50:06] <shyam_k> hai was reading about the license change of SGI license B know whether the opengl related softwares had a new release inorder to include the license modification?
[23:52:37] *** dizekat has quit IRC
[23:56:41] <Sos> i don't get your problem bro
[23:59:18] *** v has joined ##opengl

   January 30, 2009  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >