#jogamp @ irc.freenode.net - 20131115 05:05:54 (UTC)

20131115 05:05:54 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20131114050553.html
20131115 05:05:54 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20131115050554.html
20131115 05:55:19 * [Mike] (~Mike]@anon) Quit ()
20131115 08:14:23 * eclesia (husky@anon) has joined #jogamp
20131115 08:14:27 <eclesia> hi
20131115 08:23:02 <xranby> eclesia: hi! i am testing your demo jar!
20131115 08:23:24 <xranby> eclesia: on my machine i see quite a lot of "Triangulation failed. no ear to cut." during the UI demos
20131115 08:23:29 <xranby> is it normal?
20131115 08:23:31 <eclesia> xranby: hi,
20131115 08:23:34 <eclesia> it is normal
20131115 08:23:50 <eclesia> triangulation of multipart polygon is not done et, so it bugs a bit
20131115 08:24:18 <eclesia> xranby: you seen the link to the other project ?
20131115 08:24:57 <xranby> i have not yet looked at https://bitbucket.org/Eclesia/unlicense-edit3d
20131115 08:25:40 <eclesia> It can open 3d models so it might make a nice demo too
20131115 08:26:37 <xranby> .. now i have .. BUILD SUCCESS
20131115 08:27:53 <xranby> lets see if i can figure out how to run it from the command line
20131115 08:27:53 <xranby> cd target/
20131115 08:27:53 <xranby> java -jar edit3d-1.0.jar
20131115 08:27:58 <xranby> its working :)
20131115 08:29:17 <xranby> i have to download some nice 3d model from some place
20131115 08:37:19 <eclesia> xna (mesh), ply, md5, pmd pmx work fine, others have some bugs
20131115 08:57:26 <xranby> all the classics (ply) http://graphics.im.ntu.edu.tw/~robin/courses/cg03/model/
20131115 09:05:24 * hija (~hija@anon) Quit (Quit: hija)
20131115 09:09:49 <eclesia> I'll have a look this evening
20131115 09:10:02 <eclesia> I tested only one ply file :D
20131115 09:10:46 * monsieur_max1 is now known as monsieur_max
20131115 10:02:14 <sgothel> @Eclesia/Johann: Have you added references of original software you have used implementing all the features or did you do this all from scratch? I.e. this is ofc important if we or somebody else likes to [re]use your code. Have you included references to specs you might have used ?
20131115 10:02:20 <sgothel> .. and .. Good Morning
20131115 10:03:21 <eclesia> sgothel: yes I did. if it's specification/wikis/faq the links are in the class javadoc
20131115 10:04:06 <eclesia> sgothel: if it's code from other projects, author tags are preserved, most of the time a link to the original project too, and they are listed on the contributor web page
20131115 10:04:44 <xranby> http://unlicense.developpez.com/apidocs/un/science/encoding/base64/Base64.html
20131115 10:04:53 <xranby> http://unlicense.developpez.com/apidocs/index.html
20131115 10:05:39 <eclesia> http://unlicense.developpez.com/contrib.html
20131115 10:09:00 <eclesia> the only parts which are not public domain are : JOGL,JOAL,Maven,JUnit,JVM
20131115 10:13:43 * rmk0 (~rmk0@anon) Quit (Ping timeout: 244 seconds)
20131115 10:16:37 <sgothel> great thank you!
20131115 10:17:18 <sgothel> so your [un]license would allow us to accompany your code and publish it under our used BSD license - while preserving you as the source ?
20131115 10:18:06 <sgothel> btw the source / author tracing is ofc very important to defend oneself from litigations ..
20131115 10:18:32 <sgothel> our codebase (gluegen and jogl) passed a few audits so far
20131115 10:18:40 <eclesia> you can copy/paste whatever you want, no obligations to preserve license or author informations. that's public domain
20131115 10:18:58 <eclesia> still I would appreciate if you preserve them
20131115 10:19:08 <sgothel> ah - iff - we would of course preserve traceability ..
20131115 10:19:56 <eclesia> (contributing would be event better :D )
20131115 10:20:00 <eclesia> even*
20131115 10:20:26 <sgothel> sounds great - very much! i.e. the references gives a peace of mind, allowing one to use the code for products
20131115 10:20:58 * rmk0 (~rmk0@anon) has joined #jogamp
20131115 10:21:04 <sgothel> contribution .. I guess I will start another round of discussion after 2.1.3 :) .. [license, whats-best-for-what project, ..]
20131115 10:21:17 <sgothel> but until then .. *shut up sven and work* :)
20131115 10:24:47 <eclesia> sgothel: don't forget my link on the jogl web site :p
20131115 11:22:50 * eclesia (husky@anon) Quit (Read error: Operation timed out)
20131115 11:27:58 * eclesia (husky@anon) has joined #jogamp
20131115 11:33:34 * hija (~hija@anon) has joined #jogamp
20131115 12:17:04 * xranby (~xranby@anon) Quit (Ping timeout: 260 seconds)
20131115 12:18:35 * xranby (~xranby@anon) has joined #jogamp
20131115 12:22:54 * eclesia (husky@anon) Quit (Ping timeout: 252 seconds)
20131115 12:42:38 * eclesia (husky@anon) has joined #jogamp
20131115 13:35:05 * eclesia (husky@anon) Quit (Quit: Leaving.)
20131115 13:39:40 * eclesia (husky@anon) has joined #jogamp
20131115 14:16:30 <hija> another question for you opengl dudes
20131115 14:16:43 <hija> is it better to store in a shader:
20131115 14:17:02 <hija> a uniform array of points and calculate their distances to the vertex?
20131115 14:17:27 <hija> or an attribute array of the distances from the vertex to each point?
20131115 14:19:23 <monsieur_max> interesting question :)
20131115 14:21:31 <hija> storing the uniform array requires double the storage (they are 2d points) and calculation of roots (distance)
20131115 14:21:40 <hija> but its a uniform array...
20131115 14:22:47 <hija> I think I am mostly scared of calculating the roots in each frame
20131115 14:24:32 <hija> maybe a better question would be if anyone knows how to benchmark this?
20131115 14:26:47 <xranby> write both program.. and check which one if faster for you usecase?
20131115 14:27:44 <hija> you mean just look?
20131115 14:27:50 <hija> isnt there a way to measure?
20131115 14:27:56 <rmk0> sgothel: was apparently a driver issue; there's no error on the latest "legacy" drivers from AMD, on windows 7 (was previously windows XP)
20131115 14:28:14 <rmk0> unfortunately, i'm now getting an awful framerate instead
20131115 14:28:35 <rmk0> think it's going to be one of those weeks
20131115 14:29:16 <rmk0> ah, forcing vsync in the control panel fixed it!
20131115 14:29:28 <rmk0> surprisingly painless...
20131115 14:29:34 * rmk0 eyes everything suspiciously
20131115 14:29:37 <rmk0> ahem
20131115 14:29:40 * rmk0 merges back into shadows
20131115 14:31:36 <rmk0> er, actually... anyone happen to know if there's a way to request vsync when using the GLCanvas in swing?
20131115 14:31:57 <rmk0> the default with AMD drivers is "vsync disabled unless the application requests it"
20131115 14:43:54 <rmk0> ah, setSwapInterval on the canvas' GLContext
20131115 14:49:35 <rmk0> hrm, doesn't make any differencre
20131115 14:49:38 <rmk0> ... -r
20131115 14:51:20 <sgothel> I use default as well ..
20131115 14:52:03 <sgothel> problem .. sometimes .. the swap interval is not 'synchronized' .. i.e. on some platforms if vsyncs for all GL commands :)
20131115 14:52:23 <sgothel> i.e. tears down perf. multiplies the vsync value ..
20131115 14:53:19 <rmk0> unpleasant
20131115 14:53:49 <sgothel> I 'played' w/ a group vsync .. but didn't complete
20131115 14:53:59 <sgothel> must be somewhere in GLContext .. or so .. hmm
20131115 14:54:36 <rmk0> i use fraps to give a visual readout of the current framerate
20131115 14:54:57 <rmk0> essentially, if i create a GLCanvas, with a 60fps animator, fraps claims that the framerate is ~31fps, but it feels extremely rough
20131115 14:55:03 <rmk0> sort of jumpy, and more like half that
20131115 14:55:37 <rmk0> if i force vsync in the driver control panel, i get a smooth 60fps
20131115 14:56:16 <sgothel> ofc ..
20131115 14:56:21 <sgothel> FPSAnimator sucks
20131115 14:56:32 <sgothel> (by nature)
20131115 14:56:38 <rmk0> is there an alternative?
20131115 14:56:43 <sgothel> Animator :)
20131115 14:56:49 <rmk0> ...
20131115 14:56:53 <sgothel> and proper vsync ..
20131115 14:57:18 <sgothel> we have to experiment .. i.e. I guess on AMD I only set the last GLCanvas to vsync=1, the rest w/o
20131115 14:57:21 <sgothel> works nice
20131115 14:57:31 <sgothel> NV .. I guess all of 'em .. not so sure now
20131115 14:57:50 <sgothel> maybe we add a hint/quirk .. to deal w/ it in an agnostic way
20131115 14:58:54 * rmk0 tries Animator
20131115 14:59:22 <sgothel> .. and if you like to use 30fps .. swapInterval:=2
20131115 14:59:37 <rmk0> i'd like to use whatever the display refresh rate is really
20131115 14:59:47 <rmk0> i was only using FPSAnimator because i wasn't aware of an alternative
20131115 14:59:52 <sgothel> good .. so it's 1
20131115 15:00:43 <rmk0> so i do need to set the swap interval on the context in the GLEventListener, yes?
20131115 15:00:43 <rmk0> to 1
20131115 15:00:56 <sgothel> sure .. looks at GearsES2
20131115 15:01:12 <rmk0> right
20131115 15:01:14 <sgothel> if in doubt .. always look at our infamous example :)
20131115 15:01:18 <rmk0> hehe, yes
20131115 15:01:45 <sgothel> "INfamous .. must be very famous, right ?", The Three Amigos
20131115 15:02:11 <rmk0> /o\
20131115 15:02:55 <rmk0> silly question... why does FPSAnimator still exist?
20131115 15:03:04 <rmk0> sort of seems like it couldn't really do the right thing in most cases
20131115 15:03:36 <sgothel> well .. history .. and I actually don't know how GLJPanel works out w/ vsync - since it uses offscreen FBO rendering .. hmm, does it work ? :)
20131115 15:03:45 <sgothel> I have to check ..
20131115 15:04:07 <rmk0> this is actually GLCanvas, no GLJPanel, to clarify
20131115 15:04:09 <sgothel> FPSAnimator shall use Platform's currentMillis() .. since it is accurate
20131115 15:04:15 <rmk0> *t
20131115 15:04:23 <sgothel> however .. nothing can beat the vsync IRQ
20131115 15:05:07 <rmk0> vaguely wonder why anyone would not use vsync in programs
20131115 15:05:40 <rmk0> tearing, and wasting time generating frames that most likely won't be displayed
20131115 15:06:11 <sgothel> well . we don't want to patronize our user base :) .. so if they want to do things single threaded .. w/ polling and all sorts of crap - they can :)
20131115 15:06:20 <rmk0> yeah, nice, GLCanvas with setSwapInterval(1) and Animator works well
20131115 15:07:36 <rmk0> i wasn't suggesting that vsync be forced on anyone
20131115 15:07:43 <rmk0> but... am just not sure why anyone wouldn't want it
20131115 15:07:53 <sgothel> same here .. sure
20131115 15:08:00 <rmk0> wondering if there's some obscure use case i'm not aware of
20131115 15:08:22 <sgothel> proprietary sync for stereo glasses ? :)
20131115 15:08:45 <rmk0> yow!
20131115 15:14:42 <rmk0> hm, extremely minor nit... is there a way to clear the contents of the canvas before the GL context is initialized?
20131115 15:15:29 <rmk0> hard to explain what i mean
20131115 15:15:43 <rmk0> on linux, when the JFrame containing the canvas opens, the contents of the canvas are just those of the JFrame (ie, a flat grey colour)
20131115 15:15:46 <rmk0> on windows, it's actually whatever is displayed on the desktop behind it
20131115 15:15:50 <rmk0> looks a bit nasty
20131115 15:16:04 <rmk0> is only there for a couple of seconds whilst JOGL initializes
20131115 15:31:45 <hija> sgothel: any ideas about my question?
20131115 15:32:03 <hija> (about an hour ago ^ )
20131115 15:48:57 <hija> hmm it appears attribute arrays are actually not possible
20131115 15:56:02 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131115 16:59:40 * eclesia (husky@anon) has left #jogamp
20131115 17:25:38 * monsieur_max (~maxime@anon) has joined #jogamp
20131115 18:54:23 * Eclesia (~eclesia@anon) has joined #jogamp
20131115 18:54:44 * Eclesia fixing ply reader
20131115 18:56:57 * hija (~hija@anon) Quit (Quit: hija)
20131115 19:51:26 * hija (~hija@anon) has joined #jogamp
20131115 20:06:48 * hija (~hija@anon) Quit (Quit: hija)
20131115 20:13:53 * hija (~hija@anon) has joined #jogamp
20131115 20:15:59 * hija (~hija@anon) Quit (Client Quit)
20131115 20:21:31 * [Mike] (~Mike]@anon) has joined #jogamp
20131115 20:45:08 <Eclesia> xranby: ply should be better now
20131115 21:00:59 * [Mike] (~Mike]@anon) Quit (Ping timeout: 272 seconds)
20131115 21:30:30 * void256 (~void@anon) has joined #jogamp
20131115 21:38:45 * [Mike] (~Mike]@anon) has joined #jogamp
20131115 21:39:20 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131115 21:49:01 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20131115 22:51:00 * kermyt (~kermyt@anon) Quit (Ping timeout: 246 seconds)
20131115 22:52:30 * kermyt (~kermyt@anon) has joined #jogamp
20131115 23:19:09 <rmk0> ugh
20131115 23:19:18 <rmk0> crash in native code on windows 7, takes out the vm
20131115 23:19:30 <rmk0> completely unable to produce it with a smaller program, no idea how to track it down
20131115 23:19:33 <rmk0> infuriating
20131115 23:19:45 <rmk0> it happens when the user resizes the JFrame containing a GLCanvas
20131115 23:20:06 <rmk0> it happened on windows XP too
20131115 23:20:31 <rmk0> doesn't happen on any other platform
20131115 23:25:29 <rmk0> it doesn't seem to happen immediately on resize... it's as if the resize occurs, i reallocate various things that need to be resized (such as framebuffers), and then by the next display call, they're corrupt in some way
20131115 23:29:33 * rmk0 hits it with a wrench
20131115 23:45:29 * hija (~hija@anon) has joined #jogamp
20131115 23:45:35 * hija (~hija@anon) Quit (Client Quit)
20131115 23:50:41 * hija (~hija@anon) has joined #jogamp
20131115 23:51:30 <rmk0> yeah, have tracked it down to a draw call
20131115 23:51:59 <rmk0> for some reason, either a VBO or an IBO is invalidated after the canvas is resized
20131115 23:52:19 <rmk0> not sure which, because they're obviously both bound during the draw call
20131115 23:52:59 * kermyt (~kermyt@anon) Quit (Ping timeout: 272 seconds)
20131115 23:53:03 <rmk0> seems like another driver bug to me... i certainly don't touch either of those buffers after they're initially created
20131115 23:53:16 <rmk0> and it doesn't happen outside of windows
20131115 23:55:10 * kermyt (~kermyt@anon) has joined #jogamp
20131116 00:21:26 * hija (~hija@anon) Quit (Quit: hija)
20131116 00:34:59 <sgothel> @Mark: This is weird, since we do have many GL buffer test cases and resize tests - all work
20131116 00:35:38 <sgothel> it's more like we almost *only* use GL buffers
20131116 00:35:43 <sgothel> (VBO IBO .. whatever)
20131116 00:35:56 <rmk0> yeah, same here
20131116 00:36:16 <rmk0> obviously strictly core here
20131116 00:36:22 <sgothel> but we decorate the usage w/ enableBuffer / draw / disableBuffer
20131116 00:37:03 <sgothel> i.e thats how we use our GLDataArray ..
20131116 00:38:05 <sgothel> me still stuck w/ issue w/ JAWTWindow and Hierarchy/Component listener issues .. duh! - trying to give same experience across platforms to visibility. blabla
20131116 00:38:25 <rmk0> sounds unpleasant
20131116 00:38:37 <sgothel> https://jogamp.org/bugzilla/showdependencytree.cgi?id=889&hide_resolved=0
20131116 00:38:44 <sgothel> yes .. it's a looong story
20131116 00:38:50 <sgothel> all started w/ OSX .. ofc
20131116 00:39:09 <sgothel> so you do the enable/disable ?
20131116 00:40:30 <rmk0> i don't have anything that automatically unbinds, no...
20131116 00:40:30 <rmk0> going to pick through the drawElements calls and make sure everything actually is unbound
20131116 00:40:58 <rmk0> could there potentially be a buffer that's still bound but deleted?
20131116 00:41:06 <rmk0> i mean... i'm not sure what the spec says about that, could that cause crashes?
20131116 00:41:27 * void256 (~void@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332])
20131116 00:41:40 * rmk0 eyes spec
20131116 00:42:49 <rmk0> hm
20131116 00:43:41 <sgothel> always a crash if resource is n/a
20131116 00:43:50 <sgothel> delete should postpone until unbind
20131116 00:43:58 <rmk0> interesting paragraph in the spec
20131116 00:44:02 <rmk0> http://waste.io7m.com/2013/11/16/delete.png
20131116 00:44:03 <sgothel> *should* - well, I never use such tweak
20131116 00:44:46 <rmk0> i've not checked... but i think already know the answer; the methods of a GLEventListener are not guaranteed to always be called in the same thread, are they?
20131116 00:44:57 <rmk0> it obviously takes care of making the context current on the calling thread
20131116 00:45:22 <sgothel> no guarantee right
20131116 00:45:38 <sgothel> but if anim thread exist - we try hard to only use that to support fluent animation
20131116 00:45:45 <rmk0> right
20131116 00:45:50 <rmk0> wondering if i've managed a subtle issue where i've deleted something that was still bound, and that's caused issues here
20131116 00:45:53 <sgothel> ctx is always claimed before issuing display .. sure
20131116 00:46:01 <sgothel> and that will lock the whole baby
20131116 00:46:10 <sgothel> no concurrency
20131116 00:46:15 <rmk0> yeah
20131116 00:46:32 <sgothel> release afterwards .. or use exclusive-ctx-thread feature
20131116 00:46:50 <sgothel> sure .. don't delete and use ..
20131116 00:46:56 <rmk0> hehe
20131116 00:47:11 <sgothel> in our concurrent shared ctx tests - we do similar tests
20131116 00:47:28 <sgothel> glIsBuffer .. or something
20131116 00:47:41 <sgothel> i.e. check whether shared buffer object is still alive
20131116 00:47:46 <rmk0> yeah, will do
20131116 00:47:57 <rmk0> thanks... have given me some leads to chase
20131116 00:47:59 <sgothel> is it a shared concurrent object ?
20131116 00:48:18 <rmk0> shouldn't be, no... there's only one context
20131116 00:48:20 <sgothel> then read my long remarks to GLSharedContextSetter ..
20131116 00:48:28 <sgothel> oh .. then it really should just work
20131116 00:49:01 <sgothel> trace should tell you who deletes it .. of do the manual query and stack trace .. etc
20131116 00:49:07 <sgothel> usually it's simple
20131116 00:49:34 <rmk0> not sure i mentioned that the actual object that causes the crash is created once and never deleted
20131116 00:49:42 <rmk0> but it's possible that some other object is still bound somehow
20131116 00:49:53 <rmk0> and that one has been deleted... maybe i missed an unbind somewhere
20131116 00:50:31 <sgothel> so check traces .. for object type bind/unbind
20131116 00:50:40 <sgothel> not a pair -> bug
20131116 00:50:51 <rmk0> right
20131116 00:50:53 <sgothel> thats the reason I always do enable/disable .. bind/unbind
20131116 00:51:20 <sgothel> b/c complex scenes get complicated :)
20131116 00:51:52 <sgothel> the GLSL handler for GLServerArray takes care and read current bindings .. some 'fast path'
20131116 00:52:02 <sgothel> but actually .. it doesn't really matter
20131116 00:59:06 <sgothel> jogl.debug.DebugGL .. uses the debug context - isn't this saying anything - so bad that GL just crashes ..
20131116 01:00:56 <rmk0> when you say debug context... is that a GL extension?
20131116 01:01:17 <rmk0> i'm certainly not getting any extra output before the VM dies
20131116 01:01:34 <rmk0> i'm using new DebugGL3(new TraceGL3(...))
20131116 01:02:08 <sgothel> -Djogl.debug.DebugG (like jogl.debug.TraceGL) _property_ triggers us to make a debug context _besides_ the pipelining
20131116 01:02:10 <rmk0> is fine though... i think you've pointed me in the right direction already
20131116 01:02:22 <rmk0> ah, right
20131116 01:02:35 <sgothel> you can do that manually w/ the setContextCreationFlags(..)
20131116 01:02:55 <sgothel> this will enable the DEBUG ctx of the GL driver
20131116 01:03:05 <sgothel> sometimes .. quite verbose
20131116 01:03:14 <rmk0> hehe, yes, i was just about to say
20131116 01:03:24 <sgothel> AMD always great, NV is getting better
20131116 01:03:25 <rmk0> "type Warning: implementation dependent performance"
20131116 01:03:36 <sgothel> yup .. at every state change :)
20131116 01:03:37 <rmk0> it's not keen on my choice of UNSIGNED_BYTE for index buffer indices
20131116 01:04:04 <sgothel> hmm .. not a native format, sure
20131116 01:04:58 <sgothel> I guess 32bit is used internally at least
20131116 01:05:31 <rmk0> it suggests UNSIGNED_SHORT
20131116 01:05:35 <rmk0> it's going to get UNSIGNED_BYTE and like it
20131116 03:04:16 * xranby (~xranby@anon) Quit (Ping timeout: 268 seconds)
20131116 03:09:58 * xranby (~xranby@anon) has joined #jogamp
20131116 05:05:54 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20131116050554.html