May 15, 2008 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
May 15, 2008 [00:01:42] *** chondrite has joined ##OpenGL[00:02:21] <rsp> How does a Index Buffer look like? (GL_ELEMENT_ARRAY_BUFFER)[00:07:51] *** groton has quit IRC[00:07:52] *** Jernej has joined ##OpenGL[00:14:25] *** PhrostByte has joined ##opengl[00:16:38] *** DobosCake has joined ##OpenGL[00:18:23] *** Gudy has quit IRC[00:19:05] <rsp> Anyone have experienced with drawing indexed VBOs?[00:20:16] <prophile> no, but I can play the bassline from Under Pressure[00:20:19] <prophile> (great song!)[00:23:09] *** Gudy has joined ##OpenGL[00:23:53] *** phrosty has quit IRC[00:26:23] *** JernejL has quit IRC[00:29:03] *** prophile has quit IRC[00:29:06] *** domino14 has joined ##OpenGL[00:29:37] *** Gudy has quit IRC[00:29:45] <domino14> hi, i have a question about glMultMatrix that I'm still unclear on after reading the documentation on opengl.org[00:29:56] *** Gudy has joined ##OpenGL[00:30:15] <domino14> it says that if the current transformation is C, then calling glMultMatrix with M replaces the current transformation with (C x M) x v[00:30:33] <domino14> where v is the point we are trying to transform[00:30:50] <domino14> what does this mean in terms of positioning? which matrix will act "first" on v, C or M ?[00:42:16] *** reviver has joined ##OpenGL[00:43:36] *** Jorachim has joined ##openGL[00:45:27] *** juanmabc has quit IRC[00:46:46] *** Foloex has joined ##OpenGL[00:46:53] <Foloex> hello[00:47:05] <Foloex> can I ask question about Devil here ?[00:48:22] <Foloex> it's about the ilSetWrite function, I was wondering how it works because the documentation isn't very clear ...[00:52:08] *** enoex has joined ##OpenGL[00:57:10] *** domino14 has quit IRC[00:57:28] *** LordMetroid has quit IRC[00:58:43] *** Suprano has quit IRC[00:59:59] * rsp knows how to use indexed VBOs now[01:00:29] *** juanmabc has joined ##opengl[01:01:50] <rutski> I'm really really confused about why this is happening to my "e" and "o", given that the texture data doesn't have the weirdness, and my glTexCoord calls look OK to me[01:01:59] <rutski> http://rutski89.com:31597/upload/Picture%209.png[01:02:17] <rutski> notice how the top of the "e" and "o" is cut off, and then pasted to the bottom[01:03:11] <rutski> the "e" in the middle on the checkered background is what OS X's OpenGL debugger reads the texture to be, so the actual texture data must be OK[01:06:08] *** m4ggus has quit IRC[01:08:51] <Foloex> I guess your texture mode is repeat and your texture indices are a bit off[01:09:17] <Foloex> Only the T coordinate seem wrong[01:10:29] <rutski> Foloex: that thought just crossed my mind as well[01:10:30] <Foloex> never minded, your glTexCoord2f are correct[01:10:40] <rutski> so I added glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);[01:10:44] <rutski> but no luck; same weirdness[01:10:45] *** m4ggus has joined ##OpenGL[01:10:52] <Foloex> :)[01:10:59] <rutski> :([01:11:21] <Foloex> it does give a slight reflexion effect to the letters ...[01:11:33] <rutski> reflexion effect?[01:11:40] <rutski> I'm not sure that I know what that means[01:11:54] <rutski> but it's worth noting that if I resize the window (thus resizing the viewport) the effect goes away[01:12:08] <rutski> it's at that very specific viewport size that the weirdness is there[01:12:15] <Foloex> I think this problem is on the H also[01:12:22] <rutski> although at other specific viewport sizes I get different weird effects[01:12:37] <Foloex> the bar in the middle of the H seem to be a bit high[01:12:41] <rutski> hmm, I don't see it on the H[01:12:45] <rutski> oh, that's just the font[01:13:01] <rutski> hmm, or is it[01:13:14] <Foloex> why do you use texture to display text anyway ?[01:13:54] <Foloex> if you use glut you have some font rendering functions in it[01:14:15] <rsp> That would be ugly for a serious game[01:14:29] <rutski> I hear that glBitmap tends to be unoptimized; and also with bit blitting methods wouldn't I have to resent the pixel data down to the card every frame?[01:15:17] <Foloex> rsp: yeah, but you can use opengl for other things[01:16:58] <rutski> Foloex: you were right about the H just by a hair[01:17:00] <rutski> it's one pixel off[01:17:09] <rutski> http://rutski89.com:31597/upload/Picture%2011.png[01:17:28] <Foloex> rutski: I think it's the same with every letters[01:17:40] <rutski> yep, very probably; I'm trying other more obvious letters now[01:18:36] <rutski> that's odd; it's just the 'a'[01:18:46] <rutski> http://rutski89.com:31597/upload/Picture%2012.png[01:19:01] <rutski> actually all the rest are cut off at the top as well[01:19:12] <rsp> I get funny looking textures with glTexCoord what might the problem be[01:19:15] <rutski> but the top part isn't pasted onto the bottom like it is with the 'a'[01:19:34] <Foloex> yeah, strange[01:19:45] <rutski> rsp: but have you seen this? http://rutski89.com:31597/upload/Picture%209.png my glTexCoord calls appear to be OK[01:20:42] <rsp> I use glTexCoordPointer btw I was referring to the wrong function ._.[01:20:52] <Foloex> if you look closely the missing top part is not completely pasted at the bottom[01:20:53] <rutski> ah[01:21:12] <Foloex> there is still a small part that remain missing[01:21:32] <rutski> Foloex: yep, I see what you mean; the top part that's pasted to the bottom should be wider[01:21:43] <rutski> hmm, this is really really puzzling[01:22:53] <Foloex> do you call an automatic GEN_T function ?[01:23:11] <Foloex> I forgot the name of the function ...[01:24:30] <rutski> I don't think so; nope[01:24:53] <rutski> wait.. you mean glGentextures?[01:24:58] <Foloex> yes[01:25:07] <rutski> well, yea; of course[01:25:18] <rutski> that's what makes the textures objects for me to bind to[01:25:19] <Foloex> wait, no, sorry[01:25:45] <rutski> Foloex: http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/[01:26:17] <Foloex> I meant glTexGendv[01:26:28] <rutski> ah, nope; that I definitely didn't call[01:26:31] <rutski> should I?[01:27:00] <Foloex> it's used to automaticly generate the texture coordinate[01:27:09] <rutski> I'm not quite sure what that means[01:27:17] <rutski> I only started learning about texturing about 3 days ago by the way[01:27:26] <rutski> on account of having to render fonts[01:27:47] <Foloex> I started learning opengl in january ...[01:27:53] *** xonev has left ##OpenGL[01:27:58] <Foloex> maybe you could cheat asking for glTexCoord2f(0.0f, -0.2f) instead[01:28:37] <Foloex> but it doesn't really solve the problem ...[01:28:44] <rutski> heh, I could try that just for the heck of it; but it's no solution[01:28:45] <rutski> yea[01:29:08] *** juanmabc has quit IRC[01:29:47] <Foloex> are your textures dimension a multiple of 2 ?[01:30:05] <rutski> ah, nope; no they're not[01:30:11] <rutski> I was going to fix that later for performance reasons[01:30:29] <Foloex> It could be the problem[01:30:46] <rutski> but I hear that OpenGL 2.0 (and probably a few versions under 2.0 as well), can accept non power of 2 dimensions (although at a performance hit)[01:30:53] <rutski> also, http://rutski89.com:31597/upload/Picture%2013.png[01:31:02] <rutski> with -0.2f instead of 0.0f[01:31:15] <Foloex> smoking letters :)[01:31:20] <rutski> heh, yea[01:32:20] <Foloex> try using a texture with power of 2 dimensions[01:32:32] <Foloex> who knows ...[01:32:51] <rutski> but[01:32:52] <rutski> http://www.opengl.org/documentation/current_version/[01:32:55] <rutski> "Non-Power-Of-Two Textures"[01:33:09] <Spark> why would it be a performance hit[01:33:14] *** m4ggus has quit IRC[01:33:14] <Spark> scaling them up to the next power of 2 would be a RAM hit[01:33:18] *** m4ggus_ has joined ##OpenGL[01:33:25] <Spark> which might cause a performance hit if you run out of GPU RAM[01:33:33] <Spark> but i don't see why it should directly be a performance hit[01:34:58] <rutski> Spark: I don't have a problem believing that non-power-of-2 texture dimensions will be a performance hit; doesn't the hardware that accesses memory have an easier time accessing it on power-of-two aligned boundaries[01:35:01] *** reviver has quit IRC[01:35:10] <Foloex> I leaned not to always trust what's written in the documentation... maybe because I made some development on windows mobile 6 ^^[01:35:23] <rutski> Spark: also because you just got here, this is the problem: http://rutski89.com:31597/upload/Picture%209.png[01:35:26] <rutski> note the "e" and the "o"[01:35:34] <rutski> Foloex: heh[01:35:44] <Spark> alpha is broken?[01:35:45] <rutski> Foloex: I'm checking my OpenGL version now[01:36:03] *** MatthiasM has quit IRC[01:36:09] *** MatthiasM has joined ##opengl[01:36:13] <Foloex> I don't think the alsa composent is used here[01:36:15] <rutski> Spark: oh, no; I'm just using GL_DECAL instead of GL_REPLCE to illustrate the polygons that the textures are being mapped onto[01:36:18] <Foloex> *alpha[01:36:49] <rutski> the trouble is that the tops of the "e" and "o" are being cut off and pasted onto their bottoms[01:36:50] <Spark> tops being cut off then?[01:36:53] <rutski> yep[01:37:00] <Spark> ah yes i didn't notice the wrapping[01:37:04] <rutski> the same is happening with the H and l's, but it's just not visible given the nature of those characters[01:37:14] <Spark> well, do you need to set the addressing mode to clamp?[01:37:31] <rutski> but the weirdest part is that a call to glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); doesn't fix things[01:37:41] <rutski> (I set it for GL_TEXTURE_WRAP_T as well)[01:37:57] <Foloex> I was about to ask about GL_TEXTURE_WRAP_T :D[01:38:06] <rutski> heh, yea[01:38:23] *** speedy1 has quit IRC[01:39:13] <Spark> what are the texture coords?[01:39:27] <Spark> 0 at the bottom, 1 at the top?[01:39:30] <Spark> or is the whole alphabet a texture[01:39:38] <Foloex> I should go to sleep, it's late here ... good luck rutski[01:40:19] * rsp yawn[01:40:26] <Foloex> each letter is a different texture[01:41:12] <Foloex> Spark: you can see part of the code here: http://rutski89.com:31597/upload/Picture%209.png[01:41:15] *** juanmabc has joined ##opengl[01:41:34] <Spark> ah yeah i didn't see that[01:41:35] <Spark> heh[01:41:38] <rutski> heh, yea; sleep tight Foloex[01:42:07] <Foloex> rutski: thanks[01:42:08] <rutski> Spark: yea, given those texture coordinates I didn't even think I'd have to set GL_CLAMP[01:42:11] <Spark> weird that setting it to clamp doesn't fix it[01:42:12] *** Foloex has quit IRC[01:42:14] <Spark> yeah you will[01:42:17] <Spark> well[01:42:32] <Spark> hmm[01:42:32] <rutski> really? I thought it would just stretch the textures to fit the polygon[01:42:35] <Spark> no you shouldn't, heh[01:42:44] <rutski> yea, exactly[01:43:29] <Spark> actually[01:43:32] <rutski> ?[01:43:34] <Spark> if you sample the texture at 0,0[01:43:50] <Spark> it will use (-0.95 -> 0.5) will it not?[01:43:51] <rutski> ohhhhhhhhhhh, right[01:43:55] <rutski> good point[01:44:02] *** amz has joined ##opengl[01:44:05] <Spark> depending on how big the texture is[01:44:10] <Spark> what are the dimensions of the texture[01:44:11] <rutski> so it might be glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);[01:44:14] <rutski> screwing it up[01:44:21] <Spark> set them all to nearest[01:44:23] <Spark> see what that dose[01:44:36] <rutski> yea, they are all nearest[01:44:44] <rutski> the dimensions of the texture should be the same as the pixel dimensions of the rasterized polygon[01:45:44] <rutski> oh, I was confusing GL_NEAREST and GL_LINEAR[01:45:47] <rutski> I thought I had it on GL_LINEAR[01:45:54] <Spark> NEAREST should fix it[01:45:55] <rutski> but I did indeed have it on GL_NEAREST already[01:46:00] <rutski> so the problem still stands[01:46:01] *** Encryption767 has left ##OpenGL[01:46:04] <Spark> NEAREST is the blocky one, right?[01:46:05] <rutski> Spark: nope; it's always been on GL_NEAREST :([01:46:12] <rutski> blocky one?[01:46:18] <Spark> no filtering at all[01:46:22] <rutski> right, I think so[01:46:27] <Spark> and you're clamping it too?[01:46:54] <rutski> http://rafb.net/p/uX8WX580.html[01:48:04] <Spark> hmm[01:48:21] <Spark> do changing those make any difference at all?[01:49:07] <Spark> it looks like it's not using NEAREST[01:49:08] <Spark> from the screenshot[01:49:15] <Spark> it's antialiased a bit[01:49:49] *** Madsy has quit IRC[01:50:09] <rutski> it's antialised because freetype is rendering an AA image[01:50:14] <Spark> anyway, you could try tweaking the texcoords by a bit, i.e. instead of 0 to 1 you could try 0.5/tex_width to (tex_width-0.5)/tex_width[01:50:19] <Spark> ah right[01:50:24] <rutski> I'm going to test it sans the glTexParamateri settings[01:50:28] <Spark> so it is exactly off by a pixel[01:50:31] <Spark> try it with "y"[01:50:32] <Spark> as well[01:51:13] <rutski> yea, commenting out the glTexParamateri calls really breaks things; I don't think it's worth looking into[01:51:29] <rutski> why would I need to tweak the TexCoord calls though?[01:51:44] <Spark> lack of any other ideas :)[01:51:50] <rutski> I'll try it just for fun though; why not. I'll make the 1.0's into 0.5's[01:51:53] <rutski> he, yea[01:51:54] <rutski> **heh[01:52:12] *** chondrite has quit IRC[01:52:36] *** _spec has joined ##OpenGL[01:53:25] <rutski> Spark: http://rutski89.com:31597/upload/Picture%2014.png[01:57:59] <rutski> another thing worth noting is that if I resize the viewport the issue goes away[01:58:05] <rutski> at most viewport sizes it's fine[01:58:16] <rutski> at a rare few viewport sizes I get other weird artifacts[01:58:44] *** DMINATOR has quit IRC[01:58:46] <rutski> (a window resize triggers a viewport resize, of course)[02:02:01] <Spark> how big is that e[02:02:36] <Spark> it looks liek it's only the height that's fucking up[02:03:04] *** rsp has left ##opengl[02:03:16] *** dvoid_ has quit IRC[02:03:26] *** juanmabc has quit IRC[02:04:25] <rutski> what do you mean how big?[02:04:31] <rutski> how big is the texture, pixel wise?[02:04:37] <Spark> yeah[02:04:38] <Spark> how many texels[02:05:14] *** juanmabc has joined ##opengl[02:06:36] <_spec> i'm going to be in LA during siggraph.. would it be a good idea to go to the OpenGL BOF? i mean, can we expect some new information[02:07:11] <rutski> Spark: http://rutski89.com:31597/upload/Picture%2015.png[02:07:24] <rutski> 38[02:08:49] <rutski> Spark: and I just look a screenshot and zoomed on it on in Preview.app, the white polygon that the "e" is being rendered to is indeed: 34x38 pixels[02:10:49] <rutski> I'm going to have a party or something when I finally figure this out :)[02:10:52] <rutski> you're invited[02:10:59] <Spark> will there be cocaine[02:11:06] <rutski> heh[02:11:23] <Spark> instead of 0 to 1 on the y range of texture coordinatse[02:11:32] <rutski> right?[02:11:33] <Spark> try 0.5/38 to 37.5/38[02:11:42] <Spark> then try[02:11:45] <Spark> try 0.5/38 to 38.5/38[02:11:52] <rutski> right, will do[02:13:01] *** tmccrary has joined ##OpenGL[02:13:59] <rutski> cut off the top, but not pasted to the bottom: http://rutski89.com:31597/upload/Picture%2019.png[02:15:00] <rutski> and the second one is seemingly the same result: http://rutski89.com:31597/upload/Picture%2020.png[02:16:52] <Spark> hmm[02:17:53] <Spark> try -0.5/38 to 37.5/38 then[02:18:23] <Spark> i suggest you make a "letter" which is just a border around the edge[02:18:26] <Spark> like an empty box[02:18:29] <Spark> to test this thoroughly[02:18:53] <Spark> or maybe a different colour pixel in each colour, and leave the rest blank[02:19:00] <Spark> *in each corner[02:20:00] <rutski> sure, should be easy enough[02:20:21] *** LordMetroid has joined ##OpenGL[02:26:00] <rutski> Spark: hand on there just a few more minutes; fascinating video coming up[02:26:08] *** LiQuiDninja has quit IRC[02:32:56] <rutski> Spark: ok, still with me?[02:33:09] <Spark> yep[02:33:42] <rutski> I hope you can play mov files[02:33:51] <Spark> i can probably manage[02:33:58] <rutski> Spark: http://rutski89.com:31597/upload/weird.mov[02:34:16] *** juanmabc has quit IRC[02:34:41] <Spark> that has to be a bug in GL, surely[02:34:49] <Spark> can you try it on another GL implementation[02:35:56] <rutski> heh, yea; I've been meaning to port this most recent progress in font rendering to windows[02:36:05] <rutski> I've just been too lazy to figure out how to compile freetype for win32[02:36:54] <Spark> are you using msvc?[02:37:10] <rutski> the reason I thought that video was particularly interesting was on account of the fact that at certain sizes only half the bar at the top shows up[02:37:14] <rutski> yep, msvc[02:37:23] <rutski> editing in emacs though[02:37:31] <Spark> someone build freetype for the ogre dependencies package[02:37:36] <Spark> among a bunch of other stuff[02:37:37] *** juanmabc has joined ##opengl[02:37:47] <Spark> so you might be able to just use the .lib and headers from that[02:40:19] <rutski> ah[02:40:38] <rutski> INSTALL.UNIX in the doc/ dir says "This also works for emulations like Cygwin or MSys on Win32"[02:40:40] <rutski> should be easy then[02:41:04] <rutski> (I'd use the ogre one, but I'm generally in favor of fiddling with things for myself)[02:42:40] <Spark> i don't think ogre uses an emulation layer[02:42:49] <Spark> i think you want to find a visual studio projcet file and use that[02:42:53] <Spark> it will probably just work then[02:42:54] <rutski> oh, no; it's just an emulation layer for the compiler tools[02:42:55] <rutski> I think[02:42:57] <rutski> or is it..[02:42:57] <rutski> hmm[02:43:11] <Spark> sounds like "emulations of posix on win32" to me[02:43:33] <rutski> yea, good point; now that I think of it, that seems to be what they're saying[02:43:58] <rutski> afk for a bit, gota eat[02:46:24] *** Nai has quit IRC[02:46:39] *** Nai has joined ##OpenGL[02:54:23] *** bbeausej has quit IRC[02:54:29] *** Jernej has quit IRC[03:01:29] *** Jorachim has quit IRC[03:09:35] *** Nai has quit IRC[03:21:08] *** Amorphous has quit IRC[03:22:08] *** Amorphous has joined ##opengl[03:36:48] *** LordMetroid has quit IRC[03:42:11] *** dust-- has quit IRC[03:42:53] *** hibread has joined ##opengl[03:43:31] *** neunon has joined ##opengl[04:01:19] *** obmij has joined ##OpenGL[04:01:35] <obmij> how many texture units can I use for textures in my GLSL shader code?[04:01:55] <obmij> or how can I check the amount I can use for a certain graphic card or system setup?[04:02:56] *** tmccrary has quit IRC[04:03:42] <Satan_Inside> query the value for GL_MAX_TEXTURE_IMAGE_UNITS_ARB[04:03:52] <Satan_Inside> via glGetInteger( ... )[04:05:01] <rutski> hi all[04:05:22] <rutski> I've been having this really weird problem; and I've been hoping to get some fresh ears to hear it[04:05:44] <rutski> http://rutski89.com:31597/upload/weird.mov[04:06:38] <rutski> that's the result of the following code: http://rafb.net/p/XIjyZF89.html[04:06:59] <rutski> the weird part is that the texture is just a rect with empty space, and solid black border pixels[04:07:09] <rutski> and it's mapped directly onto a rectangular polygon[04:07:29] <rutski> yet for some reason, at some specific sizes of the viewport, it does that weirdness displayed in the video; and I just can't figure out why[04:10:12] *** dust-- has joined ##OpenGL[04:11:49] <obmij> hmm 32[04:12:03] <obmij> Satan_Inside, what's your card and how many texture units do you have?[04:12:08] <obmij> 8800 GTX here[04:13:40] <Satan_Inside> umm why?[04:13:59] <obmij> I want to be a bit careful with multitexturing and shadow cubemaps and color maps[04:14:10] <Satan_Inside> being that GL_MAX_TEXTURE_IMAGE_UNITS_ARB is a implementation dependent value this will vary between drivers and between renderers[04:14:14] <obmij> I have a good card, but I want the program to run on maybe older cards as well[04:14:24] <Satan_Inside> I still don[04:14:34] <Satan_Inside> err don't see why you are asking me[04:14:52] <Satan_Inside> heh I don't have "old hardware" by any stretch of the imagination :P[04:14:53] <obmij> I was checking to see if you have an older card[04:15:07] <obmij> Oh so you're pretty high-end eh?[04:15:16] <obmij> maybe highest-end? 9800 gx2? :D[04:15:19] <Satan_Inside> glances to the side noting the ~30K of GPU equipment I have[04:15:31] <obmij> holy crap[04:15:37] <obmij> you working at nVidia research ? :o[04:15:46] <Satan_Inside> a similar group yes[04:15:50] <obmij> ^_^[04:16:19] <obmij> So maybe ..... I should use a 3D texture?[04:16:41] <obmij> just to be ummm, 'economic' with the number of units[04:16:46] <Satan_Inside> in any case being that you can query this value at runtime this shouldn't be a problem for you[04:17:27] <Satan_Inside> and considering I don't know what you are doing I couldn't say what you should use...[04:18:04] <Satan_Inside> other than you don't need more than a single TMU for 1D, 2D, RECT, 3D, ... targets[04:18:09] <obmij> Well, I might do multitexturing, upto like 10 textures/surface maybe. Aside from that I'm doing color/shadow cubemaps PER active light[04:18:10] <Satan_Inside> heh[04:18:31] <obmij> So I'm just using these a lot[04:18:52] <obmij> So maybe I'd allocate a whole 3D texture for shadow maps, color maps, and textures[04:19:15] <Satan_Inside> umm you wouldn't use a volume texture for that[04:19:25] <Satan_Inside> ideally you would use a texture array[04:19:40] <obmij> yeah but wouldn't that again be a burden on texture units?[04:19:55] <obmij> when I'm going glActiveTexture (...)[04:20:00] <Satan_Inside> in fact EXT_texture_array was created for situations like this[04:20:11] <obmij> Hmm.... now this sounds interesting[04:20:24] <obmij> only 1 TMU/array?[04:20:32] <Satan_Inside> read the spec[04:20:39] <obmij> where is it?[04:20:50] <Satan_Inside> http://opengl.org/registry/specs/EXT/texture_array.txt[04:21:01] <Satan_Inside> its called Google[04:21:08] <obmij> well I was about to do that[04:21:26] *** oc2k1___ has joined ##opengl[04:22:18] <Satan_Inside> in any case its not a widely supported extension (i.e. highly limited by platform and renderer currently -- for example only DX10 compliant GPUs will export this functionality) but if its available its a good one to look at for the situation above[04:22:29] *** blight_ has quit IRC[04:22:45] <obmij> Hmm, GeForce 8 seems to be ok with it[04:22:53] <obmij> by the time the application is out, it'll be the norm[04:23:06] <obmij> So I don't think we'll have a problem there[04:25:10] *** kiras has quit IRC[04:26:48] <obmij> wait 1 second, there is not samplerCubeArray is there?[04:27:15] <oc2k1___> cubearrays aren't available jet[04:27:39] <rutski> I would literally be willing to pay $20 to the first person to solve this problem for me[04:28:03] <hibread> 42?[04:28:06] <obmij> Well that breaks the entire thing[04:28:07] <oc2k1___> you could build your own with 2dtexture arrays[04:28:16] <obmij> nah pointless from this point on[04:28:43] <obmij> I would have to do some cube vs. line interestion routines[04:28:45] <obmij> I did that once[04:28:50] <obmij> tideous and boring[04:28:57] <oc2k1___> layered rending many cube to a 2d texture array isn't a problem[04:28:59] <obmij> intersection*[04:29:47] <obmij> Didn't say it is, I just don't want the extra lines in my shader code[04:31:22] <Ragnarok> whens a good time to start learning GLSL?[04:31:44] <HuntsMan> Ragnarok: when you need it[04:31:47] <oc2k1___> now....[04:32:02] <Ragnarok> after 6 months of knowing GL etc[04:32:12] <obmij> heh wait, till OGL 3.0 ;D[04:32:13] <oc2k1___> or after understanding the basic concept of lighting....[04:32:24] <obmij> how deep into lighting?[04:32:35] <obmij> ambient? diffuse? specular?[04:32:46] <obmij> Or maybe Oren-Nayar? micropatches? :D[04:33:01] <obmij> Complex nasty stuff? Fresnel term? :D[04:33:09] <Ragnarok> obmij, I doubt I could run opengl 3.0 on a GeForce 6150 LE :P[04:33:12] <rutski> I'm getting texture wrapping despite the fact that I used glTexParamateri() to set GL_CLAMP and GL_NEAREST; what the heck is going on here?[04:34:18] <obmij> Come to think about it ... maybe I should recode all that crap[04:34:22] <obmij> I don't know... :/[04:34:28] <oc2k1___> lighing basic: difuse with dot prodoct, and maybe blinn-pong[04:34:44] <obmij> Ragnarok, you can learn it *anytime*[04:34:51] <obmij> never is a better time[04:34:54] <obmij> just grab a book[04:35:03] <obmij> the book I got was for HLSL but the optics information it gave[04:35:11] <obmij> it was good enough to drag into GLSL[04:35:29] <obmij> and all the hints/tips/tricks etc.[04:36:30] <obmij> One thing that's sad though... why is OpenGL so harder to code for?[04:36:35] <oc2k1___> You could try my GLSL IDE .... http://lumina.sourceforge.net/[04:36:38] <obmij> I can't put a finger on 'where' but[04:36:47] <obmij> the general experience kind of indicates[04:36:59] <obmij> a slight bitterness :P[04:43:20] <Ragnarok> oc2k1___, I didn't like it :([04:43:31] <oc2k1___> Why not?[04:43:43] <Ragnarok> it was too complicated to use[04:44:31] <obmij> just a slight question[04:44:55] <obmij> could you let's say have an array of 40 2D samplers while your card only supports upto 32 texture units?[04:45:11] <obmij> 40 2D sampler that you're actively using in your GLSL code[04:47:18] *** stevosICBM has joined ##OpenGL[04:56:52] <obmij> gah nevermind[04:57:04] <obmij> However, 3D textures seem to be supported from a long time ago[04:57:38] <obmij> would chosing 3D textures over texture arrays be a wiser choice when trying to cater to older cards?[04:59:09] <oc2k1___> 3d textures arn't a solution, because the mipmap will mix them tegether[04:59:25] <obmij> ow[04:59:36] <obmij> could I turn mipmapping off on them?[05:00:17] <oc2k1___> sure, but in that case you 'll have aliasing atifacts a minification[05:00:38] <obmij> Oh, they're mainly to store information[05:00:47] <obmij> I could multi sample right in the GLSL code[05:00:59] <obmij> If I need to[05:02:07] <obmij> soo... o_O...[05:02:13] <obmij> the verdict is...? :)[05:02:28] <oc2k1___> multisampling wouln't help much ...[05:02:55] <obmij> Actually I'd be happy if it didn't average out over texel values[05:03:07] <obmij> they're to store like distances from light source etc.[05:03:17] <rutski> Spark: let me know when you get back[05:03:20] <rutski> Spark: good news :)[05:03:26] <oc2k1___> you could try a textur attlas...[05:04:11] <obmij> extension name...[05:04:21] <obmij> oh wait wait[05:04:32] <obmij> You mean one biiiiig texture with so many little textures inside?[05:04:37] <oc2k1___> yes[05:05:35] <obmij> Hmm[05:05:53] <obmij> Not a bad idea, despite the fact that it'll come out huuuuuge[05:06:05] <obmij> however I can check for video ram to see if it fits[05:06:28] <oc2k1___> how many textures do you have (and which size?)[05:06:58] <obmij> well tweakable. 600x600x6 (600 cube map) 2 cubemaps per light, 10 lights[05:07:33] *** neunon has quit IRC[05:08:11] <oc2k1___> choose a power of two resolution so you could store 16 or 64 of them into a 4096x4096 texture[05:08:27] * obmij goes to do some calculations[05:08:45] *** peda__ has joined ##OpenGL[05:09:51] <oc2k1___> older hardware won't be able to handle it fast enough and would run well with 2048 too (256 or 512 width)[05:10:02] <obmij> oh yeah[05:10:04] <obmij> good reminder[05:10:15] <obmij> old hardware likes ^2 dimension[05:10:41] <obmij> And there's an old extension for it in fact[05:10:42] <obmij> afaik[05:11:10] <obmij> but texture atlas was good actually[05:11:28] <obmij> But just wondering... I guess I won't be having the leisure of 'multiple texture processing units'[05:11:39] <obmij> or I will?[05:12:07] <oc2k1___> no a single texturunit for all, but you have to calculate the texcoords[05:12:27] <obmij> oh I'll get the texture coords myself, no worries[05:12:51] <obmij> I'll pass them down using attrib[05:13:20] <obmij> will it be umm, 'slower' than using let's say separate textures?[05:13:28] <oc2k1___> that won't work on cubemap, because a triangle could be textred by different faces[05:13:50] <obmij> For those I'll pass down a vector3 ;)[05:14:01] <obmij> I'll have to code the intersection test routines as well[05:14:18] <obmij> and I'll arrage the cubes in like -x,+x,-y,+y,-z,+z order or something[05:14:42] <obmij> s/cubes/faces[05:15:00] <obmij> but will this be slower than let's say using 3 MTUs?[05:15:03] <oc2k1___> use a cubemap with one texel per face, first color for the facenumber, the other 3 for a sorting net to swap x,y,z to s and t[05:15:27] <obmij> or whatever number of MTUs[05:15:39] <obmij> or the speed difference will be small?[05:15:57] <oc2k1___> it could be also a good idea to stor 6x6 cubemap faces into a texture because it simplifies the texture coord calculation[05:15:58] <obmij> if there's not much of a difference I'd be happy as heck to use an atlas[05:16:53] <obmij> will there be much of a difference?[05:16:59] <obmij> in terms of speed? :/[05:17:06] *** juanmabc has quit IRC[05:17:09] <oc2k1___> I have seen shaders for virtual cubemaps, that creates hot air only :P[05:17:32] <obmij> Hehe I know[05:17:41] <obmij> code that you 'theoretically' don't need[05:18:30] <obmij> arrays seem too new[05:18:34] <oc2k1___> for example 6 ifs for each face[05:18:36] <obmij> like way too new[05:18:48] <oc2k1___> arrays are GF8 only (currently)[05:18:51] <obmij> 8 series?[05:18:57] <obmij> come on most people still have 7[05:19:11] <obmij> people are 'planning' on buying 8800 GT[05:19:12] <oc2k1___> GF6 and 7 have the same features[05:19:21] *** neunon has joined ##opengl[05:19:30] <obmij> heh I got my 8800 GTX before 9 was even out[05:19:37] <obmij> then 9800 GX2 came out :([05:19:42] <obmij> and I become the 2nd best :D[05:20:13] <oc2k1___> the 9 series is a die shrink (and doubles in cuda)[05:20:14] <obmij> hmm[05:20:34] <obmij> Ok, all fingers point to atlas[05:21:02] <obmij> I guess I'll be using 3 atlases[05:21:16] <obmij> 1 for color cube maps, 1 for shadow cube maps, and a small one for multitexturing[05:21:44] <obmij> and a single cube map for environment map[05:21:55] <obmij> and a single 2d map for normal map :P[05:22:02] <obmij> and height map x_x[05:22:07] <oc2k1___> sometimes is multipass renering not a bad idea...[05:22:26] <obmij> There's gonna be a single pass for both shadow and color[05:22:33] <obmij> but that's as far as it can go[05:22:57] <obmij> unless I'll be doing HDR or something[05:23:01] <obmij> or maybe motion blur[05:23:20] *** peda_ has quit IRC[05:23:21] <obmij> This thing stretches as far as you stretch it X|[05:23:41] <oc2k1___> I mean one pass per light, in that case it's possible to use true cubemaps (but the GF6/7 doesn't support shadowcubes)[05:24:05] *** peda_ has joined ##OpenGL[05:24:06] <obmij> I'm gonna gonna let the API know anything about the type of cube[05:24:23] <obmij> It's just gonna be your average day float RGB[05:25:44] * obmij goes to some number crunching[05:26:06] <_spec> is anyone here going to the GL BOF at Siggraph?[05:26:38] <_spec> i'll be in LA then and am wondering if it's worth going to.. will there be the announcement we've all been waiting for or will they just punt again[05:28:10] <oc2k1___> As long the announcement isn't: "We didn't do anything...."[05:29:16] *** hibread has quit IRC[05:30:23] <oc2k1___> The sun is rising, time to go sleep.....[05:30:33] *** peda__ has quit IRC[05:31:47] *** neunon has quit IRC[05:31:47] *** oc2k1___ has quit IRC[05:41:09] *** stevosICBM has quit IRC[05:53:22] *** m4ggus_ has quit IRC[05:57:40] *** stevosICBM has joined ##OpenGL[06:01:43] *** stevosICBM has quit IRC[06:06:16] *** TheLorax has joined ##opengl[06:21:42] *** Lucine2 has quit IRC[06:28:30] <Spark> rutski: fixed it?[06:31:45] *** enoex has quit IRC[06:31:48] *** PhrostByte is now known as phrosty[06:39:00] *** TheLorax has quit IRC[06:41:00] *** amz has quit IRC[06:47:00] <rutski> Spark: still ther?[06:47:02] <rutski> **there[06:47:38] <rutski> http://rutski89.com:31597/upload/not_as_weird.mov[06:47:56] <rutski> it's still off at that initial viewport size, but at all other viewport sizes it's alright[06:48:13] <rutski> much much better than the original http://rutski89.com:31597/upload/weird.mov[06:48:26] <rutski> all I did was change the textures dimensions to powers of two[06:49:03] <rutski> and at least it's still broken in that initial frame it's only just shifted up a pixel; and there's no wrapping to the bottom[06:49:09] *** BahamutZERO has quit IRC[06:49:52] *** enoex has joined ##OpenGL[06:51:40] *** Madsy has joined ##opengl[06:53:56] *** neunon has joined ##opengl[06:53:59] <Spark> hmm[06:54:07] <Spark> power of 2 will probably have affected the clamping[06:54:19] <Spark> it would only have clamped at 0, not at 1[06:55:22] *** [Trinary] has joined ##OpenGL[06:55:30] *** [Trinary] has quit IRC[06:55:34] *** [Trinary] has joined ##OpenGL[06:55:37] *** Lucine2 has joined ##OpenGL[06:56:03] <rutski> hmm, good point[06:56:31] * rutski thinks[06:56:59] <rutski> yea, I don't think the clamping matters[06:57:14] <rutski> isn't clamping only for when your glTexCoord call is passed <0 or >1?[06:57:21] <Spark> it will do unless you set the texture coords so that they sample bang in the middle of each texel[06:57:45] <rutski> I think you're confused about what clamping means[06:58:10] <Spark> i think it affects when two neighbouring texels sampled together, and the result combined into a single value[06:58:17] <rutski> so long as you only pass values in the range 0.0-1.0 to glTexCoord then your choice of GL_CLAMP vs GL_REPEAT doesn't matter[06:58:21] <Spark> which you can get if the texture coordinate is right on the edge of the texture[06:58:27] <rutski> oh, no; that's not clamping[06:58:28] <Spark> even if it is 0 or 1[06:58:50] *** [Trinary] has quit IRC[06:58:52] *** Lemml has joined ##OpenGL[06:58:56] *** Lucine has joined ##OpenGL[06:59:01] <rutski> what you're thinking is GL_LINEAR vs GL_NEAREST, which is for {MIN,MAG}_FILTER[06:59:20] <Spark> i can't imagine it being any other way without introducing seams[06:59:38] <rutski> huh? what do seams have to do with this? I don't have tiled textures[07:00:19] <Spark> how does it know that unless you set the clamping though[07:00:33] *** mm^away has joined ##opengl[07:01:14] <rutski> what do I have to do to get you to understand that clamping doesn't come into play here since I don't pass values less than 0.0f or greater than 1.0f to glTexCoord?[07:01:36] <rutski> The whole point of "clamping" is to "clamp" values to the range [0, 1][07:01:41] *** neunon has quit IRC[07:01:59] <rutski> which obviously doesn't come into play to if you don't go outside that range to begin with (which I don't)[07:02:22] <Spark> how can it sample at (0,0) though, since that's not in the middle of a texel, it must sample many texels[07:02:22] *** neunon has joined ##opengl[07:03:04] <rutski> when the pixel doesn't hit dead on a texel then what happens depends on whether you set GL_NEAREST or GL_LINEAR[07:03:18] <Spark> ok since you're using NEAREST it shouldn't matter, i agree[07:03:23] <rutski> right[07:03:39] <rutski> it should just use the bottom-left most texl[07:03:40] <rutski> **texel[07:03:50] <Spark> yeah it will round it off to be the middle of that texel[07:03:57] <rutski> right, exactly[07:04:09] <Spark> it's quite disturbing that it changes when you resize the viewport[07:04:16] <rutski> it doesn't though[07:04:19] <rutski> not anymore[07:04:26] <Spark> hmm, is it consistently broken then?[07:04:40] <rutski> oh, wait... did you see the new video or not?[07:04:48] <Spark> not for a good few hours[07:04:57] <rutski> oh, I uploaded a new one[07:05:00] <Spark> http://rutski89.com:31597/upload/not_as_weird.mov[07:05:01] <Spark> that one?[07:05:04] <rutski> right, that one[07:05:10] <rutski> that's the one with power of two textures[07:05:14] <rutski> which is basically 99% fixed[07:05:30] <rutski> much better than the old one: rutski89.com:31597/upload/weird.mov[07:06:14] <rutski> I think it's just that this OpenGL implementation has crappy support for the rather new non-power-of-2 texture feature[07:07:14] <rutski> actually I think you were the one to suggest that to begin with[07:09:57] <Spark> computer crashed[07:09:58] <Spark> heh[07:10:30] <rutski> ah, ouch[07:10:31] <rutski> what'd you miss?[07:10:42] <rutski> http://rafb.net/p/RAcaqZ20.html[07:10:44] <Spark> nothing the irc client is in a remote screen session[07:10:58] <Spark> can you resize it to exactly the size it started at?[07:11:11] <Spark> it seems to me that it has a bug where it's not sure about the initial viewport size[07:11:30] <Spark> maybe it misses a resize event because it wasn't paying attention early enough[07:12:26] <rutski> ah, could be; I'll try[07:13:52] <rutski> heh yea; it breaks when I resize it back to that exact size[07:14:06] <Spark> heh[07:14:18] <Spark> how inconvenient that it picks that particular size[07:14:20] <rutski> but that seems to be literally the only size that it breaks at[07:14:32] <Spark> how do you handle the resizing? do you add more space around the thing you're rendering[07:14:36] <Spark> or do you scale the thing you're rendering[07:14:51] <Spark> is it the point where something goes from being <1 to being >1[07:15:11] <rutski> hmm, I'm not sure how to answer this[07:15:23] <rutski> when I get a resize event I rescale the viewport[07:15:32] <rutski> and then I make a call to glOrtho[07:15:52] <rutski> making it so that the square in the center of the viewport is [-1,1] on both the x and the y axis[07:16:28] <rutski> if the viewport is wider than it is tall, then to the far left and right it'll be less than -1 and greater than 1[07:16:38] <rutski> and if it's taller than it is wide then to the top and bottom it'll be greater than 1 and less than -1[07:16:39] <Spark> the square in the centre? i.e. the largest square that fits in the viewport?[07:16:46] <rutski> right, exactly[07:17:12] <Spark> ok and where do you render these quads in particular[07:17:22] <Spark> in terms of the floating point scale pre-projection[07:17:30] *** mm765^sleep has quit IRC[07:17:43] <rutski> you mean the quads that eventually get the letter textures pasted on to them?[07:17:57] <Spark> yeah[07:18:41] <rutski> what exactly do you mean by "where"[07:18:51] <Spark> well it could be -0.3 to 0.3[07:18:53] <Spark> or something like that[07:18:54] <rutski> they're rendered right into that glOrtho projection that I described[07:19:48] <rutski> is that basically the answer you were looking for?[07:19:59] <Spark> what is pen_x + xb[07:21:02] <rutski> http://freetype.sourceforge.net/freetype2/docs/tutorial/metrics.png[07:21:07] <rutski> the b in 'xb' is "bearing"[07:21:27] <rutski> and pen_x is the x pos of the "origin" dot in that image[07:21:32] <Spark> and pen_x,pen_y is the origin there[07:21:32] <Spark> yeah[07:21:37] <rutski> right :)[07:24:01] <Spark> you're working entirely in pixels here, yet you're using this -1 -> 1 scale[07:24:29] <Spark> that's got to get confusing, when you need pixel accuracy[07:25:01] <rutski> it's not that bad[07:25:35] <rutski> it's worth the extra effort for being able to specify where items will go in the UI in a viewport size neutral system like [-1,1][07:25:53] <rutski> I just have to figure out how many units on the [-1,1] scale a pixel is, and then it's all good; it's not that hard[07:27:03] <Spark> you're not always [-1,1] though are you[07:27:07] <Spark> sometimes it's more than that[07:27:35] <rutski> well, sort of[07:28:27] <rutski> what I do is I let every UI item decide where it's hooked; either to the top left, top center, top right, right center, bottom right, bottom center, bottom left, right center or actual center[07:28:41] <rutski> then that point that it's hooked to becomes it's coordinate origin[07:28:59] <rutski> **its coordinate ori..[07:31:35] <Spark> so at that point you work out the width of a pixel and all that[07:31:49] <Spark> don't you have to round it off so that you're exactly aligned with the pixels[07:31:50] <Spark> or anything like that[07:33:23] <rutski> nope[07:33:35] <rutski> lets say that the viewport is wider than it is tall[07:33:50] <rutski> then I read how many pixels tall it is, lets say pt for "pixels tall"[07:34:19] <rutski> then I just do 2.0f/pt, and that gives me the floating point size of a pixel[07:34:31] <rutski> as exact as it can get; no rounding necessary[07:34:54] <rutski> also, sorry for using the abbrev "pt", that might be confusing since font literature likes to use "pt" for "point size"[07:35:43] <rutski> also, you said "so at that point you work out the width of a pixel and all tha"[07:35:59] <rutski> the "so at that point" part isn't necessary[07:36:10] <rutski> I mean.. the pixel size is the same no matter where I hook the UI element[07:40:21] <Spark> ok so you don't have to worry about aspect ratio since htat's already encoded in the coordinate system[07:41:01] <Spark> you only have to worry about the size of a pixel which is 1/viewport_width[07:41:02] <Spark> sorry 2/viewport_width[07:41:02] <Spark> height, rather[07:41:03] <rutski> well, whether I use width or height there depends on which one is smaller[07:41:11] <rutski> so I do have to worry about aspect ratio[07:41:36] <Spark> but it's a boolean flag[07:41:41] <Spark> rather than a ratio[07:41:44] <rutski> what is?[07:41:58] <Spark> whether the height is -1 to 1 or the width is -1 to 1[07:42:13] <rutski> right, it's essentially boolean[07:42:24] <rutski> but in one case the AR will be <1.0, and in the other it'll be >1.0[07:43:17] <Spark> is there any hack you can do with the texture coordinates to make it work at that initial viewport size, even if it doesn't work at any other size[07:43:41] <rutski> not sure[07:43:46] <rutski> I'm not going to bother though[07:44:25] <rutski> it's not worth looking into further; since 99.9% of the time it works, and then 0.1% that it doesn't, it's hardly even noticeable[07:45:07] <Spark> heh[07:45:20] <Spark> probably if you leave it a while, it will come to you[07:45:25] <Spark> especially if you try another platform[07:45:38] <rutski> if it is indeed just a glitch on this one particular ATI card, then no it wont :)[07:45:54] <Spark> ATI haven't got a wonderful track record with GL :)[07:45:58] <rutski> and I'm porting all this font rendering stuff to windows right now; I can't wait to see what'll happen[07:46:05] <rutski> heh, yea; good to know[07:51:09] *** kaotrix has quit IRC[07:52:54] *** reviver has joined ##OpenGL[07:52:57] *** Lemml has quit IRC[07:55:58] *** korff has joined ##OpenGL[08:01:55] *** neunon has quit IRC[08:20:40] <Jupp3> Spark: What you mean? Unlike some, they have released some documentation, which has made it possible for people to write proper open source drivers :)[08:21:20] <Spark> i've never actually owned one[08:21:35] <Jupp3> Currently have 2 in use[08:21:42] <Spark> but i have seen a lot of people complaining, even on windows[08:21:58] <Jupp3> Well, it's a bit os specific[08:22:14] <Jupp3> I mean, which cards have problems under which operating systems[08:22:46] *** reviver has quit IRC[08:22:54] *** scy has joined ##opengl[08:26:11] *** enoex has quit IRC[08:27:04] *** DobosCake has quit IRC[08:32:05] <rutski> Spark: ha! you still there dude?[08:32:14] <Spark> mostly[08:32:17] <Spark> i'm quite drunk now[08:32:24] <rutski> heh, I see[08:32:29] <rutski> well, 1 sec, putting up the screenshot now[08:34:53] <rutski> Spark: http://rutski89.com:31597/upload/weird.png[08:35:14] *** odietsch has quit IRC[08:35:26] <rutski> again, that special resolution gives rise to some weirdness; only this time it's horizontal instead of vertical[08:35:28] <Spark> lol, the other dimension[08:35:31] <rutski> yep[08:35:40] <rutski> but again, any other dimension seems to work perfectly[08:35:54] <Spark> hmm[08:35:55] <rutski> wow, look how bad the H looks[08:36:24] <Spark> what about the rectangle special glyph[08:36:25] <rutski> oh, actually; it's not just that dimension[08:36:35] <rutski> apparently on this system more dimensions get screwed up[08:36:42] <rutski> ah, the square; I'll try now[08:36:55] <Spark> the e looks like it's using the same pixels twice[08:37:51] <rutski> hmm, this is odd[08:38:07] <rutski> for the viewport size in this image: http://rutski89.com:31597/upload/weird.png[08:38:10] <rutski> the box test works fine[08:38:14] <rutski> I mean... the boxes show up perfectly[08:38:21] <rutski> but at other dimensions they get messed up[08:39:10] <rutski> http://rutski89.com:31597/upload/boxes.png[08:39:17] <rutski> looks like this is going to be worth getting to the bottom to after all[08:39:24] <rutski> **getting to the bottom of[08:43:03] *** andikr has joined ##OpenGL[08:43:20] *** _spec has quit IRC[08:45:35] *** scy has quit IRC[08:45:54] *** Lucine2 has quit IRC[08:46:23] *** Lucine2 has joined ##OpenGL[08:46:23] *** Jupp3 has quit IRC[08:46:30] *** Burga has joined ##OpenGL[08:47:33] *** karabash has joined ##OpenGL[08:53:47] *** Roderic has joined ##OpenGL[08:53:48] *** Roderic is now known as Ingenu[09:01:19] *** neunon has joined ##opengl[09:03:55] *** sohail has quit IRC[09:07:01] *** Burga__ has joined ##OpenGL[09:08:30] *** neunon has quit IRC[09:08:47] *** Eforen has quit IRC[09:11:41] *** Walt has joined ##opengl[09:22:36] *** Burga has quit IRC[09:25:53] *** korff has quit IRC[09:40:30] *** groton has joined ##OpenGL[09:47:09] *** [AD]Turbo has joined ##OpenGL[09:47:24] *** ajww has joined ##OpenGL[09:48:00] <[AD]Turbo> yo[09:53:32] *** belou has joined ##OpenGL[09:54:04] *** Lucine has quit IRC[09:57:20] *** korff has joined ##OpenGL[10:02:33] *** amalon_ has quit IRC[10:04:43] *** [AD]Turbo is now known as TurboAWAY[10:05:47] *** Walt has quit IRC[10:06:24] *** nplus_ has joined ##OpenGL[10:08:09] *** Lucine has joined ##OpenGL[10:14:58] *** nplus_ has quit IRC[10:15:52] *** nplus_ has joined ##OpenGL[10:23:38] *** charlie_zzz is now known as charlie5[10:30:07] *** dvoid_ has joined ##OpenGL[10:40:31] *** nplus_ has quit IRC[10:41:19] *** mads- has joined ##OpenGL[10:46:37] *** neoneye2 has joined ##OpenGL[10:51:01] *** blbmp has left ##OpenGL[10:55:29] *** andikr has quit IRC[10:55:29] *** belou has quit IRC[10:55:55] *** andikr has joined ##OpenGL[11:00:14] *** BahamutZERO has joined ##OpenGL[11:07:43] *** WimLeers has joined ##OpenGL[11:15:29] <rutski> yo[11:17:29] *** Ademan_ has joined ##OpenGL[11:32:52] <mads-> yo[11:33:16] *** Ademan has quit IRC[11:54:26] <rutski> yo[11:54:32] <rutski> mads-: still there?[11:54:38] *** _boto has joined ##opengl[11:55:02] <mads-> rutski : yeah :)[11:55:27] <rutski> have any knowledge about getting pixel perfect textures to display correctly?[11:56:08] <rutski> e.g. I want my 10x10 texture mapped onto a quad of the right size so as to be be rasterized to 10x10 pixels on to the screen, and then have the 10x10 texture mapped onto the 10x10 quad[11:56:11] <Ingenu> "pixel perfect textures" what would that be ?[11:56:27] <Ingenu> use glortho[11:56:37] <rutski> right[11:56:41] <rutski> yea, I'm using ortho[11:57:01] <Ingenu> you know teh res of the screen, the res of the texture[11:57:02] <rutski> I have an ortho projection that goes from 0->viewport_width on the X axis and 0->viewport_height on the Y axis[11:57:06] <rutski> but it's still not working[11:57:09] <Ingenu> then you should be able to render whatever you want[11:57:11] <rutski> here, let me post a screenshot[11:57:17] *** Ademan_ has quit IRC[11:59:21] <rutski> Ingenu: http://rutski89.com:31597/upload/Picture%2022.png[11:59:26] <rutski> the top is getting cut off[12:00:54] *** _boto has quit IRC[12:08:09] <rutski> Ingenu: as puzzled as I am?[12:12:08] *** Burga__ is now known as Burga[12:17:00] *** DenisKoronchik_ has joined ##OpenGL[12:17:03] <DenisKoronchik_> hi to all[12:17:52] <DenisKoronchik_> does anyone know, why i gl initialized on nvidia normaly and draw my meshes, but on ATI it takes latest info from memory[12:18:14] *** WimLeers has quit IRC[12:21:16] <ville> Call glClear()?[12:23:16] <DenisKoronchik_> yes[12:23:17] <DenisKoronchik_> thanks[12:23:18] <DenisKoronchik_> found it[12:23:27] <DenisKoronchik_> just some seconds ago :)[12:36:50] *** prophile has joined ##opengl[12:38:49] *** Jorachim has joined ##openGL[12:41:57] *** Burga has quit IRC[12:48:16] *** meteors has quit IRC[12:52:47] *** rutski has quit IRC[12:54:51] <quicksilver> I suspect rutski had an off-by-one error myself.[13:00:03] *** [this] has joined ##opengl[13:09:03] <mads-> glTexCoord2i(0,0) - is that the upper left corner of the texture?[13:13:13] *** LordMetroid has joined ##OpenGL[13:14:56] *** karabash has quit IRC[13:17:15] *** Suprano has joined ##OpenGL[13:17:47] <quicksilver> mads-: that's a matter of opinion.[13:18:04] <quicksilver> (how do you tell which is up and left anway?)[13:19:11] <mads-> quicksilver : But if I paint an arrow pointing upwards and save it as a bmp, then load it and look at (0,0,0) from (0,0,15) with up-vector (0,1,0) - would it then be pointing upwards if I set glTexCoord2i(0,0) as upper left corner? :)[13:19:58] <mads-> My problem is just that the image I'm loading in as texture is white on screen.. I have drawn a "particle" in the bmp. If you understand?[13:20:13] <quicksilver> I think (0,0) will be what you would call the 'lower left' in that circumstance.[13:20:22] <quicksilver> I'm not 100% sure.[13:20:33] <quicksilver> I always have to reverse coordinates until it looks right :)[13:21:07] <mads-> But are you familiar with the "bmp appearing as a white thingy"-problem? :)[13:24:07] <mads-> Would you mind taking a look at my code? It's very little, actually :)[13:24:33] <mads-> http://rafb.net/p/M3H7qK38.html[13:24:51] *** hibread has joined ##opengl[13:33:27] <andikr> mads: I think you would need a glEnable (GL_TEXTURE_2D) somewhere.[13:38:40] <mads-> O M G ... andikr THANK YOU SO MUCH :)[13:39:27] <mads-> I don't know what I was thinking :) That was a stupid thing not remembering... I was just in the process of putting glGetError() on each second line :D[13:43:19] *** kenws has joined ##OpenGL[13:45:55] *** nayena has joined ##OpenGL[13:49:11] *** scy has joined ##opengl[13:53:27] *** Eforen has joined ##opengl[13:53:56] <hibread> mads-: if you're not getting errors somewhere, it means you're not getting errors anywhere (just to make that clear)[13:54:54] <mads-> hibread : it is? I thought if I did something wrong, then did something right that the glGetError() would output 0, since the last action gave no error[13:55:20] <hibread> mads-: the error is held until it is read iirc[13:55:33] <mads-> hibread : But thanks for clearing that :) That's gonna save me some trouble in the future :)[13:55:53] <mads-> MUCH touble probarbly :P[13:56:16] <hibread> although i can't recall if it queues up errors...[13:57:05] <hibread> it looks like it stores one error only[13:57:13] <hibread> every other subsequent error is not recorded[13:57:18] <hibread> until you read the current error[13:57:30] *** fargiolas has joined ##OpenGL[13:59:45] <mads-> I'll just look it up at opengl later :)[14:01:52] *** nayena has quit IRC[14:07:15] <quicksilver> hibread: funny, someone pasted some code the other day whose purpose was to keep calling glGetError to display multiple errors.[14:07:27] <quicksilver> hibread: if they're not queued that sounds like daft :)[14:09:35] *** blight_ has joined ##opengl[14:12:55] *** belou has joined ##OpenGL[14:23:01] *** scy has left ##opengl[14:26:56] *** oc2k1 has joined ##opengl[14:27:27] *** Jorachim has quit IRC[14:30:15] *** geocalc has quit IRC[14:31:02] *** catadoxas has joined ##OpenGL[14:31:37] <catadoxas> whats the best way to draw a circle in 2d? alpha-texture a quad?[14:32:24] <belou> cairo[14:32:32] <belou> hu hu[14:41:05] *** geocalc has joined ##opengl[14:44:28] <DenisKoronchik_> yeah[14:44:31] <DenisKoronchik_> cairo :)[14:45:48] <belou> yes cairo[14:51:04] *** chondrite has joined ##OpenGL[14:52:39] *** LordMetroid has quit IRC[14:56:00] *** odietsch has joined ##OpenGL[14:58:39] *** dv_ has joined ##opengl[15:00:56] *** Rangar has quit IRC[15:01:14] *** Rangar has joined ##OpenGL[15:07:53] <dvoid_> anyone using ati 8.4 drivers?[15:09:57] *** supertard has joined ##OpenGL[15:10:08] <supertard> i have this text i am drawing on a texture with drawtext. it scrolls vertically up the screen and when it scrolls slowly the text flickers in intensity. i think it only happens when the text is scrolling in movements that are fractions of a pixels[15:10:14] <supertard> the way we scroll the text is by modifying texture coordinates[15:11:11] <prophile> haha, funny story right[15:11:14] <prophile> there was this bloke[15:11:16] <prophile> i set him on fire[15:11:22] <prophile> the end[15:12:11] <supertard> how is that funny[15:16:42] *** rnx has joined ##opengl[15:19:39] *** LordMetroid has joined ##OpenGL[15:20:05] <mads-> prophile :P[15:24:27] *** [this] has quit IRC[15:24:30] <prophile> hahaha it's like being drunk[15:24:38] <prophile> but i'm actually just insanely tired![15:24:48] <prophile> \D:/[15:24:53] <prophile> \:D/[15:25:30] *** cdleonar2 has joined ##OpenGL[15:27:38] *** frosch_bin has joined ##OpenGL[15:30:18] *** supertard has quit IRC[15:31:49] *** cdleonar2 has left ##OpenGL[15:34:33] *** frosch_bin has left ##OpenGL[15:38:37] *** Eforen has quit IRC[15:42:53] <hibread> quicksilver: well according to http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/geterror.html it only stores the first error until glGetError is called :)[15:44:30] <quicksilver> hibread: read the second para though[15:44:47] <quicksilver> hibread: "Thus, glGetError should alwaysbe called in a loop,.."[15:45:00] <hibread> fair enough[15:45:18] <hibread> bit contradictory...[15:45:27] <hibread> but my english skills aren't great[15:46:49] <quicksilver> I think it's odd, too.[15:46:56] <hibread> I don't follow that paragraph[15:47:02] <hibread> or rather, can't[15:47:03] *** LordMetroid has quit IRC[15:47:07] <quicksilver> probably something obsolete to do with high end hardware which interfaces to multiple opengl backends or something[15:47:14] <quicksilver> SGIs with multiple cards?[15:47:21] <hibread> no idea[15:55:48] *** juanmabc has joined ##opengl[15:56:01] *** Suprano has quit IRC[15:56:42] *** Suprano has joined ##OpenGL[15:59:10] *** nplus has quit IRC[16:02:03] *** nplus has joined ##OpenGL[16:11:11] *** charlie5 has quit IRC[16:11:48] *** chondrite has quit IRC[16:14:01] *** speedy1 has joined ##OpenGL[16:16:24] *** charlie5 has joined ##OpenGL[16:27:44] *** hirofans has joined ##OpenGL[16:29:17][16:30:32] *** m4ggus has joined ##OpenGL[16:30:55] *** joakim_ has quit IRC[16:31:21] *** andikr has quit IRC[16:31:51] *** andikr has joined ##OpenGL[16:36:48] *** hirofans has quit IRC[16:39:34] *** amz has joined ##opengl[16:40:20] *** sohail has joined ##OpenGL[16:41:18] *** mm^away is now known as mm765[16:42:24] *** scy has joined ##opengl[16:43:16] *** juanmabc has quit IRC[16:43:22] *** korff has quit IRC[16:48:31] *** BahamutZERO has quit IRC[16:49:33] *** oc2k1 has quit IRC[16:49:57] *** oc2k1 has joined ##opengl[16:50:28] *** KU0N has quit IRC[16:50:53] *** catadoxas has quit IRC[16:55:21] *** Ingenu has quit IRC[16:56:08] *** juanmabc has joined ##opengl[16:57:32] *** Ademan has joined ##OpenGL[17:03:39] *** BahamutZERO has joined ##OpenGL[17:13:23] *** Suprano has quit IRC[17:13:41] *** juanmabc has quit IRC[17:15:43] <Ragnarok> blah i can't seem to get this to work :([17:15:44] <Ragnarok> http://pastie.caboo.se/197563[17:16:21] *** rsp has joined ##opengl[17:16:38] <rsp> hibread: I learnt a lot about VBOs the other night[17:17:02] *** amz has quit IRC[17:17:07] <rsp> Now I just need to figure out why the texture is being applied in a weird way[17:17:12] *** bbeausej has joined ##OpenGL[17:17:27] <dindinx> Ragnarok: there is no draw call here.[17:17:46] <Ragnarok> yeah i have glDrawElements now yet still no drawing[17:18:03] *** tmccrary has joined ##OpenGL[17:18:08] <dindinx> Ragnarok: make a testcase[17:18:21] <Ragnarok> this is a test case[17:18:27] <hibread> rsp: describe weird[17:19:06] <dindinx> Ragnarok: no this isn't.[17:19:07] <rsp> glTexCoordPointer(2,GL_FLOAT,0,&TVertices[0]); that is what I am using it should be OK[17:19:56] <dindinx> Ragnarok: you only gave a method, in where a line is missing![17:20:37] <Ragnarok> http://pastie.caboo.se/197570[17:20:41] *** LuchoVtn3d has joined ##OpenGL[17:20:58] <rsp> hibread: I'll upload a PNG that will![17:21:42] <dindinx> Ragnarok: int are unsigned byte. And this isn't a testcase at all.[17:21:58] <dindinx> int are NOT unsigned bytes, sorry[17:22:22] <hibread> Ragnarok: i think you need an index buffer to use glDrawElements...[17:22:24] <Ragnarok> okay now its GL_INT[17:22:37] <hibread> maybe you ment to use glDrawArrays?[17:22:54] <Ragnarok> no I was going by the red book on how they are doing it[17:23:14] <rsp> hibread: http://img37.picoodle.com/img/img37/4/5/15/f_Skrmbildgamm_3943935.png[17:23:33] <hibread> Ragnarok: its probably right[17:23:45] <dindinx> hibread: he is using an index buffer.[17:23:55] <Ragnarok> if i do it with GLBegin/End it works fine[17:24:18] <hibread> dindinx: where is the index buffer?[17:24:21] <dindinx> Ragnarok: don't expect more help without a complete testcase.[17:24:26] <hibread> rsp: tried rotation the texture around or wha tever?[17:24:38] <dindinx> hibread: line 9[17:24:39] <hibread> rsp: or mirrored etc[17:24:52] <hibread> dindinx: thats just an array.. not a buffer[17:25:23] <dindinx> hibread: there is so many things missing in his code...[17:25:44] <Ragnarok> dindinx, like what thats what im trying to figure not a test case debate[17:26:12] <hibread> dindinx: who knows it might be right.. i dont use them that way[17:26:38] <dindinx> Ragnarok: if you don't give us a full compilable sample how are we supposed to help you exactly? By guessing what is missing?[17:27:03] <hibread> rsp: you could check by performing matrix manipulation on the texture matrix[17:27:10] <Ragnarok> dindinx, why didn't you just say that, i only posted to revlent code[17:27:11] *** DenisKoronchik_ has quit IRC[17:27:37] <hibread> rsp: glMatrixMode( GL_TEXTURE_MATRIX); glRotatef(), glScale() etc etc[17:27:38] <Ragnarok> http://pastie.caboo.se/197574[17:27:38] <dindinx> Ragnarok: I asked you several times to post a testcase. A testcase is exactly that.[17:27:55] <rsp> hibread: ok[17:27:58] <dindinx> Ragnarok: ok, I give up.[17:28:20] <Ragnarok> you said post the code[17:28:37] *** Suprano has joined ##OpenGL[17:28:54] <dindinx> Ragnarok: which letter don't you understand in "full"?[17:30:59] <Ragnarok> dindinx, http://mihd.net/jgandr3, theres with all the files etc[17:31:10] *** dv_ has quit IRC[17:31:43] *** dv_ has joined ##opengl[17:32:55] *** KU0N has joined ##OpenGL[17:32:59] *** dust-- has quit IRC[17:33:04] <dindinx> Ragnarok: 17:27 < dindinx> Ragnarok: ok, I give up. Don't ask me anymore. Please google for "testcase"[17:33:32] <Ragnarok> why i even bother i was better off look at a example source code with no comments[17:34:08] <dindinx> Ragnarok: why would we even bother? You don't want to be helped at all.[17:34:47] <Ragnarok> i posted the fucking test case, because you say you don't want a fuction, you wanted a compile source so I did that your still not effin happen[17:37:50] <rsp> hibread: How do I rotate the texture did you mean[17:38:28] <rsp> My scene gets rotated even though I set the MatrixMode right and GL_MODELVIEW when I'm done[17:39:04] <hibread> i can't really tell from the image you posted, but does it look like mapping is far from aligned over the model properly?[17:39:26] <rsp> Yeah compared to last time when I wanted it in immediate mode[17:39:44] <Ragnarok> wow i finally got it working[17:39:44] <Ragnarok> :S[17:39:55] <Ragnarok> somehow it only worked with GLubyte o_O[17:41:22] <hibread> rsp: glMatrixMode( GL_TEXTURE); glLoadIdentity(); glScalef( 1.0, -1.0, 1.0); glMatrixMode( GL_MODELVIEW); DrawStuff();[17:41:42] <Ragnarok> ah i see my problem glDrawElements doesn't support GL_INT, GL_UNSIGNED_INT worked[17:42:37] <rsp> Yeah that changes it a bit[17:43:09] <hibread> rsp: but.. if your loading code is the same as it was before when using immediate mode, and your using the same model data, then all of this shouldn't be the issue[17:43:48] <hibread> are you usre you're loading the texture coords into the array in the same order as the vertices... as they are read 1:1 when using the index buffer[17:45:34] <rsp> Should Vertices==TexCoords[17:45:46] *** SmokingRope has quit IRC[17:47:18] <hibread> how do you mean == ?[17:47:33] <rsp> ammount in a validated model so to speak[17:48:31] <hibread> item 'n' in each array (vertex xyz, texture coordinates and normal) work together to describe a single vertex[17:48:47] <hibread> which you'd already know[17:48:59] <rsp> Yeah ok[17:49:09] <rsp> I don't use one struct for everything[17:50:02] <hibread> thats ok, as long as item n in each array of structs refer to the same vertex[17:50:30] <hibread> then your index list should index all the data correctly[17:52:23] *** LtJax has joined ##opengl[17:52:46] *** karabash has joined ##OpenGL[17:52:59] *** HuntsMan has quit IRC[17:53:41] *** mapreduce has quit IRC[17:54:11] *** DobosCake has joined ##OpenGL[17:54:59] <rsp> hibread: I'm looking at the artifact and analyzing the look of it[17:55:04] <rsp> look at it again[17:55:24] <rsp> The whole texture covers each triangle[17:55:30] <rsp> That's the problem, I got it!![17:55:53] <hibread> rsp: hehe whats the problem?[17:55:54] <rsp> I am using the tex coords from 0 to max, not indexed[17:56:23] *** neoneye2 has quit IRC[17:56:42] *** dust-- has joined ##OpenGL[17:59:22] <rsp> hibread: Now is when I need all of those values I didn't need in immediate mode[17:59:31] *** DobosCake has quit IRC[18:00:05] <hibread> alrighty[18:00:06] <rsp> :) for some reason I didn't need to index them in immediate mode[18:03:01] *** LuchoVtn3d has quit IRC[18:03:37] *** neoneye2 has joined ##OpenGL[18:04:20] *** LtJax has quit IRC[18:06:21] *** DobosCake has joined ##OpenGL[18:09:21] *** DobosCake has quit IRC[18:10:09] *** DMINATOR has joined ##OpenGL[18:12:15] *** TurboAWAY is now known as [AD]Turbo[18:14:43] *** andikr has quit IRC[18:14:44] *** groton has quit IRC[18:16:02] *** Jupp3 has joined ##OpenGL[18:20:36] <rsp> hibread: Now I know why it just worked before, the tex coords index in the obj file is from 0-max -_-'[18:22:23] *** kenws has quit IRC[18:28:45] *** Yustme has joined ##opengl[18:31:28] *** bbeausej has quit IRC[18:34:12] *** prophile has quit IRC[18:34:21] *** prophile has joined ##opengl[18:39:11] *** lolage0 has quit IRC[18:40:39] *** TheLorax has joined ##opengl[18:43:56] *** [AD]Turbo has quit IRC[18:44:33] *** Lucine has quit IRC[18:45:18] *** dolphin has joined ##OpenGL[18:45:19] *** Lucine2 has quit IRC[18:45:58] <rsp> hibread: Can it really be a vector with struct Vertex { GLfloat X,Y; }; ?[18:47:34] *** Darius_ has joined ##opengl[18:47:47] <hibread> rsp: again, i think so, but not 100% sure on guarantees. If a struct/class has only those variables, you should be able to have a std::vector of them and get access like you are now[18:48:33] <rsp> Do you think I can fix all this by scaling and rotating[18:48:39] <rsp> Although it looks way weird[18:49:51] <quicksilver> rsp, hibread: In principle you can't 100% guarantee if a particular C compiler will layout float structs without padding.[18:50:10] <quicksilver> on a 64-bit architecture with 32 bit floats, the C compiler might decide to pad the floats for aligned access[18:50:13] <quicksilver> which is faster.[18:50:19] <quicksilver> In practice I don't *think* this will happen.[18:50:22] *** dust_ has joined ##OpenGL[18:50:27] <rsp> Should I use a VBO for texture coords[18:50:40] <rsp> Wait[18:50:46] <rsp> Is that even possible lol[18:50:56] <tmccrary> yeah[18:51:38] <tmccrary> ideally, you want to have vertex, normal, texture coordinates and indices all in a vbo[18:51:46] <rsp> Ok[18:51:57] <tmccrary> where the indices are in an element buffer[18:52:16] <dolphin> in most compilers you can enforce padding of the data[18:52:25] <rsp> Using gcc[18:53:26] <quicksilver> personally I would always use a flat float*[18:53:31] <quicksilver> if I need to be sure of alignment[18:53:47] <quicksilver> seems easier than trying to find out for sure what all the compiilers you might want ot support do.[18:54:54] <rsp> What should I bind a tex coord buffer as[18:57:57] <hibread> quicksilver: yep fair enough. From memory i believe im assuming that the layout is un-padded in my app... it runs.. and tahts all that matters at the moment :)[18:58:37] <tmccrary> GL_TEXTURE_COORD_ARRAY[18:58:37] *** TheLorax has quit IRC[18:58:42] <dolphin> well it's very easy to set the padding settings :P[18:59:21] <hibread> dolphin: tell me all about it another day. Im outta ere :) seeyas![18:59:30] *** hibread has quit IRC[18:59:50] *** dust-- has quit IRC[19:00:50] *** nplus has quit IRC[19:03:17] *** dolphin has quit IRC[19:04:15] *** Yustme has quit IRC[19:04:32] *** Yustme has joined ##opengl[19:08:20] *** JernejL has joined ##OpenGL[19:14:08] *** Joakim_ has joined ##OpenGL[19:16:34] *** XzN`L3g3ndZ has quit IRC[19:16:46] *** DobosCake has joined ##OpenGL[19:19:10] *** Lemml has joined ##OpenGL[19:34:41] *** neunon has joined ##opengl[19:36:19] *** Lemml_ has joined ##OpenGL[19:40:04] *** Lemml has quit IRC[19:47:14] *** charlie5 is now known as charlie_zzz[20:03:05] *** belou has quit IRC[20:06:30] *** Madsy has quit IRC[20:15:16] *** andikr has joined ##opengl[20:20:24] *** Jupp3 has quit IRC[20:21:30] *** Joakim_ has quit IRC[20:21:51] *** jalmeida has joined ##OpenGL[20:22:30] *** Satan_Inside_ has joined ##OpenGL[20:22:39] *** speedy1 has quit IRC[20:23:08] *** Madsy has joined ##opengl[20:24:15] *** Satan_Inside has quit IRC[20:26:29] *** LtJax has joined ##opengl[20:26:35] *** speedy1 has joined ##OpenGL[20:27:50] *** rutski has joined ##OpenGL[20:27:53] *** jabxvi has joined ##opengl[20:31:24] *** karabash has quit IRC[20:34:13] *** hubbe3 has quit IRC[20:34:53] *** hubbe3 has joined ##OpenGL[20:35:34] <rutski> hi all[20:36:24] <rutski> if I have a screen aligned quad that I know is going to rasterize to 10x10 pixels on the screen, then how do I map a 10x10 texture onto it so as to exactly map to the texture pixels on the quads fragments?[20:36:53] <rutski> at the moment I'm trying, but getting odd results; it's missing the top row of pixels[20:37:07] <rutski> it's as if the texture was shifted up by one row[20:38:13] *** hubbe3 has quit IRC[20:38:34] *** Joakim_ has joined ##OpenGL[20:38:51] *** karabash has joined ##OpenGL[20:38:54] *** hubbe3 has joined ##OpenGL[20:40:39] *** nplus has joined ##OpenGL[20:42:18] *** Madsy has quit IRC[20:42:38] <tmccrary> Use an orthographic projection and nearest neighbor filtering[20:42:45] <rutski> I already am[20:43:01] <tmccrary> Are you sure your texture coordinates are between 0-1 and take up all the space?[20:43:22] <rutski> well, they're not exactly between 0-1[20:43:37] <rutski> I had to pad the texture so it'll have power of two dimensions[20:43:52] <tmccrary> I bet thats where the issue is cropping up[20:43:53] <rutski> so texture coordinates go from 0 to whatever value is necessary to hit the last useful pixel[20:43:56] <rutski> no, it's not[20:44:05] <rutski> because the cutting off happens near the 0[20:44:07] *** madsy_ has joined ##opengl[20:44:56] <rutski> I'll paste a pic, one sec[20:45:21] <rutski> http://rutski89.com:31597/upload/Picture%2023.png[20:45:34] <rutski> you'll have to view that in something other than a web browser though; or you won't see what's wrong[20:45:45] <rutski> the top right point in that image has the tex coord 0,0[20:47:04] <tmccrary> Did you do anything to the texture matrix?[20:47:20] <rutski> nope, haven't touched it[20:48:14] <rsp> tmccrary: Can you look at my render code to see if I'm doing something wrong with the texcoords?[20:48:40] <rutski> for some reason the top row of fragments that make up the rasterized quad have tex coordinates that are closer the center's of the texels in the second row than the first[20:49:00] <rutski> I really wish there was a way to see if that was indeed the case[20:49:05] *** blbmp has joined ##OpenGL[20:49:16] <tmccrary> yeah[20:49:17] <rutski> I wonder if there are any tools that let you actually examine the tex coord values assigned to individual fragments[20:50:03] <tmccrary> well you're putting the data in there, so you should know[20:50:23] <rutski> the trouble is that what I'm putting in doesn't cause the desired effect :([20:51:28] <rutski> this is so weird. the top left vertex has a tex coord of 0,0, yet the fragment that comes from rasterizing the top left vertex has a tex coord one row of pixels higher than that in the t tex coord[20:54:45] <rutski> ah, I think I got it[20:54:56] <rutski> I was specifying vertex positions via glVertex2f[20:55:20] <rutski> and the values I was passing in were measured in pixels, but they had small fractional parts that hadn't been rounded off[20:55:30] *** karabash has quit IRC[20:56:32] *** groton has joined ##OpenGL[20:59:53] <rsp> tmccrary: www.pasteall.org/821 :-S[21:01:12] *** madsy_ has quit IRC[21:01:13] *** Jupp3 has joined ##OpenGL[21:01:52] <tmccrary> Having problems?[21:02:17] *** kenws has joined ##OpenGL[21:03:15] <rsp> Yeah texture is not correct[21:03:22] <rsp> Not indexed[21:03:50] <rsp> tex coords trouble[21:04:51] <tmccrary> What do you mean by your texture coordinates are not indexed?[21:05:01] <rsp> lol dunno[21:05:19] <tmccrary> for each vertex, you should have a matching texure coordinate[21:05:31] <tmccrary> its just like the vertex's position, but the position it represents is in texture space[21:05:45] <rsp> Yeah I know but I'm getting very weird results[21:05:50] <rsp> Values seem to be right[21:07:07] <tmccrary> one thing I noticed is[21:07:16] <rsp> The whole texture is applied to each model triangle[21:07:23] <tmccrary> you should use glPushMatrix/glPopMatrix for rendering[21:07:27] <rsp> Ok[21:07:42] <tmccrary> instead of glTranslatef()/glTranslatef(-)[21:07:49] <rsp> Nice[21:08:04] <tmccrary> you can go glPushMatrix(); glTranslatef(); <render code> glPopMatrix();[21:08:18] <tmccrary> not that its related to the issue at hand[21:08:26] <rsp> Yeah but that's still great to know[21:08:53] <tmccrary> Have you tried rendering a more simple model?[21:08:57] <tmccrary> Like say a textured cube?[21:09:20] <tmccrary> I like debugging these kind of issues with a cube, because its easy to visualize the actual data in your head[21:10:07] <rsp> Yeah that's smart[21:10:21] <rsp> I don't have one though and I don't know how to texture with Blender yet[21:10:29] <rsp> Can I borrow yours in obj format[21:10:43] <tmccrary> one sec[21:10:47] <rsp> thanks[21:11:19] <rsp> Is glPushMatrix() faster[21:12:40] *** dv_ has quit IRC[21:15:26] <tmccrary> http://seventh-sun.com/tmack/box.obj[21:15:49] <tmccrary> each face occupies the entire 0-1 uv space[21:16:08] <tmccrary> I don't think glPushMatrix is faster, but it includes things like rotation and scale[21:16:29] <tmccrary> since most transforms are done using chained matrices, its not a bad idea[21:16:41] <tmccrary> the performance difference is negligible[21:17:21] <rsp> Ok[21:17:35] <rsp> Shouldn't the box have textures so I can see what's wrong[21:17:47] <tmccrary> yeah, just make sure one is bound[21:17:54] <rsp> True[21:18:11] <tmccrary> each face will use the entire texture on its surface[21:18:19] <rsp> One thing that is not as nice is that quads don't work for me :([21:18:36] <tmccrary> doh[21:18:39] <rsp> My importer sucks after immediate>VBO xD[21:18:43] <tmccrary> I thought I checked convert to triangles[21:18:50] <rsp> I can convert to triangles in Blender afaik[21:19:05] *** Madsy has joined ##opengl[21:19:34] <tmccrary> yeah its triangles already[21:20:18] <rsp> Hmm you are right[21:23:16] <rsp> Is it recommended to only draw triangles[21:23:28] <rsp> Instead of mixing[21:23:32] <rsp> (per model)[21:23:59] <tmccrary> everything will get converted to triangles at some point[21:24:04] <rsp> Yeah[21:24:09] <tmccrary> so supply quads or whatever just means more work for the driver/server to do[21:24:16] <rsp> Yeah[21:24:37] <rsp> client is the gpu in my case right[21:24:45] <rsp> using VBOs[21:24:52] <tmccrary> client is your code, the application side[21:25:01] <rsp> Ok[21:25:07] <tmccrary> VBO's are a little odd from traditional opengl[21:25:25] <tmccrary> because you can get allocated memory directly from the server side[21:25:29] <tmccrary> well, in a way[21:25:51] <rsp> Ok[21:34:57] <rsp> tmccrary: Check this out www.sendspace.com/file/i48q5u[21:36:53] *** Tag^None has joined ##OpenGL[21:37:06] <Tag^None> hi[21:37:14] <Tag^None> anybody here has ever used jogl?[21:37:31] <tmccrary> yep[21:37:52] <Tag^None> does it have a index limit or something?[21:38:05] <tmccrary> What do you mean by index limit?[21:38:27] <Tag^None> a mesh with 30000 indices is acting really weird[21:38:50] *** neoneurone has joined ##OpenGL[21:39:23] <Tag^None> draws some triangles sometimes, or not[21:39:44] <tmccrary> rsp: One thing, it doesn't look like you're really using VBO's here[21:39:56] <Tag^None> and if instead that we set 1500 indices.. it draws the mesh correctly (well, only the indices supplied, of course)[21:40:07] *** Xmas| has joined ##OpenGL[21:40:12] <tmccrary> You're supplying the data each frame with the pointer calls[21:40:28] <tmccrary> You're uploading the element indices on load into a VBO[21:40:32] <tmccrary> but not the data itself[21:40:36] <rsp> Ok[21:40:45] <tmccrary> element indices just define how the vertices are related to one another[21:40:54] <rsp> yeah[21:40:57] <tmccrary> Ideally, you'll want both in the VBO[21:40:59] <rsp> But can I have both[21:41:02] <tmccrary> yeah[21:41:02] <rsp> How?[21:41:41] <rsp> GL_ELEMENT_BUFFER_ARB?[21:41:53] <rsp> GL_ARRAY_BUFFER_ARB *[21:41:54] <tmccrary> no, its more like two objects[21:41:58] <rsp> Oh[21:43:06] <rsp> So I want glTexCoordPointer and glVertexPointer to point to VBO objects[21:43:35] <tmccrary> really you can just set them to nothing because the data is already in the vbo[21:43:40] *** Madsy has quit IRC[21:43:57] <tmccrary> glVertexPointer(2, GL_FLOAT, 0, 0);[21:44:35] <rsp> That gives me a seg fault[21:44:45] <rsp> I would have to add the upload code too right[21:44:46] <tmccrary> yeah because you didn't upload the data before hand[21:44:48] <tmccrary> yeah[21:44:49] <rsp> yeah[21:44:54] <tmccrary> in your ::Load method[21:45:13] <rsp> But what did you mean by two objects[21:45:24] <rsp> Where do I use them later on[21:46:37] *** juanmabc has joined ##opengl[21:47:44] *** dolphin has joined ##OpenGL[21:47:54] <tmccrary> Well you know what you did with your ::Load method at the end? Do the same thing, but instead of GL_ELEMENT_ARRAY_BUFFER, use GL_ARRAY_BUFFER[21:48:01] <tmccrary> and load in the vertex data[21:48:12] <rsp> Yeah but I mean where do I use that id[21:48:13] <rsp> later[21:48:29] <rsp> Or is it in the same buffer[21:48:33] <tmccrary> well after that, you have all your data loaded into the server[21:49:43] <rsp> The models renders real weird now![21:49:44] <tmccrary> So you can just bind the buffers, set your pointers to 0 (or whereever your offset starts), enable the state you need and call glDrawElements[21:51:28] *** replor has quit IRC[21:51:32] *** neunon has quit IRC[21:52:48] <rsp> It looks too weird now![21:52:57] <rsp> vertices are in the wrong places[21:53:30] <tmccrary> Here's a pretty good tutorial[21:53:31] <tmccrary> http://www.songho.ca/opengl/gl_vbo.html[21:57:32] *** Tibor__ has joined ##OpenGL[21:58:31] *** bbeausej has joined ##OpenGL[22:04:13] *** hubbe3 has quit IRC[22:06:33] *** hubbe3 has joined ##OpenGL[22:08:32] *** Lucine has joined ##OpenGL[22:11:08] *** PainBank has joined ##OpenGL[22:12:13] *** hubbe3 has quit IRC[22:15:44] *** Joakim_ has quit IRC[22:16:09] *** hubbe3 has joined ##OpenGL[22:16:16] *** Joakim_ has joined ##OpenGL[22:17:20] <PainBank> I am working with SDL and Opengl in Eclipse. Does Anyone know the library to include in the eclipse library setting for mingw32? is it SDLopengl32, SDL_opengl32? should it be above or below the other libraries?[22:18:25] *** Lemml_ has quit IRC[22:21:34] *** kaotrix has joined ##OpenGL[22:21:47] *** neunon has joined ##opengl[22:25:14] *** odietsch has quit IRC[22:28:53] *** Lucine2 has joined ##OpenGL[22:29:00] *** Lucine has quit IRC[22:29:57] *** groton has quit IRC[22:31:29] *** Yustme has quit IRC[22:31:36] <rsp> tmccrary: www.pasteall.org/822[22:32:34] <rsp> Is that how it's supposed to be done[22:33:02] <rsp> struct TextureIndex { GLfloat S,T; };[22:33:33] *** scy has left ##opengl[22:36:42] *** dolphin has quit IRC[22:38:05] <tmccrary> yeah, thats one way[22:38:15] <rsp> I get nothing rendered :'([22:38:36] <rsp> 1. bind tex coords and use glTexCoordPointer[22:38:40] <tmccrary> What does the rendering code look like?[22:38:57] *** sanjin has joined ##OpenGL[22:38:59] <rsp> 2. bind vertices and set glvertexpointer[22:39:11] <rsp> 3. bind indices and call glDrawElements[22:39:49] <rsp> No wait something does get rendered[22:39:59] <rsp> Lol my Zora is now officially a palm tree[22:40:16] <tmccrary> lol[22:40:21] <rsp> Rolf[22:42:33] <rsp> AM I doing something wrong or is it my data[22:42:49] <rsp> Does indicing take care of itself just like that?[22:42:55] <tmccrary> Can you post your rendering code?[22:42:58] <rsp> Yes[22:43:21] <rsp> www.pasteall.org/832[22:43:22] <rsp> oops[22:43:25] <tmccrary> If an element vbo is bound, the server will look at local memory instead of trying to copy it from the client[22:43:27] <rsp> www.pasteall.org/823[22:44:24] <tmccrary> comment the glBindBuffer stuff in ::Render()[22:44:39] <tmccrary> like // glBindBufferARB(GL_ARRAY_BUFFER_ARB,vBuffer[2]);[22:44:52] <rsp> Gives me weird meshes[22:45:13] <tmccrary> also, bind THEN do everything else[22:45:36] <rsp> ?[22:45:47] <rsp> Can I have more than one buffer bound at once[22:46:08] <tmccrary> whoops, sorry I read BindBuffer as bufferData[22:46:11] <tmccrary> sorry[22:46:17] <tmccrary> uncomment those ;)[22:46:24] <rsp> :)[22:46:55] <rsp> That gives me the palm tree lol[22:47:00] <tmccrary> ok, also, enable client state, THEN use glWhateverPointer[22:47:17] <rsp> Doesn't make a difference[22:47:28] <tmccrary> Yeah I think it must be the data then[22:47:31] <tmccrary> what kind of graphics card?[22:47:36] <rsp> G80[22:47:41] <tmccrary> hmm[22:47:54] <rsp> Would it be the way the data is loaded to the VBO perhaps?[22:48:04] *** oc2k1_ has joined ##opengl[22:48:05] <tmccrary> could be[22:48:13] <rsp> Because the data is fine afaik[22:48:24] *** Lucine has joined ##OpenGL[22:48:42] <tmccrary> what about &Vertices instead of &Vertices[0][22:49:07] <rsp> help[22:49:17] <rsp> my screen is filled with stuff xD[22:49:39] <tmccrary> What is Vertices exactly? Just an array or an array of arrays?[22:50:03] <rsp> Vertices are GLfloat[22:50:26] <rsp> Triangles are indices (unsigned int)[22:51:10] <tmccrary> ah its a vector[22:51:34] *** Lucine2 has quit IRC[22:51:34] <rsp> Yeah they all are[22:52:15] <rsp> I'm gonna repost now[22:52:48] <tmccrary> ah one[22:53:32] <tmccrary> You're using sizeof on that struct[22:53:44] <tmccrary> Could the compiler be padding it?[22:53:59] <tmccrary> Thus causing your app to act funny[22:54:14] *** hubbe3 has quit IRC[22:54:46] <rsp> (sizeof(GLfloat)*2) gave me the same result[22:54:51] <tmccrary> oh ok[22:55:07] <rsp> www.pasteall.org/824[22:55:19] <rsp> I seem to be the only one that uses that paste site :P[22:56:38] <rsp> I still wonder how veritces would be rendered indexed?[22:56:40] <tmccrary> bind before everything else in the render method[22:56:52] *** hubbe3 has joined ##OpenGL[22:56:53] <rsp> Can I bind a lot of buffer after each other[22:57:28] <tmccrary> bind->set client state->set pointer[22:57:31] <tmccrary> then do the next one[22:57:41] <tmccrary> after they're all done, render[22:58:20] <rsp> The client states are for rendering though?[22:58:26] *** jabxvi has left ##opengl[22:58:51] <tmccrary> yeah, that's all in the render method[22:59:04] <rsp> Yeah but I don't get how you meant[22:59:15] <tmccrary> right now you're calling enable client state before anything else[22:59:20] <rsp> halp, I don't want a palm tree![22:59:27] <rsp> Yeah you told me to[22:59:33] <tmccrary> for your vertex buffer, bind->set client state->set pointer[22:59:46] <tmccrary> then for your tex coord buffer, bind->set client state->set pointer[22:59:58] *** PainBank has left ##OpenGL[23:00:05] <tmccrary> then bind the element buffer[23:00:08] <tmccrary> and render[23:01:30] *** jabka has joined ##OpenGL[23:01:36] *** andikr has quit IRC[23:02:02] <rsp> Do you think the glDrawElements is the problem[23:02:13] <rsp> I'm not too sure about the parameters I picked there[23:02:29] <rsp> lol[23:02:32] <rsp> changed from SHORT to INT[23:02:35] *** jabka has quit IRC[23:02:38] <rsp> Now I have models rendering[23:02:44] <rsp> Back to basic, I need texturing working :([23:03:01] *** jalmeida has quit IRC[23:08:11] <rsp> tmccrary: Her eyes are all over the freaking place http://img27.picoodle.com/img/img27/4/5/15/f_Skrmbildgamm_576cbae.png[23:08:44] <rsp> Note that it's supposed to only be one texture though and eyes should be where.. eyes are and the rest that other darker green[23:10:00] *** Walt has joined ##opengl[23:10:02] <tmccrary> yeah, either the tex coords are messed up or they aren't being uploaded properly[23:11:04] <rsp> glTexCoordPointer is OK right[23:11:20] <rsp> 0,0 because of it's dedicated VBO[23:11:42] <tmccrary> yeah[23:11:55] <tmccrary> 0 means at the beginning of this buffers memory[23:12:04] <rsp> Yeah[23:12:07] <tmccrary> its different than vertex arrays, where its a pointer to the memory to upload[23:12:35] <rsp> OK[23:12:51] <rsp> I know VBOs are the fastest so I won't learn the other[23:13:10] <tmccrary> VBO's are very similar to vertex arrays[23:13:17] <tmccrary> they use pretty much all the same functions[23:13:22] <rsp> Yeah buy I mean CallLists etc too[23:13:25] <tmccrary> except as I mentioned above[23:13:27] <rsp> but*[23:14:04] <rsp> btw[23:14:13] <rsp> GL_TEXCOORD_ARRAY[23:15:45] <rsp> GL_TEXTURE_COORD_ARRAY[23:15:59] <rsp> *[23:16:07] *** pfo has quit IRC[23:16:20] <rsp> What's that and can it solve this[23:16:39] <rsp> GL_TEXCOORD_ARRAY vs GL_TEXTURE_COORD_ARRAY I don't get it[23:16:45] <tmccrary> http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/enableclientstate.html[23:16:48] <tmccrary> check the docs[23:17:21] <rsp> I'll rtfm[23:18:08] <peda_> hi all[23:18:32] *** fargiolas has quit IRC[23:19:03] <peda_> I'm pretty new to OpenGL and I'd like to write an application using OpenGL. I did some tutorials to learn about it but I have some questions.[23:19:04] *** kenws has quit IRC[23:19:59] <mads-> peda_ : fire away[23:20:03] <peda_> I have a firewire camera that passes pictures via dma. I get a pointer to that image, it's 8bit unsigned gray value. Now I want to have a little scene displaying a Monitor or two or three[23:20:23] <peda_> and the front surface will get a texture, this texture will be the image[23:20:56] <peda_> Is it a good idea to use the subimage function and directly pass the pointer that points to the dma region to opengl?[23:21:23] <peda_> i.e. I create a square texture of white pixels or whatever and I only map a subregion of it to my Monitor front surface[23:21:52] <peda_> and there's this function in opengl that can replace a subimage of a texture (currently don't remember the name)[23:22:19] *** BadChoice has joined ##OpenGL[23:22:33] <BadChoice> Hi![23:22:40] <peda_> is it a good idea to directly use that pointer? I have to enqueue that pointer at some time, can I be sure opengl will copy the image[23:22:53] <BadChoice> I've a question, does anybody know how to resize an SDL_Surface[23:23:00] <peda_> or do I have to be carefull to not realloc the image or write to it[23:23:34] <bobbens> BadChoice: that has nothing to do with opengl :)[23:23:40] <bobbens> and you need specific functions to do that :)[23:23:41] <prophile> BadChoice: there's a glu function which resizes an image[23:23:45] <peda_> btw I'm doing image processing and want to offload the CPU. I.e. fast video display with displaying debug stuff (different colored lines, curves,...)[23:23:46] <prophile> or you can ask #sdl[23:23:54] <prophile> i believe there's an SDL function to do it[23:23:59] <BadChoice> well, I want it to resize a texture[23:24:38] <BadChoice> If I have a 3000 px image that I want use as texture, first I want it resized to 200px[23:24:48] *** Jorachim has joined ##OpenGL[23:27:39] *** kiras has joined ##OpenGL[23:29:59] <BadChoice> does that glu function work with surfaces?[23:31:01] <prophile> a surface is just a bunch of metadata and the bytes[23:31:20] <prophile> just malloc a block of data, shove it into an SDL_Surface, set all the details, and call that glu function[23:31:25] <prophile> it's gluResizeImage or something[23:31:40] <BadChoice> I found gluScaleImage[23:32:14] <BadChoice> shit! segmentation fault[23:35:37] <peda_> ok, found the function again and will reformulate my question :) Is it a good idea to use glCopyTexSubImage2D to display a live video stream as a texture in an opengl scene?[23:40:44] *** Tibor__ has quit IRC[23:41:17] *** tmccrary has quit IRC[23:42:42] <BadChoice> that funciton worked preety well[23:42:45] <BadChoice> thank you!![23:49:26] <speedy1> peda_: CopyTexSubImage? you mean TexSubImage?[23:50:08] <speedy1> peda_: better option would be to use PBO extension - it's made for streaming textures[23:50:50] *** mm765 is now known as mm765^away[23:53:12] <peda_> speedy1: extension means it's only available on some hardware?[23:53:38] <speedy1> yup - mostly on all commodity hw nowadays[23:53:45] <peda_> ok[23:54:06] *** Darius_ has quit IRC[23:54:15] <peda_> and another question is about the line drawing[23:54:46] <peda_> can I write to display lists from multiple threads (i.e. my image processing thread) and at the end my render loop will display it[23:55:07] <peda_> or should I have my own structs for that and draw the lines directly in the render loop?[23:56:05] <peda_> from what I saw the main implementation is not thread safe, but I didn't try it for display lists yet[23:58:11] *** BadChoice has left ##OpenGL