January 25, 2009 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
January 25, 2009 [00:10:28] *** XT95__ has joined ##OpenGL[00:11:44] *** ixtli has joined ##OpenGL[00:14:12] *** XT95_ has quit IRC[00:17:16] *** johndoe has quit IRC[00:17:30] *** vade has joined ##OpenGL[00:18:09] <vade> stupid FBO question: if I want to know what FBO is bound, this should work right? : glGetIntegerv(GL_FRAMEBUFFER_BINDING_EXT, &previousFBO);[00:20:04] *** rnx has joined ##opengl[00:20:45] <vade> because it seems to be returning 0, even though I know i have an FBO bound[00:21:04] *** sefir has quit IRC[00:22:42] *** scai has left ##opengl[00:22:46] *** dukey` has joined ##OpenGL[00:25:55] <yno> vade: yes this shoud. make sure the FBO are supported by your graphics card[00:25:56] *** dolphin has quit IRC[00:26:42] <yno> does the macro GL_FRAMEBUFFER_BINDING_EXT has the right value?[00:28:08] *** boghog has quit IRC[00:32:52] *** johndoe has joined ##opengl[00:36:29] *** barbar__conan has joined ##OpenGL[00:41:17] *** gusnan has quit IRC[00:47:03] *** Sos has quit IRC[00:49:35] *** XT95__ has quit IRC[00:49:55] *** XT95_ has joined ##OpenGL[00:50:51] *** HuntsMan has joined ##opengl[00:52:15] *** Amorphous has quit IRC[00:53:27] *** barbar__conan has quit IRC[00:55:11] *** Amorphous has joined ##opengl[01:02:39] *** MouserSVK has quit IRC[01:09:55] <strombom> where can i find an algorithm for generating the mesh for a cone, sphere etc ?[01:11:27] <MatthiasM> strombom: in your math book[01:11:34] <strombom> >_>[01:11:48] <HuntsMan> he's right[01:12:00] <HuntsMan> a sphere has equation x^2 + y^2 = r^2[01:12:04] <Rangar> a cone is pretty simple.. take a circle, extrude the center out then create a face for every vertex of circle up to your extruded center point[01:12:10] <HuntsMan> you can generate points in the sphere using that equation :P[01:12:33] <strombom> yes, i could probably write my own, just wanted a shortcut... :)[01:12:48] <MatthiasM> trigometry[01:13:13] <Rangar> I sense someone is trying to make a modeller :)[01:13:28] *** Quentarez has joined ##OpenGL[01:13:45] <MatthiasM> "starting blender -> insert cone -> export" would also work[01:13:48] <strombom> no, just a small viewer[01:14:07] <strombom> want to draw arrows...[01:14:09] <Rangar> well, yup.. blender would be a great option too :)[01:14:22] <strombom> but those cones wont be parametric will they ?[01:14:23] <MatthiasM> if you export enough cones - you might be able to derive your desired cones by breeding the exported ones[01:14:28] <Rangar> make a pretty arrow in blender and draw it :)[01:14:43] <kbotnen> why do you need to generate it? do as Rangar says.[01:14:58] <strombom> kbotnen: i want parametric sizes[01:15:09] <MatthiasM> ...[01:15:26] <strombom> and i need spheres anyway so[01:15:38] <kbotnen> ok.[01:15:47] <MatthiasM> well - there is a difference between a sphere and a cone[01:16:03] <strombom> ok[01:16:05] <kbotnen> Ill call it the night. good luck with your stuff. Hope someone will be able to help you further :)[01:16:13] *** kbotnen has quit IRC[01:17:15] <strombom> the code so far if anyone is in dire need of a gtk widget with simple 3d view http://paste.pocoo.org/show/101242/[01:20:52] *** dukey` has left ##OpenGL[01:25:27] <strombom> i love the speed of todays computers. just loaded a 8800 triangle mesh into this python code, and it's reasonably fast[01:25:29] *** kappaOne has quit IRC[01:26:03] *** Zenja_Solaja has joined ##OpenGL[01:27:43] *** m4ggus has quit IRC[01:27:46] *** m4ggus_ has joined ##opengl[01:27:48] *** m4ggus_ is now known as m4ggus[01:28:38] *** paul424 has quit IRC[01:29:24] *** plasticpool has joined ##OpenGL[01:30:10] <Zenja_Solaja> Morning / afternoon / evening. I have a question (anyone with experience care to comment). Is it faster to a) draw LIMB+joint+LIMB where the limbs are in vertex buffers and the joint is procedural and animation is done via rotations, or b) to create one large local buffer, use keyframes and interpolate between the 2 frames to simulate rotation.[01:30:28] <Zenja_Solaja> In case a), i would use 2 VBO in hardware.[01:30:32] *** Yustme has quit IRC[01:30:52] <Zenja_Solaja> case a) involves 3 calls to glDrawElemetns[01:31:02] <Zenja_Solaja> case b) involves 1 call to gldrawElements[01:31:11] <strombom> vertexbuffer sounds interesting, thanks ;)[01:31:13] <Zenja_Solaja> However, in b) the data is NOT in a VMO[01:31:18] <Zenja_Solaja> VBO[01:33:18] <Zenja_Solaja> What I'm asking is "Is it faster to make 1 call to glDrawElements, where the all the data is local and procedurally generated via interpolation, or is it faster to make 3 glDrawElements calls, with 2 VBO and one 1 local array which is procedurally generated?"[01:34:15] *** XT95_ has quit IRC[01:34:27] <Zenja_Solaja> It's not easy to benchmark, since I'd have to spend 1 month converting case a) to case b). I dont want to spend a month in vain to determine that I'm not better off.[01:35:17] <strombom> ok, i have minimal experience. but it sounds like the difference would be minimal[01:35:24] <strombom> ...[01:35:46] <strombom> two buffers or one buffer with two frames ?[01:36:16] <Zenja_Solaja> No - 2 VBO and one local buffer, vs 1 local buffer but with the expense of interpolation.[01:36:54] <Zenja_Solaja> Basically, it's a bandwith/CPU choice.[01:36:54] <strombom> so the joint is a visible object? not just a logic entity?[01:36:59] <MatthiasM> Zenja_Solaja: use one VBO - use a vertex shader to do vertex skinning based on weights (as vertex attribute) and matrices (as uniforms)[01:37:07] <Zenja_Solaja> iPhone - no shaders[01:37:20] <Zenja_Solaja> I have palette matrix[01:37:51] <Zenja_Solaja> My current project has humans done with VBO per limb, plus procedural joints[01:38:12] <Zenja_Solaja> My next project needs to draw many more humans. The view distance is far, so I can use cheap/fudged skinning.[01:38:44] <Zenja_Solaja> So I was thinking of using one mesh per limb, but interpolate the limbs[01:39:01] <Zenja_Solaja> That means that I cannot use VBO since interpolation is done every frame.[01:39:16] <MatthiasM> why not ?[01:39:52] <Zenja_Solaja> MatthiasM: yes, I can use VBO but I would have to fill it every frame.[01:39:55] <strombom> since they change..[01:39:59] <MatthiasM> and?[01:40:05] <MatthiasM> map it, fill it, render[01:40:07] *** catvir has quit IRC[01:40:26] <Zenja_Solaja> Wouldn't it be easier to just call glDrawElements without filling a buffer[01:41:12] <MatthiasM> the data is copied anyway[01:41:23] <Zenja_Solaja> I can use VBO and GL_STREAM_DRAW, but the data is used only once[01:41:31] <Zenja_Solaja> I would avoid the copy to buffer operation[01:41:41] <Zenja_Solaja> Hence, I'd only have one copy, not 2[01:41:45] <MatthiasM> but if you map a VBO and fill it - GL might be able to render directly from it - without copy[01:41:48] *** pietia has quit IRC[01:41:56] <Zenja_Solaja> MatthiasM: fair enough[01:42:13] <Zenja_Solaja> That makes sense[01:42:19] <strombom> maybe you have to look at the iphone specs...[01:42:31] <Zenja_Solaja> But the data still has to be transferred to graphics memory[01:43:48] <Zenja_Solaja> Is interpolation expensive - for every vertex in a limb, I would have to calculate and store data in array (then transfer to card).[01:44:13] <Zenja_Solaja> If the data is already in VBO (as limb), then I'd only have to calculate joint skin.[01:44:25] <Zenja_Solaja> Since object is far away, I can skip the skinning process 90% of the time.[01:44:35] <MatthiasM> then use VBO[01:44:42] <MatthiasM> that way you can skip updates[01:44:43] <Zenja_Solaja> Hence I'm not penalised for interpolation cost.[01:45:52] <Zenja_Solaja> But I do have 2 calls to glDrawElements vs 1 call.[01:46:53] <Zenja_Solaja> Do you guys try to create a super mesh, or many smaller ones?[01:47:36] <MatthiasM> I try to put a model into a single VBO, do all transformation using vertex shaders, and draw with as few calls as possible[01:47:53] <MatthiasM> but for vertex skinning you may have more matrices then fit into uniform space[01:47:56] <Zenja_Solaja> MatthiasM: thats OK if you have shaders.[01:48:09] <MatthiasM> then you need to partition your model into batches[01:50:42] <Zenja_Solaja> Imagine a human arm - (upper, lower, hand). Would you create one super mesh (procedurally created every frame) and hence one single call to glDrawElements, or would you use 3 VBO's and only draw skin 10% of the time?[01:52:23] <Zenja_Solaja> IN the first scenario, I waste CPU time to interpolate every vertex, but then the video card can just stream through one geometry set. In the second scenario, I would start/stop the rendering 3 times on average (all objects in VBO), or5 times (3 VBO + 2 skins procedurally).[01:53:16] <MatthiasM> well - I assume that vertex transform is also done on CPU if you don't have a vertex shader[01:54:07] <Zenja_Solaja> The data is in the VBO[01:54:08] <MatthiasM> just benchmark which is faster[01:54:25] <Zenja_Solaja> It will take me one month to change to scenario a)[01:54:48] <Zenja_Solaja> I've already got scenario b) from an earlier project[01:54:58] <MatthiasM> why do you ask then[01:55:24] <Zenja_Solaja> I can benefit from an increase frame rate (iPhone) if option a) is faster.[01:55:29] <Zenja_Solaja> But I dont know that yet.[01:56:21] <MatthiasM> for far away object you should use LOD - and you may be able to skip animation at all - or not draw joints[01:56:40] <Zenja_Solaja> MatthiasM: yes, that was the idea behind the original design[01:56:56] <Zenja_Solaja> MatthiasM: LOD doesn't bother drawing joints[01:57:15] <Zenja_Solaja> So I just plough through drawing VBO's with only a rotation for each limb[01:57:28] <Zenja_Solaja> But I have to start/stop for each limb.[01:57:34] <Zenja_Solaja> I was thinking of trying out a SUPER mesh.[01:57:37] <strombom> omg, this is one handsome cone http://www.geting.se/viewimage.php?image=147363-Screenshot.jpg[01:57:50] <Zenja_Solaja> One single call to glDrawElemetns[01:58:01] <MatthiasM> you could assemble all joints into one dynamic VBO and all limbs into a single static one[01:58:22] <MatthiasM> then 1 draw call per limb (using another section of that VBO) and 1 draw call for all joints[01:59:04] <Zenja_Solaja> There is rotation between arm upper and arm lower.[01:59:15] <MatthiasM> yes - 1 draw call per limb[01:59:22] <MatthiasM> change the matrix between[01:59:28] <Zenja_Solaja> Thats what I do[01:59:34] <MatthiasM> but all joints can be rendered with one matrix[01:59:40] <MatthiasM> as you have to blend them anyway[02:00:02] <MatthiasM> so multiply the matrices before to get all joints into one common space[02:00:20] <Zenja_Solaja> MatthiasM: yes, I already do that. I was thinking of experimenting with a single super mesh which would draw the limbs and joint in one go. But at the expense of upfront interpolation.[02:00:46] <Zenja_Solaja> Currently, I just have 1 VBO for arm upper, 1 VBO for arm lower, and occassionally draw skin.[02:01:17] <MatthiasM> assuming that your GL implementation will still apply vertex transform like moldeview and perspective - you would only increae processing[02:01:30] <MatthiasM> combine all static VBOs[02:01:41] <MatthiasM> and use glDrawRangeElements[02:02:08] <Zenja_Solaja> BUt I stil have to make 2 calls (range for arm upper, range for arm lower)[02:02:15] <MatthiasM> yep[02:02:40] <Zenja_Solaja> I have a hunch that with iPhone, I might be faster to create super mesh, and do single call.[02:02:52] <MatthiasM> but an additional draw call has a fixed cost - while vertex processing cost depends on vertex count[02:03:03] <Zenja_Solaja> I noticed that when I tried to create shoulder/arm upper joint.[02:03:11] <Zenja_Solaja> Low quality models.[02:03:12] <Zenja_Solaja> Very low[02:03:19] <MatthiasM> how many vertices ?[02:03:44] <Zenja_Solaja> 18 per limb (arm upper, arm lower)[02:04:00] <MatthiasM> lol - create a super mesh - but 1 month is very long for that[02:04:01] <Zenja_Solaja> so 36 + hand[02:06:01] <Zenja_Solaja> 1 month to change tool sets[02:06:24] <Zenja_Solaja> Something has to convert the mesh to a format I can understand.[02:06:26] <MatthiasM> why do you need to change the toolset ? just create a small hack and test the performance[02:06:41] <Zenja_Solaja> MatthiasM: for benchmarking, yes[02:06:42] *** Nescafe has joined ##OpenGL[02:06:43] <MatthiasM> if it is faster - do it in a clean way[02:06:54] <Zenja_Solaja> MatthiasM: fari enough[02:06:55] *** Suprano has quit IRC[02:07:01] <Zenja_Solaja> fair :)[02:07:02] <MatthiasM> if not - store it at the bottom of your drawer[02:07:20] <MatthiasM> *fery :P[02:07:21] <Zenja_Solaja> Thanks. I was just wondering if others already ran into this dilemma[02:07:35] <Zenja_Solaja> Learn from other people's mistake :)[02:08:49] <Zenja_Solaja> For example, the first few FPS titles did interpolation. The newer batches use bones and skinning.[02:09:04] *** elite01 has quit IRC[02:09:04] <Zenja_Solaja> The hardware I'm targetting is the iPhone without shaders[02:09:33] <Zenja_Solaja> On the PC, I get 900+ frames[02:09:40] <Zenja_Solaja> On iPhone, I get 43[02:10:50] <strombom> oh nice[02:11:11] <strombom> is it the same resolution on the device?[02:11:25] <tmccrary> You could use stitching instead of skinning[02:11:29] <MatthiasM> no - it's a PC Java app :)[02:11:32] <Zenja_Solaja> Both running at 320x480[02:11:42] <Zenja_Solaja> tmccrary: I am using stiching[02:11:54] <MatthiasM> but video capture takes a lot of space on large resolutions[02:12:07] <Zenja_Solaja> The models are always up to 30% of the screen size.[02:12:13] <Zenja_Solaja> So you cannot see the detail up close[02:12:23] <Zenja_Solaja> Most models are less than 10% screen size.[02:12:38] <Zenja_Solaja> So I can avoid stiching in 90% of displayed models.[02:12:46] <MatthiasM> Zenja_Solaja: maybe just implement the "vertex shader" for vertex skinning in C/C++ then[02:13:10] <MatthiasM> and be sure to remove every not needed triangle from your model[02:13:21] <Zenja_Solaja> The next gen iPhone will probably use OpenGLES 2.0, so there will be hardware shaders.[02:14:00] <tmccrary> Are you taking advantage of SIMD support on the hardware?[02:14:13] <Zenja_Solaja> No.[02:14:19] <MatthiasM> you should[02:14:21] <tmccrary> done right, you could get a HUGE boost[02:14:38] <tmccrary> like double digits[02:14:57] <MatthiasM> you could probably do one vertex with 2 matrices in ~ 10 instructions[02:15:35] <Zenja_Solaja> tmccrary: - I'm unfamiliar with ARM SIMD. Not many libraries out there yet.[02:15:57] <Zenja_Solaja> MatthiasM: fair point, since I am doing skinning with C++[02:15:58] <tmccrary> you should be able to use instrinsics w/ xcode[02:16:28] <MatthiasM> but for such small models - did you consider key frame animations - aka MD2 ?[02:17:04] *** korff_home has quit IRC[02:17:12] <Zenja_Solaja> MatthiasM: yes, MD2 specifically. It interpolates between keyframes.[02:17:18] <Zenja_Solaja> Every vertex[02:17:29] <MatthiasM> yes - much less cpu demanding[02:17:41] <Zenja_Solaja> That was what I wanted in option b).[02:18:05] <MatthiasM> probably ~4 instruction per vertex with SIMD (again without counting loops or addressing)[02:18:05] <Zenja_Solaja> I actually wanted to grab MD2 models and convert them to my internal format. Same idea.[02:19:07] <strombom> what do you call a pipe without the hole ?[02:19:14] <Zenja_Solaja> But I already have working code that draws human models with VBO, however 3 vbo per limb + stitching.[02:19:19] <MatthiasM> cylinder ?[02:19:27] <strombom> thanks[02:20:21] <Zenja_Solaja> So that is my dilemma - swith to MD2 (and do interpolation) and draw a super mesh once, or use old code which uses 3 VBO per limb, so many calles to glDrawElements[02:20:49] *** Madsy has quit IRC[02:22:07] <Zenja_Solaja> do CPU processing up front, one single call to OpenGL, vs many calls to OpenGL with little CPU usage. I know that I have to benchmark, just wondering what other peoples experience is.[02:24:16] <strombom> probably depends on cpu, bus-bandwidth, gpu >_>[02:25:03] <Xmas|> if you generate the geometry every frame don't bother with vbos on the iphone[02:26:01] <Zenja_Solaja> Xmas|: exactly[02:26:59] <tmccrary> well, you are using the streaming vbo option right?[02:33:11] <Zenja_Solaja> tmccrary: I'm investigating if I should switch to interpolation (one super mesh calculates new vertex every frame and then use GL_STREAM_DRAW) or use my old method (many VBO with GL_STATIC_DRAW, with a rotate command in between calls to glDrawElements)[02:33:39] *** oneEyedJohn has joined ##OpenGL[02:35:54] <Zenja_Solaja> Also, with interpolation I would obviously have to create keyframe meshes (start/end point of interpolation). The old code just uses bunch of static geometry for limbs, with rotations and occassional stiching.[02:37:52] <Xmas|> STREAM_DRAW isn't available in ES anyway[02:41:58] <Zenja_Solaja> Sorry, I meant GL_DYNAMIC DRAW[02:44:55] *** LordMetroid has quit IRC[02:47:15] *** boghog has joined ##opengl[02:58:15] *** amz has joined ##opengl[02:59:35] *** HuntsMan has quit IRC[03:03:33] *** Xmas| has quit IRC[03:06:30] *** yno has quit IRC[03:21:03] *** dvoid has quit IRC[03:22:44] *** Gargantua has joined ##OpenGL[03:26:32] *** RTFM_FTW has quit IRC[03:26:44] *** RTFM_FTW has joined ##OpenGL[03:31:55] *** Eforen has joined ##opengl[03:33:02] *** johndoe has quit IRC[03:34:01] *** jcazevedo has joined ##OpenGL[03:35:12] *** itsmonktastic has quit IRC[03:37:25] *** MatthiasM has quit IRC[03:37:32] *** MatthiasM has joined ##opengl[03:39:50] *** Zenja_Solaja has left ##OpenGL[03:42:38] *** TheLorax has joined ##opengl[04:06:10] *** plasticpool has quit IRC[04:08:25] *** HuntsMan has joined ##opengl[04:12:45] *** treak007 has joined ##OpenGL[04:15:28] *** Cultz has joined ##OpenGL[04:23:14] *** _THEGOD_ has joined ##OpenGL[04:24:01] <_THEGOD_> [Linker error] undefined reference to `_imp__glewExperimental'[04:24:22] <_THEGOD_> anyone has any ideas ?[04:28:10] *** mattn2|home has quit IRC[04:28:34] *** mattn2|home has joined ##OpenGL[04:29:49] <ville> Link with the library that defines it[04:30:09] <ville> Or if it's static linking, you've the order wrong[04:41:48] *** reprore_ has joined ##OpenGL[04:44:06] *** HuntsMan has quit IRC[04:48:07] *** repror___ has joined ##OpenGL[04:48:25] *** reprore_ has quit IRC[05:01:16] <_THEGOD_> i included glew.lib[05:01:26] <_THEGOD_> but is simply misses this[05:01:44] <_THEGOD_> it[05:02:03] <_THEGOD_> im sure that its included[05:02:20] <_THEGOD_> because other definitions are foun after including glew[05:02:37] <_THEGOD_> but gcc does not sees this function[05:03:30] <_THEGOD_> i think its some problem about functions call parameter count etc whic makes function identified wrong[05:09:04] *** bijoo_appdev_ has quit IRC[05:09:04] *** bijoo_osdev_ has quit IRC[05:09:17] *** repror___ has quit IRC[05:09:27] *** reprore_ has joined ##OpenGL[05:13:10] *** jcazevedo has quit IRC[05:21:21] <vade> is there a glPush that can push the bound buffer into a stack, so I can pop it off, so I dont have to use really slow glGets to know what FBO is currently bound ?[05:24:24] <tmccrary> Why not just store it locally somewhere?[05:26:02] *** schwinn434 has joined ##OpenGL[05:31:53] *** Kasu has quit IRC[05:32:50] <vade> i cant[05:32:53] *** caine607 has quit IRC[05:33:01] <vade> because I dont own the state of every other plugin in the environment[05:44:49] <vade> poop[05:45:11] <vade> item 70 in the spec addresses the lack of push/pop for and the lack of a FRAMEBUFFER_BIT for glPushAttrib[05:45:18] <vade> this means I am most likely shit out of luck.[05:45:18] <vade> fuck.[05:48:19] *** Gorgoroth has quit IRC[05:59:15] *** qeed has quit IRC[06:00:49] *** TheLorax has quit IRC[06:01:20] *** sohail has quit IRC[06:04:05] *** xkpe has joined ##OpenGL[06:04:05] *** Gorgoroth has joined ##OpenGL[06:07:15] *** murz has joined ##OpenGL[06:09:20] *** Zenja has joined ##OpenGL[06:10:03] <murz> i'm trying to make a program that given a windows handle, can take a screenshot of that program and save it somewhere on the harddrive. I made a simple little c++ app that did that perfectly for normal windows, but for video games it would just save a picture of a black screen. So is it possible to hook into an opengl/directx program and capture/save a single frame? any ideas on how to go about it, where to start? I've only done a little o[06:10:20] <murz> *pst[06:10:24] <murz> *past[06:11:16] <Zenja> Arrrgggggg. I'm an idiot. I've borrowed some code to draw a sphere (http://ozviz.wasp.uwa.edu.au/~pbourke/texture_colour/spheremap/) and have been using the code for years. Only now have I realised that the sphere is rendered via GL_CW (glFrontFace). You can still see the inside of the sphere which is circular, with the only wrong thing being texturing (when drawing a ball, you dont notice).[06:11:28] <Zenja> Honestly, who enables glFrontFace(GL_CW) these days ... ?[06:11:45] *** b0000 has quit IRC[06:11:53] <Zenja> I've been rendering the inside of the sphere, not the outside :([06:12:33] <Zenja> So much for borrowing code from the iNet[06:19:42] *** murz has quit IRC[06:21:03] *** schwinn434 has quit IRC[06:22:59] *** treak007 has quit IRC[06:28:38] *** korff_home has joined ##OpenGL[06:30:55] <_THEGOD_> hm..[06:31:08] <_THEGOD_> here is my graphics card specs[06:31:09] <_THEGOD_> http://pastebin.com/f795b3a0b[06:31:19] <_THEGOD_> is it good enough ?[06:31:22] <_THEGOD_> ;P[06:35:23] <vade> haha[06:35:37] <vade> *awesome* ;)[06:36:11] *** Nescafe has quit IRC[06:38:55] <Zenja> He he, even Haiku with software rendering support more than that.[06:39:15] <Zenja> _THEGOD_: you running OpenGL on a network PCI card or similar?[06:39:53] <Zenja> GDI Generic from Microsoft Corporation[06:40:00] <Zenja> OpenGL 1.1[06:42:30] *** v has quit IRC[06:42:37] *** v has joined ##opengl[06:43:04] <_THEGOD_> i just dont hawe gl drivers installed because they are buggy for my device[06:43:18] <_THEGOD_> anyway.[06:43:24] <_THEGOD_> here is code[06:43:24] <MatthiasM> well - the MS software renderer is also buggy[06:43:25] <_THEGOD_> G:\ELECTRONIC-BOOKS\New Folder\OpenGL Blending\glew-1.5.1-src\glew\src>"c:\Dev-C[06:43:25] <_THEGOD_> ++\bin\g++.exe" -c glew.c[06:43:25] <_THEGOD_> glew.c:9090: warning: 'GLboolean glewExperimental' defined locally after being[06:43:25] <_THEGOD_> referenced with dllimport linkage.[06:44:03] <_THEGOD_> this little warning looks like is the main of those bib problem.[06:44:12] <_THEGOD_> which makes application to not compile.[06:44:33] <_THEGOD_> does this mean that glewExperimental will be undefined after linking ?[06:47:47] <_THEGOD_> hm...[06:47:55] <_THEGOD_> the library has a #ifdef GL_VERSION_2_0[06:47:59] <_THEGOD_> or something there.[06:48:17] <_THEGOD_> so may be my card makes it define 1.0 which is not there.[06:48:44] <_THEGOD_> so may be i hawe to include #define GL_VERSION_2_0 9999 there ?[06:48:47] <_THEGOD_> right ?[06:49:01] <_THEGOD_> or may be something like that[06:49:24] <MatthiasM> how about you start reading the glew docu ?[06:49:26] <_THEGOD_> #define GL_VERSION_9_97 GLVERSION9999 there ?[06:49:46] <_THEGOD_> so it vill not coause any problems untill next 50 years ;P[06:50:23] <_THEGOD_> hm..[06:51:10] <_THEGOD_> ewen if i define #define GL_VERSION_9_97 GLVERSION9999 ill still hawe to define 2_0 thing too for compatibility ;P heh .[06:52:04] <_THEGOD_> MatthiasM are you are still java programmer ?[06:52:21] <_THEGOD_> did you learned c++ ?[06:52:49] <tmccrary> wah wah wee wah[06:52:59] <_THEGOD_> so may be you can shed a light about inserting this elexperimental thing inside defined area ?[06:53:18] <tmccrary> would you like to touch[06:53:26] <_THEGOD_> if its eperimental why in the hell my code forces me to use it ?[06:53:28] <MatthiasM> _THEGOD_: well - it's clear that you did not learned anything at all :DD[06:53:40] <_THEGOD_> blah.[06:53:43] <_THEGOD_> thanks.[06:54:05] <_THEGOD_> that makes anything shine . and makes us see whats wrong ;P[06:54:16] <tmccrary> it is nice[06:54:23] <MatthiasM> but just a hint: defines define which GL header versions are available - not what GL version is available at runtime[06:55:19] <MatthiasM> because the software may run on another system which has different GL features[06:57:43] <_THEGOD_> hm.. you mean ill hawe to do some fix on gl drivers too ? which are not opensource for people swho dont knows assembly correctly ;) ?[06:57:48] <tmccrary> I like you, do you like me?[06:59:16] *** Zenja has left ##OpenGL[07:04:51] *** TheLorax has joined ##opengl[07:06:57] <_THEGOD_> i think i hawe to type this to somewhere inside lib definitions GLboolean glewExperimental = GL_FALSE;[07:07:18] <_THEGOD_> or GLboolean glewExperimental = GL_TRUE ;[07:07:57] <_THEGOD_> anyone knows whats the difference ? if its false or true ?[07:08:23] *** Gargantua has quit IRC[07:08:30] <_THEGOD_> probally includes experimental functions too. or not[07:09:28] *** TopMach_ has joined ##opengl[07:09:42] *** v has quit IRC[07:10:10] <MatthiasM> _THEGOD_: why do you think it's the fault of glew - it works for everyone besides you[07:10:47] <rnx> not really ...[07:11:01] <rnx> glew compilation issues came up here before[07:12:22] <_THEGOD_> may be its because gldrivers are not installed :P[07:12:41] <MatthiasM> _THEGOD_: compiling doesn't depend on GL drivers - only on GL headers[07:13:21] <_THEGOD_> hm.. so its probally my g++ setup which point to libglew.a[07:14:12] <_THEGOD_> some of those libs arround the web are for linux some are for wasting time and some of them works. ;P[07:15:08] <_THEGOD_> i cant find just official libglew.a[07:15:16] <MatthiasM> what compiler do you use ?[07:15:30] <_THEGOD_> devpaks repositorys some part is down.[07:15:34] <_THEGOD_> g++[07:15:42] <_THEGOD_> spesial editio ;P[07:16:23] <_THEGOD_> Thread model: win32[07:16:24] <_THEGOD_> gcc version 3.3.1 (mingw special 20030804-1)[07:16:42] <_THEGOD_> Reading specs from c:/Dev-C++/bin/../lib/gcc-lib/mingw32/3.3.1/specs[07:16:42] <_THEGOD_> Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=[07:16:42] <_THEGOD_> mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable[07:16:42] <_THEGOD_> nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja[07:16:42] <_THEGOD_> va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz[07:16:44] <_THEGOD_> ation[07:16:55] *** TheLorax has quit IRC[07:17:04] * MatthiasM strikes _THEGOD_ with lightning[07:17:46] <_THEGOD_> lols[07:18:00] <_THEGOD_> it looks like i hawe fortan support too ;P ?[07:18:06] <_THEGOD_> i werent know that .[07:18:18] <MatthiasM> only if you installed the fortran frontend[07:27:45] *** hibread has quit IRC[07:29:28] *** hibread has joined ##opengl[07:30:13] *** TkTech has joined ##OpenGL[07:31:46] *** Gargantua has joined ##OpenGL[07:35:09] *** javadlux has joined ##OpenGL[07:36:01] <javadlux> im trying to identify the range of gl_FragCoord.z for an orthographic projection... im assuming its 0 -> -|back-front|[07:36:12] <javadlux> where back and front are parameters to gluOrtho[07:36:25] <javadlux> *glOrtho[07:37:59] <javadlux> or does it get scaled to 0 -> 1 by the projection?[07:38:14] <MatthiasM> did you checked the GLSL spec ?[07:38:41] *** reprore_ has quit IRC[07:38:46] <TkTech> Heyo! I've peered through the NeHe tuts, and I can't find anything on moving through a 3D space using the Camera. I'm trying to (in a C++ program) 'follow' the camera around. Anyone know any documentation for controlling the camera with the mouse?[07:38:57] <TkTech> *using the mouse[07:38:57] <javadlux> im not sure if its a glsl issue or a projection issue[07:39:20] <MatthiasM> javadlux: GLSL spec defined this variable[07:40:39] <_THEGOD_> using the mouse ?[07:40:57] <_THEGOD_> getasynckeystate(1) returns left mouse state[07:41:04] <_THEGOD_> 2 for right[07:41:15] *** reprore_ has joined ##OpenGL[07:41:19] <javadlux> well the spec just calls it the fixed functionality computed depth[07:41:26] <_THEGOD_> for mouse move use mouses ports ;P[07:41:56] <MatthiasM> javadlux: no idea then - you have to check the GL spec then[07:41:57] <javadlux> so i assume that is the untransformed coordinate[07:41:59] <TkTech> ...Picture the camera being fixed onto a object (a ship) moving through a 3D space with a constant velocity in whatever direction the mouse is pointing[07:42:48] <javadlux> oh no wait its a fragment variable, so it would be transformed... so i assume then its already in the range 0 to 1[07:43:15] *** vade has quit IRC[07:43:28] <MatthiasM> I would think it's in the glDepthRange - range[07:43:57] <javadlux> well i see in the spec for gl_fragdepth that its default value is gl_fragcoord.z[07:44:09] <javadlux> thats why i assumed its the same range as the depth value[07:44:34] <javadlux> i wanted a linear transformed depth, so i guess ill have to pass it in myself as a varying[07:44:42] <MatthiasM> yep - that's better[07:45:31] <javadlux> stupid non linear depth space :P[07:45:35] <_THEGOD_> well if anyone wants a keyboard and mouse buttons libray i hawe source code.[07:45:46] <_THEGOD_> so i cant sent it in some seconds ;P[07:45:47] <MatthiasM> lol[07:46:04] <_THEGOD_> which can detect key codes just using windows.h[07:46:11] <javadlux> although actually its an ortho projection so it may be linear anyways[07:46:14] <javadlux> oh well[07:46:25] <_THEGOD_> or uses just getasynkkeystate() loop ;P[07:51:57] <javadlux> hmm.. ive got an ortho scene with a sphere filling almost the whole volume... in the vertex shader i pass a varying that is calculated from (gl_Vertex * gl_ModelViewMatrix).z[07:52:16] <javadlux> then in the fragment shader i scale this by the depth of the ortho projection and use this is a luminance for the fragment color[07:52:43] <javadlux> i should get a sphere thats dark in the middle (z is quite low) and bright at the edges... instead its uniform grey[07:53:02] <javadlux> if anyone sees an obvious problem with what im doing it would be greatly appreciated :P[07:54:09] <MatthiasM> should work[07:54:55] <MatthiasM> but maybe "ModelViewProjMatrix * gl_Vertex" will work better :)[07:55:07] <javadlux> doesn't that put it back in non-linear depth space though?[07:55:23] <javadlux> i want to be looking at the vertices as still being in world space[07:55:24] <MatthiasM> no - z is still linear - only z/w is non linear[07:56:32] <javadlux> hmm... looks better... i thought i had tried that before though and it looked non-linear... oh well, its working now :P[07:57:13] <MatthiasM> :)[07:58:02] <javadlux> where does the transform from z value to depth value occur then?[07:59:04] <MatthiasM> outside of the shader[08:00:31] <javadlux> hmm... well if the default value for gl_FragDepth is gl_FragCoord.z, then substiting gl_FragCoord.z for my varying should give the same result[08:00:48] <javadlux> but it gives a non-linear rendering[08:02:33] *** Ram2 has left ##OpenGL[08:03:21] <MatthiasM> better to not use gl_FragCoord[08:04:10] <javadlux> i know that, im just saying if the linear-non linear transform happens outside the shader, using gl_fragcoord should look the same as my version[08:04:12] <javadlux> but it doesn't[08:06:29] <javadlux> oh nvm i got it... fragcoord seems to be in -1 to 1 range[08:07:19] *** porsche911turbo has quit IRC[08:07:25] *** Gargantua has quit IRC[08:07:41] *** Gargantua has joined ##OpenGL[08:07:57] <MatthiasM> javadlux: that's the default glDepthRange[08:08:05] <javadlux> doesn't make sense as a depth value though....[08:08:16] <javadlux> i guess that is where the transform happens after the shader[08:08:21] <javadlux> from -1 to 1 to 0 to 1[08:14:36] *** Gorgoroth has quit IRC[08:18:59] <TkTech> Hmm..so, no one has any useful input?[08:21:13] *** LordHavoc has quit IRC[08:21:13] *** _3b_ has quit IRC[08:21:55] *** amz has quit IRC[08:21:55] *** LordHavoc has joined ##OpenGL[08:21:55] *** _3b_ has joined ##OpenGL[08:27:20] <_THEGOD_> there is no god ? this depends on what you mean by god . ;P[08:27:28] *** FireKitten is now known as hackkitten[08:27:54] * hackkitten points at _THEGOD_[08:27:57] <hackkitten> there is a god~ (o/[08:28:15] <MatthiasM> lol[08:29:58] *** Cultz has quit IRC[08:30:22] *** Kraln has quit IRC[08:30:35] *** Kraln has joined ##opengl[08:31:02] *** sohail has joined ##OpenGL[08:31:05] *** aliquando has joined ##OpenGL[08:36:07] *** rabbit- has joined ##OpenGL[08:36:52] *** javadlux has quit IRC[08:39:51] *** aliquando has quit IRC[08:56:37] <_THEGOD_> lols[08:56:55] <_THEGOD_> do anyone knows a book about how to archive files ? :P[08:57:12] <_THEGOD_> my filesystem looks horrible .[08:57:37] <_THEGOD_> and finding something is impossible withour searching utilities commonly.[08:58:46] <_THEGOD_> eg clasifying is hard.[08:59:10] <_THEGOD_> if i hawe knoppix dvd what could be the tag ?[08:59:52] <_THEGOD_> or simply folder name. =GL or LINUX or develop or rescuecds or operating systems or what ? ;P[09:00:13] <hackkitten> archiving is for wussies~[09:00:37] * hackkitten subscribes to the 'organized chaos' method of organizing files[09:00:38] <hackkitten> :3[09:01:04] <_THEGOD_> i tryed too much methods but at end i find my archives as a garbage ;P[09:02:56] *** UUncia has joined ##OpenGL[09:12:15] <hackkitten> :)[09:12:23] *** eXtronuS has joined ##OpenGL[09:32:03] *** Gargantua_ has joined ##OpenGL[09:32:57] *** Yustme has joined ##OpenGL[09:43:13] *** reprore_ has quit IRC[09:44:41] *** Gargantua has quit IRC[09:45:18] *** kbotnen has joined ##OpenGL[09:48:26] *** groton has joined ##OpenGL[09:49:48] *** __THEGOD_ has joined ##OpenGL[09:50:00] <__THEGOD_> hi.[09:50:18] <__THEGOD_> can anyone help me how to access a ftp server which is accesible on lan[09:50:22] <__THEGOD_> from net.[09:50:49] <__THEGOD_> eg if net ip is 200.2.2.2[09:51:06] <__THEGOD_> and local sub ip is 198.1.1.1[09:51:16] <__THEGOD_> how can i acces the 198...[09:51:53] <__THEGOD_> or do router hawe to set them automatically ?[09:52:37] <TkTech> Why are you asking these in #opengl? And yet my authentic question goes un-answered[09:54:02] <__THEGOD_> you hawe to use glRotatef[09:54:22] <__THEGOD_> and push pop matrix to reset the matric.[09:54:29] <__THEGOD_> i mean center.[09:54:52] <__THEGOD_> pop matrix resets last center of camera too.[09:54:53] *** autonomy_ is now known as autonomy[09:55:07] *** bagu has quit IRC[09:55:47] <__THEGOD_> or you hawe to use objects vertex coordinates to move objects[09:56:09] <__THEGOD_> there is not exactly camera on opengl afaik.[09:56:22] <__THEGOD_> hm.. im not sure abou this %100 anyway[09:56:59] *** _THEGOD_ has quit IRC[10:03:21] *** xkpe_ has joined ##OpenGL[10:05:10] *** scai has joined ##opengl[10:05:59] *** korff_home has quit IRC[10:06:37] *** xkpe has quit IRC[10:06:37] *** xkpe_ is now known as xkpe[10:07:37] *** m4ggus has quit IRC[10:13:09] *** korff_home has joined ##OpenGL[10:18:53] *** Ingenu has joined ##OpenGL[10:21:13] *** scai_ has joined ##opengl[10:26:48] *** groton has quit IRC[10:27:23] *** xkpe_ has joined ##OpenGL[10:27:58] *** Sarajevo has joined ##OpenGL[10:32:54] *** scai has quit IRC[10:45:06] *** xkpe has quit IRC[10:45:07] *** xkpe_ is now known as xkpe[10:46:05] *** pietia_ has joined ##OpenGL[10:48:49] *** Renderwahn has joined ##OpenGL[10:48:51] *** Sarajevo is now known as Sarajevo-Bbl[10:53:57] *** Gargantua_ has quit IRC[10:54:23] *** suppahsrv has quit IRC[10:57:45] *** neoneye has joined ##OpenGL[11:03:25] *** Ram2 has joined ##OpenGL[11:03:29] <Ram2> hi[11:03:47] <TheFlash> TkTech: There's no "easy" answer for your camera question.[11:04:13] <Ram2> how delete a vbo ?[11:04:37] <TheFlash> glDeleteBuffers?[11:05:00] <Ram2> ok thx TheFlash i will see how it work[11:10:58] *** wey has joined ##opengl[11:13:29] *** NevroPus has quit IRC[11:17:50] *** gusnan has joined ##OpenGL[11:20:24] *** TiLex has joined ##opengl[11:20:52] *** sohail has quit IRC[11:22:55] *** pietia_ has quit IRC[11:26:31] *** pietia_ has joined ##OpenGL[11:32:32] *** elite01 has joined ##opengl[11:32:34] *** dv___ has joined ##opengl[11:32:56] *** dv___ is now known as dv_[11:35:03] *** neoneye has quit IRC[11:36:28] *** groton has joined ##OpenGL[11:43:57] *** dvoid has joined ##OpenGL[11:44:38] *** Ram2 has quit IRC[11:46:41] *** wey has quit IRC[11:47:46] *** Suprano has joined ##OpenGL[11:59:29] *** ol1veira has joined ##OpenGL[12:00:10] *** bhz- has quit IRC[12:02:11] <TkTech> TheFlash: Not looking for an easy one ^_*[12:02:17] <TkTech> TheFlash: Just looking for one[12:16:35] *** korff_home has quit IRC[12:17:06] *** Spkka has joined ##OpenGL[12:17:41] *** Spkka has joined ##OpenGL[12:24:10] <TkTech> TheFlash: Really just looking for a good tutorial documenting 'camera' manipulation[12:25:05] *** PsiOmega has joined ##OpenGL[12:29:32] *** UUncia has quit IRC[12:33:13] *** jcazevedo has joined ##OpenGL[12:43:07] *** PsiOmegaDelta has quit IRC[12:44:22] <__THEGOD_> TkTech opengl.org has some samples .[12:44:32] <__THEGOD_> their page looks a bit updated[12:44:47] <__THEGOD_> but they still uses glut for tutoria;s %80+[12:45:01] <__THEGOD_> which is not good enough for beginning.[12:46:07] <__THEGOD_> eg glut call main loop using java etc stlye call. c call but jawa style[12:46:59] *** Blaay has joined ##OpenGL[12:48:08] *** Spkka has quit IRC[12:50:04] *** freeRag has joined ##OpenGL[12:55:03] *** eXtronuS has quit IRC[12:56:20] *** suppahsrv has joined ##OpenGL[12:57:34] *** mattn2|home has quit IRC[13:02:40] *** predaeus has joined ##opengl[13:13:15] *** Xmas| has joined ##OpenGL[13:15:53] *** TkTech has quit IRC[13:35:05] *** groton has quit IRC[13:59:46] *** rnx has left ##opengl[14:07:47] *** autonomy has quit IRC[14:08:58] *** druggy_ has joined ##opengl[14:16:52] *** LtJax has joined ##OpenGL[14:24:59] *** druggy has quit IRC[14:39:56] *** bhz- has joined ##opengl[14:41:22] *** freeRag has quit IRC[14:44:23] *** b0000 has joined ##opengl[14:48:19] *** m4ggus has joined ##opengl[14:49:12] *** RTFM_FTW has quit IRC[14:50:44] *** ixtli has quit IRC[14:52:44] *** predaeus has quit IRC[14:53:15] *** __THEGOD_ has left ##OpenGL[15:00:35] *** RTFM_FTW has joined ##OpenGL[15:01:12] *** XT95_ has joined ##OpenGL[15:20:41] *** __THEGOD_ has joined ##OpenGL[15:21:59] *** autonomy has joined ##OpenGL[15:22:01] *** Kasu has joined ##OpenGL[15:22:44] *** rabbit- has quit IRC[15:23:21] *** LordMetroid has joined ##OpenGL[15:24:59] *** johndoe has joined ##opengl[15:32:25] *** bijoo_osdev has joined ##opengl[15:32:25] *** bijoo_appdev has joined ##OpenGL[15:42:43] *** TopMach_ has quit IRC[15:45:22] *** __THEGOD_ has quit IRC[15:45:36] *** amz has joined ##opengl[15:58:58] *** amz has quit IRC[15:59:36] *** bijoo_osdev has quit IRC[15:59:36] *** bijoo_appdev has quit IRC[16:04:14] *** qeed has joined ##opengl[16:06:49] *** bijoo_appdev has joined ##OpenGL[16:06:50] *** bijoo_osdev has joined ##opengl[16:12:42] *** Xmas| has quit IRC[16:23:04] *** gusnan has quit IRC[16:33:12] *** t4bz has joined ##OpenGL[16:34:51] *** bhz- has quit IRC[16:37:34] *** pietia_ has quit IRC[16:38:08] *** pietia_ has joined ##OpenGL[16:41:28] *** bhz- has joined ##opengl[16:50:35] *** |t4bz| has quit IRC[16:50:42] *** escalation has joined ##opengl[16:50:44] *** bhz- has quit IRC[16:50:57] *** Gorgoroth has joined ##OpenGL[17:01:10] *** escalation has quit IRC[17:05:06] *** olavgg has left ##opengl[17:05:16] *** olavgg has joined ##opengl[17:09:36] *** bhz- has joined ##opengl[17:10:53] *** McLovin` has joined ##opengl[17:11:04] *** gusnan has joined ##OpenGL[17:11:25] *** AlastairLynn has joined ##opengl[17:12:36] <AlastairLynn> can anyone point me towards a good comparison of 3D model formats? Up until now I've only used obj and md3[17:13:24] *** htrejh has joined ##OpenGL[17:13:27] <htrejh> hellp[17:13:29] <htrejh> hello*[17:14:24] <htrejh> some opengl programs (games) lock the screen, i mean you can't use ALT-TAB for example, is there any way to disable that with an opengl hook or something like that?[17:15:13] <AlastairLynn> that's entirely down to the window system and is outside the scope of opengl[17:17:43] *** itewsh has joined ##OpenGL[17:20:10] <LtJax> htrejh: AlastairLynn is right, that's a windows message you need to suppress. nothing to do with opengl[17:21:05] <htrejh> ow, and how can i find that out? :p[17:21:26] <GuShH_> look on keyboard hooks, etc.[17:21:29] <htrejh> but isn't there any opengl function or something that locks the screen[17:21:36] <LtJax> htrejh: no[17:21:41] <htrejh> owkay thx[17:21:41] <LtJax> it's not related to OpenGL[17:21:56] <htrejh> keyboard? you jsut said it was the wm?[17:22:08] <LtJax> yea, no keyboard hooks needed[17:22:21] <htrejh> can you hook a wm? :p[17:22:23] <LtJax> at least not to suppress ALT-TAB[17:22:30] <LtJax> you don't need any hooks[17:22:38] <htrejh> what then?[17:22:41] <htrejh> owkay[17:22:43] <LtJax> it's just a window message, and now get busy RTFM[17:22:51] <htrejh> owkay thx for info[17:23:43] <LtJax> AlastairLynn: I think the consensus is to either use the model-format that your middleware requires, or roll your own, with a custom exporter[17:25:33] *** reprore_ has joined ##OpenGL[17:25:38] *** bhz- has quit IRC[17:25:57] *** bhz- has joined ##opengl[17:28:20] *** zwiep` has quit IRC[17:30:02] <AlastairLynn> LtJax: right-o[17:31:12] *** bhz- has quit IRC[17:37:40] <GuShH_> LtJax : I find your lack of information quite disturbing, telling someone to "rtfm" without actually giving them good pointers is as retarded as looking down the barrel of a loaded gun while holding it with greasy hands. The most effective way to prevent alt-tab and other keyboard shortcuts under NT and up is by using a keyboard hook as I mentioned before. If you know of a better way that works on most major versions of the OS,[17:37:40] <GuShH_> then feel free to give him some good pointers about it, for instance registering a hotkey is seen as a good practice, but you failed to mention this.[17:38:42] <htrejh> GuShH_: thanks for info, i was confused :p but actually i'm must do that on linux/unix[17:39:10] *** RTFM_FTW has quit IRC[17:39:33] <GuShH_> So it is you who should be hang from the neck instead for failing to mention such an IMPORTANT DETAIL.[17:40:16] * GuShH_ idles[17:40:45] <htrejh> could you help me to find out howto solve my problem?[17:44:17] *** RTFM_FTW has joined ##OpenGL[17:46:15] <LtJax> GuShH_: woa, no need to be so aggressive[17:51:49] <htrejh> GuShH_: can you help me please?[17:55:00] *** sohail has joined ##OpenGL[17:55:08] *** itewsh has quit IRC[18:03:42] *** iion has joined ##OpenGL[18:03:56] *** cplusplus has joined ##OpenGL[18:04:50] *** Xmas| has joined ##OpenGL[18:04:54] *** stringfellow has quit IRC[18:21:13] *** Bollinger has joined ##OpenGL[18:22:30] *** oneEyedJohn has quit IRC[18:26:59] *** bhz- has joined ##opengl[18:27:35] *** htrejh has quit IRC[18:35:27] *** predaeus has joined ##opengl[18:42:04] *** oneEyedJohn has joined ##OpenGL[18:43:30] <oneEyedJohn> hey, all -- i'm trying to do a destructable 2d landscape like tanks, or iShoot on the iphone, any guidance on the best way to store and render the pixels that make up the landscape?[18:49:28] *** gusnan has quit IRC[18:50:23] *** groton has joined ##OpenGL[18:55:22] *** Xantoz has quit IRC[18:55:31] *** Xantoz has joined ##OpenGL[18:57:58] *** HuntsMan has joined ##opengl[19:00:27] *** bhz- has quit IRC[19:00:35] *** bhz- has joined ##opengl[19:04:34] *** reprore_ has quit IRC[19:04:54] *** reprore_ has joined ##OpenGL[19:05:19] *** NightVisio has joined ##OpenGL[19:20:24] *** m4ggus has quit IRC[19:21:34] *** TheLorax has joined ##opengl[19:32:07] <Plagman> oneEyedJohn: good question[19:33:17] *** qeed has quit IRC[19:33:31] <Plagman> if the iPhone had a stencil buffer, I'd say keep the terrain in a large 2d structure that doesn't change and manage your landscape in client memory, and blit the landscape to the stencil buffer and render the big terrain texture using the stencil as a mask[19:33:36] <Plagman> but it doesn't[19:33:48] <Plagman> 2d texture*[19:41:47] *** mib_e5478r has joined ##opengl[19:43:30] *** reprore_ has quit IRC[19:43:41] <oneEyedJohn> 2d texture?[19:43:44] *** itewsh has joined ##OpenGL[19:44:38] *** itewsh has quit IRC[19:45:12] *** itewsh has joined ##OpenGL[19:49:46] *** groton has quit IRC[19:56:32] *** reprore_ has joined ##OpenGL[19:57:38] <mib_e5478r> hello, my opengl limits say that i can only use up to 8 lights, but what if i wanted to make a hallway lit with many torchs (maybe 20 torches)?[19:58:18] <RTFM_FTW> use the programmable pipeline for lighting[19:58:32] <mib_e5478r> how does that work?[19:58:40] <RTFM_FTW> fixed function (be it lighting or otherwise) is dead[19:58:53] <RTFM_FTW> read about the OpenGL Shading Language (i.e. GLSL)[19:58:58] <mib_e5478r> not how shaders work, but how would i make a shader like that[19:59:17] <mib_e5478r> is there a name for that type of shader?[20:00:23] *** groton has joined ##OpenGL[20:00:48] <HuntsMan> lighting shader?[20:01:13] <mib_e5478r> from what i've seen, the most lights they allowed was like 4[20:01:47] <HuntsMan> with a shader you can have as many as you want[20:02:37] <mib_e5478r> do you have one like that?[20:04:23] <HuntsMan> no[20:04:32] <RTFM_FTW> heh no one does :D[20:04:58] <RTFM_FTW> there are *many* ways to do lighting within the programmable pipeline[20:05:11] <RTFM_FTW> per vertex, per fragment, ... just to start with[20:05:55] <RTFM_FTW> think about what you need for your app and then look at how you can accomplish this through the programmable pipeline exposed through the GL API[20:06:22] <RTFM_FTW> if you understand your needs and the features shaders allow for this should be quite possible :D[20:06:29] <mib_e5478r> ok[20:07:08] <b0000> or just use fixed function pipeline if you dont have a spare 3 years to learn advanced lighting shaders in glsl[20:07:33] <RTFM_FTW> umm no[20:07:41] <tmccrary> advanced lighting shaders[20:07:49] <RTFM_FTW> and it doesn't take anything close to "3 years" to learn the programmable pipeline[20:08:09] <mib_e5478r> nah[20:08:15] <tmccrary> lighting is like a lot of things, its only as complicated as you want it to be[20:08:20] <RTFM_FTW> exactly[20:08:21] <b0000> *2 years[20:08:57] <tmccrary> like lambertian diffuse + blinn phone lighting, which fixed function uses, should be doable in a day[20:09:04] <tmccrary> *blinn PHONG[20:09:06] <tmccrary> ;)[20:09:44] <tmccrary> fancy brdfs can take a lot longer... but again, you don't need those to get a decent simply lit scene going[20:09:52] <RTFM_FTW> yep[20:10:04] <mib_e5478r> so, basically, what im looking at now, is making a for loop, with the amount of lights you want in a uniform..[20:10:12] *** UUncia has joined ##OpenGL[20:10:18] *** TheLorax has quit IRC[20:11:04] <tmccrary> mib_e5478r: you could probably unroll the loops, after a few lights, it gets harder to notice the difference[20:11:30] *** itewsh has quit IRC[20:13:08] <mib_e5478r> yea, theres probably optimizations that can be done later, but thats the general idea right?[20:13:13] <tmccrary> yeah[20:13:38] *** iion has quit IRC[20:13:45] <mib_e5478r> ok thanks for your help[20:16:51] *** Blaay has quit IRC[20:20:54] *** sohail has quit IRC[20:22:06] *** XT95__ has joined ##OpenGL[20:23:46] *** dolphin has joined ##OpenGL[20:27:42] *** HuntsMan has quit IRC[20:30:24] *** TiLex has quit IRC[20:35:38] *** Entelin has joined ##OpenGL[20:36:18] *** XT95_ has quit IRC[20:37:15] *** Entelin has quit IRC[20:47:10] *** vade has joined ##OpenGL[20:48:38] *** Engineer has joined ##OpenGL[20:51:16] *** Sarajevo-Bbl is now known as Sarajevo[20:54:33] *** stringfellow has joined ##opengl[20:56:23] *** scai_ has left ##opengl[20:57:19] *** NightVisio has quit IRC[21:00:52] *** mib_e5478r has quit IRC[21:03:21] *** reprore_ has quit IRC[21:06:50] *** pfo has quit IRC[21:07:13] *** pfo has joined ##OpenGL[21:07:20] *** A2intaer has joined ##OpenGL[21:07:42] *** Entelin has joined ##OpenGL[21:13:35] <strombom> is it possible to get anti-aliased edges (with minimal work) ? http://www.geting.se/viewimage.php?image=147515-robo1.png#[21:14:26] *** XT95_ has joined ##OpenGL[21:15:10] <MatthiasM> strombom: enable multisampling[21:16:31] <strombom> looks about the same[21:16:37] <strombom> glEnable(GL_MULTISAMPLE)[21:17:11] <MatthiasM> no[21:17:30] <MatthiasM> that doesn't work - you have to specify it at context creation[21:18:14] *** Walt has quit IRC[21:25:17] *** HuntsMan has joined ##opengl[21:25:25] <strombom> maybe it's not implemented in pyopengl?[21:26:41] *** predaeus has quit IRC[21:27:09] *** Yuzuru has quit IRC[21:27:53] *** Walt has joined ##opengl[21:29:09] *** Zenja has joined ##OpenGL[21:29:27] <Zenja> MatthiasM: Are you in today?[21:31:16] <MatthiasM> yes[21:31:16] *** XT95__ has quit IRC[21:31:29] <Zenja> I ended up benchmarking the differences from yesterdays conversation.[21:31:55] <Zenja> Using 3 calls to VBO for each limb, I get 24.97 fps on the iPhone[21:32:20] <Zenja> With a Super mesh (I call to glDrawElements), I get 39.15 fps[21:32:31] <MatthiasM> that's a huge difference[21:32:51] <Zenja> On the PC, the difference was 1010 vs 1270[21:33:27] <Zenja> In any case, I hit the API call overhead. Less calls means faster run.[21:33:30] <MatthiasM> well - be prepared that some optimisations have the opposite effect on one of the 2 platforms[21:33:52] <strombom> btw, i managed to generate my arrows ;) http://bilder.altronix.se/ef/arrows.png[21:34:19] <MatthiasM> heh[21:34:27] *** Spkka has joined ##OpenGL[21:34:34] <MatthiasM> I would have loaded the arrows as model :)[21:34:58] <strombom> bah, i will use them for a lot of things... the need to be long, short, wide, thin etc ;)[21:37:12] *** A2intaer has quit IRC[21:38:47] <strombom> is there any way of writing the opengl window to an image ? so that i can record a video?[21:39:02] <MatthiasM> yep[21:39:03] <HuntsMan> you can read the framebuffer using glReadPixels[21:39:10] <strombom> ok[21:42:11] *** dolphin has quit IRC[21:45:27] *** bagu has joined ##opengl[21:48:08] *** xkpe has quit IRC[21:52:06] <strombom> i guess a black image is better than no image...[21:55:59] *** Aintaer has joined ##OpenGL[21:56:35] *** ol1veira has quit IRC[22:00:21] *** loufoque has joined ##opengl[22:00:37] <strombom> i was wrong[22:00:54] <loufoque> how many polygons can a mainstream graphics card render at 30 FPS?[22:02:16] *** davidc__ has quit IRC[22:02:53] *** ata2 has joined ##OpenGL[22:03:15] *** mm765^sleep is now known as mm765[22:04:16] <MatthiasM> loufoque: a lot if you use the right method to render them[22:04:35] <loufoque> I just need an estimate[22:04:51] <loufoque> more like 100 000 or more like 1 000 000?[22:05:03] <tmccrary> unlit and untextured, millions and millions[22:06:02] <MatthiasM> it highly depends on shader complexity, number of textures used, texture format, frame buffer size, frame buffer format, over draw etc[22:07:25] *** xkpe has joined ##OpenGL[22:09:51] <loufoque> by shader complexity, you mean the amount of shaders applied per texture?[22:10:41] *** GuyFromHell_ has joined ##OpenGL[22:11:27] <HuntsMan> shader length, how many branches it has, how coherent the branches are, etc[22:15:10] <GuyFromHell_> Is there a a scenario that glNormal* doesn't change the normal; i.e. http://rafb.net/p/rYq4C571.html[22:15:31] <HuntsMan> BTW what does texture2D() return if i sample a LUMINANCE8 texture?[22:15:39] <HuntsMan> (l, l, l, 1) ?[22:15:47] <TheFlash> GuyFromHell_: If the old value is same as the new.[22:16:18] <GuyFromHell_> TheFlash: it shouldn't be, the paste also has the output of what i'm putting in[22:16:58] <MatthiasM> HuntsMan: rgb are all luminance, and alpha = 1[22:17:14] <GuyFromHell_> Hmm, perhaps i didn't do glGetDoublev... going to go research that now[22:17:23] <HuntsMan> MatthiasM: thanks[22:17:29] <HuntsMan> GuyFromHell_: try glGetFloatv[22:17:45] *** ata2 has quit IRC[22:17:49] *** cplusplus has quit IRC[22:17:57] *** cplusplus has joined ##OpenGL[22:18:13] <MatthiasM> GuyFromHell_: maybe you have auto normalisation enabled - because your normal is > 1.0[22:18:13] <TheFlash> GuyFromHell_: You may have enabled some autonormalization or similar...[22:18:35] <MatthiasM> you should not use auto normalisation but instead provide correct normals[22:18:35] <GuyFromHell_> Uhm, as in glEnable(NORMALIZE)?[22:18:46] <GuyFromHell_> >_> see and i thought that was helping >_>[22:19:01] <TheFlash> glDisable(GL_AUTO_NORMAL);[22:19:13] <HuntsMan> glDisable(GL_NORMALIZE);[22:19:25] *** shelIeycakes has joined ##OpenGL[22:19:38] <bubu`> auto normalization should not change signs of vector compontent[22:20:18] *** Xantoz has quit IRC[22:20:48] <GuyFromHell_> Mm, didn't change much except the version that does not call Normal3f before every vertex just got a bit darker[22:21:12] *** gusnan has joined ##OpenGL[22:22:14] *** Xantoz has joined ##OpenGL[22:22:24] <HuntsMan> GuyFromHell_: what if you readback a float array instead of a double array?[22:23:36] <GuyFromHell_> http://rafb.net/p/YaHKd129.html[22:23:38] *** GuyFromHell_ is now known as GuyFromHell[22:23:52] <GuyFromHell> HuntsMan: ^[22:25:34] <HuntsMan> weird[22:25:43] *** shelIeycakes is now known as Sarajevo-[22:26:09] <Zenja> HuntsMan: most implementations store floats anyway.[22:26:20] <HuntsMan> yeah[22:26:37] <Zenja> OpenGLES doesn't even support glGetDoublev[22:26:49] *** groton has quit IRC[22:27:19] <GuyFromHell> Zenja: heh, sorry. the implementation i'm using has floats too but i'm clearly not accustomed to using them yet. i just type double instinctively :P[22:27:40] <HuntsMan> GuyFromHell: don't :P[22:27:43] <HuntsMan> BTW what card it is?[22:27:45] <HuntsMan> and OS/Driver?[22:28:06] <GuyFromHell> nvidia NVS140m on GNU/Linux with binary blob drivers[22:28:18] <bubu`> actually it is not wierd - OpenGL spec in their State Tables (section 6.2) have written that GL_CURRENT_NORMAL should be retrievied only by glGetFloatv[22:28:43] <bubu`> some other states have also glGetDoublev, but not current normal state[22:28:49] <HuntsMan> yeah, but both results are wrong[22:28:51] <GuyFromHell> >_> see that jjust makes me feel like i will _never_ understand opengl :P[22:29:08] <bubu`> oh, sorry didn see float results[22:29:40] <GuyFromHell> bubu`: no i mean like the spec is so complex that it's never all going to sink in :/...[22:30:09] <HuntsMan> GuyFromHell: latest drivers?[22:31:02] <GuyFromHell> HuntsMan: seems that way, 180.22 which is latest according to nvid's page[22:31:07] *** LtJax has quit IRC[22:31:27] <HuntsMan> yes[22:31:37] <HuntsMan> with some GL 3 support and KDE4 bugfixes[22:32:22] <GuyFromHell> say what now? I am indeed on KDE4 if that matters...[22:32:48] <HuntsMan> KDE4 works without slowdowns on NVIDIA + 180.22 drivers[22:32:53] *** barbar__conan has joined ##OpenGL[22:33:21] <GuyFromHell> HuntsMan: it seemed to work on the one before this too, i only installed 180.22 3 days ago but i don't remember a significant speed up...[22:33:30] <GuyFromHell> 177.82 was the one i had before[22:33:31] <HuntsMan> nah, just saying that with older drivers, KDE4/Qt4 was significantly slower[22:34:06] <bubu`> have you GL_RESCALE_NORMAL state enabled?[22:34:24] <GuyFromHell> uhhh, let me check....[22:34:51] *** LtJax has joined ##opengl[22:36:33] <GuyFromHell> not enabled[22:37:36] *** Sarajevo has quit IRC[22:37:40] *** itewsh has joined ##OpenGL[22:47:16] *** Yustme has quit IRC[22:48:05] <GuyFromHell> Need to move networks; in case someone has an idea wait a few minutes please :)[22:54:33] *** NevroPus has joined ##OpenGL[22:55:36] *** scai has joined ##opengl[22:58:33] *** GuyFromHell_ has joined ##opengl[23:02:47] *** HuntsMan has quit IRC[23:03:38] <RTFM_FTW> sampling LUMINANCE data will give you < R = L, G = L, B = L, A = 1 >[23:03:46] *** Zenja has quit IRC[23:04:31] <RTFM_FTW> sampling ALPHA data will give you < R = 0, G = 0, B = 0, A = A > and sampling INTENSITY will give you < R = I, G = I, B = I, A = I >[23:04:51] *** McLovin` has quit IRC[23:04:53] <RTFM_FTW> LUMINANCE_ALPHA would be < R = L, G = L, B = L, A = A > of course[23:05:08] *** GuyFromHell has quit IRC[23:16:11] *** vade has quit IRC[23:16:17] *** b0000 has quit IRC[23:19:06] *** Walt has quit IRC[23:20:13] *** Sarajevo- has quit IRC[23:29:23] *** cplusplus has quit IRC[23:30:36] *** Walt has joined ##opengl[23:30:38] *** Walt has quit IRC[23:32:41] *** Renderwahn has quit IRC[23:32:45] *** Walt has joined ##opengl[23:34:29] *** xkpe_ has joined ##OpenGL[23:34:38] *** triptik has joined ##OpenGL[23:34:40] *** iion has joined ##OpenGL[23:37:03] *** xkpe has quit IRC[23:37:03] *** xkpe_ is now known as xkpe[23:41:58] *** ixtli has joined ##OpenGL[23:45:48] <Ingenu> night guys[23:46:14] *** Entelin has quit IRC[23:46:16] *** Ingenu has quit IRC[23:46:48] *** UUncia has quit IRC[23:47:32] *** gusnan has quit IRC[23:47:59] *** XT95_ has quit IRC[23:54:09] *** Spkka has quit IRC[23:55:34] *** kbotnen has quit IRC[23:55:57] *** Bollinger has quit IRC[23:56:21] *** iion has quit IRC[23:58:53] *** bhz- has quit IRC