[00:00:34] *** dirthead2 has quit IRC
[00:01:02] *** m4ggus has quit IRC
[00:01:20] *** qeed has quit IRC
[00:02:40] *** TravisD has quit IRC
[00:02:41] *** Yustme has quit IRC
[00:02:52] *** home_ has joined ##OpenGL
[00:04:03] *** shartte has joined ##OpenGL
[00:06:48] *** ShadowIce has quit IRC
[00:07:10] *** rohanrhu has quit IRC
[00:07:36] *** rohanrhu has joined ##OpenGL
[00:11:32] *** dirthead2 has joined ##OpenGL
[00:14:20] *** magentar has quit IRC
[00:16:28] *** rendar has quit IRC
[00:18:38] *** davedes has quit IRC
[00:18:55] *** tmnt has quit IRC
[00:26:18] *** davedes has joined ##OpenGL
[00:34:15] *** optln has quit IRC
[00:36:59] *** mvtx has quit IRC
[00:39:36] *** rohanrhu has quit IRC
[00:40:55] *** rohanrhu has joined ##OpenGL
[00:41:02] *** descender has quit IRC
[00:43:51] *** meoblast001 has quit IRC
[00:48:21] *** descender has joined ##OpenGL
[00:56:04] *** davidbitton has joined ##OpenGL
[01:00:02] *** kernelpanic has quit IRC
[01:00:27] *** kernelpanic has joined ##OpenGL
[01:02:44] *** descender has quit IRC
[01:04:13] *** __doc__ has quit IRC
[01:04:39] *** wwhite_ has joined ##OpenGL
[01:04:44] *** wwhite has quit IRC
[01:04:47] *** alonl has quit IRC
[01:05:50] *** meoblast001 has joined ##OpenGL
[01:06:16] *** shartte has quit IRC
[01:07:17] *** home_ has quit IRC
[01:08:12] *** descender has joined ##OpenGL
[01:08:38] *** rohanrhu has quit IRC
[01:14:48] *** dylukes has quit IRC
[01:22:07] *** plagman has quit IRC
[01:22:14] *** dylukes has joined ##OpenGL
[01:25:53] *** EddieRingle has joined ##OpenGL
[01:27:19] *** jdolan has quit IRC
[01:27:40] *** jdolan has joined ##OpenGL
[01:28:39] *** Nickeeh has joined ##OpenGL
[01:35:05] *** plagman has joined ##OpenGL
[01:38:59] *** `Assassin has joined ##OpenGL
[01:40:29] *** Noctifer has joined ##OpenGL
[01:41:36] <Noctifer> mh working opengl program - right after glXMakeCurrent i added simply the line glBindFramebuffer(GL_FRAMEBUFFER,0);
[01:43:32] <Noctifer> now this works fine so far
[01:43:49] *** LU324 has quit IRC
[01:44:01] *** mads- has quit IRC
[01:44:03] <Noctifer> i am using gdb to debug the program then this still works fine if and only if i do not step directly over this function call
[01:44:07] <Noctifer> in that case i receive
[01:44:09] <Noctifer> 0x0050d850 in ?? () from /usr/lib/i386-linux-gnu/libglapi.so.0
[01:44:38] <Noctifer> followed by Cannot find bounds of current function
[01:44:40] <HuntsMan> it crashes?
[01:44:43] <Noctifer> no
[01:44:47] <glYoda> well ask yourself why you are binding a render target AFTER context activation
[01:45:26] <glYoda> a good answer to that question is: I shouldn't be.
[01:45:31] <glYoda> heh
[01:45:54] <glYoda> *BEFORE I should say...
[01:45:56] <glYoda> heheh
[01:46:28] <glYoda> check your render targets
[01:46:30] <Noctifer> i am binding it AFTER context activation
[01:46:44] <Noctifer> first glXMakeCurrent, then glBindFramebuffer(GL_FRAMEBUFFER,0)
[01:46:57] <glYoda> make sure you aren't bound to an FBO (rather than to the system surface) when you shouldn't be
[01:47:20] *** plainflavored has joined ##OpenGL
[01:47:36] <Noctifer> the rest of the program uses neither fbos, nor textures, not anything else except of glVertex glMatrixMode glPushMatrix
[01:47:44] <Noctifer> standard stuff, runs, compiles, debugs without problems
[01:47:44] <glYoda> FBO ID = 0 implies the default drawable BTW
[01:47:49] <Noctifer> yes
[01:47:55] <glYoda> it isn't an FBO
[01:47:59] <Noctifer> i added this call because it should be neutral
[01:48:15] <glYoda> and FBOs aren't enabled unless you enable them
[01:48:38] *** LU324 has joined ##OpenGL
[01:48:44] <glYoda> i.e. somewhere you must have bound to a FBO ID > 0
[01:49:17] <glYoda> assuming what you are telling us (about resolving this error...) is correct
[01:50:12] *** LU324 has quit IRC
[01:50:52] <glYoda> check for and assert upon errors as well...
[01:50:53] <Noctifer> glBindFramebuffer(GL_FRAMEBUFFER,0) should release an existing binding and use the system frame buffer
[01:51:18] <glYoda> it simply binds to the default drawable
[01:51:18] <Noctifer> there was no framebuffer bound
[01:51:23] <glYoda> nothing more
[01:51:30] <Noctifer> well and exactly this is what happens
[01:51:56] *** LU324 has joined ##OpenGL
[01:51:57] <glYoda> if there wasn't another FBO bound (!) then your driver sucks
[01:51:59] <Noctifer> and for the 2nd time i am telling that this works fine except that it kills gdb when stepping over this function
[01:52:05] <Noctifer> i guess
[01:52:10] <glYoda> somehow I find that highly unlikely
[01:52:25] <glYoda> because that is a vast spec violation
[01:52:33] <Noctifer> well it does; i have such an intel/mesa whatever crap running here
[01:52:42] <Noctifer> one second
[01:53:18] <glYoda> this would break every single GL program in existence
[01:53:21] <glYoda> BTW
[01:53:22] <Noctifer> OpenGL vendor string: Tungsten Graphics, Inc
[01:53:23] <Noctifer> OpenGL renderer string: Mesa DRI Intel(R) 945GME x86/MMX/SSE2
[01:53:33] *** cccaldas has quit IRC
[01:53:44] <glYoda> at least every single GL program which doesn't use FBO
[01:53:46] <HuntsMan> Noctifer: so your problem is that it corrupts the stack?
[01:53:58] <glYoda> since all of them would be required to explicitly bind to the default drawable
[01:54:06] <glYoda> and that just isn't likely heheh
[01:54:30] <Noctifer> glYoda: it's ok ...
[01:54:53] <Noctifer> HuntsMan: 1) the program runs fine WITH the call in it
[01:54:57] <glYoda> and if you are getting stack corruption that implies one or more memory smashers laying around
[01:55:21] <Noctifer> HuntsMan: 1) the program debugs fine WITH the call in it
[01:55:23] <glYoda> Noctifier ?
[01:55:51] <Noctifer> HuntsMan: 3) if you step in GDB on this function call, THEN gdb reports a stack corruption
[01:56:07] <Noctifer> HuntsMan: 4) if you do NOT step in GDB on this function call, THEN gdb reports NO stack corruption
[01:56:27] *** bloony has quit IRC
[01:57:03] <HuntsMan> so the only problem is that GDB reports stack corruption?
[01:57:04] <glYoda> what happens when you remove the call?
[01:57:08] <Noctifer> oh and as a funny side note: if you step on this function call then gdb reports a  stack corruption just as described but continue lets the program execute happily
[01:57:48] <Noctifer> HuntsMan: yeah pretty much, it concerns me a bit
[01:58:26] <Noctifer> glYoda: ... if i remove the call and by the four points above then obviously everything runs fine ...
[01:58:53] <glYoda> step over != remove BTW
[01:59:01] *** bloony has joined ##OpenGL
[01:59:06] * glYoda is hoping you didn't think that...
[01:59:33] <glYoda> in any case you shouldn't ever be binding to the default drawable if you aren't using FBO
[01:59:45] <glYoda> so remove that line
[01:59:47] <glYoda> heh
[02:00:03] *** kernelpanic has quit IRC
[02:00:27] *** kernelpanic has joined ##OpenGL
[02:01:05] <glYoda> check for errors too
[02:01:53] <Noctifer> well just checked, causes no problems on nvidia drivers
[02:02:25] <HuntsMan> it's likely a implementation bug
[02:03:05] <Noctifer> well the driver also causes various valgrind warnings so i guess it is just ... well crap
[02:07:18] *** bloony has quit IRC
[02:07:50] <glYoda> well BindFramebuffer with ID = 0 and no active (client defined) frame buffer set shouldn't do anything... I'd hope that it's basically a NOP for them
[02:07:52] <glYoda> heh
[02:08:14] <HuntsMan> that's if you implement it correctly :P
[02:08:22] <glYoda> imagine that
[02:08:50] <glYoda> that damn correctness requirement strikes again
[02:08:54] <glYoda> heheh
[02:09:35] <Noctifer> well the same thing happens to glGenFramebuffers and glDeleteFramebuffers
[02:09:48] <Noctifer> the ARB extension is present btw
[02:09:54] <Noctifer> ...
[02:10:04] <Noctifer> and the application renders fine into the buffers
[02:10:31] <Noctifer> i dunno WHAT someone must do to confuse both valgrind and gdb but since the last driver update - congratulations implementors, you made it
[02:10:38] <glYoda> isn't the driver open source? ...debug it :P
[02:10:51] <glYoda> "use the source Luke"
[02:10:54] <glYoda> heh
[02:11:34] <Noctifer> i feel the open source at the moment ...
[02:11:50] *** Mercury12314 has quit IRC
[02:12:55] <glYoda> come on I thought this is what OSS people loved... being able to fix their drivers whenever problems occur in the field :P
[02:13:02] * glYoda kids
[02:14:42] <Noctifer> no opengl errors as well, before and after the calls
[02:15:28] <glYoda> well the BindFramebuffer case shouldn't error... the spec allows for that
[02:15:35] <glYoda> even if it's pointless
[02:16:18] <Noctifer> so my only idea would be that glXGetProcAddress returns an invalid pointer
[02:16:31] <Noctifer> but if that pointer would be invalid then why does fbo rendering work
[02:16:33] <Noctifer> ...
[02:16:51] *** fyolnish has joined ##OpenGL
[02:17:11] <glYoda> in terms of GenFramebuffers as long as the count is valid (i.e. non negative) you are safe with that as well
[02:17:30] <Noctifer> and it works with nvidia so i guess "tungsten graphics" whatever that is an mesa (i wish i didn't know that) are the problems
[02:17:51] <glYoda> for DeleteFramebuffers the same rule applies
[02:18:12] <glYoda> (i.e. one needs to specify a non negative count)
[02:19:06] *** Jonas__ has quit IRC
[02:19:10] *** Jonas___ has joined ##OpenGL
[02:19:35] <Noctifer> the cool thing is it feels like directx 5 days ... nothing works, everything sucks but somehow you get something on the display^^
[02:19:42] <glYoda> and again all of those should be NOPs if the client hasn't bound + used a relevant FBO
[02:19:57] <Noctifer> yeah that's why i was here; to me it was also a NOP
[02:20:08] *** fyolnish has joined ##OpenGL
[02:20:40] <Noctifer> but as this is not the only function with this behaviour, i'd say let's forget about this crap; in 2 weeks good system, good drivers then stuff like that wont happen anymore
[02:20:43] <glYoda> even setting up FBO state at this point (i.e. TexImageND + attachment setup etc.) is a NOP at this point
[02:21:12] <glYoda> since the client hasn't actually rendered to it OR bound the relevant attachment state for reading
[02:21:25] <glYoda> no point in doing any work there heheh
[02:21:49] *** Limoto has quit IRC
[02:24:05] *** KAHR-Alpha has quit IRC
[02:24:45] *** ninzine has quit IRC
[02:25:40] <xissburg> glYoda: are you into hardware design?
[02:27:43] *** replore has joined ##OpenGL
[02:27:44] *** replore_ has joined ##OpenGL
[02:27:45] *** Wisey has quit IRC
[02:28:06] <Noctifer> may i ask another question? it's about the recommended application of framebuffer objects
[02:28:44] <Noctifer> i want to display several monitors and i want to render scenes on each monitor
[02:29:03] <Noctifer> are fbos then the way to go?
[02:29:20] <Noctifer> (not that i am totally using the wrong opengl facilitites=
[02:29:32] <Noctifer> like a "scenes in a scene"
[02:30:59] <glYoda> yup they would work for this
[02:31:25] <glYoda> since you can render your scene into a texture and display that texture across N different viewports
[02:31:30] <glYoda> or whatever
[02:31:54] <glYoda> you can also render different aspects of the scene to multiple textures and display those as well
[02:32:35] <glYoda> IF you only want to render once and display N > 1 times this path can be a good basic optimization
[02:32:58] <glYoda> render -> construct
[02:33:12] *** fyolnish has quit IRC
[02:33:18] *** ragecryx has quit IRC
[02:33:23] *** dylukes has quit IRC
[02:33:29] <Noctifer> nah they are moving scenes
[02:33:37] <Noctifer> like movie clips
[02:33:43] *** fyolnish has joined ##OpenGL
[02:34:04] <Noctifer> they change all the time, so i have to update/re-render them continuously
[02:34:05] <glYoda> but is the scene the same across all N displays?
[02:34:13] <glYoda> effectively mirrored if you will
[02:35:22] <glYoda> depending upon how the scene is constructed (i.e. is it post processed? is that processing step expensive?) that case can still be a win with RTT via FBO
[02:36:05] <glYoda> since you build the scene once and mirror it multiple times
[02:36:12] <Noctifer> nope different scnes
[02:36:35] <glYoda> and is there post processing involved?
[02:36:41] <glYoda> multiple pass rendering?
[02:36:43] <Noctifer> well would be nice
[02:36:56] <glYoda> again that case is worth considering as well
[02:37:01] <Noctifer> yes i know it's expensive but those scenes are small
[02:37:09] *** dylukes has joined ##OpenGL
[02:37:11] <glYoda> since FBO would be advantageous there as well
[02:37:51] <Noctifer> so FBOs => the  way to go?
[02:37:59] <Noctifer> good
[02:38:12] <Noctifer> because this results in a nice framework, well to maintain
[02:38:13] <glYoda> they are for the cases I've mentioned
[02:38:18] *** bfgun has joined ##OpenGL
[02:38:20] <glYoda> and many more
[02:38:28] <Noctifer> are there alternatives?
[02:38:41] <glYoda> not worth discussing
[02:38:51] <Noctifer> good:D
[02:38:54] <glYoda> FBO is the standardized path for render to texture in the GL
[02:38:56] <glYoda> use it
[02:38:59] <glYoda> if you need it
[02:39:19] <Noctifer> ah i like them, they are very streamlined somehow
[02:40:27] *** bfig has quit IRC
[02:42:16] *** gridbag has joined ##OpenGL
[02:43:39] *** cccaldas has joined ##OpenGL
[02:49:36] *** neure has quit IRC
[02:49:58] *** neure has joined ##OpenGL
[02:50:37] *** contingo has quit IRC
[02:55:23] <Noctifer> the only thing i am wishing for are opengl context that finally are independend of those goddam windowing systems
[02:55:44] *** whitglint has joined ##OpenGL
[02:58:05] *** neure has quit IRC
[02:58:30] *** neure has joined ##OpenGL
[03:03:33] *** Limoto has joined ##OpenGL
[03:08:13] *** Limoto has quit IRC
[03:09:39] *** luponero has quit IRC
[03:10:35] *** Limoto has joined ##OpenGL
[03:10:41] *** madsy has quit IRC
[03:13:21] *** Dark_Confidant has joined ##OpenGL
[03:14:43] <glYoda> meh context setup being tied to the underlying platform is a minor complaint IMHO
[03:14:58] <glYoda> and there is good reason for it
[03:29:56] *** jcontra is now known as jcontra-zZz
[03:30:05] <Noctifer> well a hidden window solves most of the problems ...
[03:30:57] <Noctifer> the typical situation is, i want to render to an FBO without making obvious that  a context has to be bound to SOME window
[03:31:05] <Noctifer> so i bind it to a default window
[03:32:23] *** graphitemaster has quit IRC
[03:32:43] <Noctifer> i hope that is possible on all systems
[03:32:56] *** Deformative has quit IRC
[03:34:12] <glYoda> uh just use multiple (shared) contexts
[03:34:25] <glYoda> and RTT through those
[03:35:11] <glYoda> mark a subset of those (i.e. one or more) as contexts used for the default drawable -> display
[03:35:30] <glYoda> no need for one or more offscreen windows
[03:35:30] *** madsy has joined ##OpenGL
[03:36:08] <glYoda> shared contexts are quite handy and definitely worth learning
[03:37:37] <Noctifer> mh no the problem is somewhat different
[03:37:49] <Noctifer> consider a window and an fbo as drawables
[03:37:57] <glYoda> why?
[03:37:59] <Noctifer> i.e. something "you can draw to"
[03:38:00] <glYoda> heh
[03:38:10] <glYoda> they don't need to be
[03:38:20] <Noctifer> there is a particular instruction in my library that just says setRenderTarget(Drawable d)
[03:38:24] <glYoda> windows are far more heavyweight than a frame buffer object
[03:38:48] <glYoda> lol you have a broken library if it wants to consider these as equals
[03:38:52] <Noctifer> ok now the user calls that for a drawable then the library would somehow have to settle for some window to ensure that the context is bound
[03:38:55] <glYoda> as far as I'm concerned
[03:39:19] <Noctifer> they are not in an equality relation
[03:39:35] <glYoda> not to mention that you aren't going to render anything in the GL without a valid / active context
[03:39:45] <Noctifer> but they both implement the drawable interface
[03:40:11] <Noctifer> so either i enforce some order like the first drawable passed must be a window
[03:40:12] <Noctifer> which sucks
[03:40:16] <glYoda> and that context better have state relevant to the resources being rendered
[03:40:20] <Noctifer> or i do it differently
[03:40:24] <glYoda> again all of this is trivial to deal with
[03:40:44] <glYoda> and the path you want to use isn't the right way to solve this problem
[03:40:58] <Noctifer> it IS annoying, simply annoying
[03:41:20] <glYoda> because you aren't doing it the right way heheh
[03:42:25] <Noctifer> ok offer a solution to implicitly bind a context if its not bound to a window that might not have been created?
[03:43:28] <Noctifer> the opengl context exists even if the window it was created with is destroyed
[03:43:59] <glYoda> if the lib needs to be aware of context state then by definition it needs knowledge of a context... internally or otherwise
[03:44:02] <glYoda> simple as that
[03:44:24] <glYoda> pass it one (or more) in whatever order if you want to do this
[03:44:45] <glYoda> I'd recommend creating a set of contexts (shared) to work with that
[03:44:50] <glYoda> from the initial window
[03:45:23] <glYoda> the GL is going to require this ...like it or not
[03:46:21] <Noctifer> so an initial window must be created by the user; then the library can also created implicitly a hidden initial window
[03:47:01] <Noctifer> and if there are multiple contexts are a single one does not make a difference here; the simply requirement of
[03:47:09] <Noctifer> a) have a window to have a context and
[03:47:18] <Noctifer> b) bind a context to a window even if you render to an fbo
[03:47:21] <Noctifer> is retarded
[03:47:28] <glYoda> the point here is avoiding a 1:1 mapping between windows and contexts when that isn't required
[03:47:51] <glYoda> 1:N is far more efficient from a resource perspective
[03:48:19] <Noctifer> read a) then read b) and tell me if a 1:1 or 1:N mapping makes a difference
[03:49:02] <Noctifer> for instance an audio library also doesnt require you to create damned window just to play a sound
[03:49:28] <glYoda> once again (b) is irrelevant... RTT via FBO requires nothing more than a context... like any other GL path
[03:49:45] <Noctifer> a bound context
[03:49:47] <glYoda> only the default system drawable changes that
[03:50:11] <glYoda> so like I've said... your library sucks
[03:50:31] <glYoda> it's made invalid assumptions and now you have to deal with them
[03:50:35] <glYoda> sucks for you heheh
[03:54:12] <Noctifer> i guess you're an idiot with a poor judgement and a too big self-esteem; except of not understanding the previous question and gracefully ignoring the fact that i want to talk to HuntsMan, continuous typing of heehee (which makes you look like a retard) and the amazing capability of judging things that were not even described, you have seriously nothing to offer
[03:55:48] <Noctifer> whatever
[03:55:49] <glYoda> honestly the fact that you are surprised by any sort of window requirement for context creation is truly LOL worth
[03:55:56] <glYoda> *worthy
[03:57:08] <glYoda> FFS one generally renders the results of their scene to the system drawable at some point... that drawable generally references a window (visible OR not)... none of this is remotely surprising
[03:57:20] <glYoda> deal with it
[03:57:39] *** graphitemaster has joined ##OpenGL
[03:58:07] <Noctifer> i am suprised? that suprises me now?
[03:58:29] <glYoda> if you wish to render through N > 1 contexts AND you don't want to create a window for each of them (because the window requirement sucks as per your earlier statements) use a shared context
[03:58:31] <Noctifer> guess the force was not with you
[03:59:26] <Noctifer> guess what i AM doing?
[03:59:48] <glYoda> being an idiot?
[04:00:07] <glYoda> you are doing a good job at that so far
[04:00:09] *** Xantoz has quit IRC
[04:03:55] <Noctifer> i ask the question again and i prefer no answer from a *certain* person:
[04:04:41] <Jeaye> ...
[04:04:51] <Noctifer> does hidden window creation work on windows, linux and mac i.e. the most common platforms
[04:04:55] <glYoda> don't worry I've had my fill of responding to idiots tonight
[04:05:14] <glYoda> idiots who are incapable of listening :)
[04:05:27] <Jeaye> That doesn't sound like an OpenGL question.
[04:05:36] <Noctifer> well it is actually
[04:05:41] <glYoda> and BTW a basic Google search could have told you the answer to that
[04:05:56] <Noctifer> creating a context from that window, will it allow me to use normal hardware acceleration
[04:05:58] <glYoda> no actually it isn't
[04:06:04] <Noctifer> just shut the fuck up glYoda please
[04:06:11] <glYoda> the GL says absolutely nothing about window management
[04:06:20] <Jeaye> ^
[04:06:24] <glYoda> OR context creation / pixel format setup
[04:06:29] <glYoda> and so forth
[04:07:02] <glYoda> Noctifier nah I'd prefer if someone new to the API didn't actually take your BS seriously
[04:07:28] <Noctifer> since opengl 3.x it says but i guess your super-bible is still 1.4 or something
[04:07:38] <glYoda> prove it
[04:08:12] <glYoda> please quote where context creation and pixel format attribute setup are defined within the GL API specification
[04:08:27] <glYoda> specific definitions please
[04:08:31] <Noctifer> i have to prove nothing, and especially not to you, and as you came up with google i recommend surfing over to www.opengl.org yourself
[04:08:53] <glYoda> hell just tell us how a context is defined
[04:08:58] <Jeaye> SuperBible != GL Specification
[04:09:00] <glYoda> the spec should document this yes?
[04:09:27] <glYoda> yea yea more BS
[04:10:18] <Noctifer> sry, i am still waiting for a serious answer, but if a question regarding context creation is not considered opengl it's fine with me
[04:10:23] <Noctifer> Jeaye: is it or not?
[04:11:08] <xissburg> lol
[04:11:23] <Jeaye> You didn't ask anything about context creation, if I recall correctly. Perhaps re-word your question so I (aong with the rest of the channel) know just what you mean.
[04:11:37] *** b0tt_ has joined ##OpenGL
[04:11:41] <Noctifer> good suggestion: i will do
[04:11:48] *** b0ttt has quit IRC
[04:12:43] <glYoda> lol indeed
[04:13:23] <Noctifer> opengl 2.1< context creation; so on windows wglCreateContext (if i remember correctly), glXCreateContext and others
[04:13:52] <glYoda> WGL, GLX, AGL, CGL, NSGL, ... aren't defined within the spec
[04:14:01] <glYoda> nor are they directly discussed
[04:14:02] <glYoda> srsly
[04:14:20] <glYoda> yeah I know it's surprising to you but so be it
[04:14:28] <Noctifer> i obtain my opengl context, bind it to a window and proceed as usual
[04:14:54] <Noctifer> now on GLX i can confirm that the following procedure does not cause problems
[04:15:23] <Noctifer> i simply create a context [GLX does not require a window for context creation] create an invisble window, bind the context
[04:15:27] <Noctifer> this works, just did
[04:15:46] <Noctifer> now on windows as far as i remember, context creation there requires an existing window
[04:15:56] <Jeaye> I reckon' what you're asking is platform specific, not GL specific.
[04:16:10] <glYoda> yup
[04:16:11] <Noctifer> propably
[04:16:15] <Jeaye> So perhaps asking in ##windows or ##linux.
[04:17:13] <glYoda> the same goes for the idea that a given context requires a window... just to further expand upon what I said earlier it's useful to note that this isn't always the case
[04:18:33] <Noctifer> very well, i will do; thanks Jeaye
[04:18:45] <Jeaye> Cheers.
[04:18:57] <Noctifer> ah crap i'll just try it out that's faster propably^^
[04:19:08] <Jeaye> Mayhaps.
[04:20:54] *** mat^2 has quit IRC
[04:22:09] *** talin has quit IRC
[04:22:28] *** plagman__ has joined ##OpenGL
[04:22:39] *** plagman has quit IRC
[04:28:14] *** jackh has joined ##OpenGL
[04:31:42] *** LU324 has quit IRC
[04:37:50] *** graphitemaster has quit IRC
[04:39:12] <cantelope> $||root|| wget -qO- http://pastebin.com/raw.php?i=T6cU2mZK > derp.cpp && g++ derp.cpp -o derp && ./derp && mv moi.jpg /var/www/derp.jpg && echo http://bot.troutnet.org/derp.jpg
[04:39:12] *** wwhite_ has quit IRC
[04:39:17] <||root||> http://bot.troutnet.org/derp.jpg
[04:39:24] *** monty_hall has joined ##OpenGL
[04:39:28] *** wwhite has joined ##OpenGL
[04:39:39] <monty_hall> learning about multi render targets for fbos
[04:39:53] <monty_hall> it's about glDrawBuffers
[04:40:02] *** trentg has quit IRC
[04:40:16] <monty_hall> I can glDrawBuffers(COLOR1, COLOR2, ...) to render to multi targets
[04:40:18] <monty_hall> when I'm done.
[04:40:25] <monty_hall> it's just glDrawBuffer(GL_BACK)?
[04:41:01] *** trentg has joined ##OpenGL
[04:41:02] <HuntsMan> COLOR1?
[04:41:15] <monty_hall> GL_COLOR_ATTACHMENT0_EXT
[04:41:22] <HuntsMan> ah, yes
[04:41:28] <monty_hall> didn't feel like typing it all in.
[04:51:54] *** affine has quit IRC
[04:52:13] *** affine has joined ##OpenGL
[04:53:07] <glYoda> monty_hall for a double buffered context that would be the typical path
[04:53:49] <monty_hall> I just did a glGetInteger GL_DRAW/READ_BUFFER and they currently point to GL_BACK
[04:54:06] <monty_hall> I ask because as I'm learning opengl there seems to be a pattern with binding.
[04:54:09] <glYoda> uh huh... because you have a double buffered context
[04:54:26] <glYoda> for a single buffered one those would be FRONT
[04:55:15] <glYoda> since you (as far as the GL is concerned...) only have the FRONT buffer to render to OR read from
[04:57:32] <glYoda> buffers (from 0 to MAX_ATTACHMENTS) can be bound via COLOR_ATTACHMENT0 + i
[04:58:10] <glYoda> since ATTACHMENT enums are in contiguous order
[04:58:28] <monty_hall> is there a way to query which drawbuffers are being used?
[04:58:33] <glYoda> yup
[04:58:50] <monty_hall> I only see GL_DRAW/READ_BUFFER.  is there another name?
[05:00:05] <glYoda> look at Get + DRAW_BUFFERi
[05:01:34] <glYoda> such that i is from 0 to MAX_DRAW_BUFFERS
[05:08:31] *** trentg has quit IRC
[05:09:01] <monty_hall> thanks.  that did it.  just wanted to know how to return to my initial draw buffers configuration.
[05:09:14] <glYoda> sure
[05:09:31] *** trentg has joined ##OpenGL
[05:14:56] *** devbug has joined ##OpenGL
[05:18:45] *** wwhite has left ##OpenGL
[05:18:54] *** glYoda has quit IRC
[05:20:38] *** meoblast001 has quit IRC
[05:22:03] *** glYoda has joined ##OpenGL
[05:24:24] *** gridbag has quit IRC
[05:24:46] <devbug> This is really an abstract question but seems like the best place to ask: Deferred Shadowing; what does it actually mean? Some people are using Deferred Shadowing to describe a technique where they collect a screenspace shadow term buffer then blur it for use later when compositing or lighting.CryTek (CryEngine2) are using it to describe a technique where a  "deferred shadow mask buffer" is generated which they use later in the pipeline.
[05:24:46] <devbug>  They can get around multi-pass requirements (can only pack 4 shadows into one buffer) by using an early z pass. So, is it a broad term that describes screen space shadow collection, or a more specific term (one of these)?
[05:38:38] <devbug> Considering this *only* applies to the sun I'll just store a shadow term in my gbuffer. Terminology would still be great thoug.
[05:44:54] *** Will123456 has joined ##OpenGL
[05:45:31] <Will123456> hey guys. i have a loop in a fragment shader that does a bunch of identical step(foo,bar)s. is it worth caching this in a variable, and if so, do i declare the variable outside or inside the loop?
[05:46:39] *** brachyon1c has quit IRC
[05:52:07] *** phrosty has quit IRC
[05:52:44] *** jubei has joined ##OpenGL
[05:53:36] <glYoda> LICM (i.e. loop invariant code motion) is a pretty common optimization so I'd be surprised if moving a subroutine call out of the loop body (assuming it isn't dependent upon the loop itself) manually made any difference
[05:54:08] <glYoda> if it does AND the relevant logic isn't dependent upon the loop itself then file a bugheheh
[05:54:17] <glYoda> *bug
[05:55:56] <glYoda> a good compiler will hoist invariant code during an optimization pass
[05:59:45] <glYoda> in any case use a shader analyzer to verify what I've said occurs for your program
[06:00:03] *** tiffany has quit IRC
[06:00:28] *** HuntsMan has quit IRC
[06:00:33] *** HuntsMan has joined ##OpenGL
[06:00:53] *** cameron1337 has quit IRC
[06:00:53] *** noct has quit IRC
[06:01:09] *** ntx has quit IRC
[06:01:18] *** Yaniel has quit IRC
[06:01:18] *** TheFlash has quit IRC
[06:02:30] *** noct has joined ##OpenGL
[06:04:19] *** shintah has joined ##OpenGL
[06:04:40] *** sirdancealot2 has quit IRC
[06:05:00] *** RageD has joined ##OpenGL
[06:05:54] *** ntx has joined ##OpenGL
[06:06:44] *** RageD has quit IRC
[06:06:53] *** Yaniel has joined ##OpenGL
[06:07:09] *** tiffany has joined ##OpenGL
[06:09:11] *** Mercury12314 has joined ##OpenGL
[06:09:15] *** TheFlash has joined ##OpenGL
[06:13:24] *** Mercury12314 has quit IRC
[06:14:37] *** cameron1337 has joined ##OpenGL
[06:16:03] *** Domiiii has joined ##OpenGL
[06:17:39] <Noctifer> Will123456: depends on the shader compilers which are vendor specific; if they - for instance - perform normal compiler optimizations (by normal: constant propagation, common subexpr elimination, loop unrolling, and many more) then - no; i would not expect that from many drivers - so yes?
[06:19:01] *** diego21 has joined ##OpenGL
[06:20:35] <glYoda> oh FFS any halfway decent shader compiler will do this
[06:21:16] *** diego21 has quit IRC
[06:21:24] <glYoda> believe it or not optimization is a pretty critical requirement when you are executing shaders on a per (vertex, fragment) basis
[06:21:59] <glYoda> a good rule here is to ignore Noctifier
[06:22:02] <glYoda> heh
[06:23:59] <xissburg> obey the master glYoda
[06:25:58] *** cccaldas has quit IRC
[06:26:23] <glYoda> and stuff like constant propagation, CSE, unrolling etc. are utterly basic optimizations to accomplish
[06:26:58] <xissburg> my driver wouldn't even do that
[06:27:19] <glYoda> if you are using a driver (-> shader compiler) which cannot accomplish such optimizations then you need to find a better vendor / platform
[06:27:30] <glYoda> xissburg what driver?
[06:27:42] <xissburg> glYoda: my future driver
[06:27:49] <glYoda> heh
[06:28:01] <xissburg> I expect to write drivers one day :)
[06:28:17] <glYoda> because any closed runtime will
[06:29:09] <glYoda> compiler writers are a pretty smart and clever bunch... don't underestimate them. :)
[06:30:14] <glYoda> BTW the same goes for automatic function inlining
[06:30:53] *** jcontra-zZz has quit IRC
[06:31:03] <xissburg> is the shader compiler part of the driver? So, each driver has a specific compiler
[06:31:10] <glYoda> given that GLSL has supported subroutine calls on HW which was incapable of executing a true subroutine call
[06:31:51] <glYoda> yes the shader compiler is a part of the driver
[06:32:04] <glYoda> generally speaking
[06:32:10] *** prophile has quit IRC
[06:32:10] *** prophile has joined ##OpenGL
[06:32:21] <prophile> xissburg: from what I recall it depends on a number of factors. I think the OS X graphics stack has a common GLSL compiler and optimiser, and all the inlining and such happens before it's handed out to the IHVs' drivers
[06:32:28] <glYoda> certain APIs allow that to be a optional component tho
[06:32:32] <glYoda> ES for example
[06:32:55] <glYoda> prophile that depends upon the OS
[06:33:15] <xissburg> hm, so you'd have to supply precompiled shaders
[06:33:19] <glYoda> so that isn't a safe assumption to make
[06:33:19] <xissburg> only
[06:34:08] *** IRSteveB has quit IRC
[06:35:06] <glYoda> and there is no guarantee that function inlining for instance occurs in a higher layer on that OS
[06:35:12] <glYoda> even
[06:35:49] <Noctifer> it says they use LLVM in the OpenGL stack in OS X; if that also applies to the shaders ... hand-optimization should not be necessary then
[06:36:03] <glYoda> you really want these sorts of optimizations to be handled by the vendors... because the vendors are the best people to optimize for their own HW
[06:36:09] <glYoda> and that goes for any OS
[06:36:26] <glYoda> more BS from Noctifier
[06:36:40] *** dylukes has quit IRC
[06:37:06] <glYoda> LLVM use for GL on Mac OS X is catered towards their SW rasterizer and fallback path
[06:37:41] <glYoda> see Chris Lattner's discussion of this
[06:38:48] <glYoda> and the idea that hand optimization isn't necessary is laughable too... pointless optimizations aren't necessary
[06:39:38] <glYoda> after all clients know far more about their shaders than the driver will...
[06:40:49] <glYoda> the elimination of unnecessary (but quite reachable...) logic (based upon a higher level state known by the client) would be a good manual optimization
[06:41:23] <glYoda> one which the driver isn't necessarily capable of
[06:42:59] <glYoda> for example think about hoisting work out of the fragment shader and into the vertex shader... coordinate generation for instance
[06:45:21] *** Brend has quit IRC
[06:47:02] *** IRSteveB has joined ##OpenGL
[06:47:30] *** fmeyer has joined ##OpenGL
[06:49:13] *** xissburg has quit IRC
[07:00:54] *** XenoDuck has joined ##OpenGL
[07:01:26] *** factor has quit IRC
[07:01:39] *** maum has quit IRC
[07:05:47] *** nahhh has joined ##OpenGL
[07:05:55] *** tmnt has joined ##OpenGL
[07:06:11] *** fmeyer has quit IRC
[07:07:42] *** fayimora has joined ##OpenGL
[07:16:30] *** BlueThen has quit IRC
[07:17:17] *** adu has joined ##OpenGL
[07:18:16] *** factor has joined ##OpenGL
[07:20:36] <Will123456> glYoda, Noctifer: thanks for getting back to me on my question :) i'm sorry I didn't reply right away - got completely distracted!
[07:21:45] <glYoda> no problem...
[07:22:49] *** Rhamphoryncus has joined ##OpenGL
[07:24:56] <glYoda> as I said earlier if you want to verify what I said earlier just use a vendor specific shader profiler / analyzer
[07:25:25] <Will123456> yeah, that's a good idea
[07:25:26] <glYoda> all of the major IHVs have such tools available
[07:25:41] <Will123456> unfortunately i've not found a good one for linux, but i'll keep looking
[07:26:49] <glYoda> feel free to post the shader and I can advise you about other useful optimizations
[07:27:39] <Will123456> glYoda: sure thing. it's slightly involved and you might well declare it a mad way to go about things
[07:28:07] <Will123456> it's a metaball shader that supplies the particle positions as a long uniform array
[07:28:14] <glYoda> but don't waste your time pulling invariant work out of loops... any compiler worth it's salt is able to do that as a basic optimization step
[07:28:52] <Will123456> then each fragment shader compares the distance from itself to each particle to figure out whether to draw a colour or not. standard metaball stuff
[07:29:02] <glYoda> the same goes for flattening / inlining such loops when the conditions allow for that
[07:29:39] <Will123456> i'll bear that in mind! i had cached the result of the step function, so i think i'll just return that to how it was before i was storing the result
[07:31:01] <glYoda> we have shaders which generate thous
[07:31:20] <Rhamphoryncus> Calculating something in a previous stage is usually worth it though?
[07:31:25] <glYoda> *thousands of instructions today... good optimization an important step
[07:31:37] <glYoda> *is an
[07:31:39] *** Brend has joined ##OpenGL
[07:32:31] <glYoda> well hoisting work out of a more expensive stage and into a cheaper one is a good client side optimization
[07:32:40] <glYoda> like I said earlier
[07:33:03] <Rhamphoryncus> I have an excuse this time: I just got here ;)
[07:33:12] <glYoda> ah
[07:33:17] <Will123456> glYoda: yeah, i managed to calculate in the vertex shader when there wasn't any chance of having any nearby particles and so to discard early in the fragment shader
[07:33:54] <glYoda> also note that you have true subroutine calls nowadays...
[07:36:16] *** plainflavored has quit IRC
[07:36:26] <Will123456> the most complicated part of my metaball shader is firstly that each vertex is given a start and end index of where to iterate over the particle array, and secondly the way it stores the densities for multiple 'types' of metaball and uses those values as where to look on a texture.
[07:36:39] *** nahhh has left ##OpenGL
[07:37:13] <Will123456> i was trying to think of a good way to avoid doing 9 texture look ups if i had 9 different types of metaball that i wanted in the game (but only say, 2 being rendered in that given frame)
[07:37:16] <glYoda> two big optimizations (closely related...) useful for clients: (1) moving work between shader stages (from most to least expensive), (2) eliminating work which is unnecessary yet reachable within a given stage
[07:37:29] *** davidbitton has quit IRC
[07:37:32] <glYoda> due to some other (compiler unknown) state combination
[07:39:34] <Will123456> glYoda: thanks for the tips - i'll try to look for 2 in my shaders (as far as i can tell i've moved as much as i can from the fragment shader to the vertex shader)
[07:42:23] <glYoda> tackle higher level optimizations at your level (i.e. more efficient algorithms for instance) and you should be fine
[07:42:53] <glYoda> and use a good shader profiler to help with this
[07:43:46] <Will123456> semi-relatedly: is there any built in glsl function for doing foo / bar to get a value from 0.0 to 1.0? i can only find smoothstep, which isn't a linear interpolation. i read that using the native function for an operation is usually faster
[07:44:57] <glYoda> well LERP itself is indirectly exposed through the mix built in function
[07:47:10] <Will123456> but mix requires a value from 0.0 to 1.0 as the ratio, right? so i'd already have to do my division
[07:47:13] * Rhamphoryncus rolls his eyes at himself
[07:47:59] <glYoda> 1/x is a pretty efficient operation
[07:48:06] <Rhamphoryncus> Couldn't figure out why my dummy geometry shader wasn't drawing anything.  I was assigning to my vec3 position and vec3 colour and emitting the vertex and everything!  :P
[07:48:18] <glYoda> there is a significant amount of HW dedicated to that task on most GPUs
[07:48:24] *** ToreTank has quit IRC
[07:48:54] <Will123456> glYoda: i might as well not worry about it then :)
[07:49:10] *** replore has quit IRC
[07:49:10] *** replore_ has quit IRC
[07:49:41] <glYoda> another (possibly useful) bit of info: clamping the result of a given expression is often free (or nearly free) due to HW support for such tasks
[07:49:52] <Rhamphoryncus> Turns out opengl doesn't know that when I assign to my own vec3 that I mean it to be the vec4 for gl_Position
[07:50:19] *** maum has joined ##OpenGL
[07:52:18] <Will123456> glYoda: that is useful, yeah
[07:52:28] <glYoda> it's good to note that 1/x and 1/sqrt(x) for instance are very common operations in the graphics space
[07:52:39] <glYoda> they need to be reasonably fast
[07:53:21] <glYoda> at least for SP FP
[07:53:37] <glYoda> (in the / case)
[07:55:04] <Will123456> that's good, because i've been using a lot of them and worrying about it
[07:55:49] <Rhamphoryncus> I've heard that glsl builtins are depreciated/discouraged, but does that only apply to the ones that actually are depreciated?  I've got the quick reference open so I can see what's gone and what's left
[07:56:54] *** TheFlash has quit IRC
[07:57:07] <HuntsMan> deprecated, not depreciated
[07:57:36] <Rhamphoryncus> bluh.  I knew it was wrong but the spellcheck said it was fine.
[07:58:34] <Rhamphoryncus> *checks*  Oh yeah, that's what depreciation is..
[07:59:54] <Rhamphoryncus> Related, what about passing my own position between stages (possibly vec2 or vec3)?  Will it omit the builtin gl_Position or am I just adding another variable to copy around?
[08:00:23] *** TheFlash has joined ##OpenGL
[08:01:05] *** jmcarthur has quit IRC
[08:04:01] *** shundread has joined ##OpenGL
[08:12:07] *** affine has quit IRC
[08:12:07] *** unRuhe has joined ##OpenGL
[08:13:15] <jubei> guys this may be a bit out of ##OpenGL scope but I'll ask anyway. I'm loading geometry from an external file with assimp but whenever my loading function goes out of scope, the assimp scene object's contents become funked even if it's a pointer
[08:13:37] <jubei> const aiScene* scene;
[08:14:09] <jubei> the render function also has access to this pointer but for some reason after the init function that loads the geometry the contents of the pointer get... br0ken
[08:14:16] <jubei> how could I debug this?
[08:15:03] <jubei> (the scene pointer belongs to the parent class of those functions, they all have visibility to it)
[08:15:29] <jubei> belong to the parent class is wrong. Is a private member variable of the class, same as those functions.
[08:15:59] *** jackh has quit IRC
[08:16:11] *** jackh has joined ##OpenGL
[08:19:32] *** magentar has joined ##OpenGL
[08:20:16] *** mrotondo has joined ##OpenGL
[08:20:25] *** ToreTank has joined ##OpenGL
[08:22:15] <mrotondo> Hi! I've been seeing a particularly strange visual glitch lately: my textures end up looking like  http://d.pr/i/clI when they should look like: http://d.pr/i/DyyA (just the cap)
[08:23:03] <mrotondo> In this case, I'm generating the spotted mushroom cap texture via an FBO, and then generating the whole mushroom texture immediately afterwards, using the cap texture, in another FBO
[08:23:45] *** jackh has quit IRC
[08:24:18] <mrotondo> I have no idea what's going wrong, and it seems like this might be the kind of recognizable bug that someone could give me some pointers on
[08:25:24] *** Jeaye has quit IRC
[08:25:25] *** mrotondo has quit IRC
[08:25:52] *** mrotondo has joined ##OpenGL
[08:27:20] *** mrotondo has quit IRC
[08:27:25] *** jackh has joined ##OpenGL
[08:27:30] *** Beelsebob has joined ##OpenGL
[08:27:46] *** mvtx has joined ##OpenGL
[08:29:15] *** mrotondo has joined ##OpenGL
[08:30:24] *** mrotondo has quit IRC
[08:32:51] *** mrotondo has joined ##OpenGL
[08:33:51] *** fayimora has quit IRC
[08:35:40] <Rhamphoryncus> jubei: The obvious thought is the scene object gets deallocated
[08:36:30] <jubei> Rhamphoryncus, I think that might be happening because that's the importers job. bring stuff in, then you're supposed to convert it to your mesh format or something, then it destroys the scene object coz you don't need it anymore
[08:36:45] <Rhamphoryncus> yeah
[08:37:05] *** Noctifer has quit IRC
[08:41:57] *** KAHR-Alpha has joined ##OpenGL
[08:43:55] *** mrotondo has quit IRC
[08:45:18] *** mrotondo has joined ##OpenGL
[08:47:11] *** mrotondo has quit IRC
[08:47:48] *** mrotondo has joined ##OpenGL
[08:50:07] *** mrotondo has quit IRC
[08:52:14] *** Wagoo has quit IRC
[08:53:23] *** Wagoo has joined ##OpenGL
[09:02:46] *** damir__ has joined ##OpenGL
[09:04:12] *** Wagoo has quit IRC
[09:06:22] *** forests has joined ##OpenGL
[09:06:28] *** Wagoo has joined ##OpenGL
[09:08:00] *** pbor has joined ##OpenGL
[09:09:47] *** Burga has joined ##OpenGL
[09:12:45] *** GibbaTheHutt has joined ##OpenGL
[09:13:26] *** thedmd has joined ##OpenGL
[09:17:22] *** thedmd has quit IRC
[09:17:40] *** KAHR-Alpha has quit IRC
[09:22:27] *** mazachri has joined ##OpenGL
[09:26:40] *** thedmd has joined ##OpenGL
[09:27:28] *** madsy has quit IRC
[09:28:30] *** Beelsebob has quit IRC
[09:29:01] *** alonl has joined ##OpenGL
[09:31:38] *** Beetny has joined ##OpenGL
[09:32:58] *** adu has quit IRC
[09:34:23] *** Tuxist has joined ##OpenGL
[09:34:47] *** Lemml has joined ##OpenGL
[09:38:28] *** Xmas| has joined ##OpenGL
[09:40:28] *** skypers has joined ##OpenGL
[09:43:14] *** mm765 has joined ##OpenGL
[09:44:02] *** Beelsebob has joined ##OpenGL
[09:47:54] *** rendar has joined ##OpenGL
[09:48:10] *** rendar has joined ##OpenGL
[09:48:29] *** rendar has joined ##OpenGL
[09:50:41] *** KonoM has quit IRC
[09:52:43] *** KonoM has joined ##OpenGL
[09:59:31] *** baedert has joined ##OpenGL
[10:02:21] *** brachyon1c has joined ##OpenGL
[10:27:09] *** glcrazy has joined ##OpenGL
[10:28:56] *** ninzine has joined ##OpenGL
[10:32:26] *** glcrazy has left ##OpenGL
[10:34:29] *** Beelsebob has quit IRC
[10:34:45] *** Beelsebob has joined ##OpenGL
[10:36:32] *** glcrazy has joined ##OpenGL
[10:42:34] *** MarcoFe has joined ##OpenGL
[10:42:34] *** MarcoFe has joined ##OpenGL
[10:49:55] *** contingo has joined ##OpenGL
[10:52:42] *** rurufufuss has joined ##OpenGL
[10:52:48] *** Articulate has joined ##OpenGL
[10:54:51] *** Slartibart has quit IRC
[10:56:15] *** Will123456 has quit IRC
[10:57:08] *** __doc__ has joined ##OpenGL
[11:08:34] *** Articulate has quit IRC
[11:11:55] *** devbug has quit IRC
[11:12:54] *** TzilTzal has joined ##OpenGL
[11:22:02] *** maum has quit IRC
[11:23:16] *** fyolnish has quit IRC
[11:29:26] *** Mercury12314 has joined ##OpenGL
[11:29:55] *** Per4u3e has joined ##OpenGL
[11:30:14] *** jackh has quit IRC
[11:44:09] *** magentar has quit IRC
[11:56:19] *** magentar has joined ##OpenGL
[11:57:39] *** TheFinal has joined ##OpenGL
[11:58:07] <TheFinal> hi everyone... does anyone have a source code sample, in opengl of course, using an halfedge structure?

top