May 19, 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 19, 2008 [00:00:19] <Plagman> level1_: it should be in gl.h[00:00:38] <HuntsMan> level1_: GLShader? The SGI stuff?[00:00:53] <Plagman> I assume he meant GLSL[00:00:57] <Plagman> hopefully[00:01:59] <Arc> speedy1: AH yes I see now[00:02:06] <Arc> GL_TEXTURE refers to *this* texture unit[00:02:13] <Arc> GL_PREVIOUS refers to the output of the last[00:02:20] <Plagman> right[00:02:40] <Arc> GL_TEXTUREx refers to a specific texture unit, ie, I can say "this modifies texture 0 exactly"[00:02:40] *** level1_ has quit IRC[00:03:23] <Arc> so what does GL_CONSTANT and GL_PRIMARY_COLOR refer to?[00:03:36] <HuntsMan> a constant, and the glColor[00:03:37] <speedy1> check the spec ;>[00:04:11] <Arc> http://www.opengl.org/sdk/docs/man/xhtml/glTexEnv.xml[00:04:18] <Arc> it doesn't say[00:04:21] <Plagman> no[00:04:23] <Plagman> the spec[00:04:35] <Arc> where is the spec then?[00:04:50] <Plagman> http://www.opengl.org/registry/doc/glspec21.20061201.pdf[00:04:56] <Plagman> here for the core functionality[00:05:10] <Plagman> http://www.opengl.org/registry/[00:05:14] <Plagman> and here for the extensions[00:05:15] <speedy1> it's a hard read - but worth it[00:05:28] <Plagman> what you want is that: http://www.opengl.org/registry/specs/ARB/texture_env_combine.txt[00:07:24] <Arc> ok so PRIMARY_COLOR is the result of the lighting and material colors[00:09:02] <Plagman> non[00:09:07] <Arc> it doesn't say what GL_CONSTANT is, other than "texture environment constant color"[00:09:25] <MatthiasM> Arc: because that's all what it is - you can set it :)[00:09:40] <Arc> Plagman: non?[00:09:47] <Arc> "primary color of incoming fragment"[00:09:54] <Plagman> did you read the whole spec and not just the overview?[00:10:01] <Arc> yes I read the issues[00:10:46] <speedy1> take your time and read it all :p[00:11:07] <Arc> maybe I didnt say that right[00:11:15] <speedy1> it'll be worth the effort[00:11:16] <Arc> but I doubt this is covered, so I'll ask it[00:11:29] <MatthiasM> LOL[00:11:33] <Arc> lighting step, where the material colors are applied to the fragment[00:11:49] <Arc> does that happen before the textures are applied? I've read it does[00:12:05] <Arc> and if so, then PRIMARY_COLOR equals it, or whatever the result of previous passes is, etc[00:13:17] *** justjohn has quit IRC[00:14:13] <Arc> and no the document doesn't describe that[00:14:41] *** prophile has quit IRC[00:15:23] <Arc> if my assumption is wrong, then how is someone going to understand this when the big picture of how each component fits together is never documented?[00:15:52] *** so1 has joined ##opengl[00:15:56] <speedy1> unfortunatly, you have to read through the important parts of http://www.opengl.org/registry/doc/glspec21.20061201.pdf[00:16:50] <speedy1> everything you wanna know is in there, although described in a pretty technical way - so you really need to take some time with it[00:16:53] <Plagman> Arc: I think the fragment color you're going to get is going to be textured but not fogged[00:17:00] <so1> hi[00:17:18] <Plagman> hm[00:17:20] <Plagman> not textures[00:17:25] <Plagman> I meant lit*[00:17:52] <so1> any news about opengl3, beside they "are working on it, but can't comment"?[00:18:09] <Arc> when is fog added?[00:18:21] <speedy1> so1: check the siggraph 2008 Opengl BOF page[00:19:19] <Arc> speedy1: I'm sure it is buried in there, the memory cells of my brain are open to learning this specific subject in context though, and I have 5 other things going on that are going to need my attention soon[00:19:32] <Satan_Inside> http://www.opengl.org/documentation/specs/version1.1/state.pdf ...yes its old (although a newer one is shipping with the red / blue and orange 3 book set as I recall) but even this one is still quite useful[00:19:57] <Satan_Inside> print it off and hang it on your wall[00:20:35] <so1> speedy1: thanks, i will check[00:21:48] <Arc> Satan_Inside: ?[00:21:49] <speedy1> arc: so we all do - i'm currently trying to work, too - can't help you all the time[00:22:15] <Arc> I understand, I just want a URL that describes how it fits together[00:22:31] <so1> "OpenGL 3 Updates Don’t miss the great updates on OpenGL3 at the SIGGRAPH BOF!"[00:22:34] <speedy1> you got it from glYoda[00:22:38] <so1> lol ...[00:22:38] <Satan_Inside> note the diagram I just gave you Arc[00:22:44] <so1> they don't even got a room or time now ...[00:22:56] <Arc> Satan_Inside: I can't even read that diagram, my PDF viewer cant zoom in far enough[00:23:06] <Satan_Inside> that isn't our problem[00:23:25] <Plagman> Arc: as I said what you're going to get with PRIMARY_COLOR is going to be lit but not fogged[00:23:32] <Plagman> so your assumption was correct[00:23:35] <Satan_Inside> and as I said earlier I'd suggest printing it out in stages, taping it together and hanging it on the wall[00:24:14] <Arc> Plagman: and fog is applied after texturing, right?[00:24:23] <Satan_Inside> yes[00:24:30] <Arc> awesome.[00:24:50] <Satan_Inside> fog is after per fragment processing[00:25:05] <Satan_Inside> as the above diagram (hint) I gave you mentions[00:25:14] <Satan_Inside> or illustrates if you will[00:25:34] <Arc> so if I want to mix the PRIMARY_COLOR with just a dot3 texture then I need to enable an additional texture unit, not bound to any texture, that combines GL_PREVIOUS with GL_PRIMARY_COLOR, correct?[00:26:48] *** Xmas| has joined ##OpenGL[00:30:38] <Arc> ok I think I have enough to move forward on this[00:42:52] *** Tibor__ has quit IRC[00:47:08] *** so1 has left ##opengl[00:52:49] *** LiQuiDninja has quit IRC[01:05:07] *** amalon has quit IRC[01:10:48] *** Sabman has quit IRC[01:13:01] *** chondrite has joined ##OpenGL[01:15:21] *** njs_ has joined ##OpenGL[01:17:16] <njs_> for various reasons, I have 2d image buffers that I need to blit to the screen, and I'm using OpenGL. The code works fine using GL_TEXTURE_RECTANGLE_ARB to get non-power-of-two textures, but that's not very portable, so I'm trying to switch to plain-old GL_TEXTURE_2D[01:18:02] <njs_> so I do the exact same sequence -- glEnable(GL_TEXTURE_2D); glBindTexture(GL_TEXTURE_2D, mytexid); glTexImage2D(...), then draw a rectangle with glQuads[01:18:15] <njs_> but the rectangel is drawn with the current fill color, rather than with the texture[01:18:55] <speedy1> texture_2d uses texcoords in [0,1] range[01:19:25] <njs_> speedy1: yes, I adjusted that, but it doesn't matter anyway -- it's drawing my square without any texture at all, not even a distorted one.[01:20:14] <speedy1> did you disable tex_rect texture target and enable texture_2d texture target?[01:20:30] <njs_> speedy1: dunno, what does that mean in terms of code?[01:20:53] <speedy1> glDisable(GL_TEXTURE_RECTANGLE_ARB);[01:21:20] <njs_> doesn't help[01:22:00] <speedy1> hmm.. maybe you need to disable mip-mapping[01:22:07] <njs_> hmm, maybe[01:23:33] <njs_> though the rectangle I'm drawing is exactly the same size in pixels as the texture[01:23:50] *** neoneurone has quit IRC[01:27:25] <njs_> ah-hah, glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_{MIN,MAG}_FILTER, GL_LINEAR) magically did the trick.[01:27:35] <njs_> no clue why, but hey![01:33:11] <Xmas|> probably because you don't have mipmaps[01:33:46] <Satan_Inside> probably because the default state for GL_TEXTURE_2D is with mip-mapping (in the MIN case) enabled[01:34:20] <njs_> and mipmapping is used even when no scaling is necessary? that's the weird part, to me.[01:35:51] *** MatthiasM has quit IRC[01:35:55] <Xmas|> the texture is incomplete if the filter mode uses mipmaps and there are no mipmaps[01:35:58] *** MatthiasM has joined ##opengl[01:36:55] <Satan_Inside> GL_NEAREST_MIPMAP_LINEAR is the default MIN state for GL_TEXTURE_2D target(s)[01:37:18] *** karabash has joined ##OpenGL[01:37:19] <Xmas|> (which is the most stupid default in OpenGL)[01:37:28] <Satan_Inside> heh I'd agree[01:37:37] <karabash> hi[01:38:32] <karabash> any experience with bitmap fonts?[01:38:53] <karabash> ive tried to implement nehes 17 SDL version lesson[01:39:08] <karabash> and result is like AAAAA or ----- or ÓÓÓÓÓÓ[01:39:40] <karabash> and when i move cursors it blinks[01:39:49] <karabash> whata[01:41:02] *** speedy1 has quit IRC[01:52:32] *** LtJ4x has quit IRC[01:54:24] *** Suprano has quit IRC[01:57:33] *** Xmas| has quit IRC[02:06:31] *** hubbe3 has quit IRC[02:06:48] *** hubbe3 has joined ##OpenGL[02:06:58] *** momiage_lucky has joined ##OpenGL[02:08:42] *** blight_ has quit IRC[02:16:49] *** momiage_lucky has quit IRC[02:46:00] *** karabash has quit IRC[02:47:49] *** dv_ has quit IRC[02:49:10] *** dv_ has joined ##OpenGL[03:02:54] *** Sabman has joined ##openGL[03:03:15] *** Sabman has quit IRC[03:14:27] *** jparishy has joined ##OpenGL[03:14:41] <jparishy> Can the name returned from glGenTextures() be negative?[03:15:46] *** X-Scale has left ##OpenGL[03:16:45] <Plagman> no[03:17:18] <Plagman> they're positive integers ranging from 1 to ...[03:17:28] <Plagman> hint: the type is GLuint[03:17:33] <Plagman> u means unsigned[03:19:18] <jparishy> Hm, oh, i was doing something stupid[03:19:31] <jparishy> Casted the unsigned int to an int before printing the value.[03:20:57] *** Amorphous has quit IRC[03:21:50] <jparishy> 3086650448. Does that look valid? I don't know much about how OpenGL handles the texture names internally but that seems very high[03:22:09] *** gusano has joined ##OpenGL[03:22:14] *** Amorphous has joined ##opengl[03:23:02] *** m4ggus has joined ##opengl[03:23:29] *** HuntsMan has quit IRC[03:25:00] <Satan_Inside> did you generate a valid texture ID?[03:25:21] <Satan_Inside> i.e. GLuint TID = 0; glGenTextures( 1, &TID ); ...[03:25:48] <jparishy> That's what I did, and I got that number above for TID[03:26:29] <Satan_Inside> and how exactly are you printing this out?[03:26:48] <Satan_Inside> printf( "TID = %u\n", TID ); I'd assume?[03:27:00] <Satan_Inside> or something equivalent[03:27:01] <jparishy> std::cout << "Generated texture id: " << texId << ".\n";[03:27:04] <jparishy> Yea[03:28:37] <jparishy> Well, the actual problem is that I load the texture, set it up, but when I bind and draw it, teh texture isn't there. It's just a white rectangle[03:28:57] <jparishy> I have GL_TEXTURE_2D enabled[03:29:02] <jparishy> and I set the tex coords[03:29:39] <jparishy> But nothing comes up :([03:31:32] *** HuntsMan has joined ##opengl[03:33:05] <jparishy> Here's the code, if anyone wants to help. http://rafb.net/p/vX6pKj34.html[03:37:06] *** Sabman has joined ##openGL[03:38:57] *** dvoid__ has quit IRC[03:47:44] *** dv_ has quit IRC[03:58:20] *** hibread has joined ##opengl[04:01:53] *** peda_ has joined ##OpenGL[04:02:22] *** kenws_ has joined ##OpenGL[04:03:24] *** nathan_ has joined ##OpenGL[04:08:25] *** Dew420 has quit IRC[04:15:34] *** kenws has quit IRC[04:19:41] *** peda__ has quit IRC[04:24:25] *** Shel2476 has joined ##OpenGL[04:24:26] *** Shel2476 has left ##OpenGL[04:28:04] *** Shel2476 has joined ##OpenGL[04:28:06] *** Shel2476 has left ##OpenGL[04:31:54] *** Daigmato has quit IRC[04:41:01] *** juanmabc has quit IRC[04:50:34] *** Sabman has quit IRC[04:52:12] *** charlie5 is now known as charlie_zzz[04:53:29] *** jparishy has quit IRC[04:54:21] *** ginoman has joined ##OpenGL[05:01:39] *** rnx has left ##opengl[05:21:14] *** chondrite has quit IRC[05:21:53] *** replor has quit IRC[05:21:58] *** hibread has quit IRC[05:24:21] *** avacore has quit IRC[05:29:15] *** avacore has joined ##OpenGL[05:36:30] *** HuntsMan has quit IRC[06:01:48] *** Dew420 has joined ##OpenGL[06:12:07] *** Dew420 has quit IRC[06:17:48] *** Dew420 has joined ##OpenGL[06:19:02] *** aalex has quit IRC[06:26:03] *** meteors has quit IRC[06:26:05] *** servus has joined ##opengl[06:30:07] *** Dew420 has quit IRC[06:45:20] *** ginoman has left ##OpenGL[06:50:01] *** mm765^sleep is now known as mm765[07:00:26] *** mm^away has joined ##opengl[07:05:26] *** mastro has quit IRC[07:15:24] *** gus4n0 has joined ##OpenGL[07:15:45] *** gusano has quit IRC[07:17:33] *** mm765 has quit IRC[07:24:27] *** mm^away is now known as mm765[07:27:42] *** Dew420 has joined ##OpenGL[07:37:19] *** m4ggus has quit IRC[07:55:45] *** Dew420 has quit IRC[07:55:57] *** BahamutZERO has quit IRC[08:14:03] *** Castigador has joined ##Opengl[08:17:59] *** kenws_ has quit IRC[08:40:04] *** mediogre has joined ##OpenGL[08:41:22] *** Ademan has quit IRC[08:42:37] *** nathan_ has quit IRC[08:42:59] *** andikr has joined ##OpenGL[09:04:33] *** Burga has joined ##OpenGL[09:06:30] *** mediogre has quit IRC[09:14:22] *** [AD]Turbo has joined ##OpenGL[09:16:26] <[AD]Turbo> yo[09:32:24] *** groton has joined ##OpenGL[09:33:35] *** amz has quit IRC[09:38:14] *** Rangar has quit IRC[09:44:42] *** dvoid has joined ##OpenGL[09:49:51] *** Roderic has joined ##OpenGL[09:49:52] *** Roderic is now known as Ingenu[09:57:23] *** SolariQ has joined ##OpenGL[10:04:48] <SolariQ> Hello[10:05:12] <SolariQ> I need some help understanding texture QUADS.[10:05:56] <SolariQ> what i want to do is to "cut" a piece of an image and store it in a texture array: textures[];[10:06:55] <SolariQ> I've loaded the image, stored it in a texture, and now i want to cut the texture into sprites[10:07:51] <bobbens> modify the GL_TEXTURE matrix or modify the glTexCoord appropriately[10:20:50] *** Encryption767 has joined ##opengl[10:21:03] *** Encryption767 has left ##opengl[10:21:35] *** SolariQ has left ##OpenGL[10:44:00] *** Zenja has joined ##OpenGL[10:48:01] <Jupp3> bobbens: Just when I was going to point out that he can do that with / and % :)[10:48:45] <bobbens> well you'll need to use / and % unless it's all in a row :)[10:48:58] <Jupp3> No, you don't need to[10:49:08] <Jupp3> There are more complex ways to achieve the same result :)[10:49:43] <bobbens> there are always more complex ways[10:49:47] <bobbens> but / and % are nice fast and sexy[10:49:55] <Jupp3> Especially in OpenGL[10:50:21] *** Jernej has joined ##OpenGL[10:51:13] <Jupp3> You know, way too often people come up with a nice object oriented system, where all models consist of faces, which can have different amount of vertices... Then they loop through all faces, do separate glBegin() ... glEnd() for drawing each face[10:51:55] *** blbmp has quit IRC[10:52:10] *** korff has joined ##OpenGL[10:52:20] <bobbens> one of my first opengl implementations had a putpixel function and such that would just do a sing GL_POINTS[10:52:27] <bobbens> I had to do 5k of them sometimes[10:52:38] <bobbens> the performance boost when merging them all into one call is incredible :)[10:52:52] <bobbens> gotta minimize them glBegin and glEnd[10:53:37] *** Castigador has quit IRC[10:53:38] *** avacore has quit IRC[10:53:38] *** enoex_ has quit IRC[10:53:38] *** neric has quit IRC[10:54:04] *** Castigador has joined ##OpenGL[10:54:04] *** avacore has joined ##OpenGL[10:54:04] *** enoex_ has joined ##OpenGL[10:54:04] *** neric has joined ##OpenGL[10:54:12] *** JernejL_ has joined ##OpenGL[10:54:12] *** MatthiasM has quit IRC[10:54:35] *** MatthiasM has joined ##opengl[10:54:55] <Jupp3> bobbens: You know ldraw? Anyway, I created OpenGL viewer for the format[10:55:17] <Jupp3> Basically it can have lines, triangles and quads, in any order[10:55:54] *** NevroPus has joined ##OpenGL[10:55:56] <Jupp3> So of course the first easy solution for me was to do separate glBegin() ... glEnd() for each face, as there's no telling what the next one will be, and put it all in a display list[10:56:46] <Jupp3> So a while later, I came up with an idea of keeping the current primitive in a variable, and comparing next one againist it, thus doing glEnd only when usually needed[10:56:52] <Jupp3> I think that about doubled the framerate[10:57:25] <bobbens> yeah, glBegin is soo freaking expensive :)[10:57:41] <bobbens> feels bad though, to make code a bit uglier to gain speed :)[10:57:47] <Jupp3> Later I went even further, and made it sort the primitives, which didn't increase speed much, as they are usually quite well sorted anyway[10:58:13] <Jupp3> And now I'm just thinking of when I should rewrite the whole damn thing to use vertex arrays instead[10:59:12] *** gotan666 has joined ##OpenGL[10:59:39] <Jupp3> bobbens: To be honest, the code was clean and nice... Untill I started to optimize it seriously... And fix bugs in the format... And check for all "special cases"[11:00:15] *** BahamutZERO has joined ##OpenGL[11:00:35] *** Lacerta has quit IRC[11:00:41] *** Lacerta has joined ##OpenGL[11:00:48] *** peda__ has joined ##OpenGL[11:01:05] <bobbens> well I always optimize to a point[11:01:18] <Zenja> I have a lighting problem, such that I get wrong results based on glNormal[11:01:29] *** peda_ has quit IRC[11:01:32] <bobbens> when I see i'm starting to write SSE3 routines in a non-bottleneck area in inline assembly, it takes me a while to realize that's pretty silly :)[11:01:52] <Zenja> I am trying to draw a simple ship. 2 sides (port and starboard), front and back of ship, plus deck. Heel is underwater (not visible)[11:02:03] <Zenja> The starboard side has +y[11:02:07] <Zenja> port side has -y[11:02:18] <Zenja> Z denotes height.[11:02:19] <Zenja> z=0 water[11:02:28] <Zenja> z = 5m top of ship[11:02:45] <Zenja> With glNormal3f(0, 1, 0) Starboard is correctly lit[11:02:58] <Zenja> However, with glNormal3f(0, -1, 0) port side is wrongly lit[11:03:18] <Zenja> Port side requires glNormal3f(0, 0, -1). It doesn't make any sense.[11:03:38] <Zenja> Basically, when y+, glnormal is fine.[11:03:44] <Jupp3> Zenja: Those normals don't sound quite "correct" unless your ship is totally flat :)[11:03:45] <Zenja> With y-, glnormal is weird.[11:03:54] <Zenja> It's driving me crazy.[11:04:04] <Jupp3> Zenja: Are you giving normals before vertices?[11:04:11] <Jupp3> Assuming you use direct mode or display lists[11:04:13] <Zenja> Every vertex has a normal[11:04:24] <Zenja> glvertexarray[11:04:39] <Jupp3> Becouse when I first started using lighting, I for some reason had glNormal after the glVertex :)[11:04:53] <Zenja> It's weird, since for starboard side everything is fine[11:04:56] <Jupp3> Using vertex arrays? Good[11:05:09] <Jupp3> Zenja: What's your test case?[11:05:13] <Zenja> Port (with negative y) is giving me silly results[11:05:15] <Zenja> Test case?[11:05:20] <Jupp3> How you test it[11:05:29] <Jupp3> Was just wondering that maybe you rotate the light too?[11:05:40] <Zenja> Jupp3: - yes, light is circling[11:06:02] <Zenja> Jupp3: light makes a nice circle around the ship[11:06:12] <Zenja> Startboard side, front and back are perfectly lit[11:06:19] <Zenja> However, port side is dark.[11:06:26] <Jupp3> Well, I thought that maybe you rotate the light along with the ship, without noticing you do it :)[11:06:28] <Zenja> Unless I set normals to glNormal(0, 0, -1)[11:06:54] <Zenja> Tested on 2 machines (Windows and MacOSX) - so it is not a driver issue[11:07:11] <Jupp3> To be honest, I'm not too comfortable with naval terminology :)[11:07:34] <Zenja> if you face the direction of the front of ship, port is left, starboard is right[11:07:52] <Jupp3> ok[11:07:57] <Jupp3> are you scaling btw?[11:08:28] <Zenja> ie. if ship travelling north (0 ), port is 270 (left, -x) and starboard is right (90, +x)[11:08:35] *** JernejL has quit IRC[11:08:54] *** [this] has joined ##opengl[11:09:10] <Jupp3> Zenja: Is the model "all in one"?[11:09:13] <Zenja> Jupp3: scaling the sails, but not the hull/deck. Lighting is off for the sails for now (until I debug the hull / deck)[11:09:24] <Jupp3> Or are you using totally separate parts, which you draw with different transformations?[11:09:29] <Zenja> Jupp3: multiple triangle strips and plain old arrays of triangles[11:09:35] <Zenja> Different parts[11:09:42] *** Jernej has quit IRC[11:09:47] <Zenja> But hull has same transformation.[11:09:52] <Zenja> One massive vertex array[11:10:07] <Zenja> no transforms[11:10:12] <Jupp3> ok[11:10:26] <Zenja> I am using quantarnion for camera[11:11:29] <Zenja> Hang on a second, I will get rid of ship and just draw a lit cube.[11:11:39] <Zenja> I will then see if the plain old cube renders correctly[11:11:45] <Jupp3> That might be better[11:11:45] <Zenja> Back in a tick.[11:11:58] <Jupp3> As it sounds that with a complex model, your normals are slightly wrong anyway[11:12:10] *** enoex_ has quit IRC[11:12:11] *** neric has quit IRC[11:12:12] *** Castigador has quit IRC[11:12:12] *** avacore has quit IRC[11:12:54] *** Castigador has joined ##OpenGL[11:12:54] *** avacore has joined ##OpenGL[11:12:54] *** enoex_ has joined ##OpenGL[11:12:54] *** neric has joined ##OpenGL[11:13:54] *** gotan666 has quit IRC[11:14:40] <Zenja> Hmm, same thing.[11:14:49] <Zenja> 3 sides are lit correctly, while y- is wrong.[11:15:09] <Zenja> Give me a minute to try nothing but the cube (remove everything from scene manager)[11:17:34] <Jupp3> Zenja: Not really a solution, but you could try glLightModelf(GL_LIGHT_MODEL_TWO_SIDE, 1.0);[11:18:15] <Zenja> Jupp3: he he[11:19:45] <Zenja> OK, I've reverted to minimalistic scenes with only cube and light, now everything is fine.[11:19:59] <Zenja> That's good, because it now allows me to investigae each component seperately[11:20:13] <Zenja> Something is screwing the pooch.[11:21:06] *** gotan666 has joined ##OpenGL[11:25:03] *** gotan666 has quit IRC[11:32:52] *** NevroPus has quit IRC[11:33:39] <Zenja> I've reverted everything to a template version, and lighting is now OK. Now I have to start adding my recent code changes to discover the culprit. I'm actually quite interested in discovering what caused this to happen.[11:35:41] *** gotan666 has joined ##OpenGL[11:38:35] *** Suprano has joined ##OpenGL[11:43:05] *** mm765 has left ##opengl[11:45:03] <Zenja> Now this is weird. When the ship is smack in the middle of my world (0, 0, 0), I can not light up anything below the y=0 axis. Above it its fine, below my lighting is wrong.[11:45:14] <Zenja> When I move the ship to (0, 10, 0), everything is fine.[11:45:20] *** odietsch has quit IRC[11:45:53] <Zenja> Somehow my glNormal doesn't work when my objects are below y<0[11:46:11] <Zenja> When the object is well above y>0, glNormals seem to work absolutely fine.[11:46:26] <Zenja> Weird[11:46:42] *** mm765 has joined ##opengl[11:52:12] *** [this] has quit IRC[11:53:38] <Zenja> Now that was nuts. When the ship is at location 0, 10, 0, all glNormals produce correct effect. However, if ship is at 0, -10, 0, lighting is compeltely messed up.[11:54:18] *** enoex_ has quit IRC[11:54:18] *** neric has quit IRC[11:54:19] *** Castigador has quit IRC[11:54:19] *** avacore has quit IRC[11:54:25] *** cdleonar1 has joined ##OpenGL[11:54:39] *** cdleonar1 has left ##OpenGL[11:54:41] *** Castigador has joined ##OpenGL[11:54:41] *** avacore has joined ##OpenGL[11:54:41] *** enoex_ has joined ##OpenGL[11:54:41] *** neric has joined ##OpenGL[11:57:32] *** enoex_ has quit IRC[11:57:33] *** neric has quit IRC[11:57:33] *** Castigador has quit IRC[11:57:34] *** avacore has quit IRC[11:58:38] *** Castigador has joined ##OpenGL[11:58:38] *** avacore has joined ##OpenGL[11:58:38] *** enoex_ has joined ##OpenGL[11:58:38] *** neric has joined ##OpenGL[12:01:04] *** fengee has quit IRC[12:02:03] *** NevroPus has joined ##OpenGL[12:02:38] *** scy has joined ##opengl[12:05:37] *** nathan_ has joined ##OpenGL[12:10:56] <Zenja> OK, after much more investigation, I found the culprit. I had a glRotate3f(180, 0.0f, 1.0f, 0.0f) for my light.[12:11:16] *** sohail has quit IRC[12:12:49] <nathan_> what was the problem ?[12:12:56] <nathan_> light appearing in wrong place?[12:14:04] *** neoneye has joined ##OpenGL[12:14:07] *** gotan666 has quit IRC[12:16:24] *** enoex_ has quit IRC[12:16:24] *** neric has quit IRC[12:16:24] *** Castigador has quit IRC[12:16:25] *** avacore has quit IRC[12:16:43] *** Castigador has joined ##OpenGL[12:16:43] *** avacore has joined ##OpenGL[12:16:43] *** enoex_ has joined ##OpenGL[12:16:44] *** neric has joined ##OpenGL[12:20:15] *** gotan666 has joined ##OpenGL[12:20:56] <Jupp3> Zenja: Didn't I ask you, if you were accidentally rotating your light? :)[12:23:23] *** scy has left ##opengl[12:30:21] <Zenja> Jupp3: the weird thing is that when i disable all rotations, I still dont get glNormal working if the object is below y=0. When I move the ship and the light to y+10, everything is perfect. When I leave the ship in 0,0,0 and the light circling around 0,0,0, everything below y=0 (port side of ship) doesn't like the normal. If I flip the normal, then its fine.[12:31:10] *** Cheery has joined ##OpenGL[12:31:11] <Zenja> I can make my entire world with +y, but I dont see a reason to do that.[12:32:03] <Cheery> I'd like to know how glInterleavedArrays and glxxPointer differs.[12:32:50] <Cheery> if I'd use glInterleavedArrays, I'd need something like.. GL_T2F_C4F_V2F, or even: GL_T2D_C4D_V2D[12:33:42] <Cheery> but it seems, closest match is: GL_T2F_C4F_N3F_V3F[12:34:17] <Cheery> if I'd use this, I'd need to give 4 more floats for each vertex[12:34:42] <Cheery> Is it even reasonable versus just using glxxPointer?[12:36:08] <Jupp3> What you mean with reasonable?[12:36:37] <Jupp3> Those enums just specify, which components they supply, and in which format[12:37:16] <Cheery> Jupp3: it means I'd use 4 more floats per each vertex, versus not interleaving[12:37:35] <Cheery> is the gain big enough it is reasonable to use interleaved arrays in this case?[12:38:18] <Jupp3> Cheery: Well, those enums are probably created based on assumptions of which formats people need the most[12:38:28] <Cheery> we are talking about hundreds of vertices, so it's not an issue anyway, but I'm looking for the answer for my own interest[12:38:34] <Jupp3> Cheery: You can use interleaved arrays without glInterleavedArrays[12:38:46] <Cheery> ?[12:38:49] <Zenja> Cheery: I have never found a need to use gl**Pointer[12:39:36] <Cheery> now this is intriguing, Zenja what have you used instead?[12:39:55] <Cheery> and how can I use interleaved arrays without glInterleavedArrays?[12:40:24] <Jupp3> wtf...[12:40:50] <Jupp3> Cheery: Anyway, I have created a wrapper for it (for OpenGL ES) and here's a snippet which describes how it basically works: http://pastebin.com/d786aeba6[12:40:59] <Jupp3> Managed to paste it quite a bit too many times[12:41:23] <Zenja> Cheery: glInterleavedArray.[12:41:41] <Jupp3> Cheery: Note the stride argument[12:42:01] <Zenja> Cheery: Usually GL_T2F_N2F_C3F[12:42:12] <Jupp3> N2F? :)[12:42:27] <Zenja> Typo. N3F[12:42:36] <Jupp3> Zenja: And I really think you should supply the vertex coordinates aswell :D[12:42:43] *** mastro has joined ##OpenGL[12:42:45] *** Swords has quit IRC[12:42:46] <Zenja> I was just chasing a bug crawling in the kitchen. Partner gave a good scream[12:43:00] <Jupp3> Zenja: It was a feature[12:43:40] <Zenja> Arg[12:43:40] <Zenja> Tonight is not myh night[12:43:40] <Zenja> GL_T2F_N3F_V3F. I'[12:43:40] <Zenja> m off to bed[12:43:40] <Zenja> :)[12:43:41] <Zenja> :))[12:44:27] <Cheery> Jupp3: oh, you've understood it wrong[12:44:42] <Cheery> I'm able to fill out any kind of array I have[12:45:12] *** peda__ has quit IRC[12:45:19] *** peda__ has joined ##OpenGL[12:45:31] <Cheery> I wonder about benefits of just doing it with single glInterleavedArrays versus multiple gl**Pointers[12:45:36] <Jupp3> Cheery: And? I just pasted you a code snippet which describes, how to use interleaved arrays without glInterleavedArrays[12:45:54] <Jupp3> single line of code is less lines of code than multiple lines of code? :P[12:46:07] <Jupp3> => looks more clean[12:46:24] <Cheery> Jupp3: is there benefit if I still use interleaved arrays, but without glInterleavedArrays?[12:47:01] <Jupp3> Cheery: Sometimes it's better for you to have arrays interleaved, sometimes not[12:47:12] <Jupp3> And which is faster... I guess that depends on the implementation[12:47:37] <Cheery> for me?[12:48:39] <Jupp3> Or rather "for the API you write"[12:48:59] <Jupp3> For example comparing two vertices is usually easier with interleaved arrays[12:49:28] <Cheery> well, it gives a nice bundle..[12:49:30] <Jupp3> In my code I use indexed interleaved vertex arrays[12:49:54] <Cheery> also there seem to be benefits from using arrays that interleave[12:49:55] <Zenja> Hey Jupp3 - I ended up discovering the cause of ALL my glNormal problems. You were right. Rotations were screwing things up. I need to investigate why rotations cause glNormal to fail.[12:50:08] <Jupp3> And when adding new vertex, it goes through all vertices this far, and checks if one of them == new one, if it does, add index for that. If not, add vertex & index for it[12:50:23] <Jupp3> Not efficient at all, but the whole thing is something that needs to be rewritten some day[12:50:51] *** mm765 is now known as mm765^away[12:51:12] <Jupp3> Zenja: Well, nice that you found it :)[12:51:36] <Zenja> Hey Jupp, just did a whois on you. I had no idea that you were into alternative OS's. (amiga, morphos).[12:51:47] <Zenja> Jupp3: I myself am a Haiku / BeOS nut.[12:51:55] <Jupp3> heh[12:52:06] <Jupp3> Well of course I have couple of linux systems asweel[12:52:08] <Jupp3> aswell[12:52:10] <Zenja> Sold my Ami back in 1996[12:52:24] <Jupp3> But after coding a day for linux at work, it's nice to use something else at home[12:52:32] <Jupp3> Zenja: Come on, I have used irc even on my C64 :D[12:52:43] *** korff_ has joined ##OpenGL[12:52:55] <Zenja> Jupp3: C64, had one of those, but no accoustic coupling modem :)[12:53:04] <Jupp3> Never quite managed to connect to freenode though[12:53:07] <Jupp3> With telnet client[12:53:24] <Jupp3> Might work if I used some irc client instead, there must be few of them somewhere[12:53:33] <Jupp3> Zenja: Actually I prefer using ethernet :)[12:54:00] *** kenws has joined ##OpenGL[12:54:43] <Cheery> too bad numpy does not support structured arrays[12:54:53] <Cheery> otherwise I could've also used: GL_T2F_C4UB_V3F[12:55:28] <Jupp3> wtf[12:55:40] <Jupp3> Why isn't anyone complaining of me doing == between floats? :D[12:56:03] <Cheery> why anyone should?[12:56:14] <Jupp3> Becouse it works just fine? :)[12:56:17] <Cheery> but hey, why do you do == between arrays of floats?[12:56:41] <Jupp3> Cheery: That's a really good question[12:56:48] <Jupp3> Should just do memory compare instead[12:56:58] <Cheery> I find it interesting you actually do it[12:57:04] <Jupp3> How come?[12:57:24] <Cheery> but yes, maybe more interesting could be < or >[12:57:40] <Cheery> which'd return an array of booleans[12:57:55] <Cheery> um. array of floats[12:58:02] <Cheery> mixed up[12:58:20] <Jupp3> I can't see how that would work[12:58:23] <Jupp3> For what I do[12:58:23] <Cheery> in numpy, if I give do == to arrays, I get an array of booleans[12:59:36] <Ingenu> amusing[12:59:54] <Ingenu> I would rather expect a single boolean telling whether the values are equal[13:00:00] <Ingenu> in both arrays[13:00:09] <Jupp3> Ingenu: Indeed[13:00:21] <Jupp3> Except they are in the same array[13:00:28] <Cheery> I wouldn't[13:00:35] <Cheery> since some of the array may match, while other may not[13:00:53] <Cheery> which is as interesting fact to find out[13:00:54] <Jupp3> Cheery: If they don't, they are supposed to be separate vertices[13:00:56] <Ingenu> well it's like a string comparison[13:01:03] <Jupp3> Same coordinates, different normal, for example[13:01:08] <Ingenu> you don't care which elements are not equal[13:01:17] <Ingenu> you just want to know whether they are identical or not[13:01:18] *** korff has quit IRC[13:01:25] <Ingenu> and strings are just arrays of char so...[13:01:47] <Cheery> which brings out a though, I think they both are a comparison, but the fact that thing to compare is a container, mixes things up[13:01:59] <Ingenu> but yeah sounds like a handy debug feature[13:03:09] <Jupp3> It's just funny when some people go on claiming how you can't do == between floats, and that it doesn't work[13:03:22] <Ingenu> well it doesn't[13:03:28] <Cheery> which goes around an other thing[13:03:31] <Ingenu> yet it does[13:03:37] <Cheery> since string is also a container..[13:03:40] <Jupp3> It's just that one must know HOW it works[13:03:45] <Ingenu> the problem is that you may have some nearly identical[13:03:52] <Jupp3> I don't[13:04:15] <Jupp3> And yes, I know the problem when I do maths with values, which should result in same values[13:04:23] <Ingenu> depends on the algorithm in which you want to compare stuff[13:04:32] <Cheery> it'd be logical to be able to do like: 'abc' + 3 => 'dfg'[13:04:41] <Jupp3> But basically I do stuff like if((float)(5+1)==(float)(6+0))[13:05:06] <Ingenu> I'd say you're not sane :p[13:05:16] <Ingenu> just compare the bloody ints ;p[13:05:31] <Jupp3> Ingenu: As I said, it would need a rewrite :)[13:05:39] <Cheery> rounding errors make it hard to determine whether two floats are equal[13:06:03] <Ingenu> yes[13:06:10] <Jupp3> Ingenu: It's basically "a wrapper around display lists with glBegin, glVertex3f etc. which creates vertex arrays instead"[13:06:30] <Ingenu> oh[13:06:31] *** gotan666 has quit IRC[13:06:42] <Jupp3> And if I did comparison on ints, it would change the API a lot[13:07:37] <Ingenu> got it[13:07:40] *** gus4n0 has quit IRC[13:07:55] <Jupp3> Well it's not a wrapper really... But it has function AddC4FN3FV3FVertex()[13:08:15] <Jupp3> Which of course changed other parts of the code :D[13:08:42] <Ingenu> well I do things differently[13:08:48] <Ingenu> I have descriptors and data[13:08:51] <Ingenu> and it works perfect[13:09:00] <Ingenu> and I also have API abstraction layer[13:09:06] <Ingenu> which needs a bit more work but works just fine[13:09:19] <Jupp3> But the point is, with such comparisons (maths done while ints) shouldn't have problems with rounding inaccuracy[13:09:44] <Jupp3> And of course for normals, it's mostly 1.0f, 0.0f, 0.0f -like hardcoded values[13:10:07] <Jupp3> Basically it's a 2D game, where each block is 1.0f wide and high[13:10:20] <Jupp3> (So that's where the +1 comes from)[13:10:29] *** fargiolas has joined ##OpenGL[13:11:07] *** Ademan has joined ##OpenGL[13:11:15] <Jupp3> But anyway, the point is, those are two of the "special cases" where == comparison between floats works just fine[13:11:32] <Jupp3> And even if it doesn't - it just adds new vertex and index instead. No visual difference[13:12:11] <Ingenu> you're not working on huge datasets[13:12:12] <Ingenu> ;p[13:12:48] <Jupp3> Well I can get debug info on how many duplicates were found, and it feels close enough to what I'd expect[13:18:01] <Zenja> Jupp3: Bingo. I finally figured out the root problem.[13:18:21] <Zenja> Jupp3: When specifying light position, it should be done immediately after camera transformation.[13:18:33] <Zenja> Before any model/view transformation takes place.[13:18:46] <Zenja> Since then glNormals end up being completely screwed.[13:19:06] <Zenja> I have to change my rendering engine to FIRST draw light, then all model/view transformations.[13:19:53] <Jupp3> It's not the normals that got screwed[13:20:00] <Jupp3> But light position in relation to vertices[13:20:03] <Jupp3> Or that's how it sounds[13:20:41] <Jupp3> And when you specify a "wrong" normal, which points to the light source instead of where you expect the light to be, the vertex appears to be properly shaded[13:20:43] <Zenja> The problem I had was that I had u SUN object, with rotation. I would apply this transformation, then set the light position. Then I'd draw a yellow sphere representing light.[13:21:19] <Jupp3> Zenja: I'd use a directional light source for sun[13:21:24] <Zenja> Now I have 2 options. In my engine, handle lights immediately after camera transform, before any models drawn.[13:21:36] <Zenja> Jupp3: I'm testing a fireball.[13:21:41] <Zenja> Ships, cannons, fire[13:21:49] <Zenja> Oh my[13:21:50] *** Suprano has quit IRC[13:22:02] <Zenja> The fireball didn't light up the ship properly[13:22:06] <Jupp3> Of course the thing is, sometimes you might want lights to be attached to some objects[13:22:23] <Jupp3> Which you could do of course[13:22:36] <Zenja> Yes, thats why I'm thinking of forcing lights to be positioned before any transforms.[13:22:41] <Jupp3> Add null object type (which isn't drawn at all) which can be used for "invisible" lights[13:23:24] <Zenja> I have the concept of a 'Animator', which is called before any geometry is rendered. Animator can allow transforms. Guess what I did with fireball.[13:23:44] <Jupp3> you failed miserably? :)[13:24:23] <Zenja> The fireball transform screwed up the light position. I was focusing on setting the normals instead of investigating why the light was coming from the wrong place.[13:28:08] <Zenja> Heh heh. I was just looking at the source code for the Irrlicht engine. Guess what it does.[13:28:17] <Zenja> I first sets the cameras, then draws all lights.[13:29:23] <Zenja> Then it does skyboxes, followed by all objects, followed by shadow, transparent objects and finishes with shaders.[13:29:53] <Zenja> So I guess that this is one of the gotcha-s which people stumble upon.[13:31:36] <Zenja> This means that my engine will have to treat cameras and lights seperately from other nodes.[13:35:23] *** Suprano has joined ##OpenGL[13:39:44] *** korff has joined ##OpenGL[13:43:14] *** Zenja has left ##OpenGL[13:45:52] *** korff_ has quit IRC[13:50:50] *** Suprano has quit IRC[13:51:00] *** marenz_ has joined ##OpenGL[13:53:11] *** cami has joined ##OpenGL[14:00:36] *** NevroPus has quit IRC[14:02:44] *** marenz_ has quit IRC[14:02:51] *** dv__ has joined ##opengl[14:02:58] *** marenz__ has joined ##OpenGL[14:24:39] *** nayena has joined ##OpenGL[14:28:00] *** blight_ has joined ##opengl[14:29:44] *** Jup4 has joined ##OpenGL[14:29:45] *** Jupp3 has quit IRC[14:29:59] *** Jup4 is now known as Jupp3[14:33:23] *** gotan666 has joined ##OpenGL[14:36:30] *** blight_ has quit IRC[14:41:46] *** LordMetroid has joined ##OpenGL[14:48:31] *** marenz__ has quit IRC[14:49:01] *** nplus has quit IRC[14:53:45] *** gotan666 has quit IRC[14:59:57] *** Suprano has joined ##OpenGL[15:06:21] *** rutski has quit IRC[15:06:26] *** hibread has joined ##opengl[15:09:55] *** rutski has joined ##OpenGL[15:11:00] *** cdleonar1 has joined ##OpenGL[15:11:04] *** cdleonar1 has left ##OpenGL[15:17:34] *** LordMetroid has quit IRC[15:19:00] *** mm765^away is now known as mm765[15:26:04] *** rsp has joined ##opengl[15:26:24] <rsp> Hi[15:27:19] <hibread> rsp: how'd the soccer (football) game go with stick and ball?[15:28:39] <rsp> What xD[15:28:54] *** nathan_ has quit IRC[15:29:01] <rsp> If you mean the hockey, Russia won :) good game[15:29:11] <Jupp3> There's no ball in hockey[15:29:13] <hibread> yep cool[15:29:30] <hibread> Jupp3: what do you call it? round puck?[15:29:39] <Jupp3> Well at least not ball :)[15:29:44] <Jupp3> How about hockey? :P[15:29:47] <hibread> Jupp3: its a fucking ball ! :)[15:30:11] *** feanor_old has joined ##OpenGL[15:31:51] <hibread> Jupp3: http://images.google.com.au/images?hl=en&q=hockey+ball&um=1&ie=UTF-8 i reall hope you're trying to pull my leg[15:31:55][15:32:58] <rsp> hibread: lol[15:33:26] <rsp> feanor_old: ??? ??? ? ??++ TNT2 ??? ++?? ? glxinfo[15:33:58] <feanor_old> what?[15:34:20] <rsp> You tell me[15:34:38] <Jupp3> hibread: Well that's not really ice hockey[15:35:02] <hibread> Jupp3: who ever said "ice" hockey?[15:35:08] <feanor_old> i'm noob, i got aqainted wirh linux 2 days ago. Sorry my english[15:36:29] <feanor_old> the matter is that my ubuntu-linux is workibg too slow, i dont know what to do[15:36:40] <Jupp3> Well rsp did :)[15:36:47] <rsp> feanor_old: You are in ##opengl ffs[15:36:54] <rsp> #ubuntu[15:37:11] <hibread> Jupp3: russians dont play "field" hockey?[15:37:28] <Jupp3> hibread: Well they probably play all kinds of sports[15:37:47] *** feanor_old has left ##OpenGL[15:37:48] <Jupp3> hibread: rsp said hockey, to which I replied that there's no ball in hockey[15:38:04] <hibread> well you'd be wrong[15:38:05] <rsp> puck[15:38:10] <Jupp3> hibread: Anyway, I think this is it in english: http://en.wikipedia.org/wiki/Bandy[15:38:11] <hibread> there is no ball in ice hockey[15:38:22] <Jupp3> "ice ball"[15:38:25] <rsp> ##opengl-puckvsball[15:40:20] *** gotan666 has joined ##OpenGL[15:40:29] <Jupp3> rsp: This is about basic geometric shapes :)[15:40:45] <Jupp3> rsp: How about "closed cylinder"? :P[15:40:49] <rsp> Rolf[15:41:06] <rsp> good one xD[15:41:57] <Jupp3> or "extruded disc"[15:42:19] *** gotan666 has quit IRC[15:43:55] <hibread> Jupp3: you're talking about the ice hockey puck now?[15:47:03] <Jupp3> Well the difference in general[15:47:49] <Jupp3> Ball is subdivided icosahedron[15:51:30] *** gotan666 has joined ##OpenGL[15:54:49] *** rn1 has joined ##opengl[15:57:28] *** nayena has quit IRC[15:57:52] <pekuja> ermn, no it's not, a ball is a sphere[15:58:07] <pekuja> I mean ok I guess you can approximate a ball with an icosahedron[15:58:19] <pekuja> but you could also approximate it with a cube or a pyramid[15:58:36] <pekuja> those would be bad approximations, of course[16:00:32] *** dispraekailo- has joined ##OpenGL[16:00:41] *** geocalc has quit IRC[16:01:11] *** geocalc has joined ##opengl[16:03:36] *** rn1 has quit IRC[16:06:30] <rsp> hibread: I'm gonna do it the hard way[16:09:48] <hibread> rsp: those models don't seem to have normal data[16:10:12] <rsp> no[16:10:16] <hibread> unless you plan to create them yourself[16:10:24] <rsp> Do I need to have that when I use shader lightning[16:10:36] <hibread> most definitely[16:10:41] <rsp> Ok[16:10:51] <hibread> the normal describes the direction the surface is facing[16:10:55] <rsp> Well those models don't have normals[16:11:31] <rsp> My code loads normals already if they are available afaik[16:11:36] *** korff has quit IRC[16:11:46] <rsp> At least the version I got here[16:12:07] <hibread> if you want your whole scene to be lit, you'll need normals for everything[16:12:17] *** gusano has joined ##OpenGL[16:12:19] *** prophile has joined ##opengl[16:12:21] *** justjohn has joined ##OpenGL[16:12:24] <rsp> =)[16:12:35] <hibread> did you export the .obj files yourself?[16:12:46] <rsp> 3ds to obj with Blender[16:13:06] <rsp> Arn't there any good reference models floating around[16:13:08] <hibread> are there any options on what to output?[16:15:10] <rsp> I now have normals on the fugly goat[16:15:25] *** rnx has joined ##opengl[16:15:48] *** dispraekailo has quit IRC[16:19:53] <rsp> hibread: Could you tell me what I exactly need in detail to be able to render with correct tex coords in the way that I can use the indices[16:20:05] <rsp> And I'll implement it[16:23:49] *** rutski has quit IRC[16:23:58] *** nplus has joined ##OpenGL[16:25:58] *** aalex has joined ##OpenGL[16:30:18] *** aalex_ has joined ##OpenGL[16:30:53] *** aalex has quit IRC[16:31:55] *** tmccrary has joined ##OpenGL[16:34:42] *** bolides has joined ##OpenGL[16:37:52] <hibread> rsp: thats quite some task even to explain :) I'm heading off right now, you'll have to catch me anothe time. For now all i can suggest is to think about what data you have now, and what the data should look like after the process is complete. The first thing to understand is that you have one index list. Each element of that index list references a single vertex with its associated data (vertex pos, texcoords, normal, etc). So ultimately all you're[16:37:53] <hibread> really doing is sorting the data to create the smallest set of "unique" vertices (which means the texture coords and normals etc included) duplicating the vertex entry if the texture coord data differs, or the normal data differs. Good luck[16:41:10] *** Lacerta has quit IRC[16:41:10] <rsp> Thanks I'll try soon[16:41:28] *** nplus has quit IRC[16:44:59] *** nplus has joined ##OpenGL[16:45:15] *** replor has joined ##OpenGL[16:46:10] *** hibread has quit IRC[16:46:25] *** scy has joined ##opengl[16:54:31] *** nplus has quit IRC[16:55:11] *** lolage0 has joined ##OpenGL[16:57:44] *** nplus has joined ##OpenGL[17:14:42] *** bolides has quit IRC[17:21:15] *** Vixus has joined ##OpenGL[17:22:25] <Vixus> Hi, I've set up an projection matrix with gluOrtho2D(0,500,0,500), and positioned my camera at 0,0,0 looking down 0,0,1 with 0,1,0 being up.[17:23:06] <Vixus> but when i draw a quad 0,0 ; 400,0 ; 400,200 ; 0,200 nothing appears.[17:24:55] <Vixus> oh, glViewport uses the usual 0,0 for origin.. I guess I'm just having trouble visualising the space?[17:29:25] <Vixus> pb: http://cpp.ninjacodemonkeys.org/4254[17:30:33] *** kenws has quit IRC[17:33:56] *** andikr has quit IRC[17:40:09] <Jupp3> Vixus: What's the 3rd coordinate for quad? Don't say it's 0[17:40:13] <Jupp3> As then it might be clipped[17:41:44] <Vixus> 0.5[17:43:22] <Jupp3> Vixus: Why are you using gluLookAt with gluOrtho2D anyway?[17:43:25] <Jupp3> Or I assume you arte[17:43:26] <Jupp3> are[17:43:44] <Vixus> Ah, should I not be?[17:44:27] <Jupp3> Vixus: Well I can't see any reason why you would get any benefit from doing so[17:44:53] <Jupp3> You know, that OpenGL doesn't have movable camera[17:45:06] <Jupp3> Basically camera is always at origo, pointing at same old direction[17:45:09] <Vixus> yep[17:45:14] <Jupp3> Then you just move your objects in relation to the camera[17:45:15] <Vixus> everything else is moved instead[17:45:18] *** sohail has joined ##OpenGL[17:45:31] <Jupp3> BUT there are functions, such as gluLookAt which fake a movable camera for you[17:45:38] <tmccrary> No, opengl's "camera" is just the current modelview[17:46:04] <tmccrary> You modify that, THEN do all your object placement[17:47:07] <Vixus> anyway removing gluLookAt has fixed it..[17:47:32] <Vixus> i'll try and figure out why exactly[17:47:40] <tmccrary> but you can multiple the model view matrix by the inverse of the camera position[17:48:16] <Jupp3> Vixus: I'd rather try to figure out why exactly you need gluLookAt with gluOrtho2D :)[17:49:01] *** lgbr has left ##OpenGL[17:49:08] <Vixus> but you see, I couldn't imagine why you didn't..[17:49:47] <Jupp3> Vixus: Becouse the "camera" is already looking at a perfectly fine direction as-it-is with identity matrix?[17:50:20] <Vixus> right[17:50:52] <Jupp3> I'd call it "the unnecessary extra step"[17:51:04] <Jupp3> Although of course you might need it for other reasons[18:00:44] *** gotan666 has quit IRC[18:01:10] <Vixus> what if I want the rendering to scale with the window size rather than be independent?[18:07:33] *** Castigador has quit IRC[18:08:03] <justjohn> I am a beginner OpenGL user working on scientific visualization (Python/PyOpenGL). The thing I am dealing with right now is how to address simultaneous micro/macro contexts. That is, the 3D environment I want to create has both earth-scale (6,000,000m radius) and centimeter-scale objects. I guess the first question is whether OpenGL has the numeric precision to even do that, and the second is, does anyone have a reference to or explanation o[18:08:33] <dv__> well in the orbit your objects will visibly jump[18:08:43] <dv__> so forget about absolute frame of references[18:08:48] <dv__> frames of reference that is[18:08:59] *** [AD]Turbo is now known as TurboAWAY[18:09:04] <justjohn> ok[18:09:08] <dv__> what people usually do is subdivision of space in hierarchical cells[18:09:14] *** TurboAWAY has quit IRC[18:09:21] <dv__> this hierarchy has fixed spatial extents[18:09:34] <dv__> and your floating point coords are relative to a leaf cell[18:09:57] <dv__> your coordinate vector is: fp values + indices for the hierarchy[18:10:14] <dv__> its more work to deal with such a space,[18:10:15] <justjohn> hmm[18:10:19] <dv__> but there is little else you can do[18:10:42] <dv__> this way you can have theoretically infinite extents however .... you just deepen the tree[18:11:14] <dv__> but, well, beyond a solar system there is little point in one continuous space :)[18:11:17] <justjohn> Do you have a textbook/web tutorial reference for this kind of tree[18:11:25] <dv__> standard subdivision[18:11:27] <justjohn> heh, no kidding[18:11:36] <dv__> I'd use a simple octree[18:11:51] <dv__> or if there is really a lot of detail I'd look up R trees[18:12:19] <justjohn> To be honest, I could use a lot more detail, but I was hoping for a simple solution with cm-level objects.[18:12:22] <dv__> *moving* objects are a problem[18:12:45] <dv__> I see no easy solution for these[18:13:06] <dv__> ah, but: search for tutorials on procedural planets/universes/galaxies[18:13:11] <justjohn> So, just so I have more theoretical foundation, what is it that is limiting the OpenGL engine from displaying very 'small' objects when larger objects exist in the current space?[18:13:15] <dv__> some of them deal with scales in detail[18:13:30] <dv__> mostly the floating point precision[18:13:37] *** nplus has quit IRC[18:13:38] <justjohn> i see[18:13:48] <dv__> 32bit fp is really bad for these scales[18:13:54] <justjohn> yeah[18:14:03] <justjohn> any 64bit opengl on the horizon? :)[18:14:04] <dv__> even 64bit will only get you so far[18:14:07] <dv__> no[18:14:16] <justjohn> Well, 64 bit would cover me for sure in this situation[18:14:21] <justjohn> alright[18:14:26] <dv__> well,[18:14:28] <justjohn> Well, thanks for the help, I'm off to research[18:14:34] <dv__> you could write your renderer in CUDA[18:14:45] <dv__> and wait for the 64bit support in CUDA (which WILL come)[18:14:54] <justjohn> hmm,I'll look into it[18:15:06] <dv__> reason: a graphics api like opengl doesnt really need 64bit vertex data,[18:15:09] <dv__> (or constants)[18:15:23] <dv__> while a GPGPU API like CUDA does, because you might want to do some numerical computing with it[18:15:33] <dv__> or, some simulations[18:15:37] <dv__> and there 64bit is the norm[18:15:43] *** PainBank has joined ##OpenGL[18:16:02] <dv__> cuda also guarantees some precision in its programs,[18:16:07] <dv__> while gl shaders dont[18:16:46] <justjohn> hmmm[18:17:03] <justjohn> actually, you've got me interested, I will definitely check it out[18:17:23] <dv__> oh but NOTE:[18:17:26] <dv__> cuda is nvidia only[18:17:34] <dv__> for ati/amd, there is CTM - and its totally incompatible[18:17:47] <dv__> unfortunately, there is little hope for one vendor independent GPGPU API[18:18:12] *** Yustme has joined ##opengl[18:18:18] <dv__> and intel will also arrive with god knows what.[18:18:34] <dv__> thats the downside :)[18:18:39] <dv__> still, its worth it.[18:18:44] <dv__> so go for it.[18:20:16] *** BahamutZERO has quit IRC[18:24:13] *** Vixus has quit IRC[18:43:45] *** HuntsMan has joined ##opengl[18:44:05] *** Ingenu has quit IRC[18:51:28] *** dv__ has quit IRC[18:56:56] *** geocalc has quit IRC[18:57:44] *** geocalc has joined ##opengl[18:57:56] *** abionnnn has joined ##OpenGL[19:03:35] * abionnnn spends an hour turning a gear into a triangle strip[19:08:39] *** DobosCake has joined ##OpenGL[19:11:00] *** abionnnn has quit IRC[19:15:03] *** gotan666 has joined ##OpenGL[19:19:33] *** neoneurone has joined ##OpenGL[19:29:27] *** groton has quit IRC[19:43:18] *** gotan666 has quit IRC[19:45:47] *** ViRUS has joined ##opengl[19:47:28] *** cami has quit IRC[19:49:10] *** andikr has joined ##opengl[19:49:47] *** HuntsMan has quit IRC[19:57:08] *** fargiolas is now known as fargiolas|afk[19:57:26] *** fargiolas has joined ##OpenGL[19:57:43] *** fargiolas is now known as fargiolas|afk[20:20:15] *** juanmabc has joined ##opengl[20:21:06] *** fabz0r64 has joined ##OpenGL[20:24:10] *** aalex_ is now known as aalex[20:26:35] *** PainBank has left ##OpenGL[20:28:18] *** juanmabc_ has joined ##opengl[20:28:52] *** juanmabc has quit IRC[20:28:59] *** juanmabc_ is now known as juanmabc[20:31:13] *** fabz0r64 has left ##OpenGL[20:33:33] *** replor has quit IRC[20:35:00] *** Xmas| has joined ##OpenGL[20:47:32] *** Xmas| has quit IRC[20:47:50] *** Xmas| has joined ##OpenGL[20:49:14] *** speedy1 has joined ##OpenGL[20:50:48] *** blbmp has joined ##OpenGL[20:53:15] *** ata2 has joined ##OpenGL[20:55:56] *** ViRUS has quit IRC[20:57:05] *** ViRUS has joined ##opengl[20:57:37] *** neoneye has quit IRC[21:00:26] *** cami has joined ##OpenGL[21:05:00] *** Lucine has quit IRC[21:05:12] *** cami has quit IRC[21:21:29] *** m4ggus has joined ##OpenGL[21:24:02] *** andikr has quit IRC[21:29:06] *** gotan666 has joined ##OpenGL[21:41:50] *** ginoman has joined ##OpenGL[21:45:28] *** gotan666 has quit IRC[21:49:48] *** groton has joined ##OpenGL[21:55:30] *** Jupp3 has quit IRC[22:02:56] *** mattn2|home has joined ##OpenGL[22:11:05] *** nplus has joined ##OpenGL[22:19:34] *** Vixus has joined ##OpenGL[22:21:01] <Vixus> Hey, what's the best way to make my rendering scale with the window size?[22:23:02] <Vixus> I just can't seem to find anything on the subject and various example programs do it differently.[22:23:56] *** charlie_zzz has quit IRC[22:26:00] <Vixus> mostly there's a reshape function attached to the window resize callback[22:27:32] *** nplus has quit IRC[22:35:23] *** amalon has joined ##opengl[22:52:28] *** Suprano has quit IRC[22:53:05] *** Suprano has joined ##OpenGL[22:53:14] *** Cheery has quit IRC[23:12:38] *** ViRUS has quit IRC[23:18:25] *** Poussino has joined ##OpenGL[23:19:09] *** Poussino has quit IRC[23:20:13] <neric> I don't understand Vixus[23:20:27] <neric> resize windows => resize the viewport ?[23:20:36] <neric> what do you want to scale ?[23:20:51] <Vixus> yeah the viewport.[23:20:54] *** Yustme has quit IRC[23:21:12] <ville> well call glViewport?[23:22:21] <Vixus> will giving it fixed dimensions work?[23:22:48] *** tmccrary has quit IRC[23:23:05] <neric> it depends what effect you want ..[23:23:53] <Vixus> ok, say I have a quad 640x480.. i want it to fill the entire window width no matter what size the window is..[23:24:14] <neric> so, use the viewport[23:24:24] <neric> not a really scale (glScale)[23:25:01] <Vixus> yes, I just need to scale output.. would I need to use the window resize callback?[23:25:51] <neric> "scale output" ?[23:26:11] <neric> and yes, use the window size for the viewport[23:26:17] <MatthiasM> Vixus: learn what the viewport is and read the redbook[23:26:52] <Vixus> will do[23:26:56] *** fargiolas|afk is now known as fargiolak[23:27:01] *** fargiolak is now known as fargiolas[23:32:56] *** fargiolas has quit IRC[23:33:58] *** juanmabc has quit IRC[23:35:00] *** amalon_ has joined ##opengl[23:36:03] *** BahamutZERO has joined ##OpenGL[23:36:45] *** Xmas| has quit IRC[23:42:06] *** Vixus has quit IRC[23:47:12] *** bolides has joined ##OpenGL[23:48:39] *** amalon has quit IRC[23:48:40] *** BadChoice has joined ##OpenGL[23:48:46] <BadChoice> Hi![23:49:29] <BadChoice> what do you think about:[23:49:30] <BadChoice> http://youtube.com/watch?v=fo09GRwbokU[23:49:34] <BadChoice> it's a quicklook for linux[23:50:11] <BadChoice> I have it in a very good way[23:52:17] *** mm765 is now known as mm765^sleep[23:52:53] *** scy has left ##opengl[23:58:34] *** groton has quit IRC[23:59:41] <rsp> Just get a bigger screen BadChoice[23:59:43] <rsp> lol