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

20151228 05:05:13 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20151227050513.html
20151228 05:05:13 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20151228050513.html
20151228 12:06:02 * spaceemotion (~spaceemot@anon) has joined #jogamp
20151228 14:19:51 <spaceemotion> rmk0 btw, I got apitrace working when I put my application in a full GLWindow instead, it really is swing messing the tracing up
20151228 14:22:17 <spaceemotion> http://puu.sh/mblds/d788230397.trace
20151228 14:23:34 <rmk0> disturbing... wonder what changed
20151228 14:23:46 <spaceemotion> Seems like my framebuffers are indeed a bit worng :/
20151228 14:23:49 <rmk0> i was tracing applications in swing roughly eight months ago
20151228 14:24:04 <rmk0> haven't tried recently
20151228 14:24:42 <spaceemotion> well, i did create an issue for that: https://github.com/apitrace/apitrace/issues/409
20151228 14:25:06 <spaceemotion> but yeah, this does not seem to be right: http://puu.sh/mblly/39675bf314.png
20151228 14:26:28 <spaceemotion> although, looking through the trace, it seems like apitrace cannot handle multiple contexts, my API calls aren't even showing in there!
20151228 14:30:53 <rmk0> in my experience, it does handle multiple contexts (the last bug i filed was down to having multiple contexts but without a drawable on one of them)
20151228 14:31:14 <spaceemotion> hmmm weird…
20151228 14:31:15 <rmk0> sgothel isn't here... he might be able to shed some light on what the swing components are doing
20151228 14:31:30 <rmk0> i have no idea how the implementation works
20151228 14:39:54 <spaceemotion> well, that weird bug aside, the picking buffer still seems to have the wrong "settings"
20151228 14:40:26 <spaceemotion> you said that i should set every pixel to be a uint32 as opposed to a 4tuple 8-bit unsigned fixed point
20151228 14:40:42 <spaceemotion> did you mean that on the texture or the buffer storage itself?
20151228 14:41:25 <rmk0> i'm not sure what buffer storage would mean in this context
20151228 14:41:57 <rmk0> the texture should be R32UI
20151228 14:42:14 <spaceemotion> both, internal and normal format?
20151228 14:43:17 <rmk0> format would be GL_RED_INTEGER, internal format would be GL_R32UI
20151228 14:44:05 <rmk0> .. shit, did i say GL_RED yesterday?
20151228 14:44:08 <rmk0> if so... my mistake!
20151228 14:44:29 <spaceemotion> no problem ^^
20151228 14:44:35 <rmk0> GL_RED would be an unsigned normalized fixed-point format
20151228 14:44:44 <spaceemotion> and for the buffer storage, i currently got DEPTH24_stencil_8
20151228 14:44:58 <spaceemotion> and color_attachment0
20151228 14:45:13 <rmk0> right
20151228 14:45:44 <rmk0> by default, draw buffer 0 goes to color attachment 0, and if you don't explicitly assign a location to the fragment shader output, it uses 0
20151228 14:45:50 <spaceemotion> okay
20151228 14:46:15 <spaceemotion> my texture type is currently set to GL_UNSIGNED_IT
20151228 14:47:25 <rmk0> that seems right
20151228 14:47:42 <spaceemotion> hmmm, still getting nothing, just a black image
20151228 14:48:16 <spaceemotion> even though I already updated my shader to do "outputColor = uint(100) + u_index" to check if things change
20151228 14:48:34 <rmk0> depressing
20151228 14:48:44 <spaceemotion> nah, just programming :P
20151228 14:49:05 <rmk0> i don't tolerate silent failure in anything i program with... opengl is just horrible
20151228 14:49:27 <rmk0> would dump it in a second if there was a portable alternative
20151228 14:50:15 <rmk0> are you using the DebugGL classes?
20151228 14:50:36 <rmk0> they check glGetError after every call, to detect errors early
20151228 14:51:47 <spaceemotion> no, i'm actually not
20151228 14:52:02 <spaceemotion> but I do use a custom method that I call after every major call
20151228 14:52:12 <rmk0> right
20151228 14:52:12 <spaceemotion> e.g. texture loading, framebuffers etc.
20151228 14:52:13 <spaceemotion> it's all fine atm
20151228 14:52:23 <spaceemotion> nothing in console
20151228 14:54:43 <spaceemotion> let met try to use the pick buffer with normal RGB colors again, and see if I'm even drawing things on it
20151228 14:58:33 <spaceemotion> ah, nope, still all black… hmm
20151228 14:59:20 <spaceemotion> alright, so even if I set the output color to full white ( vec3(1) ) it remains black
20151228 14:59:25 <spaceemotion> might be something wrong entirely then
20151228 15:00:28 <rmk0> is the depth buffer cleared?
20151228 15:00:36 <rmk0> is depth testing enabled/disabled?
20151228 15:00:48 <rmk0> all shader parameters assigned?
20151228 15:01:15 <spaceemotion> testing is disabled, depth buffer only cleared on the pick framebuffer, but not the main (0) one
20151228 15:11:29 <spaceemotion> yeah, this seems pretty weird, even the clear color is not showing…
20151228 15:11:45 <spaceemotion> the one from the picking fbo
20151228 15:12:09 <rmk0> is very difficult to say what could be wrong
20151228 15:12:15 <rmk0> there's a ton of state
20151228 15:14:14 <spaceemotion> well, i am rendering the two buffers almost exactly. the only difference is that I switched out the shader
20151228 15:14:32 <spaceemotion> and even if I make the shader identical, it still remains black
20151228 15:15:06 <rmk0> are all of the shader parameters assigned?
20151228 15:15:15 <rmk0> you'd need to re-send matrices and so on
20151228 15:15:31 <spaceemotion> yes
20151228 15:15:42 <spaceemotion> but I might found out something
20151228 15:16:01 <spaceemotion> alright, yup now its rendering
20151228 15:16:09 <rmk0> hehe, what was it?
20151228 15:16:14 <spaceemotion> i forgot a resize call xD
20151228 15:16:26 <rmk0> wrong viewport?
20151228 15:16:44 <spaceemotion> well, i never created the buffer it looks like, as I never called my fbo.resize() method
20151228 15:16:54 * spaceemotion can tell he hasn't eaten breakfast yet
20151228 15:17:12 <rmk0> it's worth looking at the Parameters tab of the Current State section in apitrace
20151228 15:17:20 <rmk0> the "only show non-defaults" checkbox
20151228 15:17:31 <rmk0> it will tell you things like your current viewport size and so on
20151228 15:17:55 <rmk0> is very good at finding bits of state that could be causing problems
20151228 15:19:29 <spaceemotion> alright, jogl is striking again; 0x8236 is not supported when trying to create the texture image
20151228 15:20:14 <spaceemotion> that would be GL_R32UI
20151228 15:21:43 <rmk0> checking to see exactly which parameters i use
20151228 15:22:29 <rmk0> i wrapped this stuff in a very strongly typed API years back in despair
20151228 15:23:31 <spaceemotion> haha
20151228 15:25:35 <rmk0> the third parameter, internalformat, to glTexImage2D is 0x8236
20151228 15:26:10 <rmk0> the seventh parameter, format, is 0x8D94
20151228 15:26:33 <rmk0> the eigth parameter is 0x1405
20151228 15:47:31 <spaceemotion> hmm, while it no longer spits out an error, reading the mouse color now does
20151228 15:47:45 <spaceemotion> i actually had the internal and normal format reversed :)
20151228 15:48:32 <spaceemotion> aha! got it
20151228 15:48:35 <spaceemotion> niceee works :D
20151228 15:50:14 <rmk0> huzzah
20151228 15:50:25 <spaceemotion> \o/
20151228 15:50:53 <spaceemotion> now, how do I do 3d billboarding? something like the transformation gizmos in the 3d applications
20151228 15:51:08 <spaceemotion> as in, they don't change their size when zoomed in our out
20151228 15:51:56 <rmk0> haven't implemented that before
20151228 15:52:01 <spaceemotion> ah dang
20151228 15:52:10 <rmk0> as far as i know, it's just matrix work
20151228 15:52:15 <spaceemotion> i did see Eclesia doing something like that though
20151228 15:52:46 <spaceemotion> thanks for your support so far, rmk0, really appreciate it
20151228 15:52:53 <rmk0> no problem
20151228 15:53:17 <spaceemotion> finally somebody i can directly "talk" to, waiting for answers on stack overflow takes forever…
20151228 15:53:54 <rmk0> there is an #opengl, but in my experience it's pretty hostile
20151228 15:54:25 <rmk0> they'd probably skin you alive if you went in there and said you were using java
20151228 15:54:33 <spaceemotion> haha, yeah
20151228 15:55:02 <rmk0> everyone knows you can only talk to a gpu with c++
20151228 15:55:05 <spaceemotion> i really like java for its simplicity, quickly being able to protoype stuff, but also be able to expand it later on
20151228 15:55:20 <spaceemotion> sometimes miss pointers, but eh
20151228 15:55:52 <rmk0> there aren't many languages out there with working concurrency, a decent static type system, a good jit, a good gc, and libraries
20151228 15:56:04 <rmk0> you can usually get three out of five
20151228 15:56:23 <spaceemotion> ha, yeah. java is powerful if used correctly
20151228 15:56:33 <bruce-> don't forget the tooling
20151228 15:56:38 <rmk0> and that
20151228 15:56:48 <rmk0> i'm not exactly a fan of the language design, but it's not bad in a way that's dangerous
20151228 16:28:12 <spaceemotion> rmk0 hmm, just noticed my depth tests are not working, searching showed me that my depth buffers are wrong, would I need a second, depth-only attachement for my "visual" frame buffer?
20151228 16:29:20 <spaceemotion> and yes, i am clearing my color and depth buffers…
20151228 16:29:30 <rmk0> by visual, do you mean the one that makes it to the screen?
20151228 16:29:35 <spaceemotion> yep
20151228 16:29:44 <rmk0> you'll almost certainly have a window-provided depth buffer there
20151228 16:30:08 <spaceemotion> well, i got the default, provided buffer, my own visual and the picking one
20151228 16:30:15 <spaceemotion> the picking gets rendered first, then the visual
20151228 16:30:27 <spaceemotion> the texture of the visual gets rendered to the main one as a texture on a quad
20151228 16:31:54 <rmk0> what is it that's going wrong?
20151228 16:32:33 <spaceemotion> this it how it looks like (obviously the grid should be above the quad): http://puu.sh/mbron/86106b2627.png
20151228 16:33:56 <rmk0> which out of the grid and the quad are being rendered first?
20151228 16:34:42 <spaceemotion> first the grid, then the quad
20151228 16:35:39 <rmk0> sounds like depth testing is off
20151228 16:36:00 <spaceemotion> is depth testing global or per frame buffer? should be global, right?
20151228 16:36:13 <rmk0> yeah, global
20151228 16:36:50 <rmk0> can you verify that you've actually got a depth attachment on the framebuffer? apitrace will tell you
20151228 16:36:58 <rmk0> in the usual way, if you don't have one, depth testing will silently not happen
20151228 16:37:13 <spaceemotion> only got a color_attachement0
20151228 16:37:27 <rmk0> you need a depth attachment to get depth testing
20151228 16:37:46 <spaceemotion> alright, yup, that works now
20151228 16:38:01 <rmk0> there's a minor optimization that you could use in your case
20151228 16:38:22 <rmk0> because you're doing that picking pass prior to rendering the visuals, you could actually use the picking step to populate the depth buffer
20151228 16:38:34 <bruce-> what are good tools to debug multithreaded opengl on OSX? I am running into a strange problem where one threaded freezes in inside glTexImage2D and the other in glDrawArraysInstanced
20151228 16:38:36 <spaceemotion> so i can reuse the depth buffer?
20151228 16:38:40 <rmk0> attach the same depth texture to the picking and visual framebuffers, and set the depth test to GL_EQUAL
20151228 16:39:00 <rmk0> er, set it to GL_EQUAL after you've populated it, and turn off depth writing during the visual pass
20151228 16:39:35 <spaceemotion> well, i actually do render different things in the picking pass, so it would be different anyways
20151228 16:39:41 <rmk0> oh
20151228 16:40:26 <spaceemotion> all I did now, was adding an extra glFramebufferRenderbuffer
20151228 16:40:52 <spaceemotion> for example, the grid is not selectable
20151228 16:41:18 <rmk0> right, makes sense
20151228 16:41:35 <rmk0> yeah, you can still share the depth attachment if you'll be clearing it between passes
20151228 16:42:12 <spaceemotion> but I'm not even generating two textures per fbo…
20151228 16:42:33 <spaceemotion> oh wait, you mean the render buffer, not texture, right?
20151228 16:42:49 <rmk0> are you using a renderbuffer for the depth attachment?
20151228 16:44:03 <spaceemotion> http://hastebin.com/yuxokemutu.java this is my full FBO class http://hastebin.com/udatahavok.java
20151228 16:44:19 <spaceemotion> I'm creating the attachments in line 79 and 80
20151228 16:44:53 * spaceemotion just noticed that hastebin has weird line numbering
20151228 16:48:09 <spaceemotion> well, i guess i wouldn't need that minor optimization
20151228 16:48:28 <spaceemotion> i only update when I change my scene anyways (which is not even 10 times a second)
20151228 16:49:31 <rmk0> is mostly just to save memory
20151228 16:49:47 <rmk0> unlikely to be a problem in your case
20151228 16:49:56 <spaceemotion> yeah, but thanks for the hint!
20151228 16:49:57 <rmk0> i only work with deferred renderers, so i'm always looking to save memory!
20151228 16:50:04 <spaceemotion> ;)
20151228 18:44:22 * Eclesia (~eclesia@anon) has joined #jogamp
20151228 18:44:27 <Eclesia> hi
20151228 18:45:55 <rmk0> lo
20151228 18:49:11 <spaceemotion> o/ Eclesia
20151228 18:50:41 <spaceemotion> Eclesia i saw in one of your videos that you're working on a 3d model editor as well (specifically the bone/joints animation thingy), how did you do your rotation gizmos? how did you get them to not change their size when zooming in and out?
20151228 18:51:18 <Eclesia> they change size ^^
20151228 18:51:25 <spaceemotion> ah dang haha
20151228 18:51:33 <Eclesia> old code, not sure I still have those anyway
20151228 18:51:41 <spaceemotion> i would simply add a u_size value to my shader
20151228 18:52:03 <spaceemotion> and before each "billboard" model I would calculate the distance of their origin to the camera, and pass that as a scale-matrix
20151228 18:52:58 <Eclesia> hm nope, made it another way a few weeks ago
20151228 18:53:21 <Eclesia> screen space billboard and axis aligned billboard
20151228 18:53:35 <spaceemotion> alright, how did you approach that?
20151228 18:53:56 * Eclesia go check the code
20151228 18:54:59 <Eclesia> the class : https://bitbucket.org/Eclesia/unlicense/src/a8f50af223cf862e71dfe56e1604941005468e44/engine/engine-opengl/src/main/java/un/engine/opengl/mesh/BillBoard.java?at=default&fileviewer=file-view-default
20151228 18:55:44 <Eclesia> vertex shader : https://bitbucket.org/Eclesia/unlicense/src/a8f50af223cf862e71dfe56e1604941005468e44/engine/engine-opengl/src/main/resources/un/engine/opengl/shader/billboard/billboard-0-ve.glsl?at=default&fileviewer=file-view-default
20151228 18:55:52 <Eclesia> geometry shader : https://bitbucket.org/Eclesia/unlicense/src/a8f50af223cf862e71dfe56e1604941005468e44/engine/engine-opengl/src/main/resources/un/engine/opengl/shader/billboard/billboard-3-ge.glsl?at=default&fileviewer=file-view-default
20151228 18:57:00 <Eclesia> my shaders are 'heavy', they produce the vertex in all coordinate systems ^^ .
20151228 19:05:32 <Eclesia> spaceemotion: does that help ?
20151228 19:05:58 <Eclesia> it ain't finished, more like a working draft :/
20151228 19:06:01 <spaceemotion> was afk for a sec, currently looking through ^^
20151228 19:06:07 <spaceemotion> i am not using geometry shaders though…
20151228 19:34:25 <spaceemotion> do you by any chance have an FXAA shader though? :)
20151228 19:36:45 <Eclesia> a bad one, but I have some warnings on it, the original source where I found it isn't online anymore and I have some doubts if it's really safe to consider it public domain :/
20151228 20:07:04 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20151228 20:08:41 <spaceemotion> rmk0 how do you think Maxon achieved this effect in cinema4d? http://gfycat.com/UnrealisticEvilIchthyosaurs
20151228 20:11:14 <rmk0> hm!
20151228 20:11:43 <spaceemotion> in fact, how can one create an infinite grid anyways?
20151228 20:11:49 <spaceemotion> it's not a texture, right?
20151228 20:12:27 <rmk0> i don't think it's a texture, no
20151228 20:14:15 <rmk0> i think it's drawing a fixed-size grid, but the grid itself is not actually conceptually placed in the world as an object
20151228 20:14:32 <rmk0> it's just oriented to match the camera and overlaid (or underlaid) into the scene
20151228 20:15:47 <rmk0> i'd guess they vary the shading of individual grid lines depending on distance to give the illusion of an infinitely large grid
20151228 20:16:01 <rmk0> reminds me of https://en.wikipedia.org/wiki/Shepard_tone
20151228 20:16:18 <spaceemotion> heh, yea
20151228 20:17:59 <rmk0> i wonder if you could render this by drawing two grid structures and just fading between one or the other based on distance
20151228 20:18:43 <rmk0> ... you could probably apitrace it and find out /o\
20151228 20:18:55 <spaceemotion> uhh, right
20151228 20:18:59 <rmk0> hehe
20151228 20:23:53 <spaceemotion> http://puu.sh/mbEqs/94a0507bd0.trace
20151228 20:24:03 <spaceemotion> can't really seem to see what they're doing…
20151228 20:24:34 * rmk0 eyes it
20151228 20:24:41 <spaceemotion> their Texture1 seems to have some color on it
20151228 20:24:47 <spaceemotion> if you bump up the "lower" to 0.99
20151228 20:28:34 <rmk0> i'm not able to replay that on this hardware (only have 3.3)
20151228 20:28:37 <rmk0> currently reading the calls
20151228 20:30:53 * badshah400 (~badshah40@anon) has joined #jogamp
20151228 20:31:10 <rmk0> it does look like they draw two grids
20151228 20:31:23 <rmk0> four sets of lines
20151228 20:31:46 <spaceemotion> and then just merging two textures?
20151228 20:31:57 <rmk0> no textures involved
20151228 20:32:14 <rmk0> they just draw them directly as GL_LINES
20151228 20:32:55 <rmk0> the vertex shader works out the "fade" amount based on what i assume is the viewer distance to the origin
20151228 20:33:34 * badshah400 (~badshah40@anon) Quit (Client Quit)
20151228 20:34:07 <rmk0> they're fading out one grid as they're fading the other one in
20151228 20:53:22 <spaceemotion> how do you even fade lines? can they be rendered with an alpha color as well (never tried that)
20151228 20:55:26 <rmk0> https://www.opengl.org/wiki/Blending
20151228 20:57:07 <spaceemotion> well, yeah, but that always requires sorting my stuff first, wouldn't it?
20151228 20:57:26 <rmk0> "it depends"
20151228 20:57:49 * badshah400 (~badshah40@anon) has joined #jogamp
20151228 20:58:19 <rmk0> is typical to draw opaque objects in an arbitrary order, with depth testing enabled
20151228 20:58:30 <rmk0> and then draw translucent objects from furthest to nearest with blending enabled
20151228 22:13:42 <spaceemotion> rmk0 well, it's that time again, see you tomorrow, i guess :)
20151228 22:15:20 * spaceemotion (~spaceemot@anon) Quit (Quit: Textual IRC Client: www.textualapp.com)
20151229 00:32:24 * badshah400 (~badshah40@anon) Quit (Quit: badshah400)
20151229 00:32:55 * badshah400 (~badshah40@anon) has joined #jogamp
20151229 01:18:43 * badshah400 (~badshah40@anon) Quit (Quit: badshah400)
20151229 01:19:14 * badshah400 (~badshah40@anon) has joined #jogamp
20151229 01:24:11 * badshah400 (~badshah40@anon) Quit (Ping timeout: 264 seconds)
20151229 05:05:13 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20151229050513.html