January 18, 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 18, 2009 [00:01:02] *** Ingenu has quit IRC[00:02:02] *** eXtronuS_ has quit IRC[00:05:33] *** lewymati has quit IRC[00:06:08] *** GNU\caust1c has quit IRC[00:06:09] *** Tempoe has quit IRC[00:06:09] *** ville has quit IRC[00:06:09] *** dindinx has quit IRC[00:06:32] *** dindinx has joined ##OpenGL[00:06:32] *** ville has joined ##OpenGL[00:06:32] *** GNU\caust1c has joined ##OpenGL[00:06:32] *** Tempoe has joined ##OpenGL[00:07:37] *** Tempoe has quit IRC[00:07:47] *** Tempoe has joined ##opengl[00:10:23] <sparky> ok, who here wants to know about the diffusion equation or the approximate boundary condition? I have recently become the fricken experto![00:10:42] <e_roder> go for it[00:10:54] <sparky> he he :)[00:11:03] <tmccrary1> http://www.chicagolandmustang.com/forums/showthread.php?t=29654[00:11:04] <tmccrary1> man[00:11:08] <tmccrary1> I cannot wait to upgrade my V[00:11:12] <tmccrary1> drawls[00:11:25] <sparky> e_roder: once and for all, no more unknowns in the damn 2001 skin paper by jensen[00:11:34] <sparky> I finally managed to derive all the equations[00:11:51] <e_roder> diffusion equation?[00:11:57] <sparky> that one too[00:12:03] <e_roder> tell me about that[00:12:08] <e_roder> i need to get started on lighting[00:12:23] <sparky> well, if you need to get started it's a rough place to start[00:12:24] <sparky> but[00:12:52] <sparky> essentially it's an equation that determines "fluence" at any point as a differential equation[00:13:06] *** Bollinger has quit IRC[00:13:09] <sparky> the fluence is an overall estimation of the amount coming in from all directions[00:13:10] <e_roder> i hate dif eqs[00:13:15] <sparky> so it's an isotropic evaluation[00:13:28] <sparky> of the incoming/outgoing light at each point[00:13:54] <sparky> amount in light that is[00:13:59] <sparky> was missing the light which is radiance[00:14:36] <sparky> maybe I should show you which paper I am referring to[00:14:44] <sparky> it's one I have been browsing through for quite some time now[00:14:55] <sparky> but obviously the paper doesn't derive the equations[00:15:01] <sparky> so it was quite a mouthful to get into[00:15:39] <sparky> http://graphics.ucsd.edu/~henrik/papers/bssrdf/[00:15:45] <sparky> that's the paper I am referring to[00:16:09] <sparky> and later on by jensen and a student this one http://graphics.ucsd.edu/papers/layered[00:16:53] <sparky> the diffusion equation is on page 2 in the first paper at the bottom right[00:17:29] <sparky> the solution to the differential equation is the fluence \phi(x)[00:18:02] <sparky> the fluence is what you would get if you were to integrate the radiance over all directions[00:18:29] <sparky> it's an isotropic evaluation of the overall amount of light flowing through the point x you could say[00:19:00] <sparky> the analysis in here is to derive analytically a BRDF from scattering and absorption properties[00:19:16] <sparky> when I first started most of it was way over my head[00:19:21] <sparky> but I finally got all of it cracked[00:19:36] <sparky> I had to buy ishimaru to do it and do a lot of reading though[00:20:00] *** rabbit- has joined ##OpenGL[00:20:38] *** eXtronuS_ has joined ##OpenGL[00:22:02] <sparky> there's an awful lot of things going on in the paper that requires inside knowledge of transport theory and the diffusion equation[00:22:18] <sparky> e_roder: mind you most people probably don't feel a need to derive every equation[00:22:21] <sparky> but I did[00:22:58] <sparky> I wanted to fully grasp all of it[00:23:07] *** scai has left ##opengl[00:31:34] *** eXtronuS_ has quit IRC[00:38:19] *** Yustme has quit IRC[00:43:41] *** Amorphous has quit IRC[00:43:52] *** x0rx0r has joined ##OpenGL[00:47:18] *** Amorphous has joined ##opengl[00:48:02] *** wisey has quit IRC[00:48:45] <emzic> how do i attach a depth texture to a framebufferobject?[00:49:56] *** GX has quit IRC[00:51:26] *** elite01 has joined ##opengl[00:52:43] <HuntsMan> using glFramebufferTexture2D[00:53:02] <emzic> ok, thanks![00:59:34] *** elite01 has quit IRC[00:59:34] *** boghog has quit IRC[01:00:46] <emzic> hmmm, is it possible that a depthtexture can not be attached if a colortexture is already attached?[01:02:59] <emzic> cause i am getting GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT[01:03:13] *** mm765 is now known as mm765^sleep[01:03:51] *** zacs7 has joined ##opengl[01:05:34] *** elite01 has joined ##opengl[01:06:24] *** boghog has joined ##opengl[01:07:30] *** elite01 has quit IRC[01:07:34] *** reprore_ has joined ##OpenGL[01:11:29] *** korff_home has quit IRC[01:11:43] <fusi> whats wrong with this:[01:11:46] <fusi> glDrawBuffer(GL_BACK);[01:12:01] <fusi> it gives me GL_INVALID_OPERATION[01:12:29] <fusi> right before that call i do this:[01:12:31] <fusi> BindFrameBuffer(0);[01:19:10] *** iion has joined ##OpenGL[01:19:15] *** pietia__ has joined ##OpenGL[01:19:19] *** KU0N has quit IRC[01:22:58] *** panquequinha has joined ##OpenGL[01:25:57] *** pablo has joined ##OpenGL[01:26:34] <pablo> hi, an app with opengl will be able to compile both in windows and in linux?[01:26:44] <HuntsMan> pablo: not directly[01:26:55] <pablo> HuntsMan: what do you mean[01:27:16] *** AlastairLynn has quit IRC[01:27:40] <HuntsMan> because you need platform specific APIs to create the OpenGL context[01:27:45] <HuntsMan> such as GLX, WGL, AGL, etc[01:27:53] <zacs7> HuntsMan: Or a wrapper[01:27:55] <zacs7> such as glfw[01:27:58] <HuntsMan> that can be abstracted by things such as SDL[01:28:15] *** nailora has quit IRC[01:28:16] <pablo> HuntsMan: while developing an opengl app, can a developer be in windows and another one be in linux without much trouble?[01:28:24] <zacs7> pablo: what language?[01:28:32] <zacs7> pablo: yes[01:28:34] <pablo> zacs7: c or c++[01:28:49] <Plagman> sure, a SDL/OpenGL application should be portable across Windows and Linux[01:29:01] <Plagman> lots of projects are this way, and developed by people using either one[01:29:11] *** karsten_ has quit IRC[01:29:13] <HuntsMan> pablo: yes[01:29:13] <pablo> Plagman: why it needs sdl?[01:29:23] <HuntsMan> pablo: within some limits, such as driver differences[01:29:35] <zacs7> pablo: not just SDL, but you need to wrap the OS specific stuff[01:29:39] <zacs7> SDL does that for you[01:29:43] <zacs7> as does glut and glfw[01:29:46] <Plagman> cause SDL handles the OS-specific OpenGL context creation[01:29:47] <zacs7> take your pick[01:30:04] <Plagman> but you can use something else or have both GLX and WGL code in the project[01:30:16] <pablo> zacs7: such as keyboard threads sockets. thats what you mean?[01:30:23] <zacs7> Not sockets[01:30:29] <zacs7> well maybe[01:30:35] <Plagman> keyboard, yes[01:30:40] <Plagman> threads, I don't think so[01:30:42] <zacs7> threads mostly...[01:30:49] <Plagman> sockets are already pretty much portable[01:31:05] <Plagman> since Winsocks is only regular sockets + trivial initialization code[01:31:17] <zacs7> + a bit of renaming[01:31:18] *** Rangar has quit IRC[01:32:24] <zacs7> glfw does threads[01:32:35] <zacs7> Although why wouldn't you use pthreads?[01:32:35] <HuntsMan> SDL also i think[01:33:02] <HuntsMan> does it works on windows?[01:33:11] <pablo> which opengl library you recomend[01:33:39] <HuntsMan> opengl library? what do you mean?[01:33:52] <zacs7> HuntsMan: yes[01:34:01] <panquequinha> glut?[01:34:05] <HuntsMan> zacs7: ok, didn't know that :)[01:34:10] <panquequinha> i guess is a good choise[01:34:25] <zacs7> glut is dead / dying has been for ages[01:34:33] <HuntsMan> yeah[01:34:35] <zacs7> I'd say glfw or SDL[01:34:35] <panquequinha> :([01:34:36] <HuntsMan> only for experiments[01:34:37] <panquequinha> so[01:34:37] <HuntsMan> not real work[01:34:43] <panquequinha> what still alive?[01:34:47] <zacs7> glfw[01:34:48] <zacs7> SDL[01:34:51] <panquequinha> sdl?[01:35:56] *** _JJR_ has joined ##OpenGL[01:38:20] <LoufoQ> free glut ?[01:38:50] <pablo> sdl implements opengl? if i install libsdl thats all i need[01:38:52] <panquequinha> what da reu[01:38:52] <pablo> ?[01:39:03] <panquequinha> i didn't know about that[01:39:18] <panquequinha> sdl is an idependent graphics library isn't?[01:39:21] <LoufoQ> pablo: yes.[01:39:59] <LoufoQ> Opengl is for graphics.[01:40:46] <LoufoQ> and Sdl/ Glut / Free glut / GLFW is the window "manager" wich say you when a key is pressed, the screen resized and host your opengl application[01:41:10] <panquequinha> hmm[01:41:21] <panquequinha> i didn't know about sdl[01:41:30] <HuntsMan> pablo: no, you need your graphics card drives, those implement OpenGL, not SDL[01:41:32] <LoufoQ> sdl is good[01:41:41] <LoufoQ> its a cross plateform =)[01:41:57] <panquequinha> and opengl not?[01:42:04] <panquequinha> yes[01:42:04] <panquequinha> ![01:42:10] <LoufoQ> but in glut and free glut, you can resize the window in your programm[01:42:20] <panquequinha> oh yes[01:42:28] <panquequinha> but somebody told me that glut was dead[01:42:33] <LoufoQ> and sdl, glfw has not theses features :'[01:42:39] <LoufoQ> yeas[01:42:43] <panquequinha> what a shame[01:43:09] <LoufoQ> but there is some projects continuing the works of the author =)[01:43:19] <LoufoQ> free glut , ...[01:43:58] <panquequinha> guess the best choise is do an own opengl manager...[01:44:05] <zacs7> panquequinha: No[01:44:11] <LoufoQ> good luck ;-)[01:44:13] <zacs7> panquequinha: Don't re-invent the wheel[01:44:23] <zacs7> What's wrong with glfw!?![01:44:29] <panquequinha> nothing[01:44:37] <LoufoQ> we cannot resize the window in our code =)[01:44:39] <panquequinha> just that you don't learn nothing about opengl[01:44:47] *** _JJR_ has left ##OpenGL[01:44:49] <panquequinha> and you become dependent of it[01:45:09] <zacs7> LoufoQ: Yes you can[01:45:21] <panquequinha> [zacs7]: tell this to sdl creator....[01:45:39] <zacs7> Use glfw or SDL and shh[01:45:46] <LoufoQ> zacs7: please, say me with wich function =)[01:46:15] <zacs7> Destroy the window and recreate it[01:46:29] <zacs7> LoufoQ: Windows are resizable in glfw anyway[01:46:30] *** GuShH has quit IRC[01:46:54] <LoufoQ> zacs7: i'm sorry, i have found the functions ^^ Sorry again =)[01:47:00] *** pietia has quit IRC[01:47:02] *** pietia__ has quit IRC[01:47:09] <LoufoQ> glfwSetWindowPos[01:47:21] <fusi> huh found my problem, i was deferencing to an incorrect value, not 0[01:47:33] <fusi> got fbo's working[01:47:39] <fusi> but theyre making my scene blue :([01:47:42] <fusi> no idea why :)[01:48:12] <LoufoQ> zacs7: Is GLFW is maintained ?[01:48:18] *** Marin__ has quit IRC[01:49:17] <zacs7> Yes[01:49:39] <LoufoQ> beacause i see the last update is sep 01 2007[01:49:55] <fusi> http://91.135.13.31/strange.jpg[01:50:01] <LoufoQ> and i am seeking a maintained opengl manager[01:50:47] *** HuntsMan has quit IRC[01:53:51] *** LoufoQ has quit IRC[01:55:09] *** pablo has quit IRC[01:59:24] *** x0rx0r has quit IRC[02:00:54] <sparky> e_roder: well, you asked :)[02:09:06] *** iion has quit IRC[02:09:52] *** GuShH has joined ##OpenGL[02:11:29] *** iion has joined ##OpenGL[02:12:35] *** emzic has quit IRC[02:15:12] *** b0000 has quit IRC[02:15:52] *** LtJax has quit IRC[02:19:24] *** rorokimdim___ has joined ##opengl[02:19:30] *** rorokimdim___ has quit IRC[02:21:07] *** neoneye has quit IRC[02:23:06] *** Cultz has joined ##OpenGL[02:28:57] *** iion has quit IRC[02:30:42] *** johndoe has quit IRC[02:31:27] *** phrosty has quit IRC[02:50:32] *** reprore_ has quit IRC[02:52:17] <fusi> whats the best method of rendering text[02:52:42] <fusi> immediate mode? display lists? render to texture?[02:54:07] <tmccrary1> dynamic vbo w/ some kind of glyph caching scheme[02:54:13] <tmccrary1> to reuse common combinations of characters[02:54:34] *** panquequinha has left ##OpenGL[02:54:41] <tmccrary1> RTT is more or less an extreme way of caching[02:55:09] *** bijoo_appdev has quit IRC[02:55:40] *** Ram2 has joined ##OpenGL[02:55:44] *** Cultz has quit IRC[02:55:54] <Ram2> hi[02:55:55] *** bijoo_osdev has quit IRC[02:55:59] *** iion has joined ##OpenGL[02:56:11] *** dvoid has quit IRC[02:57:25] <fusi> thanks tmccrary1[02:57:58] <fusi> not sure how such a glyph caching scheme would work[02:58:00] <fusi> ill google[03:02:20] <tmccrary1> you can implement the caching scheme after you get the rendering stuff working[03:02:24] *** amz has quit IRC[03:02:25] <tmccrary1> I wouldn't worry about it at first[03:02:45] *** vade has joined ##OpenGL[03:03:40] *** amz has joined ##opengl[03:07:33] *** iion has quit IRC[03:12:57] *** Suprano has quit IRC[03:13:19] <fusi> :)[03:13:23] <fusi> wanna get text on the screen to aid debugging :)[03:15:26] *** phrosty has joined ##opengl[03:15:58] *** cplusplus has quit IRC[03:22:43] *** HuntsMan has joined ##opengl[03:24:53] <e_roder> fusi, one thing you could do[03:25:02] <e_roder> is first run a console app, and then start up a window[03:25:16] <e_roder> that way you can make printf calls and such[03:25:30] *** e_roder has quit IRC[03:27:05] <Ram2> how make multipass in gl ?[03:27:20] <RTFM_FTW> render to texture[03:28:04] <RTFM_FTW> using GL_EXT_framebuffer_object would be one approach[03:29:36] <Ram2> i known use the fbo but i dont see clearly the step for multipass shader :([03:30:22] <RTFM_FTW> umm it should be pretty obvious to you :P[03:31:04] <Ram2> :)[03:31:06] <RTFM_FTW> (a) render scene into texture -> (b) render texture from (a) to screen[03:31:17] <RTFM_FTW> repeat (a) and (b)[03:31:44] *** vade has quit IRC[03:36:30] <Ram2> thx for your help RTFM_FTW[03:37:06] *** m4ggus has joined ##opengl[03:38:02] *** MatthiasM has quit IRC[03:38:08] *** MatthiasM has joined ##opengl[03:39:20] <RTFM_FTW> no problem[03:48:15] *** LordMetroid has quit IRC[03:52:15] *** Quentarez has joined ##OpenGL[03:53:47] *** ol1veira_ has joined ##OpenGL[04:04:03] *** sparky has quit IRC[04:06:05] *** bijoo_appdev has joined ##OpenGL[04:06:05] *** bijoo_osdev has joined ##opengl[04:08:20] *** Tibor__ has quit IRC[04:21:27] *** montana has quit IRC[04:29:18] *** Spkka has quit IRC[04:33:01] *** LordMetroid has joined ##OpenGL[04:34:44] *** m4ggus has quit IRC[04:37:07] <forrestv> anyone know of open source software that can reconstruct 3d models from a movie of them?[04:37:39] <tmccrary1> you mean like a magic program that runs on love and fairy dust in the sorcerers kingdom?[04:39:18] <forrestv> tmccrary1, no. there are real programs that do this, but im wondering if there are any oss ones[04:52:02] *** bijoo_appdev has quit IRC[04:52:02] *** bijoo_osdev has quit IRC[04:54:31] *** GinoMan has left ##OpenGL[05:00:25] *** kbotnen has joined ##OpenGL[05:15:00] <fusi> rofl tmccrary1[05:18:35] *** kornerr has joined ##OpenGL[05:18:42] <kornerr> hi[05:20:20] <GuShH> hi kornerr[05:20:48] <kornerr> does Z go positive outside monitor?[05:22:58] <kornerr> ah, yes[05:31:15] *** Ram2 has left ##OpenGL[05:33:32] *** LordMetroid has quit IRC[05:44:04] *** zacs7 has quit IRC[05:48:18] *** plasticpool has quit IRC[06:13:19] *** zacs7 has joined ##opengl[06:14:13] *** kbotnen has quit IRC[06:30:22] *** sedeki has quit IRC[06:39:32] *** ol1veira_ has quit IRC[06:44:18] *** korff_home has joined ##OpenGL[06:47:33] *** ol1veira_ has joined ##Opengl[06:53:14] *** DanielFalck has joined ##OpenGL[06:57:12] *** zacs7 has quit IRC[07:15:30] *** Kasu- has joined ##OpenGL[07:17:23] *** vampirefrog has joined ##OpenGL[07:17:43] *** vampirefrog has quit IRC[07:36:42] *** urnotE has joined ##OpenGL[07:52:45] *** urnotE` has quit IRC[07:55:38] *** Kasu- has quit IRC[08:02:11] *** reprore_ has joined ##OpenGL[08:09:07] *** oogaw has joined ##opengl[08:11:47] *** pwned has quit IRC[08:12:54] *** pwned has joined ##opengl[08:14:39] *** nailora has joined ##OpenGL[08:25:16] *** Wagoo has quit IRC[08:32:26] *** Eforen has quit IRC[08:34:06] *** neoneye has joined ##OpenGL[08:43:26] *** groton has joined ##OpenGL[08:52:08] *** vade has joined ##OpenGL[08:57:34] *** Eforen has joined ##opengl[09:00:00] *** NorthStar has left ##OpenGL[09:26:38] *** UUncia has joined ##OpenGL[09:49:20] *** sohail has quit IRC[10:02:47] *** PsiOmega has joined ##OpenGL[10:09:50] *** reprore_ has quit IRC[10:10:07] *** PsiOmegaDelta has quit IRC[10:11:02] *** PsiOmega has quit IRC[10:13:08] *** zacs7 has joined ##opengl[10:16:17] *** ville has quit IRC[10:16:27] *** ville has joined ##opengl[10:16:39] *** scai has joined ##opengl[10:16:40] *** vade has quit IRC[10:16:41] *** reprore_ has joined ##OpenGL[10:22:49] *** reprore_ has quit IRC[10:24:04] *** PsiOmega has joined ##OpenGL[10:37:47] *** Sneetsher has joined ##OpenGL[10:40:19] *** predaeus has joined ##opengl[10:41:13] *** PsiOmegaDelta has joined ##OpenGL[10:41:13] *** geocalc has quit IRC[10:41:52] *** geocalc has joined ##opengl[10:46:16] *** pietia has joined ##OpenGL[10:46:31] *** PsiOmega has quit IRC[10:47:02] *** Sneetsher has left ##OpenGL[10:47:03] *** nailora has quit IRC[11:00:23] *** gusnan has joined ##OpenGL[11:02:02] *** Yustme has joined ##OpenGL[11:06:06] *** XT95_ has joined ##OpenGL[11:10:52] *** Suprano has joined ##OpenGL[11:11:42] *** zacs7 has quit IRC[11:13:04] *** wey has joined ##opengl[11:18:00] *** b0000 has joined ##opengl[11:25:26] *** dvoid has joined ##OpenGL[11:27:32] *** Eforen has quit IRC[11:32:38] *** wey has quit IRC[11:33:02] *** cplusplus has joined ##OpenGL[11:41:30] *** karsten_ has joined ##OpenGL[11:49:32] *** eXtronuS_ has joined ##OpenGL[11:55:40] *** scai has left ##opengl[12:07:06] *** rnx has left ##opengl[12:09:02] *** zacs7 has joined ##opengl[12:09:29] *** Ingenu has joined ##OpenGL[12:10:31] *** XT95__ has joined ##OpenGL[12:15:54] *** karsten__ has joined ##OpenGL[12:22:29] *** emzic has joined ##OpenGL[12:25:33] *** elite01 has joined ##opengl[12:27:34] *** XT95_ has quit IRC[12:31:44] *** karsten_ has quit IRC[12:39:34] *** jm|afk has joined ##OpenGL[12:50:07] *** XT95___ has joined ##OpenGL[12:57:03] *** jm|earth has quit IRC[13:04:30] *** Rangar has joined ##OpenGL[13:04:51] *** XT95__ has quit IRC[13:06:35] *** drwhen has joined ##OpenGL[13:07:32] *** oogaw has quit IRC[13:19:34] *** UUncia_ has joined ##OpenGL[13:21:19] *** UUncia_ has quit IRC[13:39:54] *** Kasu- has joined ##OpenGL[13:40:45] *** zacs7 has quit IRC[13:40:51] *** dv_ has quit IRC[13:41:07] *** rabbit- has quit IRC[13:45:52] *** UUncia has quit IRC[14:00:12] *** Wagoo has joined ##opengl[14:00:32] *** jmd has joined ##OpenGL[14:01:46] *** Rangar has quit IRC[14:02:39] *** itewsh has joined ##OpenGL[14:12:40] *** neoneye has quit IRC[14:18:49] *** johndoevodka has joined ##opengl[14:22:59] *** f00bar80 has joined ##OpenGL[14:23:08] <f00bar80> i'm searching for a simple sample for Image Enhancement through Grey-Scale Modification or any other sample technique, if anyone can help me to where i can fin such a working sample , i searched google code but i need a working/executable one[14:23:09] *** jmd has quit IRC[14:24:02] <MatthiasM> search for paper - not code[14:24:16] <MatthiasM> once you understood the idea/concept/math - then start with code[14:25:03] <f00bar80> MatthiasM, can you help me regarding that ?[14:25:30] <MatthiasM> I did - search for papers/articles[14:26:39] *** pwned is now known as iddqd[14:26:39] <f00bar80> i did but i need a simple paper or articles regarding that[14:28:56] *** iddqd is now known as afro_ninja[14:30:43] *** AlastairLynn has joined ##opengl[14:51:22] *** qeed has joined ##opengl[14:52:41] *** predaeus has quit IRC[14:54:54] *** groton has quit IRC[15:02:55] *** pietia has quit IRC[15:14:39] *** pietia has joined ##OpenGL[15:15:28] *** boghog has quit IRC[15:17:39] *** calav3ra_ has joined ##opengl[15:25:55] *** m4ggus has joined ##opengl[15:26:19] *** Suprano has quit IRC[15:26:49] *** TiLex has joined ##opengl[15:26:58] *** Suprano has joined ##OpenGL[15:34:49] *** groton has joined ##OpenGL[15:35:33] *** calav3ra has quit IRC[15:41:34] *** stringfellow has quit IRC[15:45:48] *** boghog has joined ##opengl[15:51:59] *** reprore_ has joined ##OpenGL[15:58:08] *** LordMetroid has joined ##OpenGL[16:06:04] *** hdon has quit IRC[16:08:59] *** HuntsMan has quit IRC[16:31:48] *** f00bar80 has quit IRC[16:32:10] *** f00bar80 has joined ##OpenGL[16:33:12] *** |t4bz| has joined ##OpenGL[16:33:57] *** TiLex has quit IRC[16:39:00] *** maxton has quit IRC[16:50:22] *** t4bz has quit IRC[16:53:13] *** AlastairLynn has quit IRC[16:58:45] *** LordMetroid has quit IRC[17:04:09] *** wisey has joined ##OpenGL[17:12:45] *** LordMetroid has joined ##OpenGL[17:17:43] *** XT95___ has quit IRC[17:19:17] *** XT95___ has joined ##OpenGL[17:25:40] *** reprore__ has joined ##OpenGL[17:27:46] *** RTFM_FTW has quit IRC[17:28:21] *** RTFM_FTW has joined ##OpenGL[17:37:36] *** reprore_ has quit IRC[17:41:41] *** sparky has joined ##OpenGL[17:42:27] *** reprore has joined ##OpenGL[17:48:55] *** HuntsMan has joined ##opengl[17:54:16] *** eXtronuS_ has quit IRC[17:55:19] *** AlastairLynn has joined ##opengl[17:57:37] *** f00bar80 has quit IRC[17:57:51] *** f00bar80 has joined ##OpenGL[17:58:17] *** Sudi has joined ##OpenGL[18:00:16] *** reprore__ has quit IRC[18:02:47] *** stringfellow has joined ##opengl[18:05:04] *** groton has quit IRC[18:07:01] *** suppahsrv has quit IRC[18:09:23] *** stevosICBM has joined ##OpenGL[18:09:50] *** suppahsrv has joined ##OpenGL[18:10:02] *** lewymati has joined ##OpenGL[18:11:28] *** kornerr has quit IRC[18:13:39] *** kornerr has joined ##OpenGL[18:14:05] <GNU\caust1c> is a vbo more efficent than a display list?[18:14:17] <GNU\caust1c> assuming i dont want to change the vertex data[18:15:04] <RTFM_FTW> they can be[18:15:14] *** stevosICBM has quit IRC[18:16:11] <RTFM_FTW> I'd recommend profiling both approaches on your target hardware[18:16:44] <RTFM_FTW> assuming your vertex / color / texture coordinate data (in the display list) is well structured they should be quite close[18:17:39] <GNU\caust1c> i read somewhere that displaylists are internally stored by vbos, but this isnt correct?[18:18:07] <RTFM_FTW> how display lists are handled internally is implementation dependent[18:18:33] <RTFM_FTW> on a modern driver they are likely handled as static (vertex) buffer objects[18:19:03] <emzic> hello, is there a way to visualize the depthtexture attached to a FBO? cause if i just visulize it with the id from the depth-texture it is all white.[18:19:18] <GNU\caust1c> ok, thx :)[18:24:22] <MatthiasM> emzic: you need to set the depth compare mode to render it[18:24:35] <MatthiasM> and white would mean far, black near[18:25:08] <RTFM_FTW> personally I'd suggest reading the extensions I mentioned a few days ago...[18:25:09] <emzic> ok thanks, i have set it like this glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE);[18:25:15] <emzic> is that correct?[18:25:22] <RTFM_FTW> that is half of it[18:25:27] <MatthiasM> that is if you want to do shadow mapping[18:25:39] <RTFM_FTW> what is your depth comparison function?[18:25:41] <MatthiasM> for displaying it as texture that's wrong[18:25:45] <emzic> yes, shadow mapping is what i want to do :)[18:25:55] <RTFM_FTW> the above is your texture comparison function[18:26:07] <emzic> ah, i think i see...[18:26:35] <RTFM_FTW> if you had actually bothered to read though the extension specifications I linked you would have realized this[18:26:43] <emzic> i also need to set a depth-compare function?[18:26:54] <RTFM_FTW> ARB_shadow explains this quite well[18:27:00] <emzic> those extensions are quite hard to anderstand if you are new to the topic[18:27:06] <emzic> *understand[18:27:20] <MatthiasM> emzic: complaining about doesn't help you to understand[18:27:49] <RTFM_FTW> OK the texture compare enum will enable *or* disable the R comparison during texture sampling[18:28:08] <emzic> MatthiasM: i did not complain, i just said that it is not easy to understand[18:28:11] <RTFM_FTW> the comparison function used during that step is set via the depth comparison enum[18:28:33] <emzic> RTFM_FTW: thanks![18:28:41] <RTFM_FTW> for example *_COMPARE_4_TO_TEXTURE + *_LEQUAL gives me a R comparison using LE as my comparison function[18:28:50] <RTFM_FTW> err *_COMPARE_R_TO_TEXTURE[18:29:29] <RTFM_FTW> now the [0, ..., 1] value returned from the shadow compare can be further adjusted by ARB_shadow_ambient[18:30:01] <RTFM_FTW> and EXT_shadow_funcs allows the full range of depth compare enums to be used for the R comparison[18:30:09] <emzic> so i forgot to set the compare function[18:30:45] *** stevosICBM has joined ##OpenGL[18:30:53] <MatthiasM> emzic: what do you want to do ? visalize or shadow map ?[18:30:54] <RTFM_FTW> ARB_fragment_program_shadow brings ARB_shadow into the programmable realm[18:30:59] *** repror___ has joined ##OpenGL[18:31:13] <RTFM_FTW> and that extension is supported through GLSL as well[18:31:31] <emzic> MatthiasM: both actually, first visualize so that i can see the depthmap is filled correctly[18:31:41] <emzic> then i want to use it as a shadowmap[18:31:48] <MatthiasM> emzic: you need to set a different compare mode[18:31:57] <MatthiasM> for visualize and for shadow mapping[18:32:06] *** reprore has quit IRC[18:32:08] <emzic> aha, thanks![18:32:12] *** repr_____ has joined ##OpenGL[18:35:01] <stevosICBM> If I have multiple sets of vertex data and multiple element arrays, all in VBO, how do I use glMultiDrawElements on them? Do I need to pack all the vertices together and all of the elements together?[18:35:33] <MatthiasM> stevosICBM: if you want to use a single call then yes[18:37:49] <RTFM_FTW> if you need to visualize the depth texture (versus performing the depth compare for the shadow map) then you don't want GL_COMPARE_R_TO_TEXTURE... you want GL_NONE[18:37:53] *** ol1veira_ has quit IRC[18:38:26] <RTFM_FTW> GL_NONE + whatever depth comparison function you are using[18:39:01] <stevosICBM> Matthias: Is that going to be any faster? My concern now is that I'm spending a lot of time doing memcpy in glDrawElements... I think it's because I'm rebinding buffers so often.[18:39:21] <RTFM_FTW> just remember that *_TEXTURE_COMPARE != *_DEPTH_COMPARE :D[18:39:43] <MatthiasM> Stevethepirate: copying memory slow, multiple draw calls slow, so benchmark[18:40:44] <MatthiasM> *stevosICBM[18:41:16] <emzic> RTFM_FTW: thanks.[18:42:18] <emzic> i am using a shader to write the depth information to an FBO, do i need some special commands to write the depth information or is gl_FragDepth = depth; ok?[18:43:03] <MatthiasM> emzic: depth is always written when you have depth writes enabled[18:43:13] <MatthiasM> and you should not assign to gl_FragDepth[18:43:22] <emzic> ok thanks![18:43:41] *** mads- has joined ##OpenGL[18:44:22] *** predaeus has joined ##opengl[18:48:53] *** LtJax has joined ##opengl[18:50:14] *** repror___ has quit IRC[18:51:59] *** wey has joined ##opengl[18:58:23] *** monkey_d_luffy has left ##OpenGL[19:00:40] <emzic> is there a way to get the inverse of a matrix in GLSL?[19:05:34] <LtJax> depends[19:05:51] <LtJax> GLSL defines the inverse of a few GL matrices[19:11:43] *** XT95__ has joined ##OpenGL[19:12:24] *** m4ggus has quit IRC[19:13:17] *** cmang has quit IRC[19:14:05] *** XT95___ has quit IRC[19:17:38] *** itewsh has quit IRC[19:18:13] *** itewsh has joined ##OpenGL[19:18:59] *** KU0N has joined ##opengl[19:20:17] <emzic> LtJax: thanks, but i am looking for an inverse of a general matrix. (one i pass with uniform mat4)[19:25:28] <MatthiasM> emzic: pass the inverse matrix - computing an inverse per vertex/fragment would be wasting a lot of computing power[19:27:00] <MatthiasM> you should not perform any math on uniform values - do that before passing the uniforms[19:31:58] *** Renderwahn has joined ##OpenGL[19:34:31] *** iion has joined ##OpenGL[19:38:52] *** scai has joined ##opengl[19:42:34] <GNU\caust1c> is the accumulation buffer something deprecated? i fear being attacked by velociraptors :D[19:43:03] <emzic> MatthiasM: thanks. yeah that makes sense[19:47:33] *** f00bar80 has quit IRC[19:50:35] <predaeus> GNU\caust1c, yes I think it is, but check the docs http://www.opengl.org/registry/doc/glspec30.20080811.pdf[19:52:35] *** mm765^sleep is now known as mm765[19:52:45] *** stevosICBM has quit IRC[19:53:36] <GNU\caust1c> doesnt look like its deprecated[19:56:49] <predaeus> GNU\caust1c, oh yea it isn't. I read somewhere that it will be. Currently it is optional and with RTT it is probably obsolete.[19:57:04] <RTFM_FTW> actually glAccum isn't likely to put you on the "fast path"[19:57:16] <GNU\caust1c> hm[19:57:23] <GNU\caust1c> so what is the fast solution?[19:57:27] <RTFM_FTW> specifically since anything done through glAccum can be done through RTT via FBO[19:57:39] <RTFM_FTW> so use FBO[19:57:59] <GNU\caust1c> what does rtt stand for?[19:58:07] <RTFM_FTW> render to texture[19:58:16] <GNU\caust1c> ah, ok[19:58:19] <fusi> is an fbo valid if its only got a depth attachment?[19:58:25] <RTFM_FTW> GL_EXT_framebuffer_object would be the specification to note here[19:58:51] <GNU\caust1c> so i would take maybe 5 textures and blend them over each other?[19:59:08] <GNU\caust1c> to have motion bluring for example[20:00:50] <predaeus> yes[20:03:36] *** jm|afk has quit IRC[20:03:59] *** sohail has joined ##OpenGL[20:04:17] <fusi> what is the direction of view by default[20:04:27] <fusi> alng -z isnt it?[20:04:53] <sparky> that it is[20:05:12] <fusi> ive done something very strange with my matix class[20:05:19] <fusi> everything is inverted :/[20:05:53] <sparky> and now you want to sell it?[20:06:17] <fusi> im not a saleswoman :)[20:07:02] <fusi> i was using quats[20:07:08] <fusi> and they worked[20:07:10] <fusi> but were slow[20:07:16] <fusi> so i thought mmm try matrices[20:07:21] *** GX has joined ##OpenGL[20:07:23] <fusi> rushed it i think[20:07:29] *** iion has quit IRC[20:11:35] <sparky> fusi: what are you using to setup the projection?[20:11:45] <sparky> glFrustum?[20:12:15] <sparky> near and far are giving as distances (ie. positive) eventhough the camera is looking along -Z[20:12:19] <sparky> given[20:12:43] <fusi> newp[20:12:56] *** cplusplus2 has joined ##OpenGL[20:13:15] <fusi> http://rafb.net/p/JlG6CJ61.html[20:13:19] *** cplusplus has quit IRC[20:13:48] <fusi> oooh a rogue tab[20:15:43] *** KU0N has quit IRC[20:17:48] *** HuntsMan has quit IRC[20:31:35] *** Gorgoroth has joined ##OpenGL[20:34:18] <dennda> Hey. Is any of you guys aware of some programming example that is called something with a "sponge"? The aim is to take a cube and successively make holes into it. I am looking for a name to google for[20:34:36] <dennda> http://en.wikipedia.org/wiki/Menger_sponge[20:34:39] <dennda> :-)[20:35:11] <predaeus> fusi, isn't there a lot missing? http://www.opengl.org/sdk/docs/man/xhtml/glFrustum.xml[20:37:54] <dennda> Hm how would you best realize that with OpenGL?[20:39:03] *** vade has joined ##OpenGL[20:46:27] *** LtJax has quit IRC[20:46:55] *** groton has joined ##OpenGL[20:49:54] *** qeed has quit IRC[20:58:17] *** predaeus has quit IRC[21:05:56] *** HuntsMan has joined ##opengl[21:08:18] *** XT95__ has quit IRC[21:08:19] *** XT95___ has joined ##OpenGL[21:08:48] *** afro_nin1a has joined ##opengl[21:10:50] *** dv_ has joined ##opengl[21:12:32] *** afro_nin1a is now known as pwned[21:12:34] *** GuShH has quit IRC[21:13:39] *** Sudi has quit IRC[21:13:45] *** iammisc has joined ##OpenGL[21:13:58] <dennda> How do you only translate one object of your scene while leaving the others where they are?[21:14:08] <iammisc> do texture sizes need to powers of 2 or multiples of 2?[21:14:16] <RTFM_FTW> that depends[21:14:49] <RTFM_FTW> if you have support for GL_ARB_texture_non_power_of_two then no[21:15:30] <RTFM_FTW> if you have support for GL_ARB_texture_rectangle then the POT restriction is relaxed for 2D (RECT) targets[21:15:36] <iammisc> oh ok, so in an implementation without that extension, I'll have to resize it to a power of two right?[21:15:55] <dennda> say I got one glutSolidCube(1); and another one and I want to only move the first cube while keeping the second where it is[21:16:00] <RTFM_FTW> although that particular extension is still limited (i.e. non-normalized coordinates, limited WRAP, FILTER modes etc.)[21:16:18] <iammisc> dennda: use the modelview matrix[21:16:51] <iammisc> RTFM_FTW: so in an implementation without those 2 extensions does it have to be a power or multiple of 2?[21:16:58] <dennda> iammisc: Well, yeah, but if I got glTranslatef(1, 0, 1); glutSolidCube(1); glutSolidCube(1);, both cubes are translated (of course)[21:17:21] <iammisc> dennda use glPushMatrix();glTranslatef(1,0,1);glutSolidCube(1);glPopMatrix();glutSolidCube(1)[21:18:13] <dennda> iammisc: Does that work with an arbitrary number of cubes or just two?[21:18:51] <RTFM_FTW> if GL_ARB_texture_non_power_of_two then NPOT dimensions equals YES else if GL_ARB_texture_rectangle then NPOT dimensions (for RECT targets) equals YES else NO :P[21:18:56] <iammisc> dennda: that question really doesn't make sens[21:19:23] <dennda> iammisc: Ok I will just read up the commands you gave me and check whether it does what I want.[21:19:27] <dennda> Thanks already[21:19:57] <iammisc> RTFM_FTW: you're making this harder than what it is. So it has to be a power of two (2,4,8,16,32, etc.) not a multiple(2,4,6,8,10,12,14,16,18, etc)?[21:20:34] <RTFM_FTW> no you are actually[21:20:41] <RTFM_FTW> I've been perfectly clear[21:20:53] *** afro_ninja has quit IRC[21:21:11] <iammisc> RTFM_FTW: I asked if without those extensions do textures have to be a power of two size or a multiple of two? there are two answers: power or multiple[21:21:19] <RTFM_FTW> quoting myself: "if you have support for GL_ARB_texture_non_power_of_two then no" ... "if you have support for GL_ARB_texture_rectangle then the POT restriction is relaxed for 2D (RECT) targets"[21:21:28] <RTFM_FTW> I think that is pretty fucking clear[21:21:46] <iammisc> no is ambiguous in this context seeing as i don't know if you mean no to powers of two or no to multiples of two[21:22:29] <RTFM_FTW> extension (a) relaxes the POT requirement for *all* targets... extension (b) relaxes the POT requirement for 2D (RECT) targets only *and* it has a number of other limitations as well[21:22:36] <RTFM_FTW> this is *exactly* what I said[21:22:45] <iammisc> i'm not asking about extensions though[21:22:51] <iammisc> in a vanilla implementation[21:23:45] <RTFM_FTW> hmm ... if I don't have support for (a) *or* (b) then I suppose the answer would be ___ ?[21:23:53] <RTFM_FTW> heheh[21:24:12] <iammisc> according to http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/teximage2d.html, it says the width and height have to be 2m+2 (which means a multiple of 2), but from what i've read, it has to powers of two. I'm wondering which is right?[21:31:04] *** groton has quit IRC[21:35:30] *** rnx has joined ##opengl[21:44:36] <Ingenu> power of two it is[21:44:54] <Ingenu> it can be relaxed with texture rectangle extension and non power of two extension[21:45:21] <Ingenu> first uses 0..width 0..height coordinates, second uses normalized 0..1 coordinates[21:45:26] *** iion has joined ##OpenGL[21:46:07] <Ingenu> btw it says that the +2 is for border (1 pixel each side of the texture, in width, same in height)[21:46:10] <RTFM_FTW> yeah I already covered that[21:46:58] <Ingenu> ah, ok[21:56:36] *** mccbaka has joined ##OpenGL[21:58:41] <mccbaka> Hi... I'm having some issues with GL_FOG_MODE.[22:00:47] <mccbaka> I'm setting something up where I have some more or less flat things being drawn at various distances from the camera. I want things at a certain depth (1, actually) to be perfectly clear and precisely colored, and things further back to be dimmed out so that they don't distract the eye.[22:01:02] <mccbaka> I tested a couple different fog modes, and i found that GL_EXP2 looks the best.[22:01:21] <mccbaka> However, I also find that when I'm using fog mode GL_EXP2, EVERYTHING is darkened. even the stuff very close to the camera.[22:01:55] <Ingenu> I'd look up the fog equations if I were you[22:02:01] <mccbaka> i am looking at the fog equations[22:02:06] <mccbaka> and it looks like this is expected for gl_exp2[22:02:14] <Ingenu> I don't remember them, but you can find them in either the blue or red book (OpenGL Reference Manual, or OpenGL Programming Guide)[22:02:21] <mccbaka> f = e^-( (density dot z)^2)[22:02:26] <mccbaka> is the GL_EXP2 equation[22:02:29] <Ingenu> is there no linear fog in GL ?[22:02:31] <mccbaka> (although, i'm confused-- does "dot" just mean "times"?[22:02:41] <Ingenu> (I only use programmable hardware since years now)[22:02:45] <mccbaka> i see[22:03:45] <mccbaka> there is a linear fog mode and the linear fog mode can be set to start and stop at given distances. basically the problem is that it does not look as good. I have a use for the exponential fog mode, but i can't use it if it's going to dim out the entire screen the way it's doing currently.[22:04:07] <mccbaka> I was wondering if there is a trick to make exponential fog "start" at a specific distance.[22:04:11] <Ingenu> http://www.opengl.org/sdk/docs/man/xhtml/glFog.xml[22:04:13] <mccbaka> by Programmable hardware do you mean you use shaders for fog?[22:04:37] <Ingenu> shaders for the whole rendering process, I don't use "fixed function"[22:04:54] <Ingenu> (It's just a shader anyway on programmable hardware, not fixed silicon)[22:05:00] <mccbaka> i see[22:05:42] <mccbaka> what kinds of hardware support programmable shaders?[22:05:50] <mccbaka> i mean, how many years back do you have to go before they're no longer supported[22:05:53] *** wey has quit IRC[22:06:52] <Ingenu> if we are talking about modern stuff, it's GF5 (but slow in FP32) and RadeOn 9500[22:07:04] <Ingenu> starting from those generations, everything is programmable[22:07:27] <Ingenu> the R9500 was the first ATi chip w/o fixed function, the GF5 I believe, still had fixed function hardware in[22:07:37] <Ingenu> but both were programmable to good extent[22:07:51] <mccbaka> hm, ok[22:08:17] <Ingenu> must have been 5 years ago or something[22:08:37] <mccbaka> when i look at the gf3 and radeon 9200 specs, i find that they claim to support pixel or vertex "shaders" of some sort.. do you mean that those are not as much control as you would expect?[22:08:58] <Ingenu> GF3 had register combiners[22:09:14] <Ingenu> 9200 is a 8500 so it has some programmability[22:09:22] *** calav3ra has joined ##opengl[22:09:27] <Ingenu> let's say configurable instead of programmable[22:09:54] *** repr_____ has quit IRC[22:10:09] *** GuShH has joined ##OpenGL[22:10:12] <Ingenu> you could write your program but it was very limited and very hardware dependant, not something one would like of any program (basically you had to write one program per chip)[22:10:15] <mccbaka> you mean you would say the gf3/9200 are configurable, but not programmable?[22:10:25] <mccbaka> i see[22:10:26] <Ingenu> or target lowest common denominator of course[22:10:34] <Ingenu> yep[22:10:36] <mccbaka> so like you'd write a program that would work on the 9200 but it wouldn't work on the gf3?[22:11:07] <Ingenu> yes[22:11:34] <Ingenu> the 9200 (which really is a 8500) was more capable and had slightly different instruction set[22:11:41] <Ingenu> but you could write some code that would work on both though[22:12:28] <Ingenu> it's just that if your hardware can't do much and you don't take advantage of its capabilities, you're kinda stuck in low speed or low quality...[22:13:10] <mccbaka> i see[22:13:51] <mccbaka> well... i'm thinking about my current situation. which is, i don't want to do much. i just want exponential fog that leaves distances < 1 at a constant 1.0[22:14:26] <RTFM_FTW> actually the 9200 and 8500 have a (nearly) identical feature-set[22:14:49] <mccbaka> would this be something that would be possible on even the old, crappy early shader cards?[22:14:51] <RTFM_FTW> the only difference being related to tru-form as I recall[22:15:26] <mccbaka> if there's not some way to get that using the built in stuff[22:15:52] <RTFM_FTW> in any case those ASICs (in the R2xx family) support a very limited sub-set of programmability though GL_ATI_fragment_shader or GL_ATI_text_fragment_shader[22:16:00] <mccbaka> (it seems baffling they'd even include a fog mode like that in opengl to begin with, why would anyone want a fog mode that leaves the entire screen dimmed with no pixel at full strength?)[22:16:00] <sparky> fusi: still there?[22:16:13] <sparky> fusi: if you are stil there, your projection is wrong[22:17:05] <Ingenu> dunno, artists always complained about fog anyway, and I remember some issues on some cards/drivers with some settings[22:17:17] <Ingenu> so the solution was to move to a program to get what they wanted[22:17:18] <RTFM_FTW> http://www.opengl.org/registry/specs/ATI/text_fragment_shader.txt http://developer.amd.com/gpu_assets/ATI_fragment_shader.txt[22:17:37] <Ingenu> I believe the text_fs was only available on MacOS[22:17:41] <RTFM_FTW> read through those if you want more information[22:17:55] <RTFM_FTW> Ingenu that would be correct[22:18:03] <Ingenu> I think he would prefer to stick to regular fixed function OpenGL[22:18:08] <RTFM_FTW> but the feature-set is identical between the two[22:18:18] <RTFM_FTW> only the syntax changes[22:18:21] <Ingenu> yep I know[22:18:36] <Ingenu> that's what made OpenGL so annoying compared to D3D at the time ^^[22:18:44] <sparky> fusi: http://www.opengl.org/sdk/docs/man/xhtml/glFrustum.xml[22:18:50] <Ingenu> (two different interfaces to do very similar things)[22:19:15] <RTFM_FTW> meh there are good reasons for that[22:19:33] <RTFM_FTW> in any case I wouldn't avoid the non-FF path if you can make it work for you[22:19:45] <RTFM_FTW> since it does perform quite well on that HW[22:20:03] <RTFM_FTW> OTOH the limitations frequently make life a PITA :P[22:20:39] <mccbaka> i'm pretty much indifferent, i guess i really need to learn shaders eventually? the problem here is i'm at the very end of a project and i'm trying to clean up things a little bit, so learning an entire new programming paradigm (i've never used shaders) seems like it may be inviting trouble[22:21:04] <mccbaka> so what's this GLSL thing[22:21:05] <Ingenu> indeed[22:21:06] <RTFM_FTW> well its always a good time to start[22:21:09] <mccbaka> is that only supported on newer hardware?[22:21:16] <Ingenu> yes[22:21:22] <RTFM_FTW> not quite[22:21:23] <mccbaka> darn[22:21:24] <Ingenu> GF5/RadeOn 9500 and above[22:21:25] <mccbaka> oh[22:21:31] <Ingenu> like I said earlier[22:21:32] <mccbaka> see i'd say a good time to start is when it won't effect schedules ^_^[22:21:36] <RTFM_FTW> R3xx+ or NV3x+[22:21:39] <Ingenu> some it's 5 years old hardware[22:21:47] <Ingenu> some/so[22:21:50] <RTFM_FTW> which isn't at all "newer hardware" AFAIC[22:22:10] <RTFM_FTW> Intel's GMA 9xx series also supports this[22:22:22] <RTFM_FTW> with the vertex pipe done in SW versus HW[22:22:38] <Ingenu> reminds me the KYRO[22:22:47] <mccbaka> is "GF5/RadeOn 9500" the same thing as "R3xx+ or NV3x+" ?[22:22:50] <Ingenu> at least the KYRO had shiny TBDR[22:22:57] <Ingenu> yes[22:23:06] <mccbaka> i'm actually at this point just considering just doing the fog myself[22:23:08] <Ingenu> I give you the marketing name, he gave you the chip names[22:23:13] <RTFM_FTW> the Radeon 95xx series is effectively the R3xx[22:23:21] <RTFM_FTW> concerning the ASICs used[22:23:25] <mccbaka> like just by changing the color at each vertex :P[22:23:27] <mccbaka> i see[22:23:47] <RTFM_FTW> GeForce FX would be the NV3x series[22:24:01] <mccbaka> Does D3D require you to learn two different ways of shaders for cards <5 vs >5 years old, out of curiosity?[22:24:06] <Ingenu> I'm a bit curious, you said things < 1 should be shiny... what's your front clip plane distance ?[22:24:06] <RTFM_FTW> GeForce5 is a meaningless term since no one really calls it that :P[22:24:34] <Ingenu> yeah GF FX, I said it earlier ;p[22:24:52] <Ingenu> it's the GF fail anyway ;p[22:25:02] *** calav3ra_ has quit IRC[22:25:04] <Ingenu> and no[22:25:06] <RTFM_FTW> actually the D3D shader model(s) are quite difference even up through today[22:25:25] <Ingenu> D3D HLSL and OpenGL GLSL both cover the same hardware[22:25:29] <RTFM_FTW> SM4 and beyond is quite different (WRT feature-set) than SM 3.x[22:25:33] <mccbaka> ingenu: well, my near clip is 0.5, my far clip is 5.0, and the most important objects are drawn at 1.0.[22:25:49] <RTFM_FTW> err quite different[22:26:05] <dennda> With glutSolidCube(1); and no further transformations, is it drawn with its center in the origin or some corner of the cube being in the origin?[22:26:12] <mccbaka> the glfog says the exponential models base their colors off "distance".. does clip plane make a difference somehow?[22:26:13] <RTFM_FTW> Ingenu well that depends upon the GLSL version in question[22:26:28] <Ingenu> yes[22:26:39] <RTFM_FTW> GLSL 1.3 differs considerably from GLSL 1.x[22:26:44] <RTFM_FTW> err 1.2[22:26:49] <Ingenu> well I was considering it compared to the R2xx & NV2x differences[22:27:06] <Ingenu> starting from NV3x & R3xx things shape better[22:27:21] <RTFM_FTW> in any case there isn't a high-level shader model out there which will support any possible program in hardware[22:27:23] *** mmmmmmm has joined ##opengl[22:27:27] *** Wagoo has quit IRC[22:27:29] *** mmmmmmm is now known as mmmmmmm|away[22:27:35] <Ingenu> indeed[22:27:39] <RTFM_FTW> when it comes to implementations[22:27:52] *** Wagoo has joined ##opengl[22:27:55] <RTFM_FTW> as long as you keep that in mind you should be OK :D[22:28:11] <Ingenu> mccbaka I don't think so, I think the doc says it's eye distance[22:28:16] <Ingenu> so clip plan wouldn't matter[22:28:18] <mccbaka> ingenu: it looks like it does[22:28:25] <mccbaka> i guess it seems like i'm surprised that like[22:29:23] <mccbaka> if there's fog it seems like there ought to be some kind of a "multiply by" feature in opengl, somewhere. like so that if at my optimal distance (1.0?) glcolor(1,1,1) actually comes out as glcolor(0.8,0.8,0.8), or something, I could tell it "just multiply all colors by 1.2" and it would balance out[22:29:42] <mccbaka> i mean, it seems like it is surprising if there is not such a feature[22:30:16] <Ingenu> you might want to read that : http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html[22:30:44] <iammisc> is using glLoadMatrix for all transforms plausible or is setting a matrix like that too slow?[22:31:16] <Ingenu> iammisc, what do you mean ? how else would you do it ?[22:31:57] <iammisc> Ingenu: using glTranslatef, glRotatef, and glScalef?[22:32:00] <mccbaka> ingenu: hm, would this be relevant to the fog stuff? Oddly in this program I have depth testing almost always turned off[22:32:26] <Ingenu> better load the matrix then[22:32:41] <iammisc> okay cool I'll use that[22:32:52] <Ingenu> mccbaka, unfortunately as I told you, I don't really remember how the fog stuff works ^^[22:32:55] <mccbaka> aha ^_^[22:33:01] <mccbaka> ok well thanks anyway[22:34:14] <Ingenu> any reason why you don't use linear fog though ?[22:34:26] <mccbaka> one more question... if glsl only works on gf5/9500/r3xx/nv3x or newer... what do you do when you're writing it? I mean, do you just say, this program will not work on those older cards? or do you actually have to write it once in glsl for the newer cards, and once in whatever the older cards used to use?[22:34:45] <Ingenu> check extension string[22:34:56] <Ingenu> if it's not there, tell the user to get newer hardware[22:35:05] <mccbaka> i see[22:35:26] <Ingenu> well that's one option, the other is to have different systems for older card[22:35:39] <Ingenu> I used to do that for games, it's a pain and I wouldn't recommend it.[22:35:39] <mccbaka> ingenu: basically linear is what i'm using now. the problem is that the far-away stuff is still pretty bright. the foreground and background are very similar in color and hard to distinguish.[22:35:42] <Ingenu> do it if you must[22:35:45] <mccbaka> i see[22:36:03] <mccbaka> ...well all my hardware is older than glsl supports, so if i did it the other way i'd be excluding myself -_-;[22:36:39] <mccbaka> ok well thanks for the help[22:36:59] <Ingenu> you're welcome, not sure I was useful anyway ;)[22:38:30] <RTFM_FTW> honestly GPUs are cheap nowadays (specifically when it comes to something with GLSL support in HW)... :D[22:39:09] <LordMetroid> Is there a way to find out if I can not store any more data on the graphics card?[22:39:30] <Ingenu> no[22:39:32] <RTFM_FTW> be more specific[22:39:37] *** Yustme has quit IRC[22:39:42] <RTFM_FTW> because the answer isn't quite "no" :P[22:39:55] <Ingenu> it's no if I say so ;p[22:40:01] <LordMetroid> If a buffer is full or I can't create any more buffers[22:40:03] <RTFM_FTW> how are you storing data on the GPU?[22:40:06] <Ingenu> you're just jealous you couldn't make a single word answer ;)[22:40:18] <LordMetroid> Buffer Objects[22:40:23] <RTFM_FTW> Ingenu your single word response is full of shit :P[22:40:45] <Ingenu> what the hell do you expect from a single word answer anyway ?! seriously ?[22:40:48] <Ingenu> ;p[22:40:50] <RTFM_FTW> well to start with consider that MapBuffer can fail[22:41:00] <RTFM_FTW> in resource limited situations[22:41:14] <LordMetroid> I never used MapBuffer[22:41:28] <LordMetroid> BindBuffer, GenBuffers, BufferData[22:41:30] <RTFM_FTW> so can glBuffer[Sub]Data[22:42:07] <RTFM_FTW> ideally an implementation will return GL_OUT_OF_MEMORY in these scenarios[22:42:19] <Ingenu> yep[22:42:32] <Ingenu> but that be well after the GPU memory has been filled up[22:42:41] <Ingenu> since the GL might use RAM to store data[22:42:49] <Ingenu> no matter what flag you use to create the buffer[22:43:00] <Ingenu> +may[22:43:03] <RTFM_FTW> not really actually[22:43:20] <RTFM_FTW> I haven't run into an implementation which backs BOs in client side memory :P[22:43:34] <RTFM_FTW> generally speaking that would be far too slow to be useful[22:44:04] <RTFM_FTW> in any case checking for GL_OUT_OF_MEMORY is your best bet here[22:44:18] <LordMetroid> But the rendering do need to have a fallback on client side storage of the data[22:44:37] <LordMetroid> In case BOs aren't supported on the card, right?[22:45:05] *** Sudi has joined ##OpenGL[22:45:32] <RTFM_FTW> you don't really store data on the GPU via non-BO paths[22:46:14] <Ingenu> well[22:46:16] <RTFM_FTW> take for example immediate mode... in the most naive case the CPU is literally driving the data submission process... call by call[22:46:50] <RTFM_FTW> you aren't mapping a shit-load of {vertices, ...} and then executing them directly in server side memory asynchronously... as is the case with VBO and friends[22:46:51] <AlastairLynn> what's a good, lightweight GUI toolkit for use over OpenGL?[22:47:01] <Ingenu> AFAIR when you create a VBO you have no guarantee where it'll end up[22:47:13] <RTFM_FTW> although you could as an optimization[22:47:24] <RTFM_FTW> Ingenu they will end up in GART or in VRAM[22:47:26] <RTFM_FTW> period[22:47:35] <Ingenu> that's RAM[22:47:50] <Ingenu> that can be DMAd to the GPU right, but RAM none the less :p[22:48:04] <RTFM_FTW> doesn't matter[22:48:10] <RTFM_FTW> doesn't change anything here :P[22:48:19] <LordMetroid> ok[22:48:23] <Ingenu> performance characteristics still[22:48:23] *** hibread__ has quit IRC[22:48:39] <RTFM_FTW> that depends upon how its done :D[22:48:56] <LordMetroid> I suppose there is no real need to test if there are room left cause there's just so much space anyway, or?[22:48:57] <RTFM_FTW> GART in a number of cases *could* be faster than VRAM[22:49:14] <Ingenu> you're assuming we don't saturate memory bandwidth already[22:49:22] <RTFM_FTW> w/ the right usage scenarios[22:49:43] <Ingenu> LordMetroid, not really[22:49:56] <RTFM_FTW> huh? ...actually I'm not assuming anything here[22:49:58] <Ingenu> you have GL_OUT_OF_MEMORY errors, as RTFM_FTW said earlier[22:50:13] <RTFM_FTW> hence my "w/ the right usage scenarios" statement :P[22:50:21] <Ingenu> you shouldn't ignore that kind of GL error at runtime[22:50:23] <Ingenu> not healthy[22:50:51] <Ingenu> yeah RTFM_FTW, I understood you right.[22:51:13] <RTFM_FTW> rendering a large, point filtered texture into a small viewport would be one such usage case where GART is likely to win over VRAM :P[22:51:28] <Ingenu> :)[22:51:30] <RTFM_FTW> for vertex submission its not nearly as clear cut[22:51:36] <RTFM_FTW> but there are still cases[22:52:13] <mccbaka> hey another question... what cards support the "frame buffer object" extension?[22:52:17] <Ingenu> but anyway for his problem, he can't know he can't store any more data on the card[22:52:23] <mccbaka> and/or is there a big list somewhere of which opengl features are supported by what cards?[22:52:25] <Ingenu> but he can know the GL can't allocate more memory[22:52:40] <RTFM_FTW> well for the OP those are one in the same[22:52:48] <Ingenu> mccbaka, the same that support GLSL at least[22:52:52] <mccbaka> hm, ok[22:52:59] <Ingenu> older might too, but then RTFM_FTW would know better than me[22:53:17] <Ingenu> there's delphi3D[22:53:20] <Ingenu> not sure it's up to date[22:53:34] <Ingenu> usually firms have the hardware they are interested in or rely on D3D (most likely)[22:53:50] <Ingenu> since all hardware advertise their D3D level of support[22:54:00] <RTFM_FTW> *if* allocations fail (w/ GL_OUT_OF_MEMORY or otherwise) *then* you can assume a resource (be it VRAM, GART, ...) limitation[22:54:03] *** itewsh has quit IRC[22:54:08] <RTFM_FTW> and that is *all* you should care about[22:54:10] <LordMetroid> OpenGL is clearly my choice of API[22:54:11] <Ingenu> make that: all manufacturers advertise the version of D3D their hardware supports[22:54:34] <Ingenu> I'm moving to D3D[22:54:44] <Ingenu> until GL 2.0 Pure arrives[22:54:50] <RTFM_FTW> LOL[22:54:53] <Ingenu> it was suggested about 5 years ago or so[22:55:02] <Ingenu> no need to worry, in ten years it should be there[22:55:06] <Ingenu> it'll be totally irrelevant[22:55:10] <Ingenu> but it will ;p[22:56:19] <Ingenu> anyway, use whatever you prefer, if I'm on this channel, it's prolly that I've not given up on GL just yet ;)[22:57:42] <LordMetroid> I don't get it, why is Microsoft part of the Chronos board... They clearly have no business to be there![22:58:03] <Ingenu> are they ?[22:58:09] <Ingenu> they were kicked out of the ARB AFAIR[22:58:26] *** hibread has joined ##opengl[22:58:34] <LordMetroid> I see... Then I may have faulty information.[22:58:52] <RTFM_FTW> I'll say this: ten years -> forever in this business[22:59:00] <Ingenu> I agree[22:59:19] <RTFM_FTW> so its completely meaningless to discuss where GL, CL, ... will be then :P[22:59:57] <RTFM_FTW> and MS isn't in Khronos[23:00:06] <Ingenu> but we can see how it evolved the last 5 years and it ain't that pretty IMO[23:00:07] <RTFM_FTW> whoever told you that was FOS :P[23:00:32] <RTFM_FTW> oh I'd disagree with that[23:01:44] <RTFM_FTW> see you have to realize that GL is *not* just a "gamer's API"[23:02:32] <Ingenu> it's my API of choice, I make games, so it shall be a game API[23:02:34] <Ingenu> :p[23:02:45] <RTFM_FTW> LOL yeah... good luck with that[23:02:48] *** GX has quit IRC[23:03:00] <Ingenu> yeah[23:03:03] <Ingenu> it's not[23:03:05] <RTFM_FTW> I'll be another one to suggest that you use D3D[23:03:08] <Ingenu> the game API is D3D[23:03:25] <LordMetroid> D3D is so platform limited...[23:03:29] <RTFM_FTW> oh well[23:03:30] <Ingenu> or to the metal ! even more fun ![23:03:42] <Ingenu> like you're gonna sell games on anything but Windows or a console...[23:03:58] <Ingenu> D3D works on PC & X360[23:04:14] *** Renderwahn has quit IRC[23:04:18] <Ingenu> there's an OpenGL port on the PS3 though[23:04:20] <RTFM_FTW> oh I think the iPhone is disproving that line of BS :P[23:04:33] <Ingenu> mmh[23:04:44] <Ingenu> iPhone has PowerVR inside, must be a console then :p[23:04:52] <RTFM_FTW> haha[23:05:00] <Ingenu> small market for 3D games I'd think[23:05:01] <Ingenu> is it not ?[23:05:08] <Ingenu> have any reliable data about that ?[23:05:13] <LordMetroid> You will never sell your game on another platform if you don't even try to sell it on another platform[23:05:22] <RTFM_FTW> "small market" ...LOL seriously?[23:05:32] <Ingenu> a number of firms tried selling on another OS, Linux[23:05:36] <Ingenu> they are all dead now[23:05:38] <RTFM_FTW> I wouldn't say its a small market at all[23:05:52] <Ingenu> MacOS get more and more games[23:06:22] <RTFM_FTW> the Mac gaming market gets stronger and stronger with passing quarter[23:06:28] <Ingenu> RTFM_FTW, compared to PS3, 360 or Wii ? I'd think so indeed[23:06:35] <RTFM_FTW> *each[23:06:56] <Ingenu> Blizzard offer on MacOS likely helps[23:07:20] <RTFM_FTW> doesn't matter though... not everyone needs to target the console market :P[23:07:55] <Ingenu> better have clients in the market you target ;p[23:08:02] <RTFM_FTW> the fact of the matter is that a large number of share-ware game developers are making a *very* comfortable living on iPhone / Mac OS X[23:08:02] <Ingenu> I'm gonna make a GL game for the BeOS ![23:08:10] <Ingenu> it's my favorite API and OS[23:08:16] <RTFM_FTW> not even including the larger publishers[23:08:17] <Ingenu> it ought to be working good ![23:08:23] <Ingenu> ;)[23:09:40] <rektide> i'm looking to do an RTS like app, but i dont know very much about various ways of using the mouse to do camera controls[23:10:01] <rektide> does anyone have recommendations for a book or site or whatever that lays out different possibilities of camera control?[23:10:15] <Ingenu> I'd try the usual suspects[23:10:18] <Ingenu> gamedev.net[23:10:20] <Ingenu> gamasutra.com[23:10:22] *** JohnnyL has joined ##OpenGL[23:10:24] <Ingenu> google.com ^^[23:11:04] <RTFM_FTW> I think the size of the iPhone application market (gaming or otherwise) shows that this is definitely a force to be reckoned with[23:11:38] <RTFM_FTW> anyone who disagrees with that statement is delusional :P[23:12:15] <Ingenu> good for PowerVR then :)[23:12:24] <Ingenu> my favorite 3D chip brand & tech[23:18:23] <rektide> i'm still hoping AMD is devleoping their ATI Imageon stuff[23:18:48] <rektide> competition is goo[23:18:50] <rektide> *good[23:19:55] *** Spkka has joined ##OpenGL[23:22:52] <tmccrary1> iphone still sucks as a gaming platform[23:23:22] *** lewymati has quit IRC[23:23:30] <RTFM_FTW> it really depends upon the title[23:23:34] <tmccrary1> true[23:23:55] <RTFM_FTW> some titles are far better than others when it comes to multi-touch support[23:23:56] <tmccrary1> There are a few genres I think would be cool to try out[23:24:02] <tmccrary1> like a rogue/diablo game[23:24:22] *** scai has left ##opengl[23:27:17] <JohnnyL> kill monsters and collect treasure?? That's unprecidented!!!![23:27:31] <Ingenu> Door Monster Treasure[23:27:43] <Ingenu> that's from Dungeon and Dragons back in the 70s[23:27:59] <Ingenu> at least there were traps back then[23:28:09] <Ingenu> now it's simplified to Monster Treasure ^^[23:28:29] <Ingenu> but we're getting off topic[23:33:11] *** tmccrary1 has quit IRC[23:33:34] *** gusnan has quit IRC[23:39:16] *** TbbW has joined ##OpenGL[23:40:39] *** attacke has joined ##OpenGL[23:41:22] *** XT95___ has quit IRC[23:42:09] <attacke> anyone heard of any problems regarding ATI (4800 series) while displaying multitextured model/meshes ? http://xs435.xs.to/xs435/09030/blarf814.png <- this is how it looks for everyone else, http://xs135.xs.to/xs135/09030/mt878.png <- this is how it looks for me and some others.[23:43:26] *** LordMetroid has quit IRC[23:43:31] <attacke> with some others i mean people with ATI graphic cards.[23:45:11] *** jmd has joined ##opengl[23:51:31] *** joemax has joined ##OpenGL[23:51:33] <joemax> alright[23:51:50] <joemax> anyone know a good paper on fast omni-directional shadowmaps?[23:52:08] <joemax> the lights that I'm having should have small radiuses[23:52:32] <joemax> so there's a lot of optimization possibility (bringing far plane close etc., I don't know)[23:53:22] <joemax> and if the shadow maps are gonna end up with small resolutions, that's ok... as long as I can multisample it to death and create really soft penumbras[23:54:12] <joemax> seriously... shadow mapping is the future[23:56:15] *** mmmmmmm|away has quit IRC[23:57:17] *** kbotnen has joined ##OpenGL[23:59:46] *** mccbaka has quit IRC