#jogamp @ irc.freenode.net - 20130408 05:06:10 (UTC)

20130408 05:06:10 -CatOut- Previous @ http://jogamp.org/log/irc/jogamp_20130407050556.html
20130408 05:06:10 -CatOut- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130408050610.html
20130408 05:42:44 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130408 05:46:23 * [Mike] (~Mike]@anon) Quit ()
20130408 06:24:31 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 260 seconds)
20130408 07:37:41 * masterzen (~masterzen@anon) Quit (Quit: Au revoir!)
20130408 07:38:00 * masterzen (~masterzen@anon) has joined #jogamp
20130408 10:35:56 * masterzen (~masterzen@anon) Quit (Ping timeout: 246 seconds)
20130408 10:40:48 * masterzen (~masterzen@anon) has joined #jogamp
20130408 11:03:40 * gouessej (546051e4@anon) has joined #jogamp
20130408 11:03:44 <gouessej> Hi
20130408 11:04:20 <sgothel> hi - good day to you Julien, and the others!
20130408 11:04:25 <gouessej> Sven, have you looked at my fix for the bug 697?
20130408 11:04:42 <gouessej> I added the missing file several days ago
20130408 11:05:24 <sgothel> oh .. I didn't poll - will look later, currently refining keyCode/keySym - remaining OSX issues
20130408 11:05:29 <sgothel> thx
20130408 11:05:43 <gouessej> you're welcome
20130408 11:05:55 <gouessej> there is no hurry, it can wait for some days
20130408 11:06:30 <gouessej> but if you need me to modify some aspects, try to let me know that as soon as possible
20130408 11:06:53 <sgothel> ay .. will do,sure
20130408 11:08:30 <gouessej> it respects all your recommendations (safe loop, no Java callback, use WindowUserData, ...)
20130408 11:08:53 <sgothel> hope it still works :)
20130408 11:10:35 <gouessej> lol you're right
20130408 11:11:29 <gouessej> instead of using a dummy count of attempts, I use the first value returned by ShowCursor
20130408 11:12:05 <gouessej> I don't call ShowCursor several times if it has no effect on the display count, for example when there is no mouse
20130408 11:12:28 <sgothel> ah .. sounds much better, yup - I guess I was just hacking this in quite fast, trying to avoid the ugly details :)
20130408 11:12:45 <sgothel> yes .. that was also in the 'safe loop'
20130408 11:13:06 <gouessej> that's my fault, I ignored that it had to be called in a DefWindowProc
20130408 11:13:26 <gouessej> I'm not an expert of the Win32 API
20130408 11:14:20 <gouessej> the support of JPEG and PNG is really useful
20130408 11:14:37 <gouessej> now I don't need AWT
20130408 11:15:33 <sgothel> yup - if you have sort of corrupt jpeg files, which were displayed w/ AWT but not w/ our new decoder .. pls add them w/ some meaningfull name to the unit tests, so I can fix it -> more tolerant parsing
20130408 11:16:18 <gouessej> Ok. For the moment, it works very well
20130408 11:16:31 <gouessej> My flipping method is just a bit slow
20130408 11:16:58 <gouessej> Do you plan to update the online Java documentation of all JogAmp APIs?
20130408 11:17:00 <sgothel> flipping ? you don't need texture flipping anymore w/ our decoder
20130408 11:17:14 <sgothel> yes, w/ 2.0.2 :)
20130408 11:17:26 <gouessej> Ardor3D image supports flipping, I'm forced to flip the data
20130408 11:17:51 <sgothel> hmm .. more than just the texture-coords ?
20130408 11:17:56 <gouessej> yes
20130408 11:17:59 <sgothel> i.e. -> stupid :)
20130408 11:18:21 <sgothel> why on earth would anybody flip the image in CPU space ?
20130408 11:19:15 <sgothel> well, we could add the vert-flipping for jpeg / png as well, since it's a simple loop direction change
20130408 11:19:44 <gouessej> I will just enhance it a bit but of course, developers should just flip the images once for all and save them
20130408 11:19:45 <sgothel> i.e. at no cost - but again, looks funny
20130408 11:20:48 <sgothel> flipping for rendering is usually done w/ texture coords, you know he code I guess
20130408 11:20:58 <gouessej> yes
20130408 11:21:28 <sgothel> well, in GLJPanel I had to really flip the GL rendered image, but using GLSL/shader - you may use that code.
20130408 11:21:52 <gouessej> I have to support OpenGL 1 too
20130408 11:21:59 <sgothel> since java2d operates on the actual pixels ..
20130408 11:22:18 <sgothel> yes, GLJPanel does respect that .. i.e. if GLSL is n/a .. see code
20130408 11:22:42 <gouessej> ok I will give it a look, thanks
20130408 11:22:48 <sgothel> then we do a simple for-loop, well
20130408 11:22:55 <gouessej> I assume it uses the raster
20130408 11:24:09 <gouessej> Do you think we will have some time to work on an alternative runtime for Android before Siggraph?
20130408 11:24:38 <sgothel> you mean a different JVM ?
20130408 11:24:55 <gouessej> a different JRE
20130408 11:26:03 <sgothel> well, I could only see a bundle of JVM/JRE, i.e. avian etc .. then it would also need some windowing toolkit binding etc - I guess not
20130408 11:29:29 <gouessej> I see only Avian as a viable solution for Android, iOS and Windows Phone 8
20130408 11:29:30 <gouessej> Normen already worked on NEWT under iOS
20130408 11:29:31 <gouessej> but I don't know what he really succeeded to implement
20130408 11:29:33 <sgothel> I also don't see the point .. hmm
20130408 11:29:36 <sgothel> but running w/ a bundled JVM .. like avian .. fastest 'bringup' would be w/ some GNU/Linux X11 environment
20130408 11:29:36 <sgothel> such a proof of concept could make a point for other JVM unfriendly environments :)
20130408 11:29:37 <sgothel> i.e. if a company likes to pay big bucks - then we could do the iOS port ..
20130408 11:30:22 <sgothel> Dunno Normen. Win8, well - AFAIK they don't have OpenGL :(
20130408 11:30:44 <gouessej> Normen is one of the main contributor of JMonkeyEngine 3
20130408 11:30:58 <sgothel> Win8/WinRT - We would need to have a new Windowing Toolkit impl., GDI -> ??
20130408 11:31:51 <sgothel> iOS: We would need to split and clean our NativeWindow/NEWT code for desktop and iOS .. not too much work
20130408 11:32:04 <gouessej> We will need a new windowing toolkit implementation without GDI as it will be dropped in future releases of Windows
20130408 11:32:07 <sgothel> So where are Normen's patches ? :)
20130408 11:32:28 <sgothel> re win8: yes, thats what I meant w/ GDI -> ??
20130408 11:32:31 <gouessej> in the trunk of JMonkeyEngine 3 on Google Code?
20130408 11:32:46 <sgothel> so he doesn't like to share w/ us ?
20130408 11:33:02 <sgothel> i.e. collab w/ us in our 'space' ?
20130408 11:33:04 <gouessej> he spoke about that to me at first
20130408 11:33:23 <sgothel> yeah well, he is welcome - but I will not peek & poke around like crazy :)
20130408 11:33:52 <sgothel> so better he joins us for such task, to make code persistent in NativeWindow, JOGL and NEWT
20130408 11:34:02 <gouessej> ok we will talk to him later. I think he would agree with contributing :)
20130408 11:34:23 <sgothel> hope he doesn't mind that I am quite anal :)
20130408 11:35:02 <sgothel> ofc - we don't have a machine to test iOS
20130408 11:35:05 <gouessej> I just want to avoid any legal troubles
20130408 11:35:17 <sgothel> legal ? whats the problem here ?
20130408 11:35:51 <sgothel> writing source code for some Apple API and using it - is not illegal.
20130408 11:36:24 <gouessej> If he wants to contribute back to JogAmp, he will do so. I don't know the exact differences between the license used by JogAmp and the license used by JMonkeyEngine
20130408 11:36:24 <sgothel> Normen just need to contribute _his_ code under our license, while he _owns_ the code (not copy/paste - stolen w/o references etc)
20130408 11:36:40 <sgothel> tsts
20130408 11:36:41 <gouessej> ok
20130408 11:37:13 <sgothel> guess it makes very little sense to add iOS features for JogAmp in the jME3 space :)
20130408 11:37:23 <sgothel> but sure - they can fork us - np :)
20130408 11:37:39 <gouessej> I have to leave. Good luck with my bug fixes and remaining bugs under Mac.
20130408 11:37:43 <gouessej> Bye
20130408 11:37:48 <sgothel> bye
20130408 11:37:54 * gouessej (546051e4@anon) Quit (Quit: Page closed)
20130408 12:21:51 * xranby (~xranby@anon) has joined #jogamp
20130408 13:34:43 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20130408 13:39:07 * xranby (~xranby@anon) has joined #jogamp
20130408 14:15:50 <sgothel> https://twitter.com/BenNunney/status/320473828545421312/photo/1 <- 'Kernel Dump' :)
20130408 14:37:04 <rmk0> considering putting together a physics engine
20130408 14:37:09 <rmk0> and 'lo
20130408 14:37:42 <sgothel> sweet - have you checked existing stuff ?
20130408 14:37:56 <rmk0> it seems that the choices on the jvm are jbullet (unmaintained, old, and an ugly c++ port), jode (unmaintained, old, and an ugly c++ port), and jinngine (barely started, unmaintained)
20130408 14:38:12 <rmk0> jmonkeyengine seem to have some bindings to the native bullet library, but that's a bit terrifying
20130408 14:38:13 <sgothel> .. and one referenced on JOGL .. hmm
20130408 14:38:21 <rmk0> which one's that?
20130408 14:38:57 <rmk0> ah, there's dyn4j but that's only 2D
20130408 14:39:07 <sgothel> www.dyn4j.org .. dunno how much 3d is in there .. yup
20130408 14:39:07 <rmk0> is very cleanly implemented and nicely done
20130408 14:39:34 <rmk0> java could really do with a good 3D physics engine
20130408 14:39:42 <rmk0> ideally with some optional OpenCL acceleration
20130408 14:40:12 <sgothel> pushed buttons .. floating in space since they are not attached to a wall :)
20130408 14:40:40 <sgothel> ofc .. cloth .. inverse K .. all awesome ..
20130408 14:40:57 <rmk0> i'm rereading: http://procyclone.com/
20130408 14:41:14 <rmk0> is an excellent walkthrough of building a full 3D engine
20130408 14:41:31 <rmk0> but i'm not sure how much of it is obsolete now... it came out in 2007
20130408 14:43:12 <sgothel> the engine discussion .. maybe we can do a project to have more like a graph/resource-manager w/o too much semantics, to be used for all this
20130408 14:43:38 <rmk0> how d'you mean?
20130408 14:43:40 <sgothel> like today, we only have our nodes w/ data .. interaction is all custom by the programmer
20130408 14:44:09 <sgothel> probably you have all that already in your repos, dunno.
20130408 14:44:30 <rmk0> not sure what you're referring to with "nodes"
20130408 14:44:37 <sgothel> I like to spend time again (as always) to finish up the graph/ui thingy, but in a generic way
20130408 14:44:45 <rmk0> ah, right
20130408 14:45:00 <sgothel> well, the nodes in some space - directed or not .. have to see (reusing etc)
20130408 14:45:08 <sgothel> how to hash them out (find)
20130408 14:45:26 <sgothel> how to represent data properly w/o conversion
20130408 14:45:37 <sgothel> how to allow mutability
20130408 14:45:56 <sgothel> then the feedback, impact of node modifications to others ..
20130408 14:46:06 <sgothel> I guess thats it so far, not too much :)
20130408 14:46:11 <rmk0> right
20130408 14:46:20 <sgothel> then using it for 3d, physics - whatever
20130408 14:46:43 <sgothel> i.e. this is more generic, like a no-sql DB :)
20130408 14:46:55 <rmk0> i think in general, the physics engines are black boxes... you supply collision shapes, masses
20130408 14:47:10 <rmk0> and then once per frame, it gives you back new positions, velocities, and calls any collision callbacks you've provided
20130408 14:47:24 <rmk0> it's pretty easy to attach them to things without them having to know anything about your program
20130408 14:47:29 <sgothel> the node interaction
20130408 14:47:41 <sgothel> and nodes may be animated .. keyframe, etc
20130408 14:48:49 <sgothel> maybe we can start such project next month ?
20130408 14:49:12 <sgothel> at least this would be a good motivation for me to finish 2.0.2 early :)
20130408 14:49:20 <rmk0> well, i'm going to be working on implementing "something" so that i can get a good understanding of it
20130408 14:49:29 <rmk0> so... we'll see what happens
20130408 14:49:38 <sgothel> can we use git then ?
20130408 14:49:50 <rmk0> if you like
20130408 14:50:09 <sgothel> or maybe we both do something in parallel .. trying to merge the ideas for the better one
20130408 14:50:17 <sgothel> for sure communication is most important here
20130408 14:50:33 <sgothel> nice
20130408 14:52:16 <sgothel> b/c all the culling, graph, DB stuff - like to bring things a bit together, at least in my mind :)
20130408 14:52:38 <sgothel> btw .. I have see you have those 'angles' too in your APIs .. can you pls check https://jogamp.org/bugzilla/show_bug.cgi?id=703 ?
20130408 14:52:48 * rmk0 eyes it
20130408 14:53:10 <sgothel> Harvey wanted to check as well .. but no time yet
20130408 14:53:15 <sgothel> Rami .. no time
20130408 14:53:23 <sgothel> so we have a lot 'no time' :)
20130408 14:54:02 <rmk0> this shouldn't be difficult
20130408 14:54:05 * rmk0 eyes textbook
20130408 14:54:27 <sgothel> awesome .. if you have unit tests for quaternions .. would be great!
20130408 14:55:06 <sgothel> guess I have scared Ola away - even though I can finish Bug 641 today :)
20130408 14:55:12 <sgothel> (which was inspired by him)
20130408 14:55:20 <rmk0> http://fossil.io7m.com/repo.cgi/io7m-jtensors/artifact/2adc5b2dbfc3385fd7ca9df66c4b434f50c36f99
20130408 14:55:23 <rmk0> just a few
20130408 14:55:42 <sgothel> awesome!
20130408 14:56:51 <sgothel> if you could add those .. big thx
20130408 14:57:01 <sgothel> btw .. how is your mood for siggraph ?
20130408 14:57:28 <rmk0> when's it?
20130408 14:58:08 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=661
20130408 14:58:15 <sgothel> SIGGRAPH 2013 - JogAmp BOF [2013 07 21–25, Anaheim, CA, USA]
20130408 14:58:38 <sgothel> Date: Wednesday, July 24 Location: Anaheim Convention Center Time: 1:00 -2:30 PM
20130408 14:58:48 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=661#c16
20130408 15:11:23 * rmk0 emerges
20130408 15:11:57 <rmk0> is there a diagram somewhere showing the parts of jogl?
20130408 15:12:16 <rmk0> .. found it
20130408 15:12:47 <sgothel> which one ? GLProfiles ?
20130408 15:13:05 <rmk0> well i was thinking about something more coarse grained
20130408 15:13:14 <sgothel> - NativeWindow
20130408 15:13:16 <sgothel> - JOGL
20130408 15:13:16 <rmk0> i wouldn't personally know how to find graph-ui in the tree
20130408 15:13:17 <sgothel> - NEWT
20130408 15:13:36 <sgothel> it's in junit/test .. not intended to be a public API in JOGL, as discussed
20130408 15:13:50 <sgothel> the graph part of this test, doesn't really exist really :)
20130408 15:13:52 <rmk0> right
20130408 15:14:06 <sgothel> it just shows a few UI elements in space
20130408 15:14:24 <sgothel> allowing some poor interaction, rendered w/ the graph curve rendering
20130408 15:14:49 <sgothel> so the curve rendering itself can stay in JOGL, it can utilize pluggable shaders
20130408 15:15:12 <sgothel> fonts shall go away ofc, users can use separate package, or bundle it
20130408 15:15:51 <sgothel> the 'new graph' package, as discussed above, will be another bundle - if we ever do it :)
20130408 15:16:32 <sgothel> beside this, NativeWindow abstracts away the windowing toolkit
20130408 15:16:45 <sgothel> in JOGL we have core JOGL stuff and:
20130408 15:16:57 <sgothel> - texture utils incl. decoder (png, jpeg)
20130408 15:17:10 <sgothel> - VBO/Shader utils
20130408 15:17:26 <sgothel> - a _very_ little math incl. PMVMatrix
20130408 15:17:52 <sgothel> in short, just the basics allowing a user to jumpstart w/ ES2 and FFP coding
20130408 15:18:15 <rmk0> right
20130408 15:18:21 <sgothel> NEWT, just the windowing and event handling
20130408 15:19:15 <sgothel> As one put it, the heart of JOGL is actually the resource management (windowing system and GL context)
20130408 15:19:29 <sgothel> not exposing the GL functions - thats easy :)
20130408 15:19:49 <rmk0> yep
20130408 15:19:52 <sgothel> but handling all the other things and putting them together platform agnostic is the cool stuff
20130408 15:20:05 <sgothel> for example, OpenCL is much easier - those things simply doesn't exist
20130408 15:20:49 <rmk0> i've had extremely limited experience with openCL, but it looks like they've not made the same design mistakes as in openGL
20130408 15:21:05 <rmk0> has context/device handling in the API
20130408 15:21:07 <rmk0> etc
20130408 15:21:26 <sgothel> well, you just don't have the windowing dependencies .. which itself adds an explosive growth of complexity :)
20130408 15:21:34 <rmk0> right
20130408 15:21:43 <rmk0> .. do openCL drivers require access to X?
20130408 15:21:47 <sgothel> nope
20130408 15:21:49 <rmk0> \o/
20130408 15:22:03 <sgothel> under the surface .. sort of :)
20130408 15:22:48 * rmk0 shovels under the carpet
20130408 15:23:06 <sgothel> OpenKD was an early attempt to unify windowing toolkits :)
20130408 15:23:14 <rmk0> not seen that
20130408 15:23:28 <sgothel> EGL is the current attempt to at least unify the gluing part (GLX, WGL, ..)
20130408 15:23:50 <sgothel> i.e. GLX, WGL - is sort of deprecated
20130408 15:23:56 <rmk0> yep
20130408 15:24:31 <sgothel> we sort of can handle that already, but a few changes to use EGL instead of GLX etc must be made
20130408 15:25:04 <sgothel> however, we do not expose this level in an platform agnostic manner .. only very few parts
20130408 15:25:20 <sgothel> like .. swapInterval ..
20130408 15:25:31 <rmk0> can't say i've ever seen it
20130408 15:25:38 <rmk0> it's nice that i haven't!
20130408 15:25:42 <sgothel> yup :)
20130408 15:26:25 <sgothel> thats actually it .. quite simple from a top-down perspective
20130408 15:26:38 <rmk0> yep
20130408 15:27:20 <sgothel> one of the user convenient features is GLAutoDrawable
20130408 15:27:23 <sgothel> (GLAD)
20130408 15:27:53 <sgothel> GLAD allows lifecycle oriented binding of drawable and GL resources, while the user does not need to care
20130408 15:28:20 <sgothel> recently we have removed differences of offscreen and onscreen details, and you can move your resources between GLADs
20130408 15:28:46 <rmk0> yep... i'm using the new stuff in jcanephora's test suite
20130408 15:28:54 <rmk0> it runs all the unit tests offscreen
20130408 15:29:08 <rmk0> i have to do the same things with LWJGL using PBuffers
20130408 15:29:10 <rmk0> it's not pretty
20130408 15:30:03 <sgothel> a nice free lunch while fighting w/ OSX and adding proper FBO support via FBObject - then my urge to seek harmony lead to having it unified w/ GLAutoDrawable[Factory] :)
20130408 15:31:30 <sgothel> another lifecycle feature is GLEventListenerState, moving GL ctx + GLEventListener between GLADs. Inspired by our dear DOW users for Android.
20130408 15:31:56 <rmk0> not familiar with that one
20130408 15:32:05 <sgothel> this will also lead to a printing API, coming up.
20130408 15:32:26 <sgothel> GLAD[GL ctx, drawable, listener*]
20130408 15:32:37 <sgothel> the ctx and the listener depend on each other
20130408 15:32:56 <sgothel> you can move both between GLADs
20130408 15:33:18 <sgothel> you can 'preserve' them .. and re-attach later (killing of a GLAD and resurrection)
20130408 15:33:53 <sgothel> for printing: you can move it from low-res GLAD, to high-res GLAD for tiled-based rendering and later printing (giga pixel)
20130408 15:34:13 <sgothel> important: you don't need to go through destroy/init and recover your application state
20130408 15:34:30 <rmk0> hm
20130408 15:34:36 <sgothel> another way would have been to use a shared GL ctx
20130408 15:34:52 <sgothel> which would preserve the GL resources, and hence keep the GLEventListener 'valid'
20130408 15:35:12 <sgothel> however - this is not efficient, and share GL ctx .. are sort of a bitch :)
20130408 15:35:25 <rmk0> have heard that drivers have trouble with them
20130408 15:36:05 <sgothel> this was planted from the day you asked me about re-association of ctx/drawable .. :)
20130408 15:36:26 <rmk0> long time ago!
20130408 15:36:37 <sgothel> at least this proves our ctx/drawable model is correct
20130408 15:36:48 <sgothel> yes .. 1 year ? or more ?
20130408 15:36:57 <rmk0> must be about that
20130408 15:37:26 <sgothel> see - from idea, via enhancements to production quality .. it's a tedious road :)
20130408 15:37:52 <rmk0> meanwhile... his quaternion slerp code looks correct
20130408 15:38:08 <rmk0> unfortunately i don't have unit tests for slerp, as i've not implemented it yet
20130408 15:38:11 <sgothel> e.g. the NewtCanvasAWT idea .. was done in a few seconds - impl. took a while :)
20130408 15:38:27 <sgothel> oh .. maybe you can make a comment .. in the bug report
20130408 15:38:39 <sgothel> thx
20130408 15:38:57 <rmk0> http://waste.io7m.com/2013/04/08/equations.png
20130408 15:39:20 * rmk0 locates bugzilla password
20130408 15:39:31 <rmk0> i go through this routine every time
20130408 16:08:32 * hharrison (~chatzilla@anon) has joined #jogamp
20130408 16:10:09 <hharrison> Sorry I have no bandwidth right now, but I can promise to review any changes to the Quaternion stuff
20130408 16:15:08 <rmk0> hharrison: looks like i screwed up the conversion to ASCII from the textbook, yes
20130408 16:16:14 <rmk0> looks like the author of the actual code did make the changes necessary for values near 0
20130408 16:17:25 <hharrison> No worries, the reason I like the one I linked is, you can change the test for cos(t) >= 1.0
20130408 16:17:40 <hharrison> to cos(t) >= 0.95 and do linear interpolation in those cases
20130408 16:18:16 <hharrison> as it ends up being trivially close in that range
20130408 16:18:42 <rmk0> right
20130408 16:19:56 <hharrison> BUt, then again, he who codes, rules, so I certainly won't object to yours if you get it coded
20130408 16:20:17 <rmk0> oh, it's not mine
20130408 16:20:29 <rmk0> i've no idea who Tek is, i was just trying to see if what he'd written was right
20130408 16:20:39 <rmk0> it... looks it, but i've not got unit tests to verify
20130408 16:21:04 <rmk0> i've not actually implemented slerp in my own quaternion library, so i looked it up in the textbook i was using
20130408 16:21:21 <rmk0> there's a good chance i'm entirely wrong :)
20130408 16:22:20 <hharrison> The orignal code that is there really looks like it mixed up MathFloat.E and MathFloat.EPSILON
20130408 16:22:51 <hharrison> That was the only problem I had with it...Tek's too
20130408 16:23:26 <rmk0> oh, i assumed E was EPSILON there.. i'm not familiar with MathFloat
20130408 16:23:27 <hharrison> With that changed, Tek's would be fine
20130408 16:23:33 <rmk0> that'd be a pretty nasty mistake
20130408 16:24:09 <hharrison> Just means you get LERP, always
20130408 16:24:21 <rmk0> hehe
20130408 16:24:23 <hharrison> at least in Tek's
20130408 16:24:43 <rmk0> maybe he should use LERP, then... he seems happy with it!
20130408 16:25:00 <hharrison> At least it will be stable!
20130408 16:25:06 <rmk0> \o/
20130408 16:55:28 * [Mike] (~Mike]@anon) has joined #jogamp
20130408 17:15:02 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130408 21:12:41 * xranby1 (~familjen@anon) has joined #jogamp
20130408 21:15:18 <xranby1> Now is a bright NEWT input good night!
20130408 21:16:42 <xranby1> sgothel: thank you! https://jogamp.org/bugzilla/show_bug.cgi?id=641
20130408 21:18:16 <xranby1> sgothel: i have sent a NEWT input pull request for the raspberry pi some minutes ago
20130408 21:18:45 <xranby1> that totally got smashed by this :)
20130408 21:23:44 <sgothel> hi .. all - thank you Harvey and Mark looking after Bug 703. If you can give a recommendation what we should do (make it 'stable' ..) that would be great. Harvey, you mentioned something above - but ..
20130408 21:24:00 <sgothel> Hi Xerxes .. sorry :)
20130408 21:24:24 <sgothel> I guess we can drop a few of the UTF conversion methods to the UTFKeyUtil ..
20130408 21:24:47 <sgothel> not a big thing, just have it all at it's place to easy review maybe
20130408 21:25:04 <sgothel> was unsure about your UTF usage in evdev ..
20130408 21:25:51 <sgothel> .. looking at your pull request - looking fwd to do more fun things than this tedious key-input thingy :)
20130408 21:26:05 <xranby1> right now i only assume NEWT _VK is using UTF
20130408 21:26:24 <sgothel> yup
20130408 21:26:34 <sgothel> I 'hope' that as well :)
20130408 21:26:43 <sgothel> see new def. of keySym ..
20130408 21:27:57 <sgothel> great, was having that in mind while changing your code a bit ..
20130408 21:28:05 <xranby1> i get a debug todo now when i insert the headphone jack , kind of fun
20130408 21:28:15 <sgothel> if you can, pls deliver keySym as the unshifted and un-mod value
20130408 21:28:37 <sgothel> keyCode as well - right, you have no layout :)
20130408 21:28:50 <sgothel> guess you do that already .. at least you did
20130408 21:29:14 <sgothel> thank you for the SPACEs :)
20130408 21:29:18 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 245 seconds)
20130408 21:30:15 <sgothel> @Harvey,Mark: So all there is todo is to rename: MathFloat.E -> MathFloat.EPSILON right ?
20130408 21:30:31 <sgothel> and you both agree that Tek's patch makes it at least more stable/correct ?
20130408 21:31:03 <sgothel> @Mark: Do you like to try to apply Harveys 'journey of math' ?
20130408 21:31:17 * rmk0 eyes it
20130408 21:31:42 <rmk0> i agree with what harvey said, although i think my opinion is worth less :)
20130408 21:31:51 <sgothel> so please feel free to either make a pull request for me - or tell me what todo :)
20130408 21:31:53 <rmk0> fixing E -> EPSILON is definitely required
20130408 21:31:59 <rmk0> the code seems fine otherwise
20130408 21:32:33 <xranby1> sgothel: i will add the keySym then and apply the modifiers afterwards.
20130408 21:32:54 <sgothel> keyCode + keySym w/ any modifier - right: thank you
20130408 21:32:58 <xranby1> so that keyChar gets the mapping
20130408 21:33:09 <sgothel> ofc modifier alone should be the modifiers itself :)
20130408 21:33:27 <sgothel> yup .. keyChar mapping post keyCode/keySym
20130408 21:34:22 <sgothel> after that I will remove the redundant TYPED event - which probably brings back user to bugzilla :)
20130408 21:36:59 <sgothel> Re Bug 703: I liked Harveys impl. better as well, i.e. the lerp reusage in slepr .. well, but nor qualified here to really make a statement
20130408 22:21:42 * xranby1 (~familjen@anon) has left #jogamp
20130408 22:34:09 <hharrison> Added the code I haven't had tme to test properly yet to Bug 703, feel free to use it....or not
20130408 22:35:42 <sgothel> thx harvey
20130408 22:35:43 <rmk0> i think we're unified in complete indifference
20130408 22:36:08 <sgothel> so .. what shall I do now ? :)
20130408 22:36:17 <rmk0> i'm unable to commit enough to say for sure
20130408 22:36:21 <hharrison> aye, the biggest decision to make is what arbitrary function you use to deal with nearly-opposite quaternions
20130408 22:37:24 <hharrison> I'm confident enough in that code to suggest it can be used as-is, it's no worse than the existing
20130408 22:37:28 <sgothel> understand that issue, i.e. the 'invalid / undefined space' for slerp .. problem: Rami added it for fun .. i.e. no test, no use case - intended for later use
20130408 22:37:44 <sgothel> awesome - so I merge w/ your name as author ?
20130408 22:38:36 <hharrison> I'll be honest it doesn't have the usual amount of thoroughness I put into things, with that caveat, please do
20130408 22:38:55 <sgothel> thx - will add your notes/disclaimer
20130408 22:39:13 <hharrison> I've been working on a eulogy the past week which has sapped my energy considerably
20130408 22:39:59 <sgothel> err .. is it review / performance time again ? :)
20130408 22:40:08 <sgothel> eulogy -> to praise .. :) ?
20130408 22:40:27 <hharrison> Alas, eulogy for my father that passed away
20130408 22:41:55 <hharrison> So, yes to your question I suppose ;-)
20130408 22:42:07 <sgothel> My condolences, ~3 yrs ago I did that for my dear mother, a little speech. Better than some stranger talking.
20130408 22:42:49 <sgothel> .. always tough for the survivors / family .. oh well.
20130408 22:43:04 <hharrison> Thanks, it's OK, getting back to things this week
20130408 22:44:11 <sgothel> Sidenote: My begging to find a certain hardware to be able to fix a bug ..
20130408 22:44:14 <sgothel> http://forum.jogamp.org/Req-HP-ProBook-4720s-XX838EA-to-fix-Bug-706-Windows7-ATI-Mobility-Radeon-HD-6370-crash-wglCreateContB-td4028943.html
20130408 22:44:57 <hharrison> Also, re: SLERP, the only concern I have left is that a call to normalize() before each exit path _may_ be a good idea
20130408 22:45:55 <sgothel> normalize[x,..,w] I guess ?
20130408 22:46:10 <hharrison> Depends on the prevailing theory as to whether the helpers should do that themselves, or leave it up to the caller
20130408 22:46:52 <sgothel> yup .. so, we make a boolean flag .. and add a note - since we have no user yet (no unit test etc ..)
20130408 22:46:55 <hharrison> esentially normalize the quaternion length, normalize() is already implemented by JOGL's Quaternion, just needs the calls added (maybe)
20130408 22:47:36 <sgothel> got it, thx - will add it now .. otherwise its 'gone' :)
20130408 22:48:27 <hharrison> Nice bug, we have an intel integrated here in the office that freakin' segfaults when you use the drawElements call with vertex indices
20130408 22:48:53 <hharrison> ...took us awhile to realize it wasn't our fault, that the driver was just shit
20130408 22:49:37 <sgothel> Bug 520 and Bug 706 (probably same) .. and I cannot reproduce. Wade already tried to jump through hoops .. analyzing the whole WGL stuff .. result: it should work.
20130408 22:49:53 <sgothel> Hence - I need such a machine which doesn't work that way :)
20130408 22:58:10 <sgothel> oh - so E (exp const 2.7...) was used somewhat as an epsilon like value (here your limes -> 1) .. if I express that right :)
20130408 22:58:31 <hharrison> yeah
20130408 22:58:50 <hharrison> that was a typo I imagine in what was there originally
20130408 22:59:26 <hharrison> so 1 - cosom and 1 + cosom were trying to look at values near 1
20130408 23:00:24 <sgothel> but d(2.7 - 1.95) .. left quite a gap .. compared to 0.05 :)
20130408 23:00:51 <hharrison> ...nominally cosine(angle) has to be within [-1.0, 1.0]
20130408 23:01:02 <hharrison> cosom == cosine(omega)
20130408 23:01:31 <hharrison> hence it's pretty hard to ever hit that codepath in the original
20130408 23:01:33 <sgothel> unsure about the number of sin ops and your one sqrt op .. - ofc, I am unsure about the whole thing :) .. ok, adding your patch now - w/ the note that it's not normalized
20130408 23:02:13 <hharrison> sin2 + cos2 = 1
20130408 23:03:36 <hharrison> and at that point cosom is for sure in-range, so slightly cheaper than doing the acos and then calling sin()
20130408 23:04:13 <hharrison> That's a dubious optimization of mine, used to sin/cos being super expensive
20130408 23:04:29 <hharrison> Not that sqrt is going to win any prizes either
20130408 23:04:49 <sgothel> oh .. nice, thought trigonometry is a table lookup :)
20130408 23:05:28 <hharrison> Haven't benchmarked that in over 10 years now, probably should re-check ;-)
20130408 23:08:15 <hharrison> muscle memory can be hard to change
20130408 23:09:39 <sgothel> that experience giving an edge to the old dog, even when we are slower :)
20130408 23:12:46 <sgothel> http://jogamp.org/git/?p=jogl.git;a=commit;h=2b3bb9426385d97375c3312f5c0f4e2a827b1fbb
20130408 23:14:48 <hharrison> Thanks for that
20130408 23:15:16 <hharrison> Hopefully tek can give it a run-through
20130408 23:15:41 <sgothel> yup .. made a note
20130408 23:29:34 <sgothel> something to relax .. (old stuff) .. http://www.beyond3d.com/content/articles/8/
20130408 23:31:21 <sgothel> maybe we can use that in slerp :)
20130408 23:31:39 <sgothel> (inverse sqrt .. https://en.wikipedia.org/wiki/Fast_inverse_square_root .. just kidding)
20130408 23:44:00 * masterzen (~masterzen@anon) Quit (Ping timeout: 252 seconds)
20130408 23:44:45 * masterzen (~masterzen@anon) has joined #jogamp
20130408 23:50:58 <sgothel> good night .. and laters
20130408 23:51:02 <hharrison> night
20130408 23:51:11 <[Mike]> night
20130409 00:10:07 * rmk0 (~rmk0@anon) Quit (Ping timeout: 264 seconds)
20130409 00:20:21 * rmk0 (~rmk0@anon) has joined #jogamp
20130409 00:20:52 <rmk0> won't press that button again
20130409 00:25:32 <[Mike]> rmk0: the red button?
20130409 00:25:48 <rmk0> if only
20130409 00:48:34 * [Mike] (~Mike]@anon) Quit ()
20130409 01:26:24 * [Mike] (~Mike]@anon) has joined #jogamp
20130409 02:43:27 <[Mike]> rmk0: In your jogl module for jcanephora which repo are you getting 2.0.2-rc20130404 from? I didn't see it in maven central. Or you depending on a local `mvn install` of gluegen-rt/jogl?
20130409 03:26:18 * hharrison_ (~chatzilla@anon) has joined #jogamp
20130409 05:06:23 -CatOut- Continue @ http://jogamp.org/log/irc/jogamp_20130409050623.html