[00:01:26] *** Ragnarok has quit IRC
[00:05:51] *** Yustme has quit IRC
[00:13:40] *** nodesert has joined ##OpenGL
[00:15:40] <nodesert> is there anyone who can help me how to do my opengl bone project.I just need to move bones but i can not find a good sample on internet
[00:30:58] *** [this] has joined ##opengl
[00:40:18] *** mads- has quit IRC
[00:43:37] *** nodesert has quit IRC
[00:47:33] *** gusnan has quit IRC
[01:02:14] *** neoneurone has quit IRC
[01:06:35] *** ectropy has quit IRC
[01:15:02] *** bolides has quit IRC
[01:21:57] *** scy has left ##opengl
[01:23:38] *** DobosCake has quit IRC
[01:25:39] *** danieljames has joined ##OpenGL
[01:26:49] *** Gizwiz has joined ##OpenGL
[01:27:25] <Gizwiz> Is there any way (other then making a texture) to send arguments (floats) to a fragment shader?  - Expecting a "no", is there an easy way to make and transfer a texture ?
[01:27:40] <danieljames> hello, can anybody recommend any lightweight libraries for doing hit-testing, simple scene-graphing (mainly to allow me to do translucency) etc also possibly loading a 3ds model
[01:28:40] *** speedy1 has joined ##OpenGL
[01:28:42] <RTFM_FTW> well you can generate procedural texture data via the programmable pipeline... you can also pass { boolean, float, integer } data into the programmable pipeline via uniform variables
[01:28:47] <RTFM_FTW> in the GLSL case
[01:29:56] <Gizwiz> Great, I'll go googeling :) - thanks
[01:30:05] <RTFM_FTW> int, unsigned int, float, ivec[2,3,4], bvec[2,3,4], uvec[2,3,4], vec[2,3,4] for example
[01:30:13] <RTFM_FTW> with the addition of the
[01:30:19] <RTFM_FTW> "uniform" keyword
[01:30:42] <speedy1> gizwiz: best check out glsl spec
[01:31:31] <RTFM_FTW> http://www.opengl.org/sdk/libs/OpenSceneGraph/glsl_quickref.pdf http://www.opengl.org/documentation/glsl/
[01:31:35] <RTFM_FTW> read those
[01:31:55] <speedy1> hello yoda ;)
[01:32:01] *** ectropy has joined ##OpenGL
[01:32:18] <RTFM_FTW> I'm not sure why you think I'm "yoda"
[01:32:29] <RTFM_FTW> since my handle is quite clear...
[01:32:54] <RTFM_FTW> related to the OP you can also pass matrix data into the programmable pipeline
[01:37:13] *** MatthiasM has quit IRC
[01:37:19] *** MatthiasM has joined ##opengl
[01:38:29] *** obmij has joined ##OpenGL
[01:38:32] <obmij> render to surface
[01:38:39] <obmij> umm
[01:38:52] <obmij> gah, nevermind the above statement X|
[01:38:54] <RTFM_FTW> hmm?
[01:39:17] <RTFM_FTW> because you don't have to RTT in order to generate procedural data in GL...
[01:39:18] <RTFM_FTW> heh
[01:39:37] <RTFM_FTW> although it frequently comes in handy to do so
[01:40:36] <obmij> Ok I'm rendering to cubemap surfaces through a frame buffer, I shouldn't call SwapBuffers inbetween the render should I?
[01:40:56] <RTFM_FTW> correct
[01:41:06] <obmij> ok
[01:41:19] <obmij> when I jumped in and typed 'render to surface'
[01:41:22] <obmij> I have no idea why I did that
[01:41:36] <obmij> it was half sub conscious
[01:41:39] <obmij> =|
[01:42:07] <speedy1> hmm i've got an interesting problem regarding object space motion blur - what's the best place and way to preserve previous frames transform matrix with least overhead
[01:43:01] <speedy1> because object can be moved by scripts multiple times per frame
[01:43:53] <speedy1> tricky stuff...
[02:02:08] <Gizwiz> Cool, the uniform float interface did it for me, now I do realtime ColorCorrection on the GPU. Thanks
[02:04:01] *** IJs\laptop has quit IRC
[02:08:58] <speedy1> gizwiz: saturation and contrast?
[02:09:05] <Gizwiz> yes
[02:09:29] <speedy1> cool :) using a simple linear function?
[02:09:41] <Gizwiz> yeps.... but there's a catch
[02:09:55] <speedy1> eh?
[02:10:09] <speedy1> gamma maybe? ;)
[02:10:20] <Gizwiz> The original images are YUV, so they are Sat and Contrast is easy (Done in YUV colorspace) before converting to RGB (also on GPU)
[02:11:09] <speedy1> btw. take care that you do it in linear gamma space, too
[02:11:40] <Gizwiz> I don't do gamme
[02:11:44] <Gizwiz> gamma
[02:12:12] <speedy1> i guess if YUV are linear and your conversion to RGB takes into account default 2.2 gamma, you're good
[02:12:28] <Gizwiz> the YUB data is in gamma 2.2 already
[02:12:39] <Gizwiz> YUV :) (it's 2 at night here, getting tired)
[02:12:41] <Gizwiz> Do you have a simple example of using pbuffer? - I need to do the CC in rendering too
[02:12:50] *** amalon has quit IRC
[02:13:02] <speedy1> then for the linear function to work properly you need to convert it to 1.0 gamma
[02:13:21] <speedy1> uh consider using FBOs instead
[02:13:46] <speedy1> though if you use ATI and want multisampling, you have to use pbuffers
[02:13:53] <Gizwiz> I guess, in theory, but it looks cool, and I can CC it as expected (GUI feels natural) so it's all good.
[02:14:05] <Gizwiz> FBO?
[02:14:12] <speedy1> frame buffer objects extension
[02:14:17] <Gizwiz> All Nvidia Quadro
[02:14:25] <speedy1> should do the trick
[02:14:49] <Gizwiz> well, do you have a simple (non-windows specific, please) example of FBO's handy?
[02:15:07] <speedy1> check the spec for them - they're simple to use
[02:15:24] <speedy1> ~20 lines of code and you're done
[02:15:42] <Gizwiz> yeah, that's what I figured. Can I render at any res?
[02:15:49] <Gizwiz> EXT_framebuffer_object man page is like 200 pages :)
[02:15:56] <speedy1> ah oh - lots of notes
[02:16:12] <speedy1> spec itself is short
[02:16:13] *** NeoThermic has quit IRC
[02:16:30] <speedy1> it's worth the read if you're going to use them
[02:17:54] <Gizwiz> I bet, and I will, but right now I just need it to work in a hurry, doing a demo for a client on Monday morning
[02:18:12] <Gizwiz> It's 2:18 Sat night here
[02:18:38] <speedy1> can't help with example code
[02:18:48] <speedy1> could send you mine but I doubt you could use it
[02:18:58] <speedy1> as it relies on other stuff
[02:19:17] <Gizwiz> ofc. never mind, I'll find something. Thanks :)
[02:19:50] *** mm765 is now known as mm765^away
[02:19:55] <speedy1> cheers :)
[02:28:46] <obmij> speedy1, how do you deal with sizzling?
[02:29:00] <obmij> are you doing motion blur in real time?
[02:29:18] <speedy1> sizzling?
[02:29:31] <speedy1> maybe you mean aliasing?
[02:30:05] <obmij> yeah
[02:30:52] <speedy1> simple - just do multiple passes with the same motion vector texture
[02:31:05] <speedy1> "ping-pong" the result
[02:31:29] <obmij> and it comes out real time?
[02:31:31] <obmij> how many passes?
[02:31:47] <speedy1> ie. for 2 pass use half size motion vectors and do the blur twice
[02:32:10] *** replor has joined ##OpenGL
[02:32:15] <speedy1> sure, just like in crysis DX10 or project offset
[02:33:45] *** obmij_ has joined ##OpenGL
[02:33:50] <obmij_> gah
[02:33:55] <obmij_> my connection got reset
[02:34:40] <speedy1> <speedy1> ie. for 2 pass use half size motion vectors and do the blur twice
[02:34:48] <speedy1> <speedy1> sure, just like in crysis DX10 or project offset
[02:36:14] <obmij_> like guassian blur?
[02:36:36] <speedy1> something like that
[02:36:49] <obmij_> you know
[02:37:00] <obmij_> I'm kind of hell bent on making it beat Crytek
[02:37:20] <obmij_> sure a direction based blurring
[02:37:53] <obmij_> but then what's interesting is that, every object that moves only gets a blur
[02:37:57] <obmij_> I wonder how to do it with that
[02:39:00] *** dvoid has quit IRC
[02:39:48] <obmij_> maybe render blurred result to small texture and display with alpha blending
[02:40:04] <speedy1> check stupid shader opengl tricks paper :)
[02:41:00] <obmij_> where is it ? :o
[02:41:08] <speedy1> google
[02:46:48] <obmij_> heh interesting paper
[02:47:34] *** nathan__ has joined ##OpenGL
[02:48:04] <Gizwiz> So, I'm now doing a FBO rendering into a texture. How do I get it into system RAM?
[02:48:22] <speedy1> glGetTexImage
[02:48:29] <Gizwiz> nice :)
[02:49:32] <obmij_> wouldn't that slow things down?
[02:49:37] <obmij_> generally speaking
[02:49:43] <obmij_> dragging from video ram
[02:49:47] <obmij_> and back and forth
[02:49:49] <obmij_> etc.
[02:51:17] <Gizwiz> glGetTexImage(tex, 0, GL_RGB, GL_UNSIGNED_BYTE, memory); ?
[02:51:32] *** obmij has quit IRC
[02:52:10] <Gizwiz> Hmmm, it's full of 0xcd
[02:54:27] <speedy1> check glGetError()
[02:54:43] <speedy1> 0xcd means it didn't do anything ;)
[02:57:16] <Gizwiz> Ya, I know. First arg had to be GL_TEXTURE_2D - how do I select what texture is copied?
[02:58:00] *** TheLorax has quit IRC
[02:58:51] <speedy1> maybe bind it
[02:58:52] <RTFM_FTW> heh EXT_framebuffer_multisample *and* EXT_framebuffer_blit are supported on ATI (and as I recall *not* on Nvidia) on APPLE renderers
[02:59:15] <speedy1> apple is niche
[02:59:18] <speedy1> ;)
[02:59:21] <RTFM_FTW> no its not
[02:59:39] <RTFM_FTW> and in any case query those extensions if you need that functionality
[03:00:45] <obmij_> I could do alpha blending with Zbuffer on right?
[03:01:52] <Gizwiz> Can you take a look at this, please? http://pastebin.com/d13ef8911
[03:03:05] <Gizwiz> results in www.concave.dk/screendump.gif
[03:03:10] <Gizwiz> ...it's not a screendump :)
[03:04:33] <obmij_> Nope
[03:04:36] <obmij_> it's dump
[03:04:41] <obmij_> just kidding ;D
[03:05:01] <Gizwiz> :P
[03:05:16] *** Morphous has joined ##opengl
[03:05:55] <Gizwiz> FBO rendering does support fragment shaders, right?
[03:06:50] <obmij_> yes
[03:07:09] <RTFM_FTW> well I'm not aware of any renderers supporting EXT_framebuffer_object which lack support for the programmable pipeline so that would be correct
[03:08:21] <RTFM_FTW> just query support at runtime to be safe
[03:08:33] *** danieljames has quit IRC
[03:10:13] <Gizwiz> ofc :)
[03:16:16] <obmij_> hmm
[03:16:28] <obmij_> just came up with a good way of motion blur for player's head only
[03:17:24] *** KU0N has quit IRC
[03:17:49] *** rob12 has joined ##OpenGL
[03:18:36] *** obmij_ has quit IRC
[03:19:02] <rob12> man glXIntro references glIntro but I don't have it. why? I have opengl-manpages installed.
[03:20:07] *** Dew420 has joined ##OpenGL
[03:21:24] *** Amorphous has quit IRC
[03:22:20] *** prophile has quit IRC
[03:33:48] *** Burga__ is now known as Burga
[03:42:44] *** florian has joined ##OpenGL
[03:42:52] <florian> Hi!
[03:43:17] <florian> If i want to draw points/lines with a different thickness, how to do?
[03:43:42] *** dv_ has joined ##OpenGL
[03:46:48] <florian> ok, got it :-)
[03:46:51] <florian> bye
[03:46:58] *** florian has quit IRC
[04:00:58] *** oogaw has joined ##opengl
[04:03:51] *** ectropy has quit IRC
[04:05:25] *** rnx has left ##opengl
[04:06:38] *** Wagoo has quit IRC
[04:08:12] *** BahamutZERO has joined ##OpenGL
[04:14:15] *** paragon has quit IRC
[04:41:08] <LiQuiDninja> hi, how can i save the currently loaded matrix to a float array[]?
[04:41:30] <HuntsMan> glGetFloatv(GL_MODELVIEW_MATRIX, v);
[04:41:43] <HuntsMan> GL_MODELVIEW is the correct token i think
[04:41:49] <HuntsMan> but you need to know what's the current matrix
[04:43:36] *** Burga__ has joined ##OpenGL
[04:43:47] *** JernejL_ has quit IRC
[04:44:47] *** Rangar has quit IRC
[04:47:04] *** Burga has quit IRC
[04:51:10] *** speedy1 has quit IRC
[05:09:24] <garou> Hi.
[05:09:52] <garou> Except when using very small scales, is there any good reason for using doubles instead of floats?
[05:11:11] *** Plagman has quit IRC
[05:11:23] <HuntsMan> no, they're aren't HW accelerated, so never use them
[05:11:24] *** Plagman has joined ##OpenGL
[05:11:25] *** Suprano has quit IRC
[05:12:00] <garou> Does something similar hold true for ints and longs?
[05:12:30] <HuntsMan> there's no longs in OpenGL
[05:12:41] <HuntsMan> you can use int's on geforce 8 i think
[05:12:46] <HuntsMan> at least it does integer processing
[05:13:11] <garou> What was the fourth type again, then?
[05:13:40] <HuntsMan> fourth type?
[05:13:42] <HuntsMan> bytes maybe :P
[05:14:36] <garou> Hm, doesn't really matter right now, I'll look it up later... On most HW there's not much difference between using floats and ints, either, I guess?
[05:15:35] <HuntsMan> on geforce 8 it does
[05:15:39] <HuntsMan> on others, no
[05:15:47] <garou> Thank you.
[05:15:54] <HuntsMan> in a geforce8 you can have integer textures, integer processing in GLSL, etc
[05:18:47] <garou> I'm pretty much out of the loop about models, is GeForce 8 more bleeding edge and here to stay or something of days gone by? ^^
[05:20:04] <HuntsMan> it's about two years old
[05:20:04] <HuntsMan> there are now GeForce 9's :P
[05:20:47] <garou> Days gone by then, I guess, or you'd have mentioned them too. :)
[05:21:08] <garou> That makes writing Guile bindings much easier. ^^
[05:23:51] <garou> Well, actually not easier, but less work, but what the heck... ^^
[05:29:51] <RTFM_FTW> actually doubles are HW accelerated on certain renderers
[05:30:19] <RTFM_FTW> and 32-bit signed / unsigned integers are accelerated on anything DX10 compliant
[05:30:47] <RTFM_FTW> support for that is exposed through extensions like GL_EXT_gpu_shader4
[05:31:09] <RTFM_FTW> and (in regards to integer texturing) GL_EXT_texture_integer
[05:31:34] <RTFM_FTW> this also isn't at all specific to Nvidia's GeForce8 series
[05:32:34] *** Knightingale has joined ##OpenGL
[05:33:36] <RTFM_FTW> in regards to my "double support" comment AMD's FireStream 9170 card offers support for double precision FP in the programmable pipeline
[05:34:00] <RTFM_FTW> of course that isn't at all a consumer GPU so its probably meaningless for most of the users here
[05:35:19] <Knightingale> hi. was wondering why my view ports are not displaying the same thing. one on each side of the screen. http://cpp.ninjacodemonkeys.org/4330
[05:35:45] <RTFM_FTW> also note that "bytes" aren't an exposed type in the programmable pipeline
[05:36:22] <garou> Ummm... Hmmm... Simplicity or completeness, that is the question then...
[05:36:43] <RTFM_FTW> all integers hold a 32-bit two's complement representation
[05:37:04] <RTFM_FTW> at least in regards to the GL pipeline
[05:48:57] *** blbmp has quit IRC
[05:49:26] *** blbmp has joined ##OpenGL
[05:54:22] *** [this] has quit IRC
[05:55:42] *** demio has quit IRC
[05:58:07] *** BahamutZERO has quit IRC
[06:04:41] *** TheLorax has joined ##opengl
[06:08:07] *** nathan__ has quit IRC
[06:10:50] *** wcstok has quit IRC
[06:18:01] *** hibread has quit IRC
[06:20:10] *** hibread has joined ##opengl
[06:24:29] *** rutski has quit IRC
[06:29:46] *** Burga__ is now known as Burga
[06:30:34] <garou> Hrm... "That looks funny" is nothing that'll help me get help debugging my app, right? ^^
[06:31:31] *** rutski has joined ##OpenGL
[06:41:22] *** nathan_ has joined ##OpenGL
[06:44:50] *** rob12 has left ##OpenGL
[06:58:31] *** rutski has quit IRC
[06:58:50] *** Knightingale has quit IRC
[07:00:46] *** mm^away has joined ##opengl
[07:07:43] *** Watermelon2 has joined ##OpenGL
[07:16:25] <garou> This is effectively my glutDisplayFunc: http://rafb.net/p/mjPOba63.html
[07:16:32] <garou> (It's C and Scheme)
[07:16:53] <garou> What it should do is set up the camera and draw a pyramid.
[07:17:06] <garou> What it should to is displaying blackness.
[07:17:58] *** mm765^away has quit IRC
[07:18:36] <garou> What is strange is that when I put the camera eye to 0 0 0 and the center on the rotating circle, I get a very strangely distorted pyramid.
[07:19:14] *** rhythm has joined ##Opengl
[07:19:22] <garou> If you'd like the complete code, I'll put it up in a sec...
[07:22:06] *** demio has joined ##OpenGL
[07:22:48] <garou> And here it is: http://www.kollektiv-hamburg.de/~garou/rtim/
[07:31:41] <garou> Heehehe... One part of the problem might be that the default viewing volume seems to be limited to [-1, 1] on all axes.
[07:35:06] <garou> Okay, I changed the model accordingly, now I have a pyramid that is seemingly changing its rotational direction every half rotation.
[07:35:24] <garou> It's as if the far surfaces would come to the front and vice versa.
[07:37:24] *** rutski has joined ##OpenGL
[07:38:18] <garou> Hmmmm... Do I have to activate face culling myself?
[07:38:32] <garou> 'Cause if so, that might be the solution...
[07:38:38] <Watermelon2> you are talking to yourself O_o?
[07:38:47] <garou> The last surface drawn is always on top.
[07:38:52] *** ectropy has joined ##OpenGL
[07:39:09] <garou> It seems so, I hope that someone will pick it up eventually before I solve it myself. ^^
[07:45:14] *** hd_ has joined ##OpenGL
[07:45:41] *** hd_ has left ##OpenGL
[07:46:36] *** Lucine2 has quit IRC
[07:48:03] <garou> Okay, the problem REALLY seems to be that vertices are just drawn on top of each other, not sorted by depth. I added GLUT_DEPTH to glutInitDisplayMode, glEnable(GL_DEPTH_TEST); and also added GL_DEPTH_BUFFER_BIT to glClear. What the heck am I missing?
[07:49:58] *** Lucine2 has joined ##OpenGL
[07:50:39] <Watermelon2> you have a screeenshot of the problem?
[07:51:37] *** Gizwiz has quit IRC
[07:52:47] <Watermelon2> perhaps you need to clear depth bit also
[07:53:05] <Watermelon2> and make sure you draw them in from-far-to-near order
[07:56:14] <garou> I thought I would do the first with GL_DEPTH_BUFFER_BIT?
[07:56:40] <garou> And the latter, can I make OpenGL do that for me? Or do I have to sort them myself?
[08:10:02] <garou> Ummm... fooo?
[08:10:27] *** TheLorax has quit IRC
[08:10:33] <garou> Do I have to sort? Can OpenGL sort for me? ^^
[08:13:31] *** Watermelon2 has quit IRC
[08:23:12] *** ectropy has quit IRC
[08:28:02] *** neoneurone has joined ##OpenGL
[09:02:32] *** [this] has joined ##opengl
[09:09:47] *** rhythm has quit IRC
[09:11:28] <LiQuiDninja> is there any way to introduce scaling to the render matrix?
[09:12:46] <garou> Like in http://www.glprogramming.com/red/chapter03.html under "Scale"?
[09:13:23] *** blbmp has quit IRC
[09:14:36] <HuntsMan> render matrix?
[09:18:44] *** rhythm has joined ##Opengl
[09:19:07] <garou> model view matrix, I'd assume.
[09:20:02] *** rhythm has quit IRC
[09:24:19] <LiQuiDninja> thanks for the tutorial, decided to scale the mesh on load to improve efficiency, dificult to tell if your overworking the rendering engine
[09:24:40] <LiQuiDninja> ill invest in a profiler near the project completion to find the real problems
[09:25:24] <MatthiasM> applying a scale to the model&view matrix will have no performance impact at all (beside the call to set the scale) - but it may affect your normals
[09:29:49] *** rhythm has joined ##Opengl
[09:30:53] *** rhythm has quit IRC
[09:32:37] *** Tenac has joined ##opengl
[09:34:23] *** scy has joined ##opengl
[09:34:56] <Tenac> Is there any article about how to set up an entity manager?  I have a great working texture manager for all my textures but I have no idea how to approach coding an entity manager for all my models/meshes.
[09:35:40] *** Yustme has joined ##opengl
[09:36:01] <MatthiasM> Tenac: depends heavily on your requirements
[09:36:37] <MatthiasM> if you only have static geometry (eg meshes that are not modified at runtime) you can just create a cache
[09:43:07] <Tenac> should I have a seperate mesh cache and model cache?  like I can have a bunch of entities models that sue the same mesh
[09:43:28] <Tenac> yikes, my spelling and grammar sucks
[09:46:43] *** Dew420 has quit IRC
[09:47:45] <MatthiasM> depends on what you mean with model
[09:48:17] <Tenac> I think I just need time to brainstorm actually lol
[09:54:05] <garou> BTW, can you define "entity"?
[09:55:25] *** lolage0 has quit IRC
[09:55:46] <Tenac> An object in my 3d world that you see/collide with/interact with.  Characters, powerups, trees, that stuff I guess.
[09:58:21] <garou> Ah... General objects. ^^
[09:58:48] <Tenac> that is the definition of an entity basically, right?
[09:58:53] <Tenac> I'm not 100% sure even lol
[09:59:51] <garou> Heh. I guess for me it then will be "anything that I put into my scene graph". :)
[10:15:54] *** groton has joined ##OpenGL
[10:27:39] *** nathan__ has joined ##OpenGL
[10:28:00] *** amz has quit IRC
[10:28:21] *** daniel_s has joined ##OpenGL
[10:28:36] *** LiQuiDninja has quit IRC
[10:28:54] *** nathan_ has quit IRC
[10:30:25] *** daniel_s has quit IRC
[10:37:15] *** dv_ has quit IRC
[10:40:42] *** rsaltini has quit IRC
[10:41:00] *** rsaltini has joined ##OpenGL
[10:50:12] *** dv_ has joined ##OpenGL
[10:58:52] *** amalon has joined ##opengl
[11:00:15] *** BahamutZERO has joined ##OpenGL
[11:08:14] *** neoneye has joined ##OpenGL
[11:12:15] *** LordMetroid has joined ##OpenGL
[11:15:21] *** rutski has quit IRC
[11:22:48] *** kaotrix has joined ##OpenGL
[11:31:54] *** dvoid has joined ##OpenGL
[11:39:14] *** LtJax has joined ##opengl
[11:41:40] *** danieljames has joined ##OpenGL
[11:41:44] *** danieljames has left ##OpenGL
[11:49:37] *** dvoid has quit IRC
[11:57:48] *** LordMetroid has quit IRC
[11:58:45] *** LordMetroid has joined ##OpenGL
[11:59:58] *** amalon has quit IRC
[12:02:26] *** daniel_s has joined ##OpenGL
[12:02:33] *** florian has joined ##OpenGL
[12:02:40] <florian> Hi!
[12:03:13] <garou> Hi.
[12:03:26] <florian> If i would like to texture a quad with an image which has not 2^n-sizes, how's the best way?
[12:06:31] <Jupp3> florian: Round up to closest valid texture size, and use that
[12:07:10] <Jupp3> then put the image in the texture (glTexSubImage2D or use valid size to begin with)
[12:07:40] <Jupp3> Then instead of using 0.0f-1.0f, use whatever area of the texture the image covers
[12:08:22] <MatthiasM> if you don't need mipmaps then use GL_TEXTURE_RECTANGLE as target
[12:08:47] <Jupp3> and hope that it's supported on all target platforms
[12:09:18] <MatthiasM> atleast it works on ATI as opposed to the NPOT extension :)
[12:09:27] *** IJs\laptop has joined ##OpenGL
[12:09:41] <Jupp3> OpenGL ES?
[12:10:44] <florian> Ok. I'm loading the images using qts qimage and then get the texture-data using qwidget::convertToGLFormat. So i have to create a seperate data-array and write my own routine to place the qimage-data in it?
[12:11:45] *** rnx has joined ##opengl
[12:12:49] <florian> I'm placing it into the left upper of the new array and the coordinates are (0,0) - (imageWidth/1024, 0) - (imageWidth/1024, imageHeight/1024) - (0, imageHeight/1024)? (if the image-width/height is >512 & <1024)?
[12:13:23] <MatthiasM> yes
[12:13:44] <MatthiasM> but clamp modes won't work then
[12:13:51] <florian> Hm, a lot to do ;-)
[12:14:59] <florian> That's ok, i'm rendering a camera and would like to texture the image-plane with the image the camera is viewing
[12:15:44] *** Suprano has joined ##OpenGL
[12:16:03] <florian> Thanks alot to all!
[12:17:57] *** andikr has joined ##opengl
[12:21:17] <Jupp3> florian: And there might be some problems with blending
[12:21:41] *** lordmetroid_ has joined ##OpenGL
[12:21:43] <florian> Jupp3: what kind of problems?
[12:22:01] <Jupp3> florian: You do know how blending works?
[12:22:16] <florian> I used it years ago
[12:22:19] <Jupp3> It blends the colors of adjacent pixels together
[12:22:44] <Jupp3> So it can happen that you'll blend pixels from the edges of the image with pixels outside the image
[12:22:44] <florian> Ah, i remember
[12:22:49] <florian> so at the edges
[12:22:50] <florian> yes
[12:23:01] <florian> How to handle that?
[12:23:29] <Jupp3> It won't matter if drawing "1 pixel to 1 pixel" with glOrtho
[12:23:38] <Jupp3> That's where I use it
[12:25:11] <florian> ok, but i'll think about that when i finished the first step :-)
[12:26:02] <florian> thanks for the advice
[12:29:25] *** kaotrix has quit IRC
[12:33:30] <rsaltini> glGetString(GL_VERSION) returns to me : 1.3 Mesa 7.0.1
[12:33:41] <rsaltini> i'm using ubuntu 7.10
[12:34:13] <rsaltini> But mesa 7.0.0 should implement opengl 2.0
[12:34:23] <rsaltini> i can't understand
[12:37:42] *** predaeus has joined ##opengl
[12:38:21] *** LordMetroid has quit IRC
[12:44:46] *** lordmetroid__ has joined ##OpenGL
[12:47:49] *** whoppix has quit IRC
[12:57:48] *** rsaltini has quit IRC
[13:01:11] *** lordmetroid_ has quit IRC
[13:02:30] *** pfo has joined ##OpenGL
[13:06:22] *** daniel_s has quit IRC
[13:09:15] *** dv_ has quit IRC
[13:09:58] <florian> Ok, now it works :-)
[13:13:56] *** lordmetroid__ is now known as LordMetroid
[13:18:06] *** gusnan has joined ##OpenGL
[13:21:08] *** prophile has joined ##opengl
[13:21:26] *** kramer3d has joined ##OpenGL
[13:21:43] <kramer3d> hi , how do you move the camera ?
[13:21:55] <kramer3d> is it gluPerspective?
[13:22:33] <kramer3d> nvm
[13:22:37] *** kramer3d has quit IRC
[13:22:43] <prophile> opengl doesn't have any concept of a camera
[13:23:00] <Burga> bloody fruit loops
[13:23:09] <prophile> to get the equivalent transform you'd use glTranslate ( -x, -y, -z ); or gluLookAt
[13:23:12] <prophile> not that you care
[13:23:13] <prophile> because you're gone
[13:23:15] <Burga> he's gone
[13:23:17] <prophile> also eugh
[13:23:19] <Burga> :)
[13:23:26] <prophile> i hate fruit loops
[13:23:29] <prophile> horrible things
[13:23:35] <prophile> especially when they're bloody
[13:23:43] <prophile> gives them that nasty metallic taste
[13:26:11] <florian> What does "bloody fruit loops" mean? :-)
[13:26:27] <prophile> fruit loops which have blood on them
[13:26:42] <prophile> is it not obvious!
[13:27:10] <florian> ok :-)
[13:32:43] <Burga> the "camera men"....
[13:33:55] *** emma_ has joined ##OpenGL
[13:35:53] *** JernejL has joined ##OpenGL
[13:36:17] <emma_> hello.  i have a question about translucency.  I believe that to achieve translucency, one must render primitives from back to front, using alpha blending.  How can this be done if you have a shape built from triangle strips?  Do the strips need to be z sorted in some way?  I would be grateful if anybody has any tips or links.
[13:39:15] <MatthiasM> emma_: if the strips are self overlapping then you need to split them into non overlapping parts which can be sorted
[13:39:38] <MatthiasM> or you could try depth peeling
[13:40:31] <emma_> ok thanks, i'll try googling for that
[13:47:26] *** prophile has quit IRC
[13:49:48] <Jupp3> emma_: In short, that's something that can become VERY complex
[13:50:37] <emma_> Jupp3: would it be easier to split into triangles and just z sort them?
[13:50:57] <Jupp3> emma_: The thing is, the sorting changes, when you rotate the object
[13:50:59] <LtJax> no, because they could still be intersecting
[13:51:10] <LtJax> that too
[13:51:16] <Jupp3> And when you start sorting triangles according to their distance from camera, it can become REALLY slow
[13:51:17] <MatthiasM> depending on your model you could create a simplified version for the transparent case
[13:51:18] <LtJax> depth peeling is the way to go imo
[13:51:53] <Jupp3> emma_: Of course you can try drawing the object without depth testing and see how it looks
[13:52:02] <MatthiasM> when the amount of change from frame to frame is not too large you could use an incremental sorting approch
[13:52:22] <emma_> oh dear, this sounds like a minefield
[13:52:39] <MatthiasM> and I suggest that you use indexed triangles instead of strips - they are easier to handle
[13:52:58] <MatthiasM> http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html
[13:53:20] <Jupp3> emma_: sounds like something you should avoid having to do :)
[13:53:41] *** dvoid__ has joined ##OpenGL
[13:53:56] <emma_> well I think I may have told my boss that it was fairly easy... oops
[13:54:16] <MatthiasM> heh
[13:54:30] <Jupp3> emma_: Have you tried how it looks without starting to sort triangles?
[13:54:52] <MatthiasM> emma_: disable depth testing and writes
[13:54:53] <emma_> the domain of the problem is quite simple thought, its basically a very translucent ship hull, inside of which i need to display some opaque cubes
[13:55:17] <MatthiasM> *only depth writes
[13:55:39] <emma_> MatthiasM: you mean just pile up the translucent bits on top of each other?
[13:56:05] <MatthiasM> render the last after all other objects and without depth writes
[13:56:14] <Jupp3> emma_: Are you using one sided faces?
[13:56:19] <MatthiasM> depending on your textures the results might be ok
[13:56:32] <emma_> no textures, just smooth shaded
[13:56:45] <MatthiasM> that should work
[13:57:23] <emma_> MatthiasM: so, render the opaque objects first with depth test on, then the translucent ones, but with depth testing off?
[13:57:39] <MatthiasM> with depth testing ON and depth writes off
[13:57:56] <Jupp3> emma_: Are you using one sided faces?
[13:57:58] <emma_> ah I see
[13:58:41] <emma_> Jupp3: ..actually I am not sure, I think they are double sided, it is C code exported from a 3DS model using Okino
[13:58:41] <Jupp3> Was just wondering if you wanted to see the "back" side of the faces further away through front sides facing you
[13:58:55] <Jupp3> emma_: glEnable(GL_CULL_FACE)
[13:59:00] <emma_> Jupp3: yes, probably
[13:59:12] <Jupp3> emma_: Becouse you can easily achieve seeing back faces through front faces
[13:59:19] <Jupp3> First draw only back faces, then only front faces
[13:59:29] *** greg_ has joined ##OpenGL
[13:59:47] <Jupp3> Of course that's not the ultimate solution that will always look 100% correct, but it's relatively lightweight, and looks quite nice in most cases
[14:00:30] <emma_> Ok, I see, I think that would be suitable, as it is only an 'overview', definately not going for accuracy here
[14:01:21] <Jupp3> emma_: With a simple cube, that will result in 100% "correct" result
[14:01:38] <Jupp3> Try enabling GL_CULL_FACE and see if the model looks different
[14:01:53] <Jupp3> Is the concept of back & front faces clear to you btw?
[14:02:39] <emma_> Do I need to set GL_FRONT then GL_BACK with that GL_CULL_FACE?
[14:03:26] <Jupp3> What do you mean?
[14:03:45] <Jupp3> Just try with only glEnable(GL_CULL_FACE) first
[14:03:55] <Jupp3> And make sure there's no glDisable(GL_CULL_FACE) anywhere :)
[14:04:36] <emma_> ok, i think that the Okino export has glDisable(GL_CULL_FACE).  I can't check because I'm not at work
[14:04:53] <Jupp3> emma_: Is the concept clear?
[14:05:01] <Jupp3> Do you mean what difference that makes?
[14:06:37] <emma_> Ok, heres what I understood, (i may be missing the point!) Draw the front faces by using GL_CULL_FACE, then use GL_BACK and GL_CULL_FACE to render the back faces over the top
[14:07:07] <emma_> so the inside of the ships hull can be seen
[14:07:30] <emma_> is that right?
[14:07:35] <MatthiasM> other way around
[14:08:23] <emma_> ok draw the back faces (the inside of the hull) then draw the front faces over the top with blending
[14:08:50] <Jupp3> glEnable(GL_CULL_FACE) enables the feature
[14:08:55] <emma_> So, am I right in thinking you need to do a glCullFace(GL_BACK) to draw he front faces only?
[14:09:02] <Jupp3> You need to use a different function to specify, which face you want to draw
[14:11:25] <MatthiasM> emma_: yep
[14:11:29] <emma_> So (just to bore everybody).  Draw inner opaque cubes.  Turn off depth *writes*.  Turn on alpha blending.  Draw back faces, then draw front faces.
[14:11:46] <MatthiasM> yep
[14:13:08] <emma_> Ok, now I know what I'll be doing next week.  Thanks guys.
[14:15:16] <Jupp3> emma_: And you should always use GL_CULL_FACE when drawing solids
[14:15:29] <Jupp3> That way you won't waste time drawing faces that are facing "in"
[14:15:36] <Jupp3> Assuming your model is 100% "closed"
[14:16:22] <emma_> yes i think it is
[14:17:18] <Jupp3> And even when it isn't, it's usually a better idea to just to draw every two sided face both ways, rather than forcing every face to be drawn both ways
[14:17:35] <Jupp3> I mean, just specify every two sided face twice, once for both directions
[14:18:27] <emma_> i see, that may be useful, as I think i may be eventually drawing some walls as single polygons- i.e. double sided.
[14:19:33] <Jupp3> Of course that's assuming most of your faces will be one sided
[14:20:17] <emma_> yes, the outer hull of the ship will be one sided, and is closed.  The inner opaque stuff may have double sided walls etc
[14:21:06] *** pfo_ has joined ##OpenGL
[14:21:33] *** pfo has quit IRC
[14:21:33] *** Tenac has quit IRC
[14:21:34] *** marcheu has quit IRC
[14:21:34] *** Tempoe has quit IRC
[14:21:35] *** t4bz has quit IRC
[14:21:35] *** LiraNuna has quit IRC
[14:21:38] *** Seeb has quit IRC
[14:22:21] *** andikr has quit IRC
[14:22:57] <emma_> ok.  i am off now...  to watch indiana jones.
[14:23:32] *** |t4bz| has joined ##OpenGL
[14:23:32] *** Tenac has joined ##OpenGL
[14:23:32] *** marcheu has joined ##OpenGL
[14:23:32] *** LiraNuna has joined ##OpenGL
[14:23:32] *** Tempoe has joined ##OpenGL
[14:23:32] *** t4bz has joined ##OpenGL
[14:23:32] *** Seeb has joined ##OpenGL
[14:24:51] *** nplus has quit IRC
[14:24:54] *** emma_ has quit IRC
[14:26:49] *** scy has left ##opengl
[14:26:50] *** nplus has joined ##OpenGL
[14:32:46] *** daniel_s has joined ##OpenGL
[14:36:20] *** daniel_s has quit IRC
[14:36:50] *** mastro has quit IRC
[14:37:31] *** t4bz has quit IRC
[14:40:57] *** Suprano has quit IRC
[14:41:08] *** Maerz has joined ##OpenGL
[14:41:44] *** predaeus has quit IRC
[14:48:48] *** nplus has quit IRC
[14:51:27] *** nplus has joined ##OpenGL
[15:11:33] *** predaeus has joined ##opengl
[15:25:36] *** LordMetroid has quit IRC
[15:35:19] *** Xmas| has joined ##OpenGL
[15:43:47] *** rnx has left ##opengl
[15:54:13] *** nathan__ has quit IRC
[15:59:28] *** ectropy_ has joined ##OpenGL
[16:01:08] *** [this] has quit IRC
[16:01:59] *** neric has quit IRC
[16:02:43] *** mm^away is now known as mm765
[16:21:27] *** LordMetroid has joined ##OpenGL
[16:24:54] *** scy has joined ##opengl
[16:27:54] *** Walt has quit IRC
[16:32:00] *** dolphin has joined ##OpenGL
[16:37:51] *** elite01 has joined ##opengl
[16:47:35] *** Morphous is now known as Ammorphous
[16:52:45] *** sohail has quit IRC
[16:52:47] *** Arc_ has joined ##OpenGL
[16:53:10] *** rsaltini has joined ##OpenGL
[16:56:05] <rsaltini> glGetString(GL_VERSION) returns me "1.3 Mesa 7.0.1"....but Mesa 7.x should implement opengl 2.1
[16:56:11] <rsaltini> i'm using ubuntu 7.10
[16:56:26] <rsaltini> I can't understand th problem
[17:04:12] *** Arc has quit IRC
[17:05:03] <LtJax> maybe only if you have a supported hardware accelerator?
[17:06:12] *** rsaltini_ has joined ##OpenGL
[17:06:43] <rsaltini_> glGetString(GL_VERSION) returns me "1.3 Mesa 7.0.1"....but Mesa 7.x should implement opengl 2.1. i'm using ubuntu 7.1. I can't understand th problem
[17:07:14] <rsaltini_> excuse me, i have problems with my internet connection
[17:07:48] <bobbens> 17:05 < LtJax> maybe only if you have a supported hardware accelerator?
[17:07:55] <bobbens> ^ all that was said in your absense
[17:08:27] <LtJax> yea, seems I wasn't right on that tho
[17:08:54] <LtJax> maybe there's a mesa channel somewhere where you could ask?
[17:08:59] <bobbens> i've got the same string :)
[17:09:07] <bobbens> OpenGL version string: 1.3 Mesa 7.0.3
[17:09:13] <bobbens> i thought mesa 7.1 did 2.1 though
[17:12:25] *** sohail has joined ##OpenGL
[17:14:36] <elite01> well, 7.0.3 is older than 7.1, isn't it?
[17:14:37] *** LtJax has quit IRC
[17:15:01] <bobbens> yes
[17:18:09] *** brutopia has quit IRC
[17:19:37] *** fargiolas has joined ##OpenGL
[17:19:43] *** rsaltini has quit IRC
[17:26:05] *** brutopia has joined ##opengl
[17:26:05] *** fargiolas has quit IRC
[17:26:06] *** fargiolas_ has joined ##OpenGL
[17:26:34] <HuntsMan> rsaltini_: and what's your video card?
[17:42:13] *** paragon has joined ##openGL
[17:47:10] *** groton has quit IRC
[17:49:59] *** Knightingale has joined ##OpenGL
[17:50:44] <Knightingale> any idea why my program would seg fault when i add the like glutFullscreen();? works fine in a window.
[17:52:20] <Jupp3> maybe you add it too early?
[17:53:06] <Jupp3> in other words, before glutInit
[17:53:32] <Knightingale> i add it right before glutCreateWindow, but after glutInit.
[17:53:54] <Jupp3> So that's the problem then
[17:54:01] *** Arc_ is now known as Arc
[17:54:04] <Jupp3> or no
[17:56:17] *** amz has joined ##opengl
[17:56:18] <Knightingale> thats not the problem. any other idea why fullscreen wont work?
[17:56:35] <Jupp3> Yes, I noticed that too
[17:56:52] <Jupp3> Of course that might depend on the OS aswell
[17:57:05] <Knightingale> Slackware 10.2.
[17:57:29] <Jupp3> What happens when a screen of defined resolution couldn't be opened might depend on the OS
[17:57:31] <gusnan> Knightingale, requested resolution isn't in xorg.conf? *guessing*
[17:59:08] <Knightingale> yeh, but what do you have to change?
[18:00:44] <Knightingale> if you use glutFullscreen, do you also have to call glutInitWindowSize and glutInitWindowPosition?
[18:01:27] <rsaltini_> my video card is ati
[18:01:34] <rsaltini_> mobile 9000
[18:01:39] <rsaltini_> RV250
[18:01:50] <HuntsMan> rsaltini_: ok, why it would support OpenGL 2.1?
[18:02:14] <HuntsMan> AFAIK it doesn't support even 2.0
[18:04:48] <rsaltini_> so it's due to my video card?
[18:05:32] <HuntsMan> yes
[18:05:50] <rsaltini_> where could I find which video cards support opengl 2.0?
[18:06:16] <HuntsMan> just the latest
[18:06:29] <HuntsMan> from the geforce 6 onwards, and radeon x1000 i think\
[18:06:33] <HuntsMan> not sure about ATI
[18:13:01] *** fargiolas_ has quit IRC
[18:13:45] *** fargiolas_ has joined ##OpenGL
[18:14:33] *** fargiolas_ is now known as fargiolas
[18:22:29] <RTFM_FTW> R5xx, R6xx, ... support GL 2.x
[18:22:56] <RTFM_FTW> of course there is limited support for GL_ARB_texture_non_power_of_two in the R5xx series
[18:28:05] *** Ammorphous has quit IRC
[18:31:26] <rsaltini_> ok, but where could I find a list of all video cards and opengl support for each?
[18:37:02] *** fargiolas_ has joined ##OpenGL
[18:51:08] *** juanmabc has joined ##opengl
[18:53:59] *** LordMetroid has quit IRC
[19:01:28] *** fargiolas has quit IRC
[19:03:30] <demio> hey guys
[19:03:39] <demio> does anyone here know a good algorithm to generate random potatoids
[19:04:31] <HuntsMan> perlin noise?
[19:05:46] <Jupp3> random potatoes
[19:06:50] <demio> ye
[19:06:51] <demio> s
[19:06:54] <demio> potatoids
[19:08:18] <demio> I want to generate random 3d objects with the form of a potato
[19:09:00] *** Tibor__ has joined ##OpenGL
[19:14:10] <bobbens> attack of the killer potatoids >_>
[19:15:35] *** ectropy_ has quit IRC
[19:20:54] *** demio has quit IRC
[19:27:28] *** rsaltini_ has quit IRC
[19:29:43] *** TheLorax has joined ##opengl
[19:44:25] *** sohail has quit IRC
[19:48:35] *** sohail has joined ##OpenGL
[19:49:53] *** Xmas| has quit IRC
[19:50:06] *** Xmas| has joined ##OpenGL
[19:58:33] *** prophile has joined ##opengl
[20:01:10] *** speedy1 has joined ##OpenGL
[20:01:16] *** stringfellow has quit IRC
[20:02:07] *** Knightingale has quit IRC
[20:02:13] *** |t4bz| has quit IRC
[20:02:41] *** t4bz has joined ##OpenGL
[20:05:42] *** ectropy_ has joined ##OpenGL
[20:06:48] *** Amorphous has joined ##opengl
[20:07:45] *** Amorphous has quit IRC
[20:07:57] *** Amorphous has joined ##opengl
[20:09:03] *** Amorphous has quit IRC
[20:09:15] *** Amorphous has joined ##opengl
[20:10:22] *** dolphin has quit IRC
[20:10:46] *** Amorphous has quit IRC
[20:11:14] *** Amorphous has joined ##opengl
[20:12:58] *** juanmabc has quit IRC
[20:13:49] *** scy has left ##opengl
[20:14:44] *** rutski has joined ##OpenGL
[20:16:56] *** Baba__ is now known as baballama
[20:23:09] *** mastro has joined ##OpenGL
[20:23:13] *** blbmp has joined ##OpenGL
[20:27:15] *** rnx has joined ##opengl
[20:38:28] *** TurboAWAY has quit IRC
[20:40:58] *** predaeus has quit IRC
[20:41:15] *** dv_ has joined ##OpenGL
[20:45:53] *** pfo_ is now known as pfo
[20:59:50] *** DobosCake has joined ##OpenGL
[21:04:54] *** fargiolas_ has quit IRC
[21:05:31] *** mm765 is now known as mm765^away
[21:05:36] *** Tibor__ has quit IRC
[21:05:57] *** runtime has joined ##OpenGL
[21:07:21] <runtime> You mind if I ask a slightly off-topic question in here?
[21:07:38] *** runtime has quit IRC
[21:07:46] *** Walt has joined ##opengl
[21:09:50] *** runtime has joined ##OpenGL
[21:11:16] <runtime> Yeah, so, as I was saying..
[21:17:26] *** lehka has joined ##OpenGL
[21:17:37] *** lehka has left ##OpenGL
[21:17:43] *** lehka has joined ##OpenGL
[21:17:58] <lehka> :-*
[21:18:07] *** lehka has left ##OpenGL
[21:18:45] *** runtime has quit IRC
[21:21:14] *** IJs\laptop has quit IRC
[21:35:11] *** groton has joined ##OpenGL
[21:36:50] *** numpsz1 has joined ##OpenGL
[21:37:25] <numpsz1> Hello! I am searching for a good opengl GUI library.
[21:37:32] <numpsz1> /linux compatible/
[21:38:51] <prophile> CEGUI
[21:40:19] <numpsz1> i have tried it
[21:40:31] <numpsz1> too many problems under Ubuntu linux
[21:41:59] <MatthiasM> why is everyone asking about GUI or text libraries ?
[21:42:32] <groton> because there should be a free and mature library which there is not
[21:43:39] <numpsz1> For ex.: I need it;)
[21:44:04] <prophile> CEGUI worked fine on loonix for me
[21:44:41] <numpsz1> I got segmentation faults.
[21:45:05] <numpsz1> on demo programs.
[21:45:05] <prophile> did you have all your so s in the right place
[21:45:25] <prophile> that's the most common cause of cegui segfaults
[21:45:42] <numpsz1> yes
[21:46:01] <numpsz1> but those seg faults are from libcegui.so
[21:46:04] <prophile> did you at least try debugging it?
[21:46:07] <MatthiasM> and why do you think that a segfault of a library that is used in ALOT of projects is the fault of the lib ?
[21:46:58] <prophile> the only real problems I've had with CEGUI are getting static linking working and getting the tools working
[21:47:21] <numpsz1> Matthiasm: Do you need the debugging results?
[21:47:35] <MatthiasM> why?
[21:48:28] <numpsz1>  MatthiasM: and why do you think that a segfault of a library that is used in ALOT of projects is the fault of the lib ?
[21:48:54] <MatthiasM> this question was for you
[21:48:57] <groton> lol
[21:49:01] <groton> MatthiasM,  now answer
[21:49:24] <MatthiasM> I have seen this lib in action on windows and linux system - I know it works :)
[21:49:54] <numpsz1> but, not on my box
[21:49:55] <MatthiasM> but I don't use it because I use LWJGL :)
[21:50:02] <MatthiasM> then fix yopur box :P
[21:50:55] <groton> ah, a Java guy
[21:50:57] <numpsz1> no, i have finished with ot/
[21:51:01] <numpsz1> it
[21:55:38] *** nplus has quit IRC
[22:00:48] *** SANiK has joined ##OpenGL
[22:02:01] <numpsz1> libufo is better...
[22:02:10] <numpsz1> works without problems
[22:02:12] <numpsz1> it
[22:02:31] <SANiK> I'm having a bit of a problem with timing
[22:02:52] <SANiK> e.g., if the game's supposed to run at 60 FPS, and on a PC it runs 80 FPS
[22:03:01] <SANiK> I calculate a Ratio to adjust for that
[22:03:11] <SANiK> Thing is - it causes jerky behaviour
[22:05:34] <SANiK> Since the FPS fluctuates between 60 FPS and 56 FPS (I'm just drawing 1 moving polygon so it's not an issue with overloading the GPU)
[22:05:53] <SANiK> I guess the solution would be to calculate the speed ratio only once instead of on every frame
[22:06:08] *** BahamutZERO has quit IRC
[22:06:16] *** TheLorax has quit IRC
[22:06:29] *** predaeus has joined ##opengl
[22:10:44] *** gusnan has quit IRC
[22:14:44] *** stringfellow has joined ##opengl
[22:33:05] *** neric has joined ##OpenGL
[22:44:07] *** numpsz1 has quit IRC
[22:45:45] <Weiss> SANiK: what does your ratio do?
[22:46:04] <Weiss> this sounds like something i was trying to do recently
[22:58:31] *** scy has joined ##opengl
[23:01:34] *** JKnife has joined ##OpenGL
[23:04:15] <JKnife> is there a way to use a C++ list to store vertex info and pass that on to OpenGL to render? (like a Vertex Array(
[23:04:29] *** Yustme has quit IRC
[23:04:43] <MatthiasM> yes
[23:05:01] <MatthiasM> but not list - use std::vector
[23:05:07] <prophile> you have to convert it to a contiguous array before OpenGL can use it
[23:05:11] <prophile> so yeah, convert to std::vector
[23:05:56] <JKnife> ok
[23:08:45] *** mm765^away is now known as mm765
[23:12:23] *** groton has quit IRC
[23:16:41] <SANiK> Weiss - e.g., for everything that moves in my world I do: pos.x+=2.0f*Ratio;
[23:17:01] <SANiK> Where 2.0f = amount of movement and the Ratio makes the movement "the same" no matter what the FPS
[23:17:19] <SANiK> Ratio=(1.0f/FPS); except when FPS = 0 then the Ratio=1.0f;
[23:17:30] <SANiK> (To prevent crazy shit from happening)
[23:18:11] <MatthiasM> you should look at fixed logic steps
[23:18:23] *** neoneurone has quit IRC
[23:18:52] <prophile> run yer physics in another thread
[23:20:23] <Jupp3> prophile: Why?
[23:20:43] <Jupp3> To needlessly complicate the whole program?
[23:20:52] <SANiK> Yes - exactly
[23:21:15] <SANiK> The Ratio works - the only problem is that the FPS fluctuates (Even if it's barely drawing anything)
[23:21:31] <SANiK> So I guess the best thing to do would be to collect FPSs for like 10 seconds
[23:21:37] <SANiK> And then use the average for the Ratio
[23:21:39] <Jupp3> What I do is, I check how much time went in drawing the frame
[23:22:01] <Jupp3> Then I have simple while loop that will run physics with constant step as many times as is needed to reach the delta
[23:22:03] <Jupp3> Then draw
[23:22:17] <MatthiasM> how do you measure your time ?
[23:22:42] <SANiK> return GetTickCount();
[23:22:51] <MatthiasM> that's the cause of your jitter
[23:22:54] <SANiK> haha
[23:23:09] <SANiK> I'm on Windows - what's the better alternative?
[23:23:18] <MatthiasM> QueryPerformanceCounter
[23:23:42] <Jupp3> MatthiasM: With SDL_GetTicks()
[23:23:55] <Jupp3> SANiK: Linux
[23:24:45] <MatthiasM> ?
[23:24:54] <Jupp3> MatthiasM: I thought you asked me
[23:25:13] <Jupp3> MatthiasM: As you asked the question straight after my explanation
[23:25:18] <MatthiasM> sorry :)
[23:25:20] *** SirRace has quit IRC
[23:25:24] <Jupp3> No problem
[23:25:39] <SANiK> Jupp3 - I ment the better alternative to "GetTickCount()" =P
[23:25:46] <Jupp3> :)
[23:25:55] <MatthiasM> SANiK: I told you :)
[23:25:58] <SANiK> I'm reading articles about QueryPerformanceCounter, and it's buggy on some CPUs =3
[23:26:12] <Jupp3> What isn't? :)
[23:26:13] <bobbens> Jupp3: best solution is variable dt, with fixed delta if under a threshold and skipping if under the critical threshold :)
[23:26:22] <bobbens> more complicated, but I loves it :P
[23:26:37] <Jupp3> SANiK: Are you running your physics with different delta each time?
[23:26:44] <Jupp3> Or rather, "not necessarily same delta"
[23:27:03] <SANiK> "not necessarily same delta
[23:27:15] <MatthiasM> SANiK: start your system with the "/pmtimer" option
[23:27:35] <Jupp3> SANiK: That can get physics really fucked up
[23:27:58] <Jupp3> In my game I could easily fly through walls with low framerate for example :)
[23:28:06] <SANiK> Yes I know =o
[23:28:13] <bobbens> that's why you need low fps fallbacks
[23:28:14] <Jupp3> Before when I didn't have constant delta
[23:28:20] <bobbens> mix both!
[23:28:39] <Jupp3> bobbens: It's fucked up anyway, if the fps is too low
[23:28:46] <bobbens> mine is fine
[23:28:57] <Jupp3> It doesn't make things any worse if the physics are still properly done
[23:29:01] <bobbens> i use variable delta, fallback to constant if needed, and if it's too larnge I skip
[23:29:06] <Jupp3> Well didn't quite understand what you mean
[23:29:21] <Jupp3> When do you need constant delta?
[23:29:30] <Jupp3> I mean, except "always" :)
[23:29:33] <MatthiasM> SANiK: http://www.geisswerks.com/ryan/FAQS/timing.html
[23:29:38] <SANiK> I remember wasting like 3 weeks to code a collision detection system. I was like, "OMFG - it works it works!" I then happily tried to drag the window to take a picture - but then the character falls through the floor =o
[23:29:50] <bobbens> Jupp3: when below a certaion fps
[23:29:55] <bobbens> when variable starts behaving poorly
[23:30:01] <bobbens> in my case it's under 50 fps :)
[23:30:10] <bobbens> runge kutta does very well above that :)
[23:30:21] <MatthiasM> SANiK: use sweeps for physics collision tests :D
[23:30:30] <bobbens> if i "cheat" a bit on AI I could lower it to 20 or so :)
[23:30:31] <Jupp3> bobbens: I get that, but can't see the point for variable delta if above that
[23:30:38] <bobbens> more precision
[23:30:44] <bobbens> unless your constant delta is very tiny
[23:30:52] <bobbens> which can cost performance :)
[23:31:15] <MatthiasM> physics don't produce the same result if run 2x as fast :)
[23:31:30] <bobbens> more precise :)
[23:31:39] <bobbens> i tested differences
[23:31:44] <bobbens> they aren't really that big
[23:31:53] <bobbens> but i might as well aim for more precision if the box can :)
[23:33:07] *** speedy1 has quit IRC
[23:33:39] <Jupp3> bobbens: And if you have constant delta, you can remove delta from all calculations
[23:33:50] <Jupp3> Or rather "make it 1.0f"
[23:34:07] <bobbens> no fun
[23:34:16] <bobbens> i like modelizing with ODEs and integrals
[23:35:22] <Makegho> Changing delta to 1.0f is bad because it forces you to use non-SI units
[23:35:39] <bobbens> on a side note, is a pixel SI? :P
[23:35:49] <SANiK> Good question... I doubt it
[23:36:00] <Makegho> Nope, but you don't use pixels as a measure anyway
[23:36:13] <bobbens> i do, because i don't really use realism :)
[23:36:20] <Makegho> huh, and you use opengl?
[23:36:25] <bobbens> need a conversion :P
[23:36:27] <bobbens> yes
[23:36:32] <bobbens> 2d only atm :)
[23:36:38] <SANiK> I use meters for the most part
[23:36:45] <Makegho> so you have set your own matrices and such :)
[23:36:57] <Makegho> why not.
[23:37:06] <bobbens> well glortho is screen size
[23:37:15] <bobbens> so it's always pixel
[23:37:20] <Jupp3> bobbens: But I admit that I do use once-per-frame physics for particles
[23:37:26] <bobbens> need to think of a good conversion
[23:37:31] <SANiK> bobbens - Well not true
[23:37:33] <Jupp3> As they're only for visualization, the "correctness" doesn't matter
[23:37:50] <SANiK> The GL manuals state that GL can be 1 pixel off in some implementations
[23:37:53] <Makegho> Jupp3: how about for user input?
[23:38:05] <Makegho> once-per-frame or more? :)
[23:38:10] <Jupp3> Makegho: Currently it's done in the physics loop
[23:38:17] *** stringfellow_ has joined ##opengl
[23:38:22] <bobbens> SANiK: i actually notice that sadly :)
[23:38:27] <Makegho> Do you implement frame skipping?
[23:38:31] <bobbens> mesa and my driver have off-by-one issues :P
[23:38:35] <Jupp3> Makegho: Doesn't make much difference where it is, but that's where it was in the beginning, and it takes some effort to move it :)
[23:38:40] <Makegho> Probably not then, so games will just slow down.
[23:39:03] <Jupp3> What you mean with "frame skipping"?
[23:39:44] <Makegho> If you're set timing to 100 fps but the gpu can draw only 70 frames per second, will the physics drop to 70 frames per second too and so will the game run with 70% speed?
[23:39:50] <Makegho> *you've
[23:40:12] <Jupp3> Makegho: Why would it do that?
[23:40:15] *** BahamutZERO has joined ##OpenGL
[23:40:30] <Jupp3> Makegho: I can easily run the game at 5fps, and physics at 100fps, for example
[23:40:43] *** predaeus has quit IRC
[23:40:44] <Jupp3> Sure, the controls are a bit "wrong"
[23:40:53] <Jupp3> But that's not a big issue, and I'm going to move it anyway
[23:41:04] <Makegho> Jupp3: what do you mean with once-per-frame physics then?
[23:41:07] *** Xmas| has quit IRC
[23:41:13] <bobbens> but you can't run game a 500 fps and physics at 500 fps!
[23:41:37] <Jupp3> Makegho: That's what I use for particles only
[23:42:00] <Jupp3> Makegho: They can be as wrong as they can, it doesn't really matter :)
[23:42:04] <Makegho> ok, sounds weird :)
[23:42:07] <Jupp3> Actually they don't even use delta
[23:42:21] <Jupp3> Or rather they get a constant delta
[23:42:26] <Jupp3> Even if the game doesn't have
[23:42:34] <Jupp3> Visual difference, no-one will care anyway
[23:42:49] <Makegho> (except if it makes it look bad :)
[23:43:09] <Jupp3> Makegho: That's why you can disable them if you really REALLY care about that :)
[23:43:25] <Jupp3> But the thing is, they're onscreen for average less-than-second
[23:43:46] <Makegho> just suppose that the particles are affected by gravity :)
[23:43:47] <bobbens> screenshot!
[23:44:04] <Makegho> well, but it's not important.
[23:44:07] <Jupp3> Basically I keep an average of framerate of X last frames, and use that to calculate speed for each new particle
[23:44:12] * Makegho goes back to debug :)
[23:48:15] <JKnife> ok, so using a Vector with Vertex Arrays would look something like this? http://nopaste.com/p/a6fDQxiYU
[23:50:26] <MatthiasM> no
[23:50:36] <MatthiasM> JKnife: this will crash
[23:51:22] <JKnife> >_>
[23:51:53] *** stringfellow has quit IRC
[23:52:05] <Makegho> that brings to my mind that std::vector is very slow
[23:52:26] <Makegho> at least if one uses iterators
[23:52:29] *** TheLorax has joined ##opengl
[23:53:18] <Jupp3> Isn't the point of C++ to make things look more simple than they are, rather than providing ways to do an efficient solution? :)
[23:53:46] <JKnife> yes :)
[23:54:09] <Makegho> I thought scripting languages were for that
[23:54:20] <JKnife> MatthiasM: o_O i ran it.. and it didn't crash.. it just didn't draw the triang;e
[23:54:32] <MatthiasM> you were lucky :)
[23:54:41] <JKnife> Makegho: guess you have never looked at a perl script :)
[23:54:44] <Makegho> I'm coding a raytracer and using std::vector was a HUGE bottleneck
[23:55:02] <MatthiasM> Makegho: then you used wrong
[23:55:49] <Makegho> I iterated through many structures. I changed my code to use [] instead and it got like 5 times faster
[23:56:08] <Makegho> I don't know why, I would really like to know :)
[23:56:30] <MatthiasM> Makegho: a good stl implementation will result in the same code for a vector as an array :)
[23:56:47] <Makegho> That's good to hear :)
[23:58:30] *** greg_ has quit IRC

   May 25, 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 | >