#jogamp @ irc.freenode.net - 20140827 05:05:32 (UTC)

20140827 05:05:32 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20140826050531.html
20140827 05:05:32 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20140827050532.html
20140827 06:46:18 * monsieur_max (~maxime@anon) has joined #jogamp
20140827 06:57:10 * eclesia (~husky@anon) has joined #jogamp
20140827 06:57:15 <eclesia> good morning
20140827 06:58:16 * jvanek (~jvanek@anon) has joined #jogamp
20140827 08:00:28 * zzuegg2 (~zzuegg@anon) has joined #jogamp
20140827 08:00:30 * monsieur_max1 (~maxime@anon) has joined #jogamp
20140827 08:03:36 * rmk0_ (~rmk0@anon) has joined #jogamp
20140827 08:10:23 * monsieur_max (~maxime@anon) Quit (*.net *.split)
20140827 08:10:23 * rmk0 (~rmk0@anon) Quit (*.net *.split)
20140827 08:10:23 * zzuegg (~zzuegg@anon) Quit (*.net *.split)
20140827 08:11:20 * monsieur_max1 is now known as monsieur_max
20140827 09:34:44 * xranby (~xranby@anon) has joined #jogamp
20140827 10:33:45 * zzuegg2 is now known as zzuegg
20140827 10:53:33 <eclesia> sgothel: 2 questions
20140827 10:53:35 <eclesia> is it possible to make a frame passthrought for mouse events ?
20140827 10:54:19 <eclesia> is it possible to know where are located the other windows ? (all open ones on the desktop)
20140827 10:55:15 <sgothel> (2) technically yes, but we do not expose info of foreign resources
20140827 10:55:32 <sgothel> (1) you need to elaborate on this .. probably best in email/forum post
20140827 10:56:10 <sgothel> (1) public ofc ..
20140827 10:56:26 <eclesia> I played with with javafx recently and noticed when you make a translucent frame, the mouse events are send to the frame under.
20140827 10:56:42 <eclesia> (where pixels has an alpha of 0)
20140827 10:57:24 <sgothel> this surely would violate WMs input event logic .. however, since you can receive and forward events ..
20140827 10:57:50 <eclesia> we can forward events ?
20140827 10:57:56 <eclesia> that would do the trick
20140827 10:58:01 <sgothel> i.e. this would be more a detail of e.g. 'Graph UI' or similar toolkits, than using plain NEWT
20140827 10:58:31 <sgothel> the TK would need to identify the object .. in 3D space (sort of)
20140827 10:58:36 <eclesia> graph ui uses newt, to the fonctionality must be there right ?
20140827 10:58:38 <sgothel> on a WM level .. well
20140827 10:58:46 <eclesia> so the*
20140827 10:58:59 <sgothel> Graph UI would not use native NEWT windows .. but simply doing all in GL within one drawable
20140827 10:59:15 <sgothel> the ray/intersection would determine the object ..
20140827 10:59:35 <sgothel> object can be a 'window' in Graph UI space (we have to do this)
20140827 10:59:48 <sgothel> so bringing all this down to the WM level ..
20140827 11:00:12 <sgothel> you would need to read pixels alpha value .. and have all your NEWT window info .. and then fwd the event ..
20140827 11:00:29 <sgothel> IMHO .. useless
20140827 11:00:30 <eclesia> sgothel: I already have this info,
20140827 11:00:57 <sgothel> then .. you can do this, even though the 'pure GL UI' strategy might me faster etc ..
20140827 11:01:40 <eclesia> so how do I do that ? how I send back the event to the WM ?
20140827 11:02:22 <sgothel> you would need to re-create the even w/ the target window object ..
20140827 11:02:30 <sgothel> then dispatch it .. lets see
20140827 11:03:01 <eclesia> which brings us to question 2 : need to find other windows
20140827 11:03:37 <sgothel> [1.1] either direct to the target window w/o creating a new event: make a calltree of WindowImpl.doPointerEvent(...)
20140827 11:05:39 <sgothel> [1.2] or via Window.enqueueEvent(..)
20140827 11:05:52 <sgothel> I answered (2) already
20140827 11:06:27 <sgothel> (2) you would need to implement a WM query for all TKs
20140827 11:07:02 <eclesia> WM = WindowManager TK = ?
20140827 11:07:06 <sgothel> i.e. walk through all windows for each WM ...
20140827 11:07:25 <sgothel> TK = X11/Xlib, GDI, ..
20140827 11:07:32 <sgothel> the ToolKit
20140827 11:07:36 <sgothel> WM TK
20140827 11:08:12 <eclesia> don't you already have those links since you made newt ?
20140827 11:08:44 <sgothel> only for resources we manage, what do you mean by 'links' ?
20140827 11:09:03 <eclesia> jni to query the WM
20140827 11:09:24 <sgothel> ok, a hint: X11: walk down the X11 root window list (each window may have child windows)
20140827 11:09:41 <sgothel> GDI: I dunno, probably similar queries
20140827 11:10:14 <sgothel> OSX: we use 'high level' NSWindow .. NSSurface .. but low level CGL etc queries exist
20140827 11:10:45 <sgothel> so .. all doable - tedious work
20140827 11:11:03 <eclesia> hm...
20140827 11:11:08 <sgothel> be aware that exposing such information is SECURITY CRITICAL
20140827 11:11:26 <sgothel> i.e. focus stealing .. input event capture .. etc
20140827 11:12:57 <sgothel> In Graph UI for example, we already forward events to the UI object .. but all in GL space already using one simple window, surely this is not what you want if mixing high level TKs (javafx .. etc)
20140827 11:14:05 <sgothel> regarding javafx .. I am w/ Julien here, until there is no usable common interface to low level, we cannot properly mix JOGL w/ FX natively, but only via an FBO
20140827 11:14:12 <sgothel> similar to GLJPanel
20140827 11:14:31 <sgothel> all posted 'success' stories on the forum are unicorns
20140827 11:15:12 <eclesia> let me explain my case : I have lauch a program using java runtime, with a shell command : gdaltranslate -i ...etc...
20140827 11:15:18 <sgothel> sadly .. similar is OculusVR new SDK 0.4 .. w/ their binary blob and non GNU/Linux port
20140827 11:15:46 <eclesia> this will run another app with it's own window, and I would like to display a text and some actions above this frame
20140827 11:16:23 <sgothel> HUD
20140827 11:16:47 <eclesia> ?
20140827 11:16:57 <sgothel> Head Up Display - Overlay
20140827 11:17:48 <sgothel> and your primary gda* is ? .. an external app ? you like to capture events to be displayed in the HUD ?
20140827 11:18:23 <sgothel> i.e. multiply the events to the HUD ..
20140827 11:19:06 <eclesia> non gdal,orfeotoolbox,mathlab are scientific applications. we expect the user to do something in the app before we can continue. so we launch this app and display information message about what he is expected to do.
20140827 11:20:14 <eclesia> I don't won't to capture anything, just should a bar with texts and actions about the frame.
20140827 11:20:22 <eclesia> just show*
20140827 11:20:41 <eclesia> but to do that I need to know where this other frame is
20140827 11:20:41 <sgothel> hmm .. so non free software .., however, can't you extend the scripts in e.g. mathlab so they pipe information to a file ?
20140827 11:21:38 <eclesia> we alread ytrack what the application is doing since we gave it arguments at execution
20140827 11:22:13 <eclesia> but we still need to guide the user since they are not familiar with the app.
20140827 11:22:24 <sgothel> well, then that application shall just pipe needed information to a file, your program can utilize IMHO .. i.e. your own IPC
20140827 11:22:37 <sgothel> Inter Process Communication
20140827 11:23:06 <eclesia> If we could modify the app yes, but that's not the case
20140827 11:23:19 <sgothel> at least such architecture would work on all platforms
20140827 11:23:20 <eclesia> it's a scientific tool we don't develop
20140827 11:23:28 <sgothel> mathlab can be scripted .. i.e. you can do that
20140827 11:23:31 <sgothel> the others not ?
20140827 11:23:36 <eclesia> mathlab is just one of them
20140827 11:24:20 <sgothel> well, then - it's the hard way as you suggested (TK even capture), good luck!
20140827 11:24:45 <eclesia> :(
20140827 11:25:01 <sgothel> (interpreting those events .. associating them with the programs 'canvas', etc etc .. complicated)
20140827 11:25:41 <eclesia> I don't want to know what the events are doing or anything, just where the frame is
20140827 11:25:47 <sgothel> I would create a common language (DSL) here .. i.e. transform all WM TK events down to a NEWT event .. then fwd them,
20140827 11:25:55 <sgothel> so native code is surely required ofc
20140827 11:26:16 <sgothel> then you 'only' need to capture the WM events, or walk down the list
20140827 11:26:24 <sgothel> problem: identification of the window
20140827 11:26:39 <sgothel> which could be a specific 'atom' or titlebar text
20140827 11:26:48 <eclesia> if there is a frame name that would be enough
20140827 11:27:12 <sgothel> I did a similar thing back in 1993 or so w/ DOS and Maple
20140827 11:27:17 <sgothel> funny thing
20140827 11:27:43 <sgothel> manual cooperative multi-tasking :)
20140827 11:28:31 <eclesia> I don't have a choice ^^
20140827 11:29:22 <sgothel> yeah .. so walk the window list down .. query titlebar text, then the coordinates etc for all supported platforms
20140827 11:30:31 <sgothel> if you also need to capture the input events, things can get complicated for non multitasking WMs like GDI, where you only can do this on the creator thread/process
20140827 11:31:14 <sgothel> or NEWT events -> external app event injection, maybe possible via the WM TK event system
20140827 11:31:21 <eclesia> found something : http://stackoverflow.com/questions/3188484/windows-how-to-get-a-list-of-all-visible-windows
20140827 11:31:30 <eclesia> seems to be the solution for windows
20140827 11:32:26 <sgothel> .. and when you look in our NEWT X11 code, you will see many pointers to the root window .. and child window queries
20140827 11:33:09 <eclesia> you mean you already have the infos but don't expose it ?
20140827 11:33:38 <sgothel> nah .. just query stuff, window relation etc of the windows we use
20140827 11:33:54 <eclesia> k
20140827 13:25:14 <bbbruce> hm
20140827 13:25:24 <bbbruce> should I be able to compile jogl with java 8?
20140827 13:25:37 <sgothel> yup
20140827 13:26:10 <bbbruce> BUILD FAILED
20140827 13:26:11 <bbbruce> […]/development/jogamp/build/gluegen/make/build.xml:924: Class not found: javac1.8
20140827 13:26:18 <sgothel> btw .. I remember you mentioned a fix for a bug here, pls provide details, maybe even a patch. pro-active participation is always welcome!
20140827 13:28:26 <sgothel> hmm .. then this is a bug (ours or theirs) .. have to validate, better w/ ant flags '-v -d'
20140827 13:28:47 <sgothel> pls file a bug w/ usual infos (platform, java version/vendor, ..)
20140827 13:49:01 * juank_prada (~juank_pra@anon) has joined #jogamp
20140827 14:07:54 <bbbruce> sgothel: https://jogamp.org/bugzilla/show_bug.cgi?id=1053
20140827 14:10:58 <sgothel> thank you!
20140827 14:17:15 <bbbruce> sgothel: I wanted to check out your work on the Oculus Rift
20140827 14:17:31 <bbbruce> sgothel: is that possible without compiling it myself?
20140827 14:21:26 <sgothel> yes, but as mentioned we have to patch the SDK to have it work w/ DK2 - DK1 works out of the box
20140827 14:21:40 <sgothel> (mentioned in forum)
20140827 14:21:59 <sgothel> if nobody does jherico's patches for DK2 in our oculusvr-sdk .. I will soon
20140827 14:22:26 <bbbruce> ahh ok
20140827 14:22:29 <bbbruce> I have a DK2
20140827 14:22:49 <sgothel> it should be simple .. i.e. check our HowTo JOGL build on front page .. (recurse submodule)
20140827 14:22:59 <bbbruce> yeah, only that breaks :)
20140827 14:23:00 <sgothel> then the sdk branch of ours is included
20140827 14:23:37 <sgothel> apply the few patches jherico did .. maybe update our OVRStereoDevice numbers .. (diff screen dimensions etc)
20140827 14:24:42 <sgothel> well, I hope the OVR folks will re-open their SDK completely .. (binary blob), allowing all devices to work .. but we don't know
20140827 14:25:05 <bbbruce> hm, so the problem is that 0.41 does not work with the DK1?
20140827 14:25:05 <sgothel> maybe alternative 'drivers' one day become useful .. openhmd etc
20140827 14:25:24 <sgothel> nope, 0.41 requires a binary blob - it's compatible w/ DK1
20140827 14:25:57 <sgothel> binary blob driver, which they have not released to GNU/Linux .. and anyways .. puts the OVR in a walled garden .. artificially
20140827 14:26:07 <bbbruce> great
20140827 14:26:23 <sgothel> i.e. w/ our 0.32 SDK support, it works on all platforms you compile it for ..
20140827 14:26:54 <sgothel> jherico is doing some pushing as it seems .. but he has been not yet answered .. oh well
20140827 14:27:16 <sgothel> OVR's business folks fault I guess
20140827 14:27:32 <sgothel> however, w/ the patch .. it will work w/ DK2 except the head tracking
20140827 14:27:38 <bbbruce> oh
20140827 14:27:43 <bbbruce> but that is the one cool thing :)
20140827 14:27:48 <sgothel> yup
20140827 14:28:28 <sgothel> its discussed at openhmd to simply use their 'drivers' .. supporting the input (rotation / tracking) .. and the mesh distortion ourselves
20140827 14:28:34 <sgothel> the later we already have in control
20140827 14:29:15 <sgothel> this will probably end up in supporting 2 OVR SDKs .. well
20140827 14:29:36 <sgothel> open and proprietary ..
20140827 14:29:53 <bbbruce> ok, I have to figure out how to temporarily use java 7 to build and try it :)
20140827 14:33:01 <bbbruce> oh that was not hard at all
20140827 14:41:23 <bbbruce> I am running com.jogamp.opengl.test.junit.jogl.stereo.StereoDemo01 but I don't see anything that resembles stereo rendering
20140827 14:41:43 <bbbruce> I just see glgears
20140827 14:42:49 <bbbruce> glob duration 10000; glob useStereoScreen true; deviceType Default; deviceIndex 0; iLinear true; numSamples 0; useSingleFBO false; useRecommendedDistortionBits true; useVignette true; useChromatic true; useTimewarp true; useAutoSwap false
20140827 14:43:07 <sgothel> check the API doc in source code ..
20140827 14:43:29 <sgothel> the device index in 'soft' mode will determine how to render ..
20140827 14:44:29 <sgothel> (I assume you are default device here is the software mode)
20140827 14:44:59 <sgothel> soon I have to check the SBS mode on a 3D TV .. if somebody has such a device .. pls test
20140827 14:46:31 <bbbruce> sgothel: which file do I have to look at?
20140827 14:46:42 <sgothel> StereoDemo01
20140827 14:48:17 <sgothel> https://www.youtube.com/watch?feature=player_detailpage&v=BbbiUyeE0VU#t=2834 <-
20140827 14:48:46 <sgothel> mono, sbs, sbs-lens
20140827 14:49:10 <sgothel> + movie ..
20140827 14:52:56 <bbbruce> https://github.com/jherico/OculusSDK this is what I have to apply?
20140827 14:54:25 <sgothel> one sec ..
20140827 14:56:11 <sgothel> https://github.com/jherico/OculusSDK/commits/stable <- top 2 (or 3) commits might be interesting
20140827 14:56:26 <sgothel> maybe also his 0.3.x branch .. hmm .. dunno
20140827 14:56:48 <sgothel> will need to pull all his branches and verify
20140827 14:57:06 <sgothel> but you see his last commits in stable simply add the DK2 device ..
20140827 14:57:27 <sgothel> (last 4 commits ..)
20140827 14:58:04 <sgothel> http://jogamp.org/git/?p=oculusvr-sdk.git;a=summary <- should go in here ..
20140827 14:58:34 <sgothel> then I will verify that it still works w/ DK1 .. and we are good to go :)
20140827 14:59:28 <bbbruce> ok, I just need to figure out how to actually do this
20140827 14:59:47 * [Mike] (~Mike]@anon) Quit ()
20140827 14:59:50 <sgothel> cherry pick his commits and try to apply the patch ..
20140827 15:00:06 <sgothel> since he and us are using the same base .. should work
20140827 15:00:35 <sgothel> well .. otherwise manually do it, pls add a 'credit' of patch origin in your git commit - thx!
20140827 15:01:03 <sgothel> http://jogamp.org/git/?p=oculusvr-sdk.git;a=commit;h=70e44b846ceaf9eebc336b12a07406c3a418a5c3 <- like here
20140827 15:04:34 <bbbruce> ok
20140827 15:05:54 <bbbruce> also, I see that there is jocular library
20140827 15:05:54 <bbbruce> which is essentially c bindings for that blob driver?
20140827 15:05:54 <sgothel> well 'jherico' has it's own JNA based binding to OVR
20140827 15:05:54 <bbbruce> c->java
20140827 15:06:07 <sgothel> I didn't use it, to favor GlueGen, plus I don't want to support the SDK based distortion b/c of:
20140827 15:06:30 <sgothel> http://forum.jogamp.org/Porting-RoomTiny-to-Jogl-tp4032722p4032937.html
20140827 15:06:56 <sgothel> i.e. _we_ render content, SDK delivers params and handles input
20140827 15:07:37 <sgothel> also, we build the native OVR part ourselves, w/o the native GL part (SDK based rendering mode)
20140827 15:07:58 <sgothel> the latter causes lots of havoc due to libGL loading and using diff. GL profiles
20140827 15:09:00 <sgothel> however .. all data/functions of OVR are available via JNI w/ our bindings (but the SDK based rendering)
20140827 15:09:12 * rmk0_ is now known as rmk0
20140827 15:09:12 * rmk0 (~rmk0@anon) Quit (Changing host)
20140827 15:09:12 * rmk0 (~rmk0@anon) has joined #jogamp
20140827 15:18:43 <sgothel> "This Connection is Untrusted" .. trying to download an Oracle Java SE .. funny (showing certificate of akamei*.*)
20140827 15:18:48 <bbbruce> I see that rendering in the client is a way more convenient approach than SDK based rendering. I am still a bit confused now about what it takes for head tracking to work
20140827 15:19:17 <sgothel> surely headtracking is complex, i.e. analyze the moving image of the camera and produce the delta for at least 2 axis
20140827 15:19:31 <sgothel> some say, using OpenCV might be of use .. well
20140827 15:20:06 <sgothel> when the GNU/Linux SDK 0.4 version arrives .. I will attempt create another variant of our binding .. and we will see
20140827 15:20:29 <sgothel> ofc .. if you like to go ahead .. 'shoot' :)
20140827 15:20:50 * xranby (~xranby@anon) Quit (*.net *.split)
20140827 15:21:23 <sgothel> you seen in the git commits .. it's not too complicated to merge existing version .. while dropping unnecessary stuff .. (blobs .. etc)
20140827 15:22:05 <bbbruce> yeah ok, that is if you insist on going the open way
20140827 15:22:47 * xranby (~xranby@anon) has joined #jogamp
20140827 15:23:08 <bbbruce> I am still figuring out how to cherry pick from the jherico's repo
20140827 15:23:18 <bbbruce> git cherry-pick 5447d1c..2c7932e; is followed by error: could not apply a41a3f6... Fixing platforms specific file issue
20140827 15:23:29 <sgothel> well, we should be able to compile the 'open parts' for sure, so this would be a dual thing then (SDK 0.4)
20140827 15:23:50 <sgothel> try to use patch manually .. hmm
20140827 15:24:16 <sgothel> but then .. the delta is minimal ..
20140827 15:24:20 <bbbruce> I feel stupid :)
20140827 15:25:52 <bbbruce> I don't understand why it tries to go back to commit a41a3f6 which before 5447d1c
20140827 15:25:54 <bbbruce> +is
20140827 15:26:57 <sgothel> I use gitk and save a commit manually
20140827 15:27:04 <sgothel> (well .. via it's UI)
20140827 15:27:18 <sgothel> then I apply this patch manually on the other repo
20140827 15:31:01 * zzuegg (~zzuegg@anon) Quit (Read error: Connection reset by peer)
20140827 15:31:01 * zzuegg (~zzuegg@anon) has joined #jogamp
20140827 15:36:09 <sgothel> AFK .. laters
20140827 15:37:33 * zubzub (~zubzub@anon) Quit (Ping timeout: 240 seconds)
20140827 15:46:56 * zubzub_ (~zubzub@anon) has joined #jogamp
20140827 15:52:48 * jvanek (~jvanek@anon) Quit (Quit: Leaving)