May 22, 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 22, 2008 [00:07:49] *** elite01_ has joined ##opengl[00:07:56] *** huperniketes has quit IRC[00:08:21] *** huperniketes has joined ##OpenGL[00:11:34] *** BahamutZERO_ has joined ##OpenGL[00:13:15] *** BahamutZERO has quit IRC[00:13:33] *** Walt has joined ##opengl[00:14:09] *** bbeausej has quit IRC[00:15:32] *** BahamutZERO_ is now known as BahamutZERO[00:24:57] *** elite01 has quit IRC[00:27:17] *** clintar_ has quit IRC[00:27:32] *** elite01_ has quit IRC[00:27:44] *** elite01_ has joined ##opengl[00:28:33] *** groton_ has quit IRC[00:28:40] *** elite01__ has joined ##opengl[00:31:38] *** elite01 has joined ##opengl[00:38:09] *** catadoxas has joined ##OpenGL[00:46:07] *** elite01_ has quit IRC[00:47:00] <catadoxas> how do you make sure you have enough particles with particle systems? Might be a stupid question but lets say you allocate 3000 particles and your effect uses 500. so if I have the effect 6 times at once I have a problem? or should I just dynamically allocate particles in such a case?[00:47:41] <speedy1> usualy each system has it's upper boundary of particles[00:48:43] *** elite01__ has quit IRC[00:48:44] <speedy1> and you can dynamically allocate or preallocate a few systems more[00:51:27] *** elite01 has quit IRC[00:54:12] *** rutski has quit IRC[00:58:43] *** juanmabc has quit IRC[01:03:51] *** rnx has quit IRC[01:03:52] *** Lucine2 has quit IRC[01:03:55] *** keitsi has quit IRC[01:05:31] *** keitsi has joined ##OpenGL[01:05:31] *** rnx has joined ##OpenGL[01:05:31] *** Lucine2 has joined ##OpenGL[01:22:01] *** ginoman has joined ##OpenGL[01:24:07] *** speedy1 has quit IRC[01:25:34] *** neoneye has quit IRC[01:30:16] *** rnx has quit IRC[01:30:17] *** Lucine2 has quit IRC[01:30:20] *** keitsi has quit IRC[01:31:17] *** amz has joined ##opengl[01:35:18] *** keitsi has joined ##OpenGL[01:35:18] *** rnx has joined ##OpenGL[01:35:18] *** Lucine2 has joined ##OpenGL[01:35:25] *** MatthiasM has quit IRC[01:35:30] *** MatthiasM has joined ##opengl[01:35:35] *** odietsch has quit IRC[01:36:35] *** Xmas| has quit IRC[01:37:48] *** amz has quit IRC[01:42:50] *** dvoid has quit IRC[01:44:10] *** speedy1 has joined ##OpenGL[01:45:39] *** SilverWolf has quit IRC[01:53:49] *** amz has joined ##opengl[02:02:12] *** Arc_ has joined ##OpenGL[02:09:19] *** Dew420 has quit IRC[02:11:02] *** catadoxas has quit IRC[02:15:05] *** mastro has joined ##OpenGL[02:18:13] *** Dew420 has joined ##OpenGL[02:19:58] *** LordMetroid has joined ##OpenGL[02:22:26] *** KU0N has quit IRC[02:36:02] *** elite01 has joined ##opengl[02:37:45] *** Satan_Inside has quit IRC[02:38:16] *** RTFM_FTW has joined ##OpenGL[02:49:07] *** ginoman has quit IRC[02:53:44] *** Suprano has quit IRC[03:02:54] *** elite01 has quit IRC[03:11:54] *** ginoman has joined ##OpenGL[03:18:36] *** rnx has left ##opengl[03:20:15] *** dispraekailo- has quit IRC[03:20:39] *** dispraekailo has joined ##OpenGL[03:20:58] *** Amorphous has quit IRC[03:22:16] *** Amorphous has joined ##opengl[03:25:35] *** bolides has quit IRC[03:27:27] *** amalon has quit IRC[03:43:53] *** NeoThermic_II has joined ##OpenGL[03:53:51] *** NeoThermic has quit IRC[03:56:35] *** NeoThermic_II is now known as NeoThermic[03:57:18] *** ginoman has left ##OpenGL[03:57:57] *** LordMetroid has quit IRC[04:18:49] *** PainBank has joined ##OpenGL[04:21:00] *** hibread has joined ##opengl[04:30:12] *** TheLorax has joined ##opengl[04:32:02] *** Walt has quit IRC[04:36:01] *** lepidus__ has quit IRC[04:37:32] *** lepidus has quit IRC[04:37:32] *** lepidus_ has quit IRC[04:38:34] *** replor has quit IRC[04:44:11] *** kiras has quit IRC[04:49:52] *** Dew420 has quit IRC[04:52:01] *** ajww has joined ##OpenGL[05:01:12] *** m4ggus has quit IRC[05:01:17] *** m4ggus_ has joined ##opengl[05:01:19] *** m4ggus_ is now known as m4ggus[05:01:32] *** speedy1 has quit IRC[05:04:40] *** dispraekailo has quit IRC[05:04:41] *** mastro has quit IRC[05:04:42] *** Lucine2 has quit IRC[05:04:43] *** keitsi has quit IRC[05:04:44] *** druggy_ has quit IRC[05:04:47] *** brutopia has quit IRC[05:04:48] *** Killari has quit IRC[05:04:48] *** hibread has quit IRC[05:04:50] *** magnet_ has quit IRC[05:04:50] *** sohail has quit IRC[05:04:51] *** lolage0 has quit IRC[05:04:51] *** DragonRift has quit IRC[05:04:52] *** Lucine has quit IRC[05:04:52] *** bobbens has quit IRC[05:04:53] *** smiler has quit IRC[05:04:54] *** cupe has quit IRC[05:05:00] *** hibread has joined ##OpenGL[05:05:00] *** dispraekailo has joined ##OpenGL[05:05:00] *** mastro has joined ##OpenGL[05:05:00] *** cupe has joined ##OpenGL[05:05:00] *** smiler has joined ##OpenGL[05:05:00] *** brutopia has joined ##OpenGL[05:05:00] *** Killari has joined ##OpenGL[05:05:00] *** bobbens has joined ##OpenGL[05:05:00] *** Lucine has joined ##OpenGL[05:05:00] *** DragonRift has joined ##OpenGL[05:05:01] *** lolage0 has joined ##OpenGL[05:05:02] *** sohail has joined ##OpenGL[05:05:02] *** magnet_ has joined ##OpenGL[05:05:02] *** keitsi has joined ##OpenGL[05:05:02] *** Lucine2 has joined ##OpenGL[05:05:59] *** magnet has joined ##OpenGL[05:07:44] *** brutopia has quit IRC[05:07:45] *** Killari has quit IRC[05:07:46] *** smiler has quit IRC[05:07:46] *** cupe has quit IRC[05:07:46] *** sohail has quit IRC[05:07:47] *** lolage0 has quit IRC[05:07:48] *** Lucine has quit IRC[05:07:49] *** magnet_ has quit IRC[05:07:52] *** DragonRift has quit IRC[05:07:52] *** hibread has quit IRC[05:07:52] *** bobbens has quit IRC[05:07:55] *** Lucine2 has quit IRC[05:07:57] *** keitsi has quit IRC[05:07:57] *** dispraekailo has quit IRC[05:07:57] *** mastro has quit IRC[05:14:28] *** charlie_zzz is now known as charlie5[05:14:46] *** PainBank has quit IRC[05:16:05] *** mm765 is now known as mm765^sleep[05:19:30] *** sohail has joined ##OpenGL[05:26:49] *** grumbel has quit IRC[05:29:39] *** dispraekailo has joined ##OpenGL[05:29:39] *** mastro has joined ##OpenGL[05:29:39] *** keitsi has joined ##OpenGL[05:29:39] *** Lucine2 has joined ##OpenGL[05:53:52] *** neunon has joined ##OpenGL[05:58:20] *** ginoman has joined ##OpenGL[06:00:25] *** m4ggus has quit IRC[06:03:12] *** X-Scale has left ##OpenGL[06:03:56] *** peda__ has quit IRC[06:04:04] *** peda__ has joined ##OpenGL[06:13:34] *** amz has quit IRC[06:20:22] *** HuntsMan has quit IRC[06:28:09] *** lolage0 has joined ##OpenGL[06:28:09] *** DragonRift has joined ##OpenGL[06:28:09] *** Lucine has joined ##OpenGL[06:28:09] *** bobbens has joined ##OpenGL[06:28:09] *** Killari has joined ##OpenGL[06:28:09] *** brutopia has joined ##OpenGL[06:28:09] *** smiler has joined ##OpenGL[06:28:09] *** cupe has joined ##OpenGL[06:28:17] *** druggy_ has joined ##OpenGL[06:41:54] *** SirRaceAlot has joined ##OpenGL[06:42:04] *** SirRace has quit IRC[06:53:05] *** druggy_ has quit IRC[06:53:10] *** brutopia has quit IRC[06:53:11] *** Killari has quit IRC[06:53:13] *** SirRaceAlot has quit IRC[06:53:13] *** cupe has quit IRC[06:53:13] *** smiler has quit IRC[06:53:14] *** DragonRift has quit IRC[06:53:15] *** lolage0 has quit IRC[06:53:17] *** Lucine has quit IRC[06:53:18] *** bobbens has quit IRC[06:53:36] *** druggy_ has joined ##OpenGL[06:53:36] *** SirRaceAlot has joined ##OpenGL[06:53:36] *** lolage0 has joined ##OpenGL[06:53:36] *** DragonRift has joined ##OpenGL[06:53:36] *** Lucine has joined ##OpenGL[06:53:36] *** bobbens has joined ##OpenGL[06:53:36] *** Killari has joined ##OpenGL[06:53:36] *** brutopia has joined ##OpenGL[06:53:36] *** smiler has joined ##OpenGL[06:53:36] *** cupe has joined ##OpenGL[06:59:39] *** HuntsMan has joined ##opengl[07:00:27] *** mm^away has joined ##opengl[07:05:12] *** BahamutZERO has quit IRC[07:17:41] *** mm765^sleep has quit IRC[07:19:05] *** sohail has quit IRC[07:21:21] *** |t4bz| has quit IRC[07:21:50] *** t4bz has joined ##OpenGL[07:30:29] *** neunon has quit IRC[07:30:37] *** mattn_ has joined ##OpenGL[07:31:31] *** Tenac has joined ##OpenGL[07:32:10] <Tenac> Is there a 3D model file that supports bone animation, texturing with normal + bump maps, vertex texturing, keyframe animation, and all of that? I know of a lot of file formats like 3ds, obj, ms3d, and others, but none support everything I need. What would be the best thing for me to use/do? btw I do know how to load the models.[07:35:20] <HuntsMan> vertex texturing isn't a feature needed for 3D model format[07:35:41] <HuntsMan> doesn't make sense :)[07:36:18] *** Jupp3 has quit IRC[07:37:29] <Tenac> HuntsMan, well if i subrtracted that off the list, what would be my best bet to use/do?[07:38:07] <HuntsMan> collada maybe?[07:38:57] *** Lucine2 has quit IRC[07:38:59] *** dispraekailo has quit IRC[07:38:59] *** mastro has quit IRC[07:38:59] *** keitsi has quit IRC[07:39:45] *** neunon has joined ##OpenGL[07:41:04] <HuntsMan> or best, your own format (TM)[07:43:16] *** TheLorax has quit IRC[07:45:43] <Tenac> HuntsMan, I made my own format using MAXscript in 3ds max but it only exports the basics, I might make it more advanced but I'd love ana alreayd existing file format that has what I need[07:45:52] <Tenac> I'm looking into collada atm to see[07:45:56] <quicksilver> I was asking a very similar question yesterday[07:46:06] <quicksilver> and people told me to make my own format (TM)[07:46:12] <quicksilver> I was surprised by the answer too :)[07:46:28] <Tenac> Well, barely any 3d file formats support bone animation alone[07:46:58] *** mattn2|home has quit IRC[07:47:16] <Tenac> I might improve my MAXscript exported later[07:47:37] <quicksilver> do you need bone animation in your actual program, though?[07:47:45] <quicksilver> if you design your animations using bones in your modeller[07:48:00] <quicksilver> then the client program rendering the animation doesn't necessariy need to understand the bone model[07:48:31] <quicksilver> Only if you're going to do tricks like dynamic ragdoll effects I would have thought.[07:49:09] <Tenac> but without the bones, doesn't that mean it needs to store to location of every single vertex at every single frame rather than just changign a single "bone" and moving the vertexes with it[07:49:37] <quicksilver> Yes, it does[07:49:45] <quicksilver> the advantage is less calculation at render time[07:49:57] <quicksilver> and vertex data is relatively compact in memory compare to other stuff[07:50:08] <quicksilver> (depending how many vertices you have!)[07:52:55] <Tenac> I'd prefer to go with "bones" I think, however I have knows of your method, I just don't think I want to waste all the memory and have such big 3d model files. I'm going to look into it a bit more though, I think I found a .MD5 MAXscript exporter a while ago that I can take apart and use.[07:54:01] <servus> Vertex keyframe animation prevents real-time interpolation of animations as well as dynamic kinematics. You can perform the bone-vertex calculations in real time quite easily with a few tricks.[07:54:09] <quicksilver> I'm not an expert, I was interested to discuss that's all :)[07:54:27] <quicksilver> servus: surely you can interpolate between vertex keyframes?[07:54:35] <quicksilver> servus: (IIRC that's how MD2 used to work)[07:55:19] <servus> Vertex keyframe animation also locks you into a framerate and makes it awkward to render more smoothly than was "baked into" the model. Not to mention the increased amount of memory storing all those vertices...[07:55:44] * quicksilver nods[07:55:52] *** neunon has quit IRC[07:56:03] <quicksilver> On a related note, if you're doing frame by frame animation and using VBOs[07:56:17] <quicksilver> you have to upload all the vertices again every frame[07:56:23] <quicksilver> is that still faster than using immediate mode?[07:56:31] <servus> Naive vertex interpolation between frames will never look right, because you simply don't have enough topological data to relate vertices to each other in a meaningful way. Bones solve all these problems pretty easily, and allow for a lot of other cool tricks.[07:56:33] <quicksilver> hasn't it lost the main advantages of VBOs[07:56:33] *** dispraekailo has joined ##OpenGL[07:56:33] *** mastro has joined ##OpenGL[07:56:33] *** keitsi has joined ##OpenGL[07:56:33] *** Lucine2 has joined ##OpenGL[07:57:20] <servus> Yeah, it's actually probably faster to use bones with modern hardware than to update every vertex position(3) and normal(3 or more) in your buffer.[07:57:46] <quicksilver> are you talking about using vertex shaders to do the actual animation part?[07:58:11] *** druggy_ has quit IRC[07:58:13] *** brutopia has quit IRC[07:58:14] *** Killari has quit IRC[07:58:15] *** cupe has quit IRC[07:58:15] *** smiler has quit IRC[07:58:15] *** SirRaceAlot has quit IRC[07:58:15] *** DragonRift has quit IRC[07:58:17] *** lolage0 has quit IRC[07:58:19] *** Lucine has quit IRC[07:58:20] *** bobbens has quit IRC[07:58:57] *** SirRaceAlot has joined ##OpenGL[07:58:57] *** lolage0 has joined ##OpenGL[07:58:57] *** DragonRift has joined ##OpenGL[07:58:57] *** Lucine has joined ##OpenGL[07:58:57] *** bobbens has joined ##OpenGL[07:58:57] *** Killari has joined ##OpenGL[07:58:57] *** brutopia has joined ##OpenGL[07:58:57] *** smiler has joined ##OpenGL[07:58:57] *** cupe has joined ##OpenGL[07:58:59] <servus> That's a useful way to do it, quicksilver.[07:59:10] *** druggy_ has joined ##OpenGL[07:59:12] <servus> If you need to do vertex-fine collisions with the world, then obviously that's not what you want.[07:59:29] <quicksilver> servus: supposing you're targetting cards without GLSL; then you have to do bone animation CPU-side, presumably?[07:59:40] <quicksilver> and that means you effectively have to upload a new vertex set every frame?[07:59:43] <servus> However, I collide my skeletons with oriented bounding boxes around each bone... another inherent benefit :)[08:00:34] <servus> Not necessarily... even very old cards support enough extensions to get *some* sort of vertex-shader boning going on... even if you have to use the ugly fixed pipeline boning procedures.[08:01:01] <servus> I never liked GLSL, anyway. I still use ARB assembly o.o[08:01:30] * quicksilver checks the extension list for his radeon 9250s...[08:02:01] *** scy has joined ##opengl[08:02:33] <Tenac> My graphics card doesn't support GLSL, but does support this: http://nehe.gamedev.net/data/articles/article.asp?article=20[08:02:42] <Tenac> Can i only use that methods in my OpenGL project?[08:03:08] <quicksilver> servus: looks like the 9250 has ARB_vertex_program[08:03:15] <servus> I believe you could even make do with this: http://www.opengl.org/registry/specs/ARB/vertex_blend.txt[08:03:48] <servus> Major caveat with vertex_blending is that you have to chunk things into 32-bone segments.[08:04:05] <servus> But, yes, vertex_program will do ya fine.[08:05:02] <servus> It's pretty straightforward. You do your normal MVP transformations on the vertex, and throw the bone matrix into the mix. Voila.[08:06:05] <Tenac> servus, your talking to me about the link I said or what?[08:06:36] <servus> Bump mapping? I'm sorry, I don't see the relation to boned mesh deformation that that has.[08:07:09] <Tenac> ehh, idk what that is lol[08:08:30] <servus> Though you can do pixel-perfect bump mapping with a vertex program (and no fragment program) that will look better than what's shown in there...[08:10:45] <servus> Anyway, the point I was trying to make is: Avoid vertex keyframing. It sucks memory, sucks in general, doesn't scale well to fast hardware (hard to interpolate), doesn't provide you with any useful information for physics caclulations, and can't scale to dynamics in the engine.[08:11:47] <quicksilver> servus: thanks, has been very interesting[08:12:32] <servus> Good luck :)[08:12:52] <servus> As far as model formats with some level of community support, you might look into adapting the Half-Life MDL format.[08:14:32] <servus> It's boned, supports separate bone controllers and animation combinations, discrete animations, and even multiple skins so you could put a normal map into it. Should do ya fine. It might be a bit imposing, but there's a good chance it will have everything you require.[08:17:40] *** neoneye has joined ##OpenGL[08:18:01] <quicksilver> thanks, I'll investigate that[08:18:14] * quicksilver wonders if someone has already written a blender -> MDL export supporting bones[08:18:29] <servus> I do believe there is such an exporter.[08:19:32] <servus> I think it is open source. It's actually not so straighforward, though... you don't export MDL files. You export SMD files, which are either a mesh reference frame, or a skeleton animation. Then you use the MDL compiler, which takes as input a QuakeC source file, to combine all the SMDs (reference mesh and skeleton animations) into a single MDL...[08:19:40] <quicksilver> http://www.moddb.com/forum/thread/blender3d-hl2-smd-export-115cript[08:19:41] * quicksilver nods[08:29:58] *** Burga has joined ##OpenGL[08:38:10] *** Lucine2 has quit IRC[08:38:12] *** dispraekailo has quit IRC[08:38:12] *** mastro has quit IRC[08:38:13] *** keitsi has quit IRC[08:45:34] *** dispraekailo has joined ##OpenGL[08:45:34] *** mastro has joined ##OpenGL[08:45:34] *** keitsi has joined ##OpenGL[08:45:34] *** Lucine2 has joined ##OpenGL[08:47:34] *** scy has left ##opengl[09:03:04] *** DragonRift has quit IRC[09:05:38] *** Roderic has joined ##OpenGL[09:05:39] *** Roderic is now known as Ingenu[09:05:46] *** cami has joined ##OpenGL[09:17:56] *** Walt has joined ##opengl[09:23:33] *** Plagman has quit IRC[09:24:04] *** mattn_ has quit IRC[09:24:34] *** [this] has joined ##opengl[09:24:37] *** Plagman has joined ##OpenGL[09:30:53] *** dispraekailo has quit IRC[09:32:13] *** [AD]Turbo has joined ##OpenGL[09:32:14] *** SilverWolf has joined ##OpenGL[09:32:26] *** dispraekailo has joined ##OpenGL[09:33:05] <[AD]Turbo> yo[09:37:34] *** groton has joined ##OpenGL[09:38:04] *** dispraekailo has quit IRC[09:43:17] *** dispraekailo has joined ##OpenGL[09:50:10] *** Plagman has quit IRC[09:51:28] *** rutski has joined ##OpenGL[09:52:29] *** cami has quit IRC[09:52:33] *** cami has joined ##OpenGL[09:53:16] *** cami has left ##OpenGL[09:54:18] *** Lucine2 has quit IRC[09:58:46] *** miCam has joined ##OpenGL[09:59:22] *** miCam has left ##OpenGL[10:01:21] *** Azzkikr_ is now known as Azzkikr[10:03:06] *** hibread has joined ##opengl[10:10:55] *** korff has joined ##OpenGL[10:14:24] <Walt> How do I use GL_FRAGMENT_PROGRAM_ARB?[10:14:43] <Ingenu> like the doc says ?[10:17:56] *** dispraekailo has quit IRC[10:18:22] <quicksilver> slowly and carefully, steering clear of sharp opcodes?[10:24:17] *** dispraekailo has joined ##OpenGL[10:27:25] *** blbmp has quit IRC[10:28:17] *** mads- has joined ##OpenGL[10:32:28] *** Walt_ has joined ##opengl[10:32:30] *** Walt_ has quit IRC[10:32:53] *** Walt_ has joined ##opengl[10:41:00] *** Walt has quit IRC[10:41:49] *** kenws has joined ##OpenGL[10:42:55] *** Foloex has joined ##OpenGL[10:43:17] <Foloex> hello[10:45:12] <Foloex> I have a little question: I have a punctual line closing on a square orthogonaly, why is the square darkening ?[10:47:19] <groton> Foloex, ?[10:47:46] *** gotan666 has joined ##OpenGL[10:48:10] <quicksilver> Foloex: I'm not entirely sure what you mean but a screenshot might be helpful :)[10:48:25] <quicksilver> certainly adding a GL_LINES line should not darken an unrelated quad.[10:48:41] <Foloex> quicksilver: I have no screenshot, it's a theorical question ...[10:49:02] <Foloex> quicksilver: I'm preparing an exam, and this is a recurent question ...[10:50:21] <quicksilver> no idea what they're talking about then :)[10:50:34] <Foloex> The more the spot light approaches, the darker the square gets[10:51:26] <Foloex> could it be a problem with the normal ?[10:51:42] <quicksilver> yes[10:51:48] <quicksilver> could be normal is facing the wrong way[10:51:59] <quicksilver> I think[10:52:07] <quicksilver> hard exam![10:52:13] <Foloex> but why would the shape grow darker when the source light approaches ?[10:52:46] <Foloex> if the normals are wrong shouldn't the shape be balck (or just show the diffuse) ?[10:52:52] <Foloex> *black[10:54:53] <Foloex> It's a small question anyway, should'nt be worth much[10:55:22] <Foloex> quicksilver: aren't you the one who had problem with letters stored in textures ?[10:58:46] <Foloex> got to go to this exam, cya[10:58:49] *** Foloex has quit IRC[10:59:11] *** Suprano has joined ##OpenGL[11:00:13] *** BahamutZERO has joined ##OpenGL[11:04:12] *** lolage0 has quit IRC[11:14:35] *** Walt_ has quit IRC[11:27:51] *** gusano has quit IRC[11:28:12] *** Lucine2 has joined ##OpenGL[11:36:31] *** Walt has joined ##opengl[11:38:51] *** dvoid has joined ##OpenGL[11:40:49] *** Suprano has quit IRC[11:41:10] *** Maerz has joined ##OpenGL[11:41:21] *** Maerz is now known as suprano[11:41:30] *** suprano is now known as Suprano[11:41:53] *** Castigador has joined ##OpenGL[11:42:25] *** Castigador has quit IRC[11:48:24] *** Arc has joined ##OpenGL[11:57:26] *** Ademan has quit IRC[11:57:54] *** Ademan has joined ##OpenGL[12:01:56] *** Arc_ has quit IRC[12:02:25] *** andikr has joined ##opengl[12:02:32] *** dv_ has joined ##OpenGL[12:25:40] *** mm^away is now known as mm765[12:32:45] *** LtJax has joined ##opengl[12:33:29] *** groton has quit IRC[12:33:43] *** groton has joined ##OpenGL[12:55:01] *** Arc has quit IRC[12:57:15] *** Baba__ has quit IRC[13:00:11] *** Arc has joined ##OpenGL[13:02:24] *** Burga has quit IRC[13:07:41] *** gotan666 has quit IRC[13:11:30] *** gotan666 has joined ##OpenGL[13:19:37] *** Baba has joined ##OpenGL[13:20:54] *** Burga has joined ##OpenGL[13:32:10] *** Baba_ has joined ##OpenGL[13:35:32] *** juanmabc has joined ##opengl[13:42:03] *** rnx has joined ##opengl[13:42:22] *** binek86 has joined ##OpenGL[13:44:10] *** binek86 has left ##OpenGL[13:47:57] *** Baba__ has joined ##OpenGL[13:48:40] *** Baba has quit IRC[13:49:08] *** WimLeers has joined ##OpenGL[14:01:20] *** abionnnn has joined ##OpenGL[14:05:38] *** Baba_ has quit IRC[14:07:21] *** pfo has quit IRC[14:17:11] *** RaYmAn-Bx has quit IRC[14:28:14] *** Arc_ has joined ##OpenGL[14:28:39] *** andikr has quit IRC[14:30:49] *** aalex has joined ##OpenGL[14:37:08] *** pirx has joined ##OpenGL[14:40:22] <pirx> hey! if i have a texture that contains characters, i mean like a font that contains "abcdef...", and want to draw it and get some antialiasing (or similar), is that possible with some GL function? the characters in the texture are very pixely, so what i am wondering is if there is a way for opengl to look inside the texture and somehow antialias the "picture" inside?[14:40:28] *** Suprano has quit IRC[14:40:51] *** Maerz has joined ##OpenGL[14:41:43] *** Arc has quit IRC[14:46:21] *** fargiolas has joined ##OpenGL[14:52:34] <Ingenu> pirx, you can use alpha luminance format[14:52:40] <Ingenu> and use alpha to smoothly blend[14:52:45] <Ingenu> (at some cost)[14:53:04] <Ingenu> or you can get a RadeOn HD3 which is capable of anti aliasing alpha tested primitives[14:53:36] <Ingenu> (or use supersampling which does it too, but AFAIR there's no way to enable that with GL and hardware out there might not handle it anymore anyway=[14:53:43] <Ingenu> =/)[14:54:25] *** korff has left ##OpenGL[14:54:47] *** Suprano has joined ##OpenGL[14:54:52] *** dvoid has quit IRC[14:56:20] *** korff has joined ##OpenGL[15:04:11] *** Maerz has quit IRC[15:10:08] *** [this] has quit IRC[15:10:38] <rutski> pirx: fonts in my experience (at leas with TrueType) are generally represented as a set of curves. So the best AA on a font can come only with the knowledge of the original curves, which is lost in non-AA rasterization.[15:10:59] <rutski> pirx: It would be better if you could get your font renderer to do the AA during it's rasterization step[15:11:04] <rutski> **its[15:11:13] <quicksilver> pirx: alternatively, draw the font bigger than needed, to start with[15:11:17] <quicksilver> if that is an option.[15:11:26] <quicksilver> then, when you reduce it, interpolation will soften the edges.[15:11:58] <rutski> Ingenu: yea, what quicksilver said might do the trick too; although I've never tried it[15:12:05] * rutski only started play with font rendering 7 days ago[15:12:09] <quicksilver> it's very hard to antialias something which has already been drawn. You can find some algorithm involving blurring areas of high contrast.[15:12:25] <quicksilver> rutski: drawing something big and then reducing it is the same thing as 'supersampling'[15:12:29] <quicksilver> which is a classic way to do AA[15:12:43] <quicksilver> (the AA in modern font engines is not supersampling, it's something rather celver and subtle)[15:12:50] <rutski> hmm, yea; I see what your saying.[15:12:51] <quicksilver> but supersampling gives decent results.[15:13:20] <rutski> yea, exactly; that was my point. Modern font engines take into account the set of curves that made up each letter, which my gut tells me is better than supersampling.[15:13:39] <rutski> plus grid fitting and all that[15:13:45] <quicksilver> modern font engines have hinting information + grid fitting[15:13:46] <quicksilver> yes.[15:14:21] <rutski> right, but even after you've fit the curve control points to the grid, the fact that you have a curve still helps you[15:14:43] <rutski> for example it would be worse to grid fit a curve, then render it in non-AA, and then pass it through super-sampling AA[15:15:00] <rutski> while it would be better to grid fit a curve, and then AA it right away during rasterization based on the metrics of the curve[15:15:31] *** elite01 has joined ##opengl[15:15:42] <rutski> I think[15:15:46] <rutski> back me up here :)[15:16:54] *** LordMetroid has joined ##OpenGL[15:17:19] <quicksilver> yes, it does[15:17:22] *** mm765 is now known as mm765^away[15:17:26] <quicksilver> the curve helps you render at a bigger size[15:17:30] <quicksilver> bigger size == higher resolution[15:17:36] <rutski> oh... hmm[15:17:36] <quicksilver> two ways of looking at the same thing[15:17:39] <quicksilver> more pixels :)[15:17:41] <rutski> don't they help with the AA at smaller sizes as well?[15:17:43] <quicksilver> without the curve you're stuffed, yes.[15:17:52] <quicksilver> they do. By pretending to render to a bigger size :)[15:18:00] <quicksilver> and then using those extra pixels to choose shades of grey[15:18:03] <quicksilver> (or shades of transparent)[15:18:08] <rutski> wait... no[15:18:23] <rutski> even at smaller sizes you can just iterate over each pixel and check it's coverage value directly based on the curve metrics[15:18:43] <rutski> I don't see any use of the "pretending to render at larger sizes" analogy there[15:18:49] <rutski> or am I mistaken about how things are done?[15:18:59] <rutski> **its[15:20:11] *** Suprano has quit IRC[15:20:15] <rutski> afk for a few[15:20:27] *** Maerz has joined ##OpenGL[15:20:28] <quicksilver> you could check its coverage based on the curve, yes.[15:20:42] <quicksilver> I don't think that's necessarily any cheaper than rendering the curve with more virtual pixels[15:20:57] <quicksilver> it might be slightly cheaper to check the intersection of the curve wiht the four sides of the pixel[15:21:09] <quicksilver> and assume straight line in between, and calculate coverage[15:21:14] <quicksilver> so, yes, there are other algorithms you can imagine :)[15:28:29] *** SilverWolf has quit IRC[15:31:09] *** speedy1 has joined ##OpenGL[15:41:09] <pirx> thanks for all the suggestions! :)[15:42:34] <abionnnn> has anyone created cubically filtered perlin noise using GLSL?[15:42:49] *** elite01 has quit IRC[15:42:53] <Ingenu> not me[15:43:02] <Ingenu> I'm fixing people shit[15:43:07] <Ingenu> and it's getting on my nerves[15:43:27] <abionnnn> Ingenu: eeep :([15:43:55] <Ingenu> if you want to work with skilled people, don't consider joining the game industry[15:44:24] <Ingenu> there are some but too few and far between[15:44:38] <abionnnn> that's true where I work too[15:44:50] <abionnnn> a few gems, and lots of people who "fill the numbers"[15:45:07] *** DarkUranium has joined ##OpenGL[15:45:13] <DarkUranium> guys, what lib comes with wgl functions?[15:45:39] <Ingenu> I'd think opengl for windows[15:46:16] <abionnnn> yeah the functions are prototyped in wingdi.h which is included by windows.h if I recall correctly[15:47:16] <DarkUranium> which is what libs..?[15:47:20] <DarkUranium> *.a[15:47:25] <Ingenu> *.lib[15:47:25] <DarkUranium> I need that for GLFW[15:47:28] <Ingenu> on windows[15:47:36] <DarkUranium> not necesarilly[15:47:43] <DarkUranium> MinGW uses *.a[15:47:52] <DarkUranium> and I use MinGW[15:47:54] <Ingenu> yup[15:48:02] <DarkUranium> that's why I said *.a[15:48:03] <Ingenu> opengl32.a maybe[15:48:07] <DarkUranium> I've tried[15:48:14] <DarkUranium> libopengl32.a doesn't work[15:48:20] <Ingenu> if you remember the name of one of the wgl function you can look it up in msdn.microsoft.com[15:48:22] <DarkUranium> wgl functions aren't in there[15:48:35] <DarkUranium> there are like 30 errors[15:48:42] <DarkUranium> I've looked up there, but dunno where it says what lib it's in[15:48:45] <abionnnn> DarkUranium: Hmmmm hang on a tic[15:48:45] <exDM69> DarkUranium: compile or link errors?[15:48:54] <abionnnn> what's your compile line[15:49:07] <abionnnn> do you define -DWINDOWS[15:49:08] <DarkUranium> link[15:49:17] <exDM69> DarkUranium: I recommend using something other than Mingw[15:49:21] <abionnnn> oh it compiles fine then[15:49:24] <DarkUranium> exDM69, why?[15:49:50] <exDM69> DarkUranium: the mingw distribution has a very old compiler[15:50:18] <exDM69> it's possible to download and install newer versions somehow, but it's a lot of trouble (IMO)[15:50:38] <exDM69> and you can't really find binary libraries for mingw[15:51:01] <quicksilver> abionnnn: no, although I keep on thinking of doing so :)[15:51:07] <exDM69> so it's a lot of hand-compiling. and many build systems can't handle mingw, so a lot of autoconf hacking too[15:51:10] <quicksilver> abionnnn: I have a CPU-side implementation which makes pretty flames.[15:51:21] <exDM69> DarkUranium: I found MSVC++ express and cmake a lot nicer[15:51:32] <DarkUranium> yuck... MSVC++[15:51:45] <abionnnn> quicksilver: hehe which of the many variations of the algorithms did you use for that[15:52:07] <exDM69> DarkUranium: I never actually code on windows, I only dualboot, compile and test[15:52:16] <abionnnn> quicksilver: I remember coming across perlin noise a decade ago, but browsing the web now there's a million different ways of producing the effect. To me they all look like 1/f noise though[15:52:35] <DarkUranium> abionnnn, you might wanna try out simplex noise[15:52:42] <DarkUranium> also made by Ken Perlin (I think he's Ken)[15:52:44] <exDM69> DarkUranium: so I really don't have lot of experience on msvc++ development, only compiling and fixing incompatibilities[15:52:47] <Ingenu> there's improved perlin noise[15:52:55] <abionnnn> DarkUranium: yeah I was going to check that out[15:53:11] <Ingenu> Visual Studio, single best IDE out there by good margin[15:53:12] <quicksilver> abionnnn: square grid, 2D[15:53:21] <quicksilver> abionnnn: I vary the interpolation function[15:53:23] <DarkUranium> Ingenu, I beg to differ.[15:53:27] <quicksilver> between linear, cubic, cosine[15:53:30] <DarkUranium> but I don't feel like arguing over which IDE is better[15:53:37] <quicksilver> for fire it makes no difference. linear is fine.[15:53:51] <quicksilver> for clouds or marble you want at least cubic.[15:53:51] <abionnnn> quicksilver: yeah true, you don't care about derivatives[15:54:10] <quicksilver> simplex would be better but I'm lazy[15:54:18] <quicksilver> and squares is distinctly easier to think about :)[15:54:43] <quicksilver> rotate your textures by 23 degrees and the squareness isn't so obvious to the typical viewer...[15:55:38] <Ingenu> DarkUranium, what's your favorite IDE ?[15:55:41] <pirx> quicksilver: will try the "create larger font to begin with". as it is now the font is scaled up when drawn. but i am not sure if it can be created larger (its a cell phone i am talking about). you know if there is some gl function that smooths stuff out when scaling up?[15:56:07] <DarkUranium> Ingenu: MSVC++ comes with tons of problems, Dev-Cpp is pretty much forgotten about... I use Code::Blocks[15:56:21] <quicksilver> pirx: yes. texture interpolating smooths stuff when scaling up or down.[15:56:25] <quicksilver> but don't expect miracles[15:56:38] <quicksilver> blocky low res stuff will still look blocky when scaled :)[15:56:44] <pirx> is this present in GLEX too?[15:56:49] <quicksilver> I assume so.[15:56:59] <pirx> some function you can suggest?[15:57:01] <quicksilver> minifcation magnification is pretty fundamental to[15:57:17] *** BahamutZERO has quit IRC[15:57:28] *** gotan666 has quit IRC[15:57:58] * quicksilver 's favourite IDE is emacs. So there.[15:58:26] <DarkUranium> pfft[15:58:32] <DarkUranium> REAL programmers use butterflies![15:58:53] <DarkUranium> quicksilver 's favourite IDE is emacs. So there.[15:58:59] <DarkUranium> hmm[15:59:02] <DarkUranium> my PC's acting up[15:59:07] <DarkUranium> copies the wrong stuff totally[15:59:08] <DarkUranium> http://xkcd.com/378/[15:59:17] <DarkUranium> that's what I meant to copy[15:59:38] <Ingenu> C++ sucks, D is better[15:59:41] <Ingenu> here I said it[16:00:04] * quicksilver nods at DarkUranium[16:00:11] <quicksilver> I got the reference anyway :)[16:00:26] <DarkUranium> Ingenu: I don't use C++ anyways... and I normally use D[16:00:51] <DarkUranium> Ingenu: I hate C++ at LEAST as much as you do. Right now I'm programming in C instead of D, which is an exception[16:04:36] * quicksilver is programming in Haskell.[16:06:00] <Ingenu> ;)[16:06:54] <DarkUranium> mabye try out LOLCode? :P[16:07:06] <Ingenu> Code::Blocks, not checked it in a while looks good[16:07:15] <DarkUranium> I use it for everything[16:07:20] <DarkUranium> even HTML (weird, I know)[16:07:36] *** Jorachim has joined ##OpenGL[16:07:50] <DarkUranium> I keep hitting CTRL+F11 (compile hotkey) even with PHP/XML though...[16:08:19] *** Jorachim has left ##OpenGL[16:08:27] <Ingenu> lol[16:09:02] *** Diagmato has joined ##OpenGL[16:09:18] <DarkUranium> got that habit from C & D[16:09:24] <WimLeers> Could anybody point me to a good tutorial about automatic texture mapping?:[16:09:25] <DarkUranium> I do some code, CTRL+F11, CTRL+F10[16:09:31] <DarkUranium> the latter is "run"[16:12:33] *** Diagmato has quit IRC[16:15:29] *** Diagmato has joined ##OpenGL[16:18:57] *** dolphin has joined ##OpenGL[16:19:08] *** joakim12 has joined ##OpenGL[16:22:17] <quicksilver> WimLeers: not really sure what 'automatic' means in that context.[16:22:55] <WimLeers> quicksilver: using this kind of stuff instead of glTexCoord*(): glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);[16:23:18] <quicksilver> ah[16:23:24] <quicksilver> that's for stuff like sphere and cube mapping sin't it?[16:23:30] <quicksilver> to get coords for reflection maps?[16:30:21] <WimLeers> quicksilver: no, it's just to not have to write a glTexCoord*() call for EVERY vertex, which is a major PITA[16:34:57] <quicksilver> well it might be a pain but it's something you need to do[16:35:03] <quicksilver> for almost all kinds of texture mapping[16:35:16] <quicksilver> it's a rather unusual case when texGen can generate useful coordinates[16:35:21] <quicksilver> it doesn't know how your model fits together :)[16:35:24] *** uchi has joined ##OpenGL[16:36:02] <Ingenu> DarkUranium, do you know where I can add arguments to the command line when starting to debug an app with Code::Blocks ?[16:37:22] <DarkUranium> Ingenu, project -> build options -> select main "project" (not only debug or release, unless you only want for one!) -> Compiler settings tab -> Other options subtab[16:40:52] <Ingenu> wouldn't someone have changed the shortcut to match those a VS already ? ^^[16:41:03] <Ingenu> (all the F* keys mapping)[16:41:46] <DarkUranium> eh?[16:42:41] *** andikr has joined ##opengl[16:42:49] <Ingenu> I'm just used to VS key mapping so if it's possible to change it in Code::Blocks that would be nice[16:42:57] <Walt> what am I doing wrong? http://rafb.net/p/eB0T0C20.html[16:46:00] <WimLeers> quicksilver: ugh! I guess I've got no choice then[16:46:26] <quicksilver> WimLeers: if you use vertex arrays or VBOs it's easier[16:46:30] <WimLeers> quicksilver: the problem is that I've abstracted my models into xml files, so I don't have to write recompile all the time.[16:46:31] *** gusano has joined ##OpenGL[16:46:43] <WimLeers> quicksilver: VBOs?[16:46:45] <quicksilver> because then you only specify tex coords once for each vertex[16:46:54] <quicksilver> (as opposed to once each time it appears on a face)[16:47:02] <quicksilver> vertex buffer objects[16:47:03] *** Ingenu has quit IRC[16:47:09] <quicksilver> basically GPU-side vertex arrays[16:48:02] <WimLeers> eh I didn't know that[16:48:11] <WimLeers> I don't want to go that advanced actually :P[16:49:49] *** obi_1 has joined ##OpenGL[16:50:02] *** dvoid__ has joined ##OpenGL[16:51:46] <quicksilver> I don't really understand why abstracting your models into XML files makes the texture coordinates harder.[16:52:04] *** stringfellow has joined ##opengl[16:52:07] <quicksilver> I'd have thought if it's all in a nice file, you dont' care about the texcoord calls because they're done automatically by some subroutine you only have to write once.[16:54:20] <quicksilver> after all that's the nice thing about writing your own model-loading-drawing functions[16:54:32] <quicksilver> you only have to do it once and then you can forget all about glVertex and glTexCoord ;)[16:54:39] <WimLeers> quicksilver: well, the code gets uglier that way, this would have solved it much more elegantly[17:00:16] *** sohail has joined ##OpenGL[17:02:07] *** uchi has quit IRC[17:03:11] <WimLeers> quicksilver: the main problem is that I then have to write a separate function for EACH of the following: quads, quad_strip, polygon, triangles, etc. That's super ugly.[17:04:30] <hibread> WimLeers: i haven't been following, but only use indexed triangles[17:04:46] <hibread> that makes it all nice and simple[17:04:49] <WimLeers> hibread: that's a no go for us[17:05:14] <hibread> maybe go back to the design stage and wonder why on earth you would need all those features :)[17:06:19] <WimLeers> this is a school project. They basically said: figure out how opengl works and make an interesting scene with picking, collision detection, textures, and make it possible to load them from files. You've got 4 days.[17:06:44] <hibread> JC![17:07:04] <WimLeers> (I'm not asking for actual code here, so that's why it's for me to ask questions while this is a school project.)[17:07:10] <WimLeers> *ok for me[17:07:13] *** korff has quit IRC[17:11:12] <WimLeers> I can't believe there isn't a single decent tutorial out there on how to use OpenGL automatic texture mapping…[17:12:29] *** aalex has quit IRC[17:12:36] <MatthiasM> WimLeers: you mean glTexGen ?[17:13:07] <WimLeers> MatthiasM: yes[17:13:40] <MatthiasM> there are a lot out there - but it's onlöy usefull for a limited set of cases[17:13:56] <WimLeers> that's enough for me[17:14:07] <WimLeers> I only need it on squares and rectangles[17:15:16] <quicksilver> that's not the limited set of cases it's useful on.[17:15:27] *** predaeus has joined ##opengl[17:15:33] <quicksilver> it's useful on the limited set of cases where you texture is planar w.r.t the observer, or a cube/sphere map, or...[17:15:41] <quicksilver> it's not useful if you're wrapping a texture around a model[17:15:48] <quicksilver> in the 'ordinary' way.[17:16:29] <WimLeers> we're really only working with planes, so that's ok[17:20:46] *** PainBank has joined ##OpenGL[17:21:33] *** PainBank has left ##OpenGL[17:22:19] *** replor has joined ##OpenGL[17:25:29] *** hibread has quit IRC[17:28:24] *** nplus has joined ##OpenGL[17:38:08] *** WimLeers has quit IRC[17:38:38] *** stringfellow_ has joined ##opengl[17:41:45] *** lolage0 has joined ##OpenGL[17:43:16] *** fengee has joined ##OpenGL[17:43:42] *** magnet has quit IRC[17:43:52] *** magnet_ has joined ##OpenGL[17:44:16] *** Jupp3 has joined ##OpenGL[17:47:04] *** Arc_ is now known as Arc[17:47:05] *** Jupp3 has quit IRC[17:54:00] *** stringfellow has quit IRC[17:56:35] *** sanjin has joined ##OpenGL[18:01:32] *** justthisguy has joined ##OpenGL[18:01:45] *** stringfellow_ has quit IRC[18:05:34] *** tmccrary has joined ##OpenGL[18:15:56] <justthisguy> hi, I have a quick question - I've got some code "glGenTextures( 1, &texture ); cout << (glIsTexture(texture) == GL_TRUE) << endl;" which prints 0 (ie, texture does not reference a texture) Is there something obvious I'm missing? I've got another texture that seems to be loading up ok, so I can't think what it is.[18:16:32] *** [AD]Turbo is now known as TurboAWAY[18:17:23] <quicksilver> you haven't actually bound that texture yet and put anything in it?[18:17:55] <HuntsMan> you need to bound, and upload texture data to become valid[18:18:04] <justthisguy> argh![18:18:11] <justthisguy> thanks, stupid me :)[18:18:30] <justthisguy> sorry about that[18:18:34] <quicksilver> the genFoo calls just generate unique IDs[18:18:45] <quicksilver> I strongly suspect you can genTexture an ID and then use it as an FBO[18:18:48] <quicksilver> although I've never tried[18:18:58] <quicksilver> (or anything else which uses the Gen mechanism)[18:19:44] <justthisguy> ok[18:20:08] <HuntsMan> not as an FBO, but as a FBO render target[18:21:04] *** TurboAWAY has quit IRC[18:22:20] *** SilverWolf has joined ##OpenGL[18:22:37] *** nplus has joined ##OpenGL[18:24:47] *** z8000 has joined ##OpenGL[18:33:06] *** nplus has quit IRC[18:33:24] *** mm765^away is now known as mm765[18:34:45] *** nplus has joined ##OpenGL[18:35:28] *** Jupp3 has joined ##OpenGL[18:37:15] *** Jorachim has joined ##OpenGL[18:39:04] *** Jernej has joined ##OpenGL[18:39:09] *** sanjin has left ##OpenGL[18:44:54] *** scy has joined ##opengl[18:47:36] *** dv_ has quit IRC[18:48:27] *** dv_ has joined ##OpenGL[18:52:38] *** LordMetroid has quit IRC[18:53:18] *** nplus has quit IRC[18:57:11] *** JernejL has quit IRC[19:04:09] *** Yustme has joined ##opengl[19:09:56] *** LordMetroid has joined ##OpenGL[19:14:28] *** prophile has joined ##opengl[19:16:31] *** tempoe has quit IRC[19:20:07] *** juanmabc has quit IRC[19:20:41] *** groton has quit IRC[19:26:09] *** stringfellow has joined ##opengl[19:26:28] *** neunon has joined ##OpenGL[19:28:13] *** lordmetroid_ has joined ##OpenGL[19:33:34] *** Frankablu has joined ##OpenGL[19:34:15] <Frankablu> Is it possible to use colored polygons and textured polygons together?[19:35:08] <MatthiasM> yes[19:36:30] <Frankablu> How?[19:36:52] <MatthiasM> if you want to render plain colored polygons disable texturing[19:37:46] <MatthiasM> if you want to mix textured and colored in one batch use GL_MODULATE and have a few white pixels in your texture for these polygons[19:38:10] <Frankablu> This is what I'm trying atm:[19:38:11] <Frankablu> http://pastebin.com/m7c03c51c[19:38:25] <Frankablu> Am I disabling texturing wrong?[19:38:39] <MatthiasM> no[19:38:44] <abionnnn> If anyone has a minute, check out this HSV to RGB conversion code: http://pastebin.com/m70ce94a2[19:38:59] <abionnnn> I'm pretty sure its correct but I could be wrong[19:39:19] <abionnnn> (gives me craptacular colors)[19:39:35] <Frankablu> The points are retaining the color of the texture[19:39:38] <MatthiasM> Frankablu: you can remove the if(active) check if you move inactive particles into their own queue - or at the end of the list and have all active at the beginning[19:40:19] <MatthiasM> Frankablu: do you use multi texturing ?[19:40:31] <Frankablu> You mean with more than 1 texture?[19:40:45] <Frankablu> In that case yes (I think)[19:40:53] <MatthiasM> Frankablu: no - glActiveTexture[19:41:00] <MatthiasM> abionnnn: your mod3 is wrong[19:41:42] <Frankablu> Nope but I am binding several different textures[19:41:53] <Frankablu> If I was what would I need to do?[19:42:06] <abionnnn> MatthiasM: definitely not :P[19:42:09] <MatthiasM> Frankablu: disable the texture in every texture unit[19:42:26] <MatthiasM> abionnnn: you access the array out of bounds -> it is wrong[19:43:03] <abionnnn> I'm pretty sure x&0x11 is within [0,3][19:43:08] <MatthiasM> lol[19:43:12] <Frankablu> Ok I can work around, how do I set GL_MODULATE? Then I'll just make a white texture[19:43:57] <MatthiasM> Frankablu: that you have to lookup yourself - I only used shaders for several years :)[19:44:25] <MatthiasM> abionnnn: 0x is hex - not binary[19:44:33] * abionnnn hits head[19:44:34] *** LordMetroid has quit IRC[19:44:39] <abionnnn> Duhhhhhhhhhhhhh >_<[19:44:48] <abionnnn> I'm staying up too long[19:44:58] <abionnnn> cheers mate[19:44:58] <MatthiasM> and your static cast is also causing errors[19:45:22] <MatthiasM> you need to limit the values to the allowed range before casting to byte[19:46:31] <abionnnn> h, s, v are [0,1] hmmm[19:46:44] <abionnnn> m will definitely be within [0,1][19:47:05] <abionnnn> n will also be within [0,1] as long as I didn't stuff variable f up[19:47:36] <MatthiasM> there is still float point rounding :)[19:48:33] <abionnnn> *changes 6 to 5.99999*[19:49:05] <abionnnn> 1.0 edge case removed :P[19:49:28] <abionnnn> but still no good hmmmm :/[19:49:34] <MatthiasM> well - keep sticking duck tape on it :P[19:51:32] <abionnnn> result http://imagebin.org/18640[19:51:34] <Frankablu> MatthiasM: Thanks[19:51:42] *** Frankablu has quit IRC[19:52:02] <abionnnn> this spans H horizontally, V vertically with S=1.0[19:52:30] <abionnnn> MatthiasM: bleh it'll be worth it :P I can easily convert this to verilog code[19:52:39] *** Maerz has quit IRC[19:52:40] *** gotan666 has joined ##OpenGL[19:52:55] <MatthiasM> abionnnn: you intend to use float point math in an FPGA for this ?[19:53:18] <abionnnn> nope[19:53:41] <MatthiasM> why would you need HSL in HW anyway ?[19:54:24] <abionnnn> hmmm just for kicks[19:54:39] <abionnnn> working on procedural texturing[19:55:06] <abionnnn> I suppose it could be converted to RGB after the result[19:55:14] *** sohail has quit IRC[19:59:15] <abionnnn> MatthiasM: is that output right btw? I'm trying canned HSV conversion code and getting the same thing[20:00:12] *** sohail has joined ##OpenGL[20:00:16] *** lordmetroid__ has joined ##OpenGL[20:00:41] *** _sohail_ has joined ##OpenGL[20:00:42] <MatthiasM> abionnnn: I don't work with HSL enough to answer that[20:01:17] *** sohail has quit IRC[20:01:17] *** _sohail_ has quit IRC[20:01:23] <abionnnn> mmmmm nevermind :/ you spotted that silly 0x11 error so thanks a lot for your help anyway![20:01:30] *** sohail has joined ##OpenGL[20:01:44] <abionnnn> I think I'll sleep on this one :\ night[20:02:06] *** abionnnn has quit IRC[20:04:19] *** Plagman has joined ##OpenGL[20:04:49] *** neunon has quit IRC[20:06:00] *** predaeus has quit IRC[20:10:00] *** vibe- has joined ##OpenGL[20:17:07] *** lordmetroid_ has quit IRC[20:19:49] *** daniel_s has joined ##OpenGL[20:27:46] *** dolphin has quit IRC[20:30:11] *** lordmetroid__ has quit IRC[20:30:51] *** Iceshadow has joined ##OpenGL[20:31:33] *** vibe- has quit IRC[20:32:24] *** Iceshadow has quit IRC[20:33:47] *** neoneurone has joined ##OpenGL[20:42:39] *** wojtek has joined ##OpenGL[20:49:06] *** juanmabc has joined ##opengl[20:58:24] *** TheLorax has joined ##opengl[21:02:23] *** bbeausej has joined ##OpenGL[21:07:11] *** ginoman has left ##OpenGL[21:15:05] *** Jorachim has quit IRC[21:19:22] *** daniel_s has quit IRC[21:19:56] *** mads- has quit IRC[21:20:57] *** wojtek has quit IRC[21:23:35] *** TheLorax has quit IRC[21:24:03] *** gotan666 has quit IRC[21:27:01] *** bbeausej has quit IRC[21:27:06] *** bbeausej has joined ##OpenGL[21:28:46] *** blbmp has joined ##OpenGL[21:34:26] *** aalex has joined ##OpenGL[21:36:38] *** dvoid__ has quit IRC[21:37:12] *** Xmas| has joined ##OpenGL[21:39:16] *** andikr has quit IRC[21:45:57] *** DMINATOR has joined ##OpenGL[21:47:30] *** m4ggus has joined ##opengl[21:49:06] *** SilverWolf has quit IRC[21:49:49] *** joakim12 has quit IRC[21:53:43] *** SilverWolf has joined ##OpenGL[21:56:33] *** snoffler has joined ##opengl[22:02:36] *** obi_1 has quit IRC[22:04:31] *** aalex has quit IRC[22:09:02] *** Sonikku` has joined ##OpenGL[22:12:19] *** Sonikku` has quit IRC[22:15:19] *** enoexxx has joined ##OpenGL[22:15:54] *** enoexxx is now known as enoexx[22:17:20] *** snoffler has quit IRC[22:19:36] *** DarkUranium has quit IRC[22:22:35] *** TheLorax has joined ##opengl[22:29:23] *** kenws has quit IRC[22:34:09] *** TheLorax has quit IRC[22:41:46] *** magnet__ has joined ##OpenGL[22:47:22] *** groton has joined ##OpenGL[22:48:42] *** Dew420 has joined ##OpenGL[22:56:45] *** thesquib has joined ##OpenGL[22:59:06] *** amalon has joined ##opengl[22:59:42] <justthisguy> hey guys, another textures question. I'm trying to load an image into a texture using SDL, can't get it to work, so I've written a smaller program (can't get this one to work either :) http://cpp.ninjacodemonkeys.org/4308 I'm probably doing something really stupid. Result is here if that helps: http://s18.photobucket.com/albums/b107/JustThisGuy/?action=view¤t=Screenshotopengl.png Many thanks![23:05:02] <HuntsMan> start simple, without mipmapping and without gluBuild2DMipmaps[23:05:07] <HuntsMan> use glTexImage2D directly[23:06:37] *** groton has quit IRC[23:06:48] *** groton has joined ##OpenGL[23:07:08] <justthisguy> ok, I'll try that[23:11:15] <justthisguy> ok, using "glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, tex->w, tex->h, 0, GL_RGBA, GL_UNSIGNED_BYTE, tex->pixels);" (instead of those three lines) I just get a white line instead of a white blurry line[23:13:23] <HuntsMan> SDL_CreateRGBSurface(SDL_SWSURFACE, bmpFile->w, bmpFile->h, 32, rmask, gmask, bmask, amask);[23:13:28] <HuntsMan> does that create RGB o RGBA surfaces?[23:14:53] *** Suprano has joined ##OpenGL[23:14:57] <justthisguy> yeah, there's no CreateRGBASurface function[23:15:13] *** Yustme has quit IRC[23:19:53] *** fargiolas has quit IRC[23:20:41] *** Arc has quit IRC[23:21:57] <HuntsMan> then use GL_RGB, not GL_RGBA[23:24:57] *** tmccrary has quit IRC[23:25:41] <justthisguy> still nothing. Sorry, when I said there's no creatergbasurface function I meant I'm pretty sure that creatergbsurface will add an alpha channel, since it's defined as 32 bits and the [rgba]masks are set up right[23:32:44] *** Walt has quit IRC[23:39:40] *** Walt has joined ##opengl[23:39:57] *** scy has left ##opengl[23:41:19] *** Arc has joined ##OpenGL[23:43:17] *** LordMetroid has joined ##OpenGL[23:43:18] *** dv_ has quit IRC[23:43:31] *** enoexx has quit IRC[23:44:07] *** LordMetroid has quit IRC[23:44:12] *** lordmetroid_ has joined ##OpenGL[23:45:30] *** lordmetroid_ is now known as LordMetroid[23:50:29] *** bbeausej has quit IRC[23:51:29] <justthisguy> bleh. Still can't find anything wrong ..[23:56:13] *** Xmas| has quit IRC[23:57:09] *** Taika-Tempoe has quit IRC[23:59:03] *** Tempoe has joined ##OpenGL