#jogamp @ irc.freenode.net - 20141002 05:05:53 (UTC)

20141002 05:05:53 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20141001050553.html
20141002 05:05:53 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20141002050553.html
20141002 05:06:07 * [Mike] (~Mike]@anon) Quit ()
20141002 05:52:28 * xranby (~xranby@anon) Quit (Ping timeout: 260 seconds)
20141002 06:07:34 * xranby (~xranby@anon) has joined #jogamp
20141002 06:21:28 * monsieur_max (~maxime@anon) has joined #jogamp
20141002 07:03:51 * eclesia (~husky@anon) has joined #jogamp
20141002 07:03:56 <eclesia> hi
20141002 07:04:52 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20141002 07:06:15 <eclesia> sgothel: TBO working in jogamp :) , here is the convenient control class if you want it : https://bitbucket.org/Eclesia/unlicense/src/tip/engine/engine-opengl/src/main/java/un/engine/opengl/resource/TBO.java
20141002 07:11:21 <sgothel> nice, thx!
20141002 07:17:23 <eclesia> sgothel: quick question : you gave me a link once, on how to create a GLDrawable instance which share the same memory space as another. do you still have the link (or another similar) ?
20141002 07:17:31 * xranby (~xranby@anon) has joined #jogamp
20141002 07:18:11 <sgothel> hu? same memory ?
20141002 07:18:20 <eclesia> same resources, textures, vbo ...
20141002 07:18:33 <sgothel> shared context you mean ?
20141002 07:18:39 <eclesia> yes sorry :)
20141002 07:19:34 <sgothel> http://forum.jogamp.org/Best-way-to-prepare-an-Image-td4031731.html#a4031732 <- one of the threads I bookmarked .. hmm
20141002 07:19:59 <sgothel> however, the GLDrawableFactory API-doc mentions this use case AFAIK
20141002 07:20:47 <sgothel> GLSharedContextSetter <- look here as well, you may find our many unit tests
20141002 07:20:56 <eclesia> ok thanks
20141002 07:23:23 <eclesia> just a thought : would be convinient to have a method : GLDrawable createFork() on GLDrawable.
20141002 07:24:31 <sgothel> we have some swapping context from drawable -> drawable .. stuff, in one util class .. so maybe that would be a good place for it
20141002 07:25:08 <sgothel> GLDrawableUtil
20141002 07:25:47 <sgothel> but the parameters would be exhausting here (fork), since use cases differ, on- and offscreen etc
20141002 07:26:48 <eclesia> 2 methods ?
20141002 07:28:08 <eclesia> or perhaps the createFork could only prepare a GLDrawableFactory, leaving all the parameters to the user ?
20141002 07:28:30 <eclesia> (not sure if that's possible, only thoughts)
20141002 07:31:26 <sgothel> GLSharedContextSetter <- I guess that interface makes it pretty easy already
20141002 08:18:50 * gouessej (5ee4b442@anon) has joined #jogamp
20141002 08:19:35 <gouessej> Hi
20141002 08:21:11 <gouessej> sgothel: I'm going to improve the fix of the bug 1078
20141002 08:36:41 * doev (~doev@anon) has joined #jogamp
20141002 08:38:58 <doev> hi
20141002 08:40:18 <doev> the context I get with render(), is it constant?
20141002 08:41:21 <doev> I wanna ask, if it is always the same object?
20141002 08:49:36 <gouessej> doev: No
20141002 08:50:02 <gouessej> doev: Never store GL objects, GLContext objects, etc...
20141002 08:50:35 <gouessej> doev: Use them locally and never make any assumption about whether or not the next display will use the same objects under the hood
20141002 08:51:12 <doev> gouessej, thx, answers my question.
20141002 08:51:14 <gouessej> doev: Where does your render() method come from?
20141002 08:51:46 <doev> gouessej, GLEventListener
20141002 08:52:08 <doev> and get it from the GLAutoDrawable
20141002 08:52:12 <gouessej> doev: ok GLEventListener.display(GLAutoDrawable)
20141002 08:54:16 <doev> gouessej, I was thinking about to store the context in the init callback, but when it is not sure the context object is not valid in later calls, I won't do that.
20141002 08:54:38 <gouessej> doev: Why do you need to do that?
20141002 08:55:04 <doev> gouessej, to reduce the parameters in function calls.
20141002 08:55:29 <gouessej> doev: I have some other suggestions to fix that :)
20141002 08:55:48 <doev> gouessej, ok, tell me :)
20141002 08:56:07 <gouessej> doev: Rather use GLContext.getCurrent() and GLContext.getCurrentGL()
20141002 08:56:37 <gouessej> doev: If you're sure that the OpenGL context is current on the thread calling these methods, it will work
20141002 08:57:20 <doev> gouessej, I don't know if I can be sure about that in future use of my objects.
20141002 08:58:01 <gouessej> doev: but anyway, using a GLContext object on a thread that wouldn't have to tinker OpenGL would be a bad idea
20141002 08:58:51 <doev> gouessej, I see
20141002 08:59:44 <gouessej> doev: getCurrent() returns null if there is no current context on this thread, you don't take the risk of breaking your code if you test the returned value
20141002 09:01:26 <gouessej> doev: In my humble opinion, you shouldn't separate the "entities" that deal with OpenGL from the others
20141002 09:01:44 <gouessej> doev: in order not to require an OpenGL context when it's not absolutely necessary
20141002 09:02:00 <doev> gouessej, agree
20141002 09:02:00 <gouessej> doev: it gives a greater flexibility
20141002 09:02:17 <gouessej> doev: you "should"
20141002 09:02:31 <gouessej> doev: I'm already tired :s
20141002 09:02:44 <doev> gouessej, np :)
20141002 09:03:55 <gouessej> doev: For example, when building a mesh, you can retrieve the mesh data from the disk, you don't need OpenGL until you call glBufferData
20141002 09:53:14 <gouessej> sgothel: GLRendererQuirks.existStickyDeviceQuirk() returns false in my case, I try to use it in PFD2GLCapabilities and AttribList2GLCapabilities
20141002 10:32:47 * doev (~doev@anon) Quit (Ping timeout: 245 seconds)
20141002 11:01:46 * doev (~doev@anon) has joined #jogamp
20141002 11:19:26 * doev (~doev@anon) Quit (Quit: Verlassend)
20141002 12:08:01 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20141002 12:08:47 * gouessej (5ee4b442@anon) has joined #jogamp
20141002 12:10:00 <gouessej> sgothel: Look at that, I pass the right capabilities object -> main-Display-.windows_nil-1-EDT-1: Pbuffer chosenCaps: GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL2ES1/GL2.hw], offscr[pbuffer]]
20141002 12:10:21 <gouessej> sgothel: and I get this crap -> 2 suitable pixel formats found [junit] pixel format 4 (index 0): GLCaps[wgl vid 4 arb: rgba 8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL2ES1/GL2.hw], offscr[pbuffer]] [junit] pixel format 6 (index 1): GLCaps[wgl vid 6 arb: rgba 8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms 24/8/0, dbl, mono , hw, GLProfile[GL2ES1/GL2.hw], offscr[pbuffer]]
20141002 12:11:52 <gouessej> sgothel: Blacklisting some capabilities objects causes much more troubles in this case, wglChoosePixelFormatARB still picks the "faulty" ones.
20141002 12:12:32 <gouessej> sgothel: Then, I get this exception when creating the pbuffer (realization): javax.media.opengl.GLException: pbuffer creation error: unable to re-query chosen PFD ID: 4, hdc 0xffffffffa3010eb9
20141002 12:16:35 <gouessej> sgothel: In my humble opinion, the capabilities objects aren't really wrong, wglChoosePixelFormatARB is buggy in my machine and GLCapabilities2AttribList is only used twice, just before calling wglChoosePixelFormatARB.
20141002 12:18:14 <gouessej> sgothel: The current fix can hardly be improved. I just would like to add a few things to help debugging: System.out -> System.err (see WindowsPbufferWGLDrawable) + AttribList2GLCapabilitiesNoCheck + wglARBPFID2GLCapabilitiesNoCheck
20141002 12:20:17 <gouessej> sgothel: Let me know whether I should add a method fix...() that would be called just before wglChoosePixelFormatARB instead of leaving my fix unchanged in GLCapabilities2AttribList
20141002 13:55:49 * zzuegg (~zzuegg@anon) Quit (Quit: Nettalk6 - www.ntalk.de)
20141002 14:21:00 <gouessej> sgothel: Please have a look at my latest pull request: https://github.com/sgothel/jogl/pull/83
20141002 14:26:58 <eclesia> does someone has code to make shadows for a scene ?
20141002 14:35:53 <gouessej> There is an example in jogl-demos but the license is probably not suitable in your case :s
20141002 14:40:47 <gouessej> sgothel: Should we call addStickyDeviceQuirks here? https://github.com/sgothel/jogl/blob/master/src/jogl/classes/jogamp/opengl/GLContextImpl.java#L2014
20141002 15:43:00 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20141002 15:46:05 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141002 16:05:54 * eclesia (~husky@anon) has left #jogamp
20141002 16:19:45 <sgothel> @Julien: Maybe we can stick w/ sharedResource quirks .. as in the other code path
20141002 16:20:10 <sgothel> i.e. we don't set the sticky quirks for this particular quirk - not necessary
20141002 16:23:13 * monsieur_max (~maxime@anon) has joined #jogamp
20141002 16:46:23 * xranby (~xranby@anon) Quit (Ping timeout: 272 seconds)
20141002 16:50:58 * gouessej (527949c4@anon) has joined #jogamp
20141002 16:51:52 <gouessej> sgothel: Do you consider that there is still something to do for the bug 1078?
20141002 16:56:44 <sgothel> I will look at your pull req 83 later today, currently busy w/ other regressions - thank you
20141002 16:59:32 <gouessej> sgothel: ok, thanks
20141002 17:01:20 * xranby (~xranby@anon) has joined #jogamp
20141002 17:06:11 * [Mike] (~Mike]@anon) has joined #jogamp
20141002 17:08:57 * Eclesia (~eclesia@anon) has joined #jogamp
20141002 17:10:32 * xranby (~xranby@anon) Quit (Ping timeout: 260 seconds)
20141002 17:11:33 * xranby (~xranby@anon) has joined #jogamp
20141002 17:40:59 <Eclesia> sgothel: I have a few problems to make the shared context GL work. it locks on the makeCurrent() method
20141002 17:41:00 <Eclesia> http://pastebin.com/AZhmSJFs
20141002 17:41:16 <Eclesia> could you tell me if I missed something ?
20141002 17:42:22 <Eclesia> gouessej: have you tryed shared context ?
20141002 17:43:35 <gouessej> Eclesia, look at how I use that in JogAmp's Ardor3D Continuation. It has worked for years.
20141002 17:44:19 <Eclesia> could you indicate in which module ?
20141002 17:44:24 <gouessej> yes...
20141002 17:47:35 <gouessej> Eclesia: Our code is a bit difficult to understand s:
20141002 17:47:55 <Eclesia> ^^
20141002 17:48:38 <Eclesia> If even you you can't, I'm goign to have a hard time :D
20141002 17:48:49 <sgothel> so you do it like in StreamWorker ..
20141002 17:49:26 <Eclesia> sgothel: well for now I'm just trying to make something work, not sure if it's the easiest way
20141002 17:50:00 <gouessej> Eclesia: Your code is a lot less robust than ours, you should look at JoglCanvasRenderer.makeCurrentContext()
20141002 17:50:01 <sgothel> whats _not_ working then ?
20141002 17:50:41 <Eclesia> the makeCurrent call is locked.
20141002 17:50:59 <Eclesia> looks like his waiting for something
20141002 17:51:04 <Eclesia> he is*
20141002 17:51:50 <Eclesia> want me to write a small working code ?
20141002 17:52:02 <Eclesia> well not 'working' but runnable :D
20141002 17:52:17 <sgothel> oh .. you have to create the shared thingy from your orig-drawable thread ..
20141002 17:52:23 <sgothel> look how initGL is called
20141002 17:53:14 <Eclesia> ho right, It's called in the main thread
20141002 17:53:58 <gouessej> Eclesia: I agree with Sven. It's so obvious :s
20141002 17:57:05 <Eclesia> Asking something stupid again :x but what is the purpose of GLDrawable if it doesn't have the methods for display and gleventlistener ?
20141002 17:57:26 <Eclesia> (like in GLAutoDrawable)
20141002 17:59:16 <sgothel> layered stuff sir - i.e. the AutoDrawable concept is higher level - and a user shall not be forced to use it
20141002 17:59:23 <sgothel> it's an optional managed code path
20141002 17:59:37 <sgothel> like in StreamWorker, we prefer to stay low ..
20141002 18:00:18 <Eclesia> does that mean we can make calls on the GL object anytime ?
20141002 18:01:05 <Eclesia> I always learned the way 'do you work in the display method' in tutorials
20141002 18:01:29 <sgothel> sure .. thats for starters :)
20141002 18:01:40 * Eclesia is a big noob
20141002 18:01:53 <sgothel> in the end .. you have to ensure makeCurrent/release complies w/ glcontext threading
20141002 18:02:08 <sgothel> in your case here .. you simply have the context current .. hence your new thread blocks, I assume
20141002 18:02:34 <sgothel> so forking off the shared thingy .. shall happen from the current orig context thread
20141002 18:03:12 <gouessej> Eclesia: Managing the context by yourself can become very challenging, I don't advise you to do so
20141002 18:03:21 <sgothel> our other use case (tests) using GLContextShareSetter (sic) .. do that beforehand AFAIK .. and doesn't matter
20141002 18:03:42 <sgothel> yeah .. so this is all NOOB vs 'you have to know what you are doing' :)
20141002 18:03:53 <Eclesia> well I would like to a attach a texture to an fbo, clean it, then cleanup. should I try to work with the GLDrawable or use a GLAUtoDrawable ?
20141002 18:04:02 <sgothel> i.e. w/ GLAutoDrawable we do handle the animator pause/resume and all those fancy things
20141002 18:04:30 <sgothel> like in GLJPanel .. we use the lower APIs in higher level API implementations
20141002 18:04:43 <sgothel> but then .. the application we write w/ higher level API, i.e. GLAD
20141002 18:04:49 <sgothel> b/c it's much easier :)
20141002 18:05:08 <sgothel> hence the lower level code .. takes a bit more time to validate
20141002 18:05:29 <Eclesia> so just to know, what would be the steps ? make current , do my work fbo, then what ?
20141002 18:05:31 <sgothel> TLDR .. your choice :)
20141002 18:05:41 <sgothel> release
20141002 18:05:46 <Eclesia> that's all ?
20141002 18:05:52 <sgothel> well
20141002 18:05:56 <sgothel> what do you want ?
20141002 18:05:57 <sgothel> :)
20141002 18:06:09 <sgothel> we have unit tests w/o using GLAD
20141002 18:06:28 <sgothel> for offscreen .. it's pretty simple, but for onscreen, w/ fullscreen and off- onscreen swaps .. things get complicated
20141002 18:06:48 <sgothel> so .. all depends on your use case
20141002 18:07:05 <Eclesia> well I'm just going to create a FBO, attah a texture, make a clear call, unload fbo and that's it
20141002 18:07:31 <sgothel> for example: On OSX do a NEwtCanvasAWT client -> fullscreen: tons of code gets executed .. from offscreen OSX calayer -> NEWT top-level window
20141002 18:07:43 <sgothel> yeah .. stay low level then
20141002 18:08:02 <Eclesia> ok I give it a try :)
20141002 18:08:20 <sgothel> and if you later want to use an GLEventListener .. then we even have an GLAD wrapper
20141002 18:09:00 <Eclesia> yes I've seen the method, but I just want to clean a multisampled texture
20141002 18:09:48 * xranby (~xranby@anon) Quit (Ping timeout: 260 seconds)
20141002 18:09:53 <Eclesia> unless you know another way to clear those textures without using an fbo ?
20141002 18:10:00 <sgothel> nope
20141002 18:10:12 <sgothel> i.e. it must be a render target
20141002 18:10:25 <sgothel> pbuffer textures .. some still exists :)
20141002 18:10:29 <sgothel> but don't do that :)
20141002 18:10:43 <Eclesia> why ?
20141002 18:10:51 <sgothel> pbuffer is really deprecated
20141002 18:10:58 * xranby (~xranby@anon) has joined #jogamp
20141002 18:11:04 <sgothel> i.e. not platform agnostic .. GLX, WGL, ..
20141002 18:11:25 <Eclesia> ha funny, I've read an article saying it was the fastest way to update a texture
20141002 18:11:46 <sgothel> FBO must be the fastest today .. since we are all relying on that
20141002 18:12:04 <sgothel> so to just clean the thing .. you can just use FBObject itself .. I guess I mentioned that earlier :)
20141002 18:12:15 <sgothel> we have unit tests for such usage as well ..
20141002 18:12:30 <Eclesia> I know but I have different APIs ;)
20141002 18:12:47 <Eclesia> alike, but not exactly the same ^^
20141002 18:12:51 <sgothel> well .. the offscreen drawable uses FBObject
20141002 18:16:04 <gouessej> Eclesia: pbuffer support is a lot less reliable than FBO support
20141002 18:24:54 <sgothel> @Mark: Cameron's Conference Rap <https://www.youtube.com/watch?v=0YBumQHPAeU> :)
20141002 18:25:57 <gouessej> sgothel: lol
20141002 18:27:37 <sgothel> I guess such a video is not possible to produce for Merkel, 'she ain't saying nothing' :)
20141002 18:36:02 <Eclesia> sgothel: I must have forgot something : http://pastebin.com/U6kZTjY0 I have some fbo error : not correctly loaded. am I using the drawable correctly ?
20141002 18:43:01 <Eclesia> AFK back in 30min ++
20141002 19:09:24 * Eclesia is back
20141002 19:33:18 <Eclesia> strange, he makes a bunch of update correctly, then make the error
20141002 19:33:56 <Eclesia> same issue using autodrawable
20141002 19:50:29 * zzuegg (~zzuegg@anon) has joined #jogamp
20141002 19:56:16 <Eclesia> ... failed again ... while make another try next week
20141002 19:56:17 <Eclesia> +++
20141002 19:56:38 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20141002 20:52:40 * gouessej (527949c4@anon) Quit (Quit: Page closed)
20141002 21:09:42 * void256 (~void@anon) has joined #jogamp
20141002 21:11:30 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141002 21:52:36 * void256 (~void@anon) Quit (Remote host closed the connection)
20141002 23:01:56 * xranby (~xranby@anon) Quit (Ping timeout: 260 seconds)
20141002 23:03:05 * xranby (~xranby@anon) has joined #jogamp
20141003 00:19:37 * hharrison (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 33.0/20140923222114])
20141003 00:27:52 * xranby (~xranby@anon) Quit (Ping timeout: 240 seconds)
20141003 01:00:42 * xranby (~xranby@anon) has joined #jogamp
20141003 05:05:53 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20141003050553.html