#jogamp @ irc.freenode.net - 20141017 05:06:23 (UTC)
20141017 05:06:23 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20141016050623.html
20141017 05:06:23 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20141017050623.html
20141017 05:17:33 * odin_ (~Odin@anon) Quit (Quit: Leaving)
20141017 06:33:28 * eclesia (~husky@anon) has joined #jogamp
20141017 06:33:32 <eclesia> hi
20141017 06:41:52 * monsieur_max (~maxime@anon) has joined #jogamp
20141017 07:25:14 * odin_ (~Odin@anon) has joined #jogamp
20141017 07:42:28 * xranby (~xranby@anon) Quit (Ping timeout: 250 seconds)
20141017 07:57:31 * xranby (~xranby@anon) has joined #jogamp
20141017 07:59:05 <xranby> good morning
20141017 08:10:48 * jvanek (jvanek@anon) has joined #jogamp
20141017 09:38:38 * doev (~doev@anon) has joined #jogamp
20141017 11:30:22 * doev (~doev@anon) Quit (Ping timeout: 240 seconds)
20141017 12:16:56 * doev (~doev@anon) has joined #jogamp
20141017 13:42:28 <rmk0> anyone implemented a mouse-controlled fps camera?
20141017 13:42:52 <rmk0> the math is fine... have all that working correctly, but i'm not exactly sure how often the cursor should be warped back to the center of the screen
20141017 13:43:45 <rmk0> if it's warped in the mouseMoved method of the MouseListener, the user can't move the mouse far/fast enough to move the camera before the cursor is cruelly warped back to the center
20141017 13:43:50 <eclesia> I did, but it's more a 'fly' camera, with roll, I warp it at each rendering
20141017 13:44:24 <rmk0> hm, right... i do seem to get better results doing it at the same rate the screen is updated
20141017 13:44:44 <rmk0> it seems sort of conceptually wrong though... am implicitly tying part of the input handling to the frame rate
20141017 13:47:06 <eclesia> hm I have a time factor, this way the update is correct, no 'jump' effect if a frame is longer to render
20141017 13:47:28 <rmk0> yeah, am doing the same
20141017 13:47:49 <rmk0> the functions to integrate the position and orientation of the camera take a delta time
20141017 13:48:29 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20141017 13:49:06 <rmk0> wondering what valve do in the source engine
20141017 13:49:10 <rmk0> some sort of smoothing, perhaps
20141017 13:49:52 <eclesia> it's smooth on my side
20141017 13:52:14 <rmk0> how do you decide how far to rotate the camera, based on the mouse delta?
20141017 14:01:32 <eclesia> rmk0: I have a radian/pixel ratio. so angle is just delta*ratio on both axis
20141017 14:02:15 <rmk0> the ratio's configurable?
20141017 14:02:34 <eclesia> yes
20141017 14:02:49 <eclesia> it's what you find in any game : mouse speed
20141017 14:02:57 <rmk0> right
20141017 14:03:03 <rmk0> what's the default for you?
20141017 14:03:29 <rmk0> trying to see how different people have implemented this stuff... there's very little information available, surprisingly
20141017 14:03:38 <rmk0> given how many games have fps cameras of this style
20141017 14:03:49 <eclesia> 0.005 radian/pixel by default
20141017 14:05:31 <sgothel> @Mark: Input [events] happen in parallel to output
20141017 14:05:53 <sgothel> sadly, only the drag modus currently keeps receiving events when mouse leaves window
20141017 14:06:18 <sgothel> this is also windowing toolkit related .. depends on settings
20141017 14:06:31 <rmk0> sgothel: i'm confining the pointer... not sure what you mean by "in parallel to output"
20141017 14:06:34 <rmk0> which output?
20141017 14:06:34 <sgothel> plus NEWT drops events if out of bounds (security)
20141017 14:06:44 <sgothel> video/opengl
20141017 14:06:53 <rmk0> yeah, assumed that
20141017 14:07:10 <sgothel> In our GearsES2 demo .. we warp too .. hmm
20141017 14:08:26 <sgothel> well .. it's a simple navigation, after receiving event warp back to center
20141017 14:09:20 <rmk0> hm
20141017 14:10:12 <sgothel> the concurrent input event handling could either change things for the next frame - or maybe even for a current one in progress .. to reduce lag .. if rendering engine allows late data injection ..
20141017 14:11:01 <sgothel> we may introduce some API for such cause to reduce event propagation overhead
20141017 14:11:18 <rmk0> i'm curious as to how tying pixels to radians affects portability to different screens
20141017 14:11:26 <rmk0> like... screens with vastly higher resolutions of the same size
20141017 14:11:27 <sgothel> currently .. it;s like 1ms .. not bad, but could be worse
20141017 14:11:46 <sgothel> I simply use the screen dpi .. and a percentage
20141017 14:11:54 <sgothel> i.e. for graph UI etc
20141017 14:12:12 <rmk0> i don't see that in GearsES2
20141017 14:12:14 <sgothel> 2 finger zoom .. and the like
20141017 14:12:20 <sgothel> ah .. one sec
20141017 14:14:37 <sgothel> UIShape.PointerEventInfo delivers relative coordinates .. where dpi related impact should be used in the gesture events .. digging :)
20141017 14:14:49 <rmk0> /o\
20141017 14:16:44 <sgothel> PinchToZoomGesture.ZoomEvent.getScale() <- API doc
20141017 14:17:47 <sgothel> PinchToZoomGesture line 222 for example!
20141017 14:18:08 * rmk0 eyes it
20141017 14:19:23 <sgothel> DoubleTapScrollGesture <- similar stuff
20141017 14:20:46 <rmk0> not sure if what i've implemented is similar
20141017 14:20:59 <rmk0> i'm not currently taking dpi into account, or anything like that
20141017 14:21:20 <sgothel> but a ratio to screen size would be fine already
20141017 14:21:28 <rmk0> i basically map the cursor position to a [-1.0, 1.0] range, where -1.0 on the X axis is the left edge and 1.0 is the right
20141017 14:21:33 <sgothel> where 'whole screen width' is 1.0
20141017 14:21:40 <sgothel> yup
20141017 14:21:57 <rmk0> i take the resulting value and multiply it by a value given in radians-per-second, to specify how the camera should rotate
20141017 14:22:21 <rmk0> the main issue is that it's just too slow... the user can never move the mouse far enough in one tick to get a delta value of more than about 0.05...
20141017 14:22:22 <sgothel> sure .. including some 'acceleration' factor
20141017 14:22:35 <sgothel> ^^ add an accel factor :)
20141017 14:22:58 <rmk0> is it... normal to need an acceleration factor of > 100.0?
20141017 14:23:43 <sgothel> yes, which would reduce the required distance .. or lets say 'touch pad size'
20141017 14:24:17 <sgothel> i.e. for a big screen .. you don't want to move all along the screen w/ finger or mouse :)
20141017 14:24:23 <sgothel> the acceleration .. hence
20141017 14:24:26 <rmk0> right
20141017 14:25:09 <rmk0> guess i'm just struggling to find values that feel pleasant
20141017 14:25:36 <sgothel> DoubleTapScrollGesture <- same issue .. i.e. how much shall a finger move (mm) to use it as a scroll .. etc
20141017 14:25:55 <sgothel> and how many pixels or mm are 1 scroll unit
20141017 14:26:09 <sgothel> so here, we try to use OS values (Android) .. or some defaults
20141017 14:27:26 <sgothel> make it a property or 'registry' .. to be configured somehow - surely, sound values are king here. took me a while to make those gesture handlers work OK
20141017 14:29:22 * rmk0 (~rmk0@anon) Quit (Ping timeout: 250 seconds)
20141017 14:30:46 * gouessej (5ee4b442@anon) has joined #jogamp
20141017 14:30:52 <gouessej> Hi
20141017 14:30:58 <sgothel> Hi
20141017 14:31:13 <gouessej> rmk0: I already implemented several FPS mouse controlled camera
20141017 14:31:13 <zubzub> Hi
20141017 14:31:22 <gouessej> "cameras"
20141017 14:33:55 <gouessej> rmk0: One of your troubles will be solved by the new input API
20141017 14:34:37 <gouessej> rmk0: I would like to expose the raw data directly
20141017 14:34:51 <gouessej> rmk0: Then, no problem with pixels, resolutions
20141017 14:36:32 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20141017 14:37:48 * rmk0 (~rmk0@anon) has joined #jogamp
20141017 14:37:48 * rmk0 (~rmk0@anon) Quit (Changing host)
20141017 14:37:48 * rmk0 (~rmk0@anon) has joined #jogamp
20141017 14:38:14 * rmk0 gnaws phone line
20141017 14:38:21 * rmk0 eyes log
20141017 14:42:43 <rmk0> warping a pointer isn't going to cause a subsequent mouse motion event to be queued, is it...
20141017 14:43:08 <sgothel> hmm :)
20141017 14:43:38 <sgothel> yes it does ofc .. hence:
20141017 14:43:45 <sgothel> if(e.isConfined() && confinedFixedCenter && null!=window) {
20141017 14:43:45 <sgothel> x=window.getSurfaceWidth()/2;
20141017 14:43:45 <sgothel> y=window.getSurfaceHeight()/2;
20141017 14:43:45 <sgothel> window.warpPointer(x, y);
20141017 14:43:45 <sgothel> }
20141017 14:43:46 <sgothel> prevMouseX = x;
20141017 14:43:46 <sgothel> prevMouseY = y;
20141017 14:43:50 <rmk0> oh
20141017 14:44:02 <sgothel> GearsES2 line 699
20141017 14:44:26 <sgothel> double check .. and tell me :)
20141017 14:44:28 <rmk0> seen it... not sure how that would imply that warping would queue another event
20141017 14:44:37 <rmk0> or at least, i don't know how i'd infer that from that code!
20141017 14:44:43 <sgothel> at least it would circumvent off effects
20141017 14:45:01 <sgothel> i.e. a zero move ..
20141017 15:01:29 <rmk0> .. i've just realized the issue
20141017 15:01:44 <rmk0> the mouse motion method fires, i calculate the delta
20141017 15:01:53 <rmk0> set the rotation speed from the delta
20141017 15:02:11 <rmk0> then soon after, the cursor is warped in the display() method
20141017 15:02:22 <rmk0> which triggers a mouse event which obviously has a resulting delta of 0.0
20141017 15:02:27 <rmk0> so i set the speed to 0.0!
20141017 15:02:32 <rmk0> which means that rotation stops
20141017 15:02:51 <rmk0> the mouse is still moving, so another event is fired, and the speed is set again to the current scrolling speed, etc
20141017 15:03:01 <rmk0> no wonder it looks rough
20141017 15:04:10 * eclesia (~husky@anon) Quit (Ping timeout: 255 seconds)
20141017 15:07:06 * bbbruce (~bx@anon) Quit (Ping timeout: 240 seconds)
20141017 15:30:37 * bbbruce (~bx@anon) has joined #jogamp
20141017 15:39:27 <rmk0> patience fraying
20141017 15:40:39 <rmk0> which one of the millions of shell scripts in jogl/make/scripts was it to run ES2 Gears NEWT?
20141017 15:41:01 <rmk0> eclipse just soils itself on the jogl/gluegen projects and keeps trying to rebuild them over and over despite being told not to
20141017 15:44:34 <rmk0> i just want to run TestES2GearsNEWT, i don't care how
20141017 15:45:12 * bbbruce (~bx@anon) Quit (Ping timeout: 265 seconds)
20141017 15:46:14 * bbbruce (~bx@anon) has joined #jogamp
20141017 15:47:57 <rmk0> additionally... is there any way to tell the difference between a mouse event that occurred as a result of moving the mouse, and one that occurred because of warping the pointer?
20141017 15:52:22 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20141017 15:53:37 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141017 15:55:27 * xranby (~xranby@anon) has joined #jogamp
20141017 16:29:11 * monsieur_max (~maxime@anon) has joined #jogamp
20141017 16:40:14 <rmk0> ... starting to think that delivering a mouse event when the cursor is warped is fundamentally wrong
20141017 16:40:20 <rmk0> i've no idea why i'd even want to be told about it
20141017 16:40:40 <rmk0> am completely unable to get usable results out of this thing
20141017 16:43:00 * doev (~doev@anon) Quit (Quit: Verlassend)
20141017 16:49:44 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141017 16:50:13 * monsieur_max (~maxime@anon) has joined #jogamp
20141017 16:54:07 <zubzub> 17:41 < rmk0> eclipse just soils itself on the jogl/gluegen projects and keeps trying to rebuild them over and over despite being told not to
20141017 16:54:10 <zubzub> eclipse
20141017 16:54:13 <zubzub> problem right there
20141017 16:54:41 <zubzub> https://www.jetbrains.com/idea/download/
20141017 16:54:47 <zubzub> you're welcome ;)
20141017 17:06:53 * rmk0 (~rmk0@anon) Quit (Ping timeout: 265 seconds)
20141017 17:10:35 * rmk0 (~rmk0@anon) has joined #jogamp
20141017 17:16:52 <rmk0> you know... of all the things that i thought were going to waste my time this week
20141017 17:17:02 <rmk0> getting the position of a mouse cursor wasn't one of them
20141017 17:32:47 <sgothel> back from babysitting, sorry Mark for the frustrations .. but look at 'warp' as a tool for generating such events as well (like AWTRobot)
20141017 17:33:23 <sgothel> scripts/tests-x64.sh for example .. which calls tests.sh .. edit both, you will see
20141017 17:33:34 * rmk0 grimaces
20141017 17:36:14 <sgothel> in this case, set your pre-pos values, so new warp-position results in a continuous velocity
20141017 17:37:24 <rmk0> $ ./scripts/tests-x64.sh
20141017 17:37:27 <rmk0> build-dir ../build-x86_64 is not a directory
20141017 17:37:35 <sgothel> one could also think of it as each move gives one tick using an exponential acceleration ..
20141017 17:37:59 <sgothel> well, I am sure you can edit that .. sorry, sven's sandbox scripts
20141017 17:38:10 <rmk0> i've no idea where the problem even is
20141017 17:38:26 <sgothel> you mean warp ?
20141017 17:38:54 <sgothel> you tell windowing system to move to a new position, it notifies you about it
20141017 17:40:20 <rmk0> leaving aside this tests-x64.sh mess for a bit... the problem is that i'm constantly being told that the cursor has moved back to the center of the screen
20141017 17:40:34 <rmk0> i have to interpret "the cursor is at the middle of the screen" as "the mouse is no longer moving"
20141017 17:40:40 <sgothel> you move it there w/ your warp, don't you ?
20141017 17:41:06 <sgothel> you use a a function f(pre-pos, current-pos)
20141017 17:41:36 <rmk0> what's pre-pos?
20141017 17:41:40 <sgothel> previous pos
20141017 17:41:57 <sgothel> position
20141017 17:42:21 <sgothel> well, you can also simply drop that event ofc :)
20141017 17:42:28 <rmk0> am i missing something blindingly obvious?
20141017 17:42:44 <rmk0> let's say i start the program
20141017 17:42:49 <rmk0> i move the mouse
20141017 17:43:01 <rmk0> the mouse moved callback fires, tells me that the mouse is at (x, y)
20141017 17:43:21 <rmk0> i work out that (x, y) is (s, t) pixels from the center of the screen
20141017 17:43:52 <sgothel> then you warp back to center and receive such mouse move event
20141017 17:44:04 <sgothel> which you can simply drop/ignore
20141017 17:44:32 <rmk0> is it guaranteed that the next event will definitely be the one triggered by the warp?
20141017 17:44:51 <sgothel> depends on windowing system, but IMHO - yes
20141017 17:45:16 <sgothel> you can check, i.e. ignore if center position
20141017 17:45:41 <sgothel> in GearsES2 it is simple, since no continuous acceleration is being used
20141017 17:46:47 <rmk0> the model i wanted is that when the mouse moves, the resulting delta applies a constant angular acceleration
20141017 17:47:02 <rmk0> when the mouse isn't moving, the angular speed is reduced by a drag factor until the rotation stops
20141017 17:47:14 <rmk0> actually determining that the mouse isn't moving seems completely unreliable
20141017 17:47:28 <sgothel> so you will apply an exponential function here probably
20141017 17:48:00 <sgothel> I see
20141017 17:48:14 <rmk0> i'm probably not going to do that
20141017 17:48:22 <rmk0> at this rate, people are going to get keyboard controls and like it
20141017 17:48:47 <rmk0> .. this is pissing me off way more than it should be
20141017 17:48:49 <rmk0> might do something else
20141017 17:49:16 <sgothel> I would assume that the tick provide (mouse movement) will continue to provide those ticks when mouse continues to move
20141017 17:49:36 <sgothel> you can use a tick consumer which consumes those provided ticks
20141017 17:49:50 <sgothel> then you don't need to detect whether the mouse is no more moving to de-accelerate
20141017 17:50:01 <sgothel> and the zero move at center shall not be a problem IMHO
20141017 17:51:14 <rmk0> there is actually another issue which i don't understand
20141017 17:51:25 <rmk0> doing the warp in the mouse movement callback...
20141017 17:51:48 <rmk0> it seems like the mouse doesn't get to move far enough before a warp occurs
20141017 17:51:54 <rmk0> so i only ever get extremely tiny delta values
20141017 17:52:14 <rmk0> i mean... ten pixels at most
20141017 17:52:21 <sgothel> which removes the windowing system own mouse acceleration
20141017 17:52:55 <sgothel> however, the 'tick model' (bad name, maybe provider/consumer) .. should simplify that
20141017 17:53:28 <rmk0> it might
20141017 17:53:38 <sgothel> you can check whether it helps to center back later, i.e. at mouse leave ..
20141017 17:54:31 <rmk0> it gives slightly better results to do it in the display() callback
20141017 17:54:49 <rmk0> at least there's more time between the mouse moving and the warp occuring
20141017 17:54:53 <rmk0> i don't like it, though
20141017 18:01:36 <sgothel> don't use no-movement as a de-accel trigger
20141017 18:01:52 <sgothel> just consume your accel ticks by movement ..
20141017 18:02:09 <rmk0> not sure if you mean what i think you mean...
20141017 18:02:30 <sgothel> like each pixel move is a drop of gasoline into the engine ..
20141017 18:02:36 <rmk0> like ... a somewhat physically-based model would apply drag every tick to slow down the camera
20141017 18:02:44 <rmk0> but mouse movement would apply acceleration
20141017 18:03:02 <rmk0> the drag would be applied regardless, so there'd be no need to track "the mouse has stopped"
20141017 18:06:48 <rmk0> i tried something along those lines first, but it becomes hard to get nice snappy movement
20141017 18:07:14 <rmk0> you need very high acceleration and very high drag to get quick starts and stops
20141017 18:08:09 <rmk0> wish i knew what the source engine was doing
20141017 18:08:20 <rmk0> get beautiful smooth movement and very precise small movements
20141017 18:19:29 * rmk0 calms down
20141017 18:40:06 <rmk0> finally, some degree of success!
20141017 18:44:27 <rmk0> apologies for getting explosive... i try not to get so aggravated these days
20141017 18:44:29 <rmk0> doesn't always work
20141017 18:48:36 <zubzub> my java opengl (jogl) wayland compositor is working! \o/
20141017 18:48:43 * zubzub does the happy dance
20141017 18:51:37 <rmk0> \o/
20141017 18:51:56 <rmk0> how easy is it to write a compositor?
20141017 18:52:09 <rmk0> i'm not sure exactly what the protocol(s) demand you implement
20141017 18:54:11 <zubzub> relatively easy actually if you know what to do
20141017 18:54:20 <zubzub> depends what functionality you want to offer
20141017 18:54:32 <zubzub> for now I just concentrated on getting something drawn on the screen
20141017 18:54:40 <zubzub> but I still have to do input
20141017 18:54:54 <zubzub> decorations, window management etc
20141017 19:08:05 * rmk0 (~rmk0@anon) Quit (Ping timeout: 272 seconds)
20141017 19:08:55 * rmk0 (~rmk0@anon) has joined #jogamp
20141017 19:08:55 * rmk0 (~rmk0@anon) Quit (Changing host)
20141017 19:08:55 * rmk0 (~rmk0@anon) has joined #jogamp
20141017 19:09:12 <sgothel> back .. in between kitchen work ..
20141017 19:09:31 <sgothel> @Mark: Can you post your solution ? N.p. of getting impatient sometimes .. all good
20141017 19:09:46 <rmk0> sgothel: was going to do a whole article on the subject
20141017 19:09:52 <rmk0> am extremely displeased at the quality of the information online
20141017 19:09:59 <sgothel> ha :)
20141017 19:10:13 <rmk0> they tend to mash all of the math, input handling, animation, etc, into one giant assumption-ridden mess
20141017 19:10:16 <sgothel> so not the tick provider in event listener .. and consumer in display ?
20141017 19:10:41 <sgothel> maybe I should install a console in the kitchen .. hmm :)
20141017 19:11:15 <rmk0> pretty much... i accumulate an "acceleration" value for each axis, with the acceleration value being increased by the delta from each mouse event
20141017 19:11:30 <sgothel> nice
20141017 19:11:39 <rmk0> and then in display() i add the accumulate acceleration to the current velocity, and apply drag
20141017 19:11:43 <rmk0> *accumulated
20141017 19:11:59 <rmk0> obviously if no acceleration was accumulated (mouse didn't move), the drag will eventually slow the rotation down to zero
20141017 19:12:11 <rmk0> but ... i think i may've triggered a bug in newt /o\
20141017 19:12:15 <rmk0> investigating
20141017 19:12:24 <sgothel> yup .. so .. hysteresis .. and no abrupt stop
20141017 19:12:32 <sgothel> that is good
20141017 19:12:34 <rmk0> calling warpPointer inside the mouse motion handler seems to steadily increase input latency
20141017 19:12:55 <sgothel> possible .. depending on windowing kit
20141017 19:13:26 <sgothel> GearsES2 didn't expose it though ..
20141017 19:13:33 <rmk0> after about ten seconds of moving the mouse about, it can take over a second to respond to the next mouse or keyboard input
20141017 19:13:54 <rmk0> am prodding things to see if i can reproduce
20141017 19:13:55 <sgothel> too much events ? X11 ?
20141017 19:14:05 <rmk0> this is linux X11, yeah
20141017 19:14:05 <sgothel> *many*
20141017 19:14:29 <rmk0> the problem doesn't occur if i move warpPointer to the display() callback... presumably that generates fewer events
20141017 19:14:54 <rmk0> 60 times a second rather than on every mouse event
20141017 19:15:30 <sgothel> will check how GearsES2 behaves .. hmm - later, when I finished cooking :)
20141017 19:17:38 <rmk0> suspect it is some queue filling up
20141017 19:17:52 <rmk0> i handle an event, and generate another event by handling it... which generates another event, and another ...
20141017 19:21:49 <sgothel> only issue warp .. if there is a delta ..
20141017 19:22:16 <sgothel> or lets say .. maybe 25% of an edge (width or height)
20141017 19:50:27 * Eclesia (~eclesia@anon) has joined #jogamp
20141017 20:02:27 <Eclesia> has someone implemented mirror/reflection textures ?
20141017 20:03:28 <rmk0> not if you mean something other than rendering to a cube map and faking reflections like that
20141017 20:04:11 <Eclesia> nope, true reflection with a second rendering pass flipping the camera
20141017 20:04:27 <Eclesia> for mirrors and water for example
20141017 20:50:58 <Eclesia> ??
20141017 20:51:11 <Eclesia> I can't find the GL constant : GL_CLIP_PLANE0
20141017 20:51:22 <Eclesia> but there is GL_CLIP_DISTANCE0
20141017 20:51:34 <Eclesia> sgothel: hi, is that the same thing ?
20141017 20:59:59 <Eclesia> ha found it
20141017 21:00:04 <Eclesia> GL2
20141017 21:11:19 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141017 22:02:31 <rmk0> http://waste.io7m.com/2014/10/17/fps_camera.mp4
20141017 22:03:18 <rmk0> it's 60fps, but unfortunately my machine can't handle rendering 60fps and capturing 60fps at the same time
20141017 22:05:59 <Eclesia> nice, cubemap shadow for point light and ssao
20141017 22:06:16 <Eclesia> that's ssao or backed shadows ?
20141017 22:06:29 <rmk0> it's not even a cubemap shadow, hehe
20141017 22:06:38 <Eclesia> baked*
20141017 22:06:50 <rmk0> is variance shadows, six projective lights arranged to look like a point light
20141017 22:06:55 <rmk0> no baking
20141017 22:07:15 <Eclesia> cheater :p
20141017 22:07:22 <rmk0> yep \o/
20141017 22:07:38 <sgothel> smooth
20141017 22:31:03 <Eclesia> :) small victory too : mirror http://jsorel.developpez.com/temp/mirror.png
20141017 22:31:47 <rmk0> nice
20141017 22:32:36 <Eclesia> going to bed now ... +++
20141017 22:32:43 <rmk0> byeee
20141017 22:32:50 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20141018 00:37:57 * rmk0 (~rmk0@anon) Quit (Ping timeout: 244 seconds)
20141018 00:39:47 * rmk0 (~rmk0@anon) has joined #jogamp
20141018 00:39:47 * rmk0 (~rmk0@anon) Quit (Changing host)
20141018 00:39:47 * rmk0 (~rmk0@anon) has joined #jogamp
20141018 01:16:27 * darkfrog (~mhicks@anon) has joined #jogamp
20141018 01:16:47 <darkfrog> are there any performance comparisons between JOGL and LWJGL?
20141018 02:06:36 * rmk0 (~rmk0@anon) Quit (Ping timeout: 250 seconds)
20141018 02:07:29 * rmk0 (~rmk0@anon) has joined #jogamp
20141018 02:07:29 * rmk0 (~rmk0@anon) Quit (Changing host)
20141018 02:07:29 * rmk0 (~rmk0@anon) has joined #jogamp
20141018 02:14:13 * rmk0 (~rmk0@anon) Quit (Ping timeout: 255 seconds)
20141018 02:16:03 * rmk0 (~rmk0@anon) has joined #jogamp
20141018 02:24:52 * xranby (~xranby@anon) Quit (Ping timeout: 240 seconds)
20141018 02:40:45 * xranby (~xranby@anon) has joined #jogamp
20141018 03:17:57 * rmk0 (~rmk0@anon) Quit (Ping timeout: 246 seconds)
20141018 03:19:37 * rmk0 (~rmk0@anon) has joined #jogamp
20141018 03:55:31 * xranby (~xranby@anon) Quit (Ping timeout: 265 seconds)
20141018 04:10:00 * xranby (~xranby@anon) has joined #jogamp
20141018 05:06:23 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20141018050623.html