#jogamp @ irc.freenode.net - 20151226 05:05:13 (UTC)

20151226 05:05:13 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20151225050513.html
20151226 05:05:13 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20151226050513.html
20151226 09:44:24 * rmk0 (~rmk0@anon) has joined #jogamp
20151226 12:32:36 * Eclesia (~eclesia@anon) has joined #jogamp
20151226 12:32:40 <Eclesia> hi
20151226 14:25:34 * Eclesia (~eclesia@anon) has left #jogamp
20151226 16:08:59 * Eclesia (~eclesia@anon) has joined #jogamp
20151226 18:01:04 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20151226 19:32:09 * spaceemo_ (~spaceemot@anon) has joined #jogamp
20151226 19:33:00 <spaceemo_> Hello and merry (belated) christmas! I'm currently having some trouble with color picking and JOGL, may I get some help with that?
20151226 19:33:05 * spaceemo_ is now known as spaceemotion
20151226 19:35:58 <rmk0> 'lo
20151226 19:36:03 <rmk0> spaceemotion: what do you mean by color picking?
20151226 19:36:49 <spaceemotion> rmk0 hey, thanks for having me.I want to add simple object selection to my application, using the so-called "color picking" method
20151226 19:37:49 <spaceemotion> it generally works like this: you assign a unique color to each object, render the scene unlit and without textures, using that color, get the color beneath the cursor, get your object from that color and re-render the scene this time with textures and lighting
20151226 19:38:04 <rmk0> hm, right
20151226 19:38:05 <spaceemotion> the user never sees the first pass
20151226 19:38:37 <spaceemotion> well, I got the two passes implemented, but JOGL's glReadPixels returns the RGB values of the previous pass it seems
20151226 19:38:57 <spaceemotion> I glClear the scene, render my stuff, glFlush and glFinish, then glReadPixels and glClear again
20151226 19:39:22 <spaceemotion> it seems like it only picks up the colors of the previous buffer swap
20151226 19:39:52 <rmk0> are you limited to some older version of opengl? it seems like framebuffer objects would make this more pleasant
20151226 19:40:13 <spaceemotion> I am already using OpenGL 3 with shaders
20151226 19:41:31 <rmk0> i would create a framebuffer object with a depth attachment and a single RED_32 color attachment
20151226 19:41:45 <spaceemotion> this is the code for my current "picking" method: http://hastebin.com/jesanetenu.java
20151226 19:42:19 <rmk0> right, nothing surprising in there
20151226 19:42:42 <rmk0> i haven't touched glReadPixels for a good five years... i'm not sure how it interacts with double buffering
20151226 19:43:22 <spaceemotion> i actually never worked with frame buffers before, although I do know that It allows to render a scene onto multiple "targets" such as to display multiple views (like CCTV cams and such)
20151226 19:43:55 <rmk0> you're actually almost certainly already using one... the window system provides a default framebuffer
20151226 19:45:58 <rmk0> basically... when you write data to a named output in a fragment shader, that output is referring to a "draw buffer"
20151226 19:46:09 <rmk0> each draw buffer is associated with a "color attachment"
20151226 19:46:44 <rmk0> you can create a framebuffer object, add a texture as a color attachment, associate a draw buffer (fragment shader output) with a color attachment, bind the framebuffer...
20151226 19:46:58 <rmk0> and then subsequent rendering commands will end up writing to the attached texture
20151226 19:47:33 <rmk0> unbind the framebuffer, and subsequent rendering commands will go to the default framebuffer (the window, or the screen)
20151226 19:47:58 <rmk0> the main advantage in this case is that you don't have to be concerned with the semantics of glReadPixels
20151226 19:49:35 <rmk0> another advantage is that you can directly render unsigned integers, without having to encode them as RGBA
20151226 19:50:45 <spaceemotion> i only ever need RGB anyways, as unsigned bytes to not loose the precision
20151226 19:51:13 <rmk0> in that example above, you appear to be rendering object indices...
20151226 19:51:52 <spaceemotion> well, I have a unique number per object assigned (not through OpenGL), that I can convert from and to an RGB color
20151226 19:52:13 <spaceemotion> when I render my objects in the "picking" mode, I simply pass that color to my fragment shader
20151226 19:52:55 <rmk0> that's what i'm referring to. you can lose that conversion step and use the unique number directly
20151226 19:53:32 <rmk0> literally render it to an image where every "pixel" is semantically a 32 bit unsigned integer, as opposed to being a 4-tuple of 8 bit unsigned normalized fixed point values
20151226 19:53:52 <spaceemotion> oh, so instead of colors i just "draw" with an index? just like the old nintendo machines did?
20151226 19:53:58 <rmk0> yep
20151226 19:54:00 <spaceemotion> I'm also currently reading through this here: http://www.learnopengl.com/#!Advanced-OpenGL/Framebuffers and it seems like framebuffers are also a nice way to be able to set the multisampling per buffer
20151226 19:54:20 <rmk0> could be... i do antialiasing as a postprocess, personally
20151226 19:54:28 <rmk0> tend to find multisampling to be more trouble than it's worth
20151226 19:55:43 <spaceemotion> i haven't found a decent tutorial on how to do GLSL anti-aliasing yet
20151226 19:55:56 <spaceemotion> I'm fairly new to the new shader pipeline actually, just started two weeks ago :)
20151226 19:57:08 <rmk0> it's a vertical learning curve from this point on!
20151226 19:57:27 <rmk0> i recommend this thing to everyone that comes in here: http://apitrace.github.io/
20151226 19:57:33 <rmk0> don't think i could work with opengl without it
20151226 19:58:46 <spaceemotion> yeah, i saw that, but haven't found a way to get it running for mac osx yet – have not tried compiling it myself though
20151226 20:03:23 <spaceemotion> alright, let's try this though
20151226 20:41:17 <spaceemotion> alright, so it compiled, but how can I build the GUI version of apitrace?
20151226 20:47:25 <spaceemotion> oh wait, installed wrong version of qt
20151226 20:54:33 <spaceemotion> got it ;)
20151226 20:57:59 <rmk0> \o/
20151226 20:59:02 <rmk0> think the most useful feature is being able to show the contents of each framebuffer attachment after each draw call
20151226 21:01:18 <spaceemotion> well, it says my jar file is not a valid application…
20151226 21:01:35 <spaceemotion> i guess I have to do "java -jar pathtojar" ?
20151226 21:07:36 <spaceemotion> yeah, I'm getting errors: "error: failed to open java.trace"
20151226 21:14:10 <spaceemotion> ah, got it working, nice
20151226 21:16:02 <spaceemotion> hmm, it says it never gets a glViewport call
20151226 21:21:30 <spaceemotion> yeah, it's crashing on me… well, let's try this framebuffer stuff then
20151226 21:30:01 <spaceemotion> rmk0 would I need two framebuffers, one for the main view and one for the picking, or just one and the default?
20151226 21:32:44 <rmk0> think that's a matter of taste
20151226 21:33:10 <rmk0> i tend to do all rendering on framebuffers, and then blit a framebuffer to the default window framebuffer as a final step
20151226 21:33:12 <spaceemotion> if I want to do anti aliasing on the main buffer, i guess I need an additional one right?
20151226 21:33:28 <spaceemotion> i would have to update its target texture each time I resize the window though
20151226 21:33:53 <rmk0> yes, and yes
20151226 21:36:35 <spaceemotion> what would the normal type of the texture be? the tutorial I linked earlier is using GL_DEPTH24_STENCIL_8 but I am not using any stencils (i think)
20151226 21:37:18 <rmk0> is up to you... is safest to use one of the formats that opengl requires implementations to support
20151226 21:37:43 <rmk0> if you look at...
20151226 21:37:46 * rmk0 locates
20151226 21:38:10 <rmk0> page 142 of the opengl 3.3 specification
20151226 21:38:59 <rmk0> which i would link to if i could find it on the khronos site
20151226 21:39:13 <rmk0> https://www.opengl.org/registry/
20151226 21:39:20 <rmk0> https://www.opengl.org/registry/doc/glspec33.core.20100311.pdf
20151226 21:39:51 <rmk0> it shows the texture formats that implementations are required to provide. in practice, i think anything >= 3.0 will provide those textures, as they generally base requirements on what existing hardware actually has
20151226 21:40:06 <rmk0> anything marked as a "renderbuffer" format can be used as a color attachment
20151226 21:40:19 <rmk0> the depth formats can be used as depth attachments
20151226 21:40:53 <spaceemotion> so the depth buffers are used for things like particle engines? in which they fade out the texture if it comes close to geometry?
20151226 21:41:19 <rmk0> they're used for depth testing
20151226 21:41:36 <spaceemotion> but seeing it as I want to display a final image on the screen I only need to care about RGB, right? the depth information is getting handled with the shaders, so it wouldn't need to store them in the frame buffer i'm guessing
20151226 21:41:44 <spaceemotion> ah okay
20151226 21:42:01 <rmk0> you need a depth attachment to get depth testing at all, even if you never actually read from the depth texture that you've attached
20151226 21:42:29 <spaceemotion> okay, good to know
20151226 21:42:31 <rmk0> even if you're not using a stencil buffer, using the DEPTH_COMPONENT24 type doesn't actually save any memory as it's padded to 32 bits
20151226 21:42:50 <rmk0> might as well stick with DEPTH24_STENCIL8
20151226 21:43:42 <rmk0> i would think you'd want to go with a single color attachment of type R32UI and a depth/stencil attachment of type DEPTH24_STENCIL8
20151226 21:45:12 <spaceemotion> but wouldn't that only be for a depth buffer then? isn't the color missing in a depth24_stencil8 buffer?
20151226 21:47:56 <rmk0> ... you realize framebuffers can (and almost always will) have more than one attachment, yes?
20151226 21:48:24 <rmk0> usually a color attachment that will contain the actual image bits, and a depth and/or stencil attachment for depth and stencil testing
20151226 21:48:48 <rmk0> it'll probably become a bit clearer when you see it in apitrace
20151226 21:49:43 <spaceemotion> I actually didn't think of that… still a bit overwhelmed by all this stuff which is why I am actually very grateful that I finally found some help :)
20151226 21:49:53 <rmk0> is fine, the api is a nightmare
20151226 21:50:12 <rmk0> in your case, you'd have a depth attachment for depth testing, which ensures your objects appear in the right order onscreen. your object indices would end up in the first (and only) color attachment
20151226 21:51:12 <spaceemotion> in case of the pick buffer, right?
20151226 21:51:16 <rmk0> yep
20151226 21:52:05 <spaceemotion> also: apitrace does seem a bit weird to me: http://puu.sh/m9wy1/a99221299b.png this is how my java application looks like: http://puu.sh/m9wDl/3600ce6cb2.png
20151226 21:52:39 <rmk0> ... that looks like a bug
20151226 21:52:52 <spaceemotion> in apitrace?
20151226 21:52:56 <rmk0> possibly!
20151226 21:53:05 <spaceemotion> how are you tracing your application?
20151226 21:53:17 <spaceemotion> i just run apitrace trace java -jar pathtomyjar.jar
20151226 21:53:25 <rmk0> yeah, like that
20151226 21:53:44 <spaceemotion> hmm, could it be because I have it inside a swing component?
20151226 21:54:23 <rmk0> could you upload the trace file somewhere?
20151226 21:54:49 <rmk0> the swing component may introduce an extra framebuffer somewhere, but it shouldn't affect rendering or apitrace
20151226 21:55:30 <spaceemotion> sure, here it is: http://puu.sh/m9wO0/d8a978509a.trace
20151226 21:55:57 <rmk0> now let's see if i can actually replay it!
20151226 21:56:09 <spaceemotion> it sadly crashes on me :/
20151226 21:56:33 <spaceemotion> may I ask which version of apitrace you are using? win, mac, linux, latest?
20151226 21:56:56 <rmk0> it's a very recent version on linux
20151226 21:57:06 <rmk0> think i compiled it about a week ago from github
20151226 21:57:12 <spaceemotion> self-compiled?
20151226 21:57:12 <spaceemotion> hmm
20151226 21:57:28 <rmk0> i notice that you set a viewport of 64x64
20151226 21:57:48 <spaceemotion> i actually do not, must be JOGL's doing
20151226 21:57:55 <spaceemotion> the only case I set the viewport is in the resize method
20151226 21:57:58 * rmk0 kicks jogl
20151226 21:57:59 <spaceemotion> which I just pass on
20151226 21:58:25 <rmk0> wonder if that's the swing component having a 64x64 starting size somehow, before it gets resized to the proper dimensions
20151226 21:58:44 <spaceemotion> might be
20151226 21:59:49 <rmk0> there's a call to glUseProgram(1) in frame 9, but it doesn't seem like a shader has ever been compiled
20151226 22:00:05 <rmk0> i'm not actually sure on which frame control reaches your code
20151226 22:00:21 <rmk0> i'm assuming that frame, because it looks like initialization code
20151226 22:00:42 <spaceemotion> I do compile three shaders, one for perspective, one for billboarding and one for picking
20151226 22:00:53 <spaceemotion> the billboarding sadly doesnt quite work though
20151226 22:02:02 <rmk0> no calls to glCompile* in that trace... is possible that tracing is broken in your version >_<
20151226 22:02:55 <spaceemotion> ah dang… what version are you using?
20151226 22:03:00 <spaceemotion> might just compile an older one
20151226 22:03:39 <rmk0> looks like it was commit 83032cb35d4a84ba28b3e829feae3f697d13f0b3
20151226 22:04:36 <rmk0> looks like they've fixed a couple of OS X bugs since then
20151226 22:04:56 <spaceemotion> the commit you linked was actually referring to a bug in JOGL as well…
20151226 22:05:09 <rmk0> yeah, i reported that
20151226 22:05:15 <spaceemotion> ah okay :)
20151226 22:05:20 <rmk0> latest JOGL release did something that apitrace couldn't handle
20151226 22:05:30 <spaceemotion> might as well try an older version, and attach my new trace to it
20151226 22:05:46 <spaceemotion> i am still waiting for that opengl3 text rendering
20151226 22:06:06 <spaceemotion> last update on it was in september
20151226 22:09:51 <spaceemotion> hmm, still same issue with 84e644fc7bb99f865374b55e13b36c6760148e53
20151226 22:10:27 <spaceemotion> well, as I don't have that much time left for today I guess I'll try some more tasty frame buffers then
20151226 22:13:32 <rmk0> it seems like they're actually failing to record calls, as opposed to failing to replay them
20151226 22:13:43 <spaceemotion> yup
20151226 22:41:32 <spaceemotion> rmk0 I also noticed that when I call canvas.display() on my GlCanvas, it also calls my reshape method
20151226 22:41:42 <spaceemotion> which updates my viewport and camera matrices…
20151226 22:42:22 <rmk0> not sure what causes that
20151226 22:42:38 <spaceemotion> i guess I'll have to cache the width and height manually and check against those
20151226 22:50:24 <spaceemotion> okay, well I have to go, thanks a lot for helping me out on this one! see you the next time :)
20151226 22:51:05 <rmk0> no problem
20151227 00:12:01 * jk4_ (~jk4@anon) has joined #jogamp
20151227 00:16:35 * spaceemotion (~spaceemot@anon) Quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20151227 00:19:01 * jk4 (~jk4@anon) Quit (Ping timeout: 246 seconds)
20151227 05:05:13 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20151227050513.html