#jogamp @ irc.freenode.net - 20130630 05:05:39 (UTC)
20130630 05:05:39 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20130629134039.html
20130630 05:05:39 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130630050539.html
20130630 07:47:24 * monsieur_max (~maxime@anon) has joined #jogamp
20130630 08:11:59 * [Mike] (~Mike]@anon) Quit ()
20130630 08:36:55 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20130630 09:36:30 * Eclesia (~eclesia@anon) has joined #jogamp
20130630 09:36:37 <Eclesia> hi
20130630 09:43:49 * monsieur_max (~maxime@anon) has joined #jogamp
20130630 09:51:22 * sgothel (~sven@anon) Quit (Quit: Leaving.)
20130630 11:22:46 * rmk0 (~rmk0@anon) Quit (Remote host closed the connection)
20130630 11:24:32 * rmk0 (~rmk0@anon) has joined #jogamp
20130630 11:24:32 * rmk0 (~rmk0@anon) Quit (Changing host)
20130630 11:24:32 * rmk0 (~rmk0@anon) has joined #jogamp
20130630 11:56:01 * xranby (~familjen@anon) has joined #jogamp
20130630 11:56:32 <xranby> good day!
20130630 11:56:39 <xranby> Eclesia: hi and welcome
20130630 11:56:55 <Eclesia> xranby: hi
20130630 11:57:21 <xranby> i browsed the backlogs and looked at the CC0 utils proposal
20130630 11:58:17 <xranby> eventually some of the jogamp util packages will be split out into a new project outside JOGL including the video player
20130630 11:59:03 <xranby> and then it would make sense to review license for use by such an subproject
20130630 11:59:24 <Eclesia> that would be great.
20130630 12:00:29 <Eclesia> even if we can only share on the api level. that would still be nice
20130630 12:01:28 <xranby> Eclesia: swithing question, you mention special needs in the API for metro-logical image data that is not covered by jogamp.. do you mind elaborate what kind of API's are needed?
20130630 12:02:45 <Eclesia> I can think of two things that usual imageing api do not handle properly
20130630 12:03:47 <Eclesia> metro-logical => Meteorological
20130630 12:03:57 <Eclesia> First : dimensions
20130630 12:03:57 <xranby> thank you :D
20130630 12:04:11 <Eclesia> often, image are limited to 2 dimensions
20130630 12:04:23 <Eclesia> in our cases we often have 5
20130630 12:04:47 <Eclesia> X,Y,Height,Creation Time, Estimation Time
20130630 12:05:06 <Eclesia> oceanography also have special dimensions
20130630 12:05:13 <Eclesia> like frequencies
20130630 12:05:25 <Eclesia> so basicly with require N dimension image support
20130630 12:05:56 <Eclesia> Second : data "views"
20130630 12:06:17 <Eclesia> in games, images have only 2 views
20130630 12:06:40 <Eclesia> the Sample view, which is the pixel stored values
20130630 12:07:04 <Eclesia> the Color view, which is the RGBA color representation of pixel sample values
20130630 12:07:23 <Eclesia> in our case we also have Geophysic view
20130630 12:07:48 <Eclesia> which is a mathematic transformation of the sample pixel value to Real data values
20130630 12:08:00 <Eclesia> often a linear transform but not always
20130630 12:08:53 <xranby> hmm.. is the sample view a point cloud?
20130630 12:08:57 <Eclesia> Adding another I just thinked about : image Size
20130630 12:09:33 <Eclesia> we can work both with finite huge image of several Gigabytes
20130630 12:10:08 <Eclesia> and also infinite image, (geoide for example), which is an image build from a mathematic formula
20130630 12:10:22 <Eclesia> think of it as a Java RenderableImage
20130630 12:10:43 <Eclesia> you ask for a size, but there is not finite real size
20130630 12:10:57 <Eclesia> ^^
20130630 12:11:38 <Eclesia> sorry if my english isn't perfect
20130630 12:12:53 <Eclesia> there is also irregular grid images, but that's a different problem
20130630 12:13:53 <Eclesia> (pixel are not placed on a cartesian grid, something like this : http://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Lambert_conformal_conic.svg/300px-Lambert_conformal_conic.svg.png)
20130630 12:14:22 <xranby> yes sounds like most of this are suitable in a util library or geo api such as nasa world wind
20130630 12:15:12 <xranby> that can handle splitting up the large infinite datasets for rendering by the GPU
20130630 12:15:14 <Eclesia> worldwind is not a professional tool. it handles only the basics
20130630 12:15:57 <xranby> if there any professional tool available in open source form?
20130630 12:16:14 <Eclesia> with 3D ?
20130630 12:17:44 <xranby> that can cover the Meteorological needs
20130630 12:18:25 <Eclesia> I can only think of 3 doing the job properly.
20130630 12:19:00 <Eclesia> OG/GDAL in C++, GeotoolKit and UcarNetcdf in java
20130630 12:19:41 <Eclesia> I work on the second one ^^ http://www.ohloh.net/p/GeotoolKit
20130630 12:20:54 <Eclesia> there was the geotools project before, but they cut down the scientific approach to focus on mass markets
20130630 12:20:54 <xranby> do these these projects use hardware acceleration using OpenGL or OpenCL to speed up processing?
20130630 12:21:50 <Eclesia> I don't know for OGR/GDAL, but the 2 others don't
20130630 12:27:38 <xranby> without any previous knowledge of geo data layouts it sounds like processing may be done using OpenCL in autility library
20130630 12:28:15 <Eclesia> It could, the problem is finding developers
20130630 12:29:10 <Eclesia> there aren't many developers with : Java + Geography + GL/OCL knowledge
20130630 12:30:32 <xranby> hopefully java + GL/OCL developers starts to grow on trees now when the mobile phone industry starts to ship OpenCL on mobile phones
20130630 12:30:47 <Eclesia> and most who say they know OpenGL are actually just developers who coded a little something with java3d or java monkey engine, pityfull ...
20130630 12:32:31 <Eclesia> I can only see the kind of candidates we receive at work. not even 1 correct in months
20130630 12:36:02 <Eclesia> xranby: just for information, I fixes a few things in the project, normaly you can run all test on your machine, also added a widget demo if you are interesed.
20130630 12:36:19 <xranby> on the mobile space OpenCL makes the cut to bring down power-consumption by offloading mathematical processing from the CPU to the GPU. And lower power usually == posibility to run faster on desktops as well since all hardware are thermal limited nowdays
20130630 12:37:30 <xranby> thus i think people that will be able to utilize GPU's for general mathematical processing will increase now when the broad industry demands this kind of knowledge
20130630 12:38:18 <xranby> Eclesia: i will take a look and run some tests as well :D
20130630 12:38:29 <Eclesia> xranby: is opencl more accurate the opengl in decimal calculation ?
20130630 12:38:46 <xranby> OpenCL can use 64bit precision
20130630 12:38:54 <xranby> https://jogamp.org/jocl/www/
20130630 12:39:27 <Eclesia> with real maths ? not bugged like intel sin/cos operation ?
20130630 12:40:56 <xranby> i dont know :/
20130630 12:41:31 <xranby> of course these accuracy tests are needed to be done and check if it rounds correctly to the last significant bit
20130630 12:42:31 <Eclesia> I'll give a try to JOCL ;)
20130630 12:42:56 <Eclesia> (one day)
20130630 12:43:31 <xranby> there is some jocl-demos in the repository https://jogamp.org/jocl-demos/www/
20130630 12:44:20 <xranby> these of course require opencl drivers to be present on the system
20130630 12:44:21 <Eclesia> I'm already at full speed on my project, don't ask me more :D
20130630 12:44:42 <xranby> yes keep up the steam at the UN train!
20130630 12:44:52 <xranby> :D
20130630 12:45:14 <Eclesia> I will I will, finished the tabbed pane yesterday, hope to finish XSD parser today
20130630 12:45:29 <Eclesia> 1+1+1+1..
20130630 12:45:38 <Eclesia> make 50.000 lines today
20130630 12:45:54 <xranby> magical powers!
20130630 12:46:13 <Eclesia> I wish I could find another developer :(
20130630 12:46:24 <Eclesia> perhaps after my JUG presentation
20130630 13:04:40 <rmk0> weird... oracle's jre returns the wrong day for Calendar.get(DAY_OF_MONTH)
20130630 13:04:50 <rmk0> it adds 1
20130630 13:05:39 <Eclesia> check the javadoc
20130630 13:05:54 <Eclesia> some values start at 0 others at 1 on the calendar
20130630 13:06:02 <rmk0> have... the first day of the month is 1
20130630 13:06:25 <rmk0> but... it adds a further 1 when the Calendar instance is constructed from a time in milliseconds
20130630 13:06:35 <rmk0> openjdk gives the right value, oracle's doesn't
20130630 13:07:24 <Eclesia> maybe a difference in timezone, check if you have hours offset
20130630 13:07:42 <rmk0> the calendar instance is explicitly constructed from a UTC timezone
20130630 13:11:04 <rmk0> http://waste.io7m.com/2013/06/30/dayofmonth.zip
20130630 13:11:08 <rmk0> $ javac Show.java && java Show
20130630 13:11:09 <rmk0> 23
20130630 13:11:12 <rmk0> on openjdk
20130630 13:11:14 <rmk0> $ javac Show.java && java Show
20130630 13:11:15 <rmk0> 24
20130630 13:11:18 <rmk0> on Oracle's
20130630 13:11:43 <rmk0> the time is taken from a file in a zip file, can see in the listing of the zip file's contents that the day is the 23rd
20130630 13:15:59 <xranby> rmk0: right... subdir/file.txt timestamp is jan 23 2012 subdir
20130630 13:19:03 <xranby> rmk0: try file a bugreport for the 7u* builds into the oracle jira system https://java.net/jira/browse/JDK
20130630 13:19:30 <rmk0> ah, so that's where they're hiding it these days
20130630 13:19:34 <rmk0> was looking for that... thanks
20130630 13:22:53 <xranby> rmk0: yes its highly confusing since they have multiple bugtracking systems in use
20130630 13:24:31 <xranby> they also have the secret bugreport submission system http://bugreport.sun.com/bugreport/ where you dont know what happens
20130630 13:25:00 <rmk0> heh
20130630 13:38:53 <xranby> rmk0: do ze.getTime() return the same value using OpenJDK and Oracle? I only have OpenJDK 6 & 7 on this machine and they return the same date.
20130630 13:39:13 <xranby> thinking it may be a bug in ZipEntry
20130630 13:39:23 <rmk0> checking
20130630 13:41:15 <rmk0> yep, different values: 1327384210000 for oracle, 1356998400000 for openjdk
20130630 13:41:38 <xranby> ok then the bug is in ZipEntry
20130630 13:42:03 <rmk0> i should mention that the two JDKs are on different operating systems, so this may be down to windows XP's differing epoch
20130630 13:42:19 <rmk0> it's obviously still very much a wrong answer
20130630 13:42:51 <xranby> i assume the two OS uses the same start epoch
20130630 13:43:18 <rmk0> well, the windows NT epoch is 1980-01-01, isn't it?
20130630 13:43:34 <rmk0> whereas linux/unix is 1970
20130630 13:46:23 <xranby> IMHO Java then should have its own java epoch that all JDK date api's are aligned against to make applications system independent.. but well in this case i dont know.. what the spec says about ZipEntry
20130630 13:46:47 <rmk0> the documentation on it is sparse
20130630 13:47:34 <rmk0> i'm not even sure the specification for the zip file format says anything about the stored time values
20130630 13:47:45 <rmk0> i think all the zip utilities assume the NT epoch
20130630 13:51:02 <xranby> in openjdk sourcecode it do an explicit conversion from "dos" time to java time
20130630 13:51:34 <rmk0> right
20130630 13:56:30 <xranby> hmm there have been one major patch to change the implementation in 2013 http://cr.openjdk.java.net/~sherman/6303183/webrev/src/share/classes/java/util/zip/ZipEntry.java.patch
20130630 13:56:31 <xranby> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6303183
20130630 13:56:57 <xranby> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f
20130630 13:57:22 <rmk0> ugh
20130630 14:36:15 <rmk0> ... just remembered that i was supposed to set up and test SMF
20130630 15:01:57 <rmk0> http://smf.io7m.com
20130630 15:02:13 <rmk0> i've installed the mailing list mod, seems like it's possible to add email addresses
20130630 15:02:25 <rmk0> so posting to jogl@domain.xyz would post to the jogl form
20130630 15:02:27 <rmk0> *forum
20130630 15:02:32 <rmk0> and so on
20130630 17:42:17 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20130630 18:26:45 * hharrison (~chatzilla@anon) has joined #jogamp
20130630 18:48:14 * monsieur_max (~maxime@anon) has joined #jogamp
20130630 18:57:09 * void256 (~void@anon) has joined #jogamp
20130630 19:07:31 * hharrison (~chatzilla@anon) Quit (Remote host closed the connection)
20130630 19:19:00 <xranby> void256: i have pushed a fix for the frame size issue
20130630 19:19:19 <void256> : D
20130630 19:19:22 <void256> awesome!
20130630 19:19:32 <void256> what was it?
20130630 19:21:06 <xranby> frame.setSize is insets + os border
20130630 19:21:47 <xranby> thus the insets became smaller than the size you inteded to request
20130630 19:22:07 <xranby> https://github.com/xranby/nifty-gui/commit/1ccfbce97037aadb3e29e3bb281307e591a7cf3d
20130630 19:22:42 <xranby> instead i used the setPreferredSize on the canvas in order to let the frame auto-adjust using pack
20130630 19:23:11 <xranby> the result is pixel perfect output
20130630 19:24:17 <void256> excellent
20130630 19:24:21 <void256> thank you very much :)
20130630 19:24:39 <xranby> you are welcome :) i will demo this at siggraph...
20130630 19:24:47 <xranby> i also solved how to setup maven 3
20130630 19:25:00 <void256> even more excellent! :D
20130630 19:25:15 <void256> so you can run the demos now with all the configurations?
20130630 19:25:16 <xranby> https://gist.github.com/xranby/e09daa4997cdd19b474e
20130630 19:25:18 <Eclesia> awt integration issue ?
20130630 19:25:19 <xranby> yes
20130630 19:25:34 <xranby> Eclesia: yes awt frame canvas setup issue
20130630 19:26:00 <xranby> void256: it looks the same using batch and core renderer.. i gess thats how it is supposed to be :)
20130630 19:26:30 <void256> yes! :)
20130630 19:26:30 <xranby> void256: the title is different of course..
20130630 19:26:39 <void256> the only difference would be the console output
20130630 19:26:50 <void256> it outputs the FPS every second I think
20130630 19:26:55 <xranby> yes
20130630 19:27:04 <void256> how is the difference?
20130630 19:27:08 <void256> on your machine?
20130630 19:27:33 <xranby> the fps stays around 58-62 using any renderer thus i think this machine is vblank locked
20130630 19:27:46 <Eclesia> talking about demos, I don't know if it's possible. in games we can switch to resolution which are different from the native. would be nice to have a fullscreen demo showing how to switch resolution
20130630 19:27:49 <void256> yes, thats the issue we discussed before
20130630 19:28:00 <void256> but it should output the frametime in ms too
20130630 19:28:10 <void256> you should (I hope) see a difference there
20130630 19:28:40 <xranby> ah you are right.. i will compare
20130630 19:29:02 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20130630 19:29:25 <Eclesia> finishing the day on some tesselation : http://jsorel.ftp-developpez.com/projetun/tessellationL.png xna mesh parseur working pretty well ^^
20130630 19:30:13 <void256> 1.736 ms (old)
20130630 19:30:13 <void256> 0.617 ms (batched)
20130630 19:30:15 <void256> 0.642 ms (batched core profile)
20130630 19:30:59 <void256> that were my values from the presentation (from my mac pro - using the standard controls demo)
20130630 19:31:17 <xranby> the default 1.3 renderer fps : 60 (6.024 ms) the 1.3 batch renderer fps : 60 (2.85332 ms) and the core renderer fps : 60 (3.07664 ms)
20130630 19:31:25 <void256> even better :D
20130630 19:31:48 <void256> not really better
20130630 19:31:51 <Eclesia> bye all ++
20130630 19:31:57 <xranby> Eclesia: nice tesselation
20130630 19:32:21 <void256> Eclesia: indeed! O_O
20130630 19:32:26 <xranby> Eclesia: we can switch native resolution in fullscreen sure
20130630 19:32:36 <void256> Eclesia: where did you get that mass effect model? =)
20130630 19:32:38 <Eclesia> flat one, but at least now I understand how it works
20130630 19:33:21 <Eclesia> there are plenty of models you can find, search for XNA/XPS/MESH format
20130630 19:33:34 <xranby> Eclesia: sgothel recently merged in the multimonitor support and we have junit tests in the jogl src tree
20130630 19:34:19 <xranby> http://jogamp.org/files/screenshots/newt-mmonitor/html/
20130630 19:34:38 <void256> Eclesia: nice ... that is garrus vakarian http://masseffect.wikia.com/wiki/Garrus_Vakarian ;)
20130630 19:34:43 <xranby> http://forum.jogamp.org/Re-Our-Road-to-2-0-2-NEWT-Multi-Monitor-Support-td4029101.html
20130630 19:34:49 <Eclesia> hm, might be interesting for control rooms
20130630 19:36:05 <Eclesia> pfff. to much things we COULD do, but not enough time to do all of them :D
20130630 19:36:27 <Eclesia> bye ++
20130630 19:36:31 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20130630 19:37:49 <xranby> void256: my machine may not be the fastest around..
20130630 19:38:07 <xranby> i will probably have a faster to demo at siggraph
20130630 19:38:23 <void256> well, 3 ms doesn't sound that much but with 16 ms for 60 fps it's quite a lot ... and now that's available for the other game/graphics code besides Nifty :)
20130630 19:38:43 <void256> (would be a nice point for the presentation I mean ^^)
20130630 19:39:11 <xranby> indeed especially since we now move towards 120 fps for stereo view setups
20130630 19:39:21 <void256> yes, I hope that your faster machine still gets some improvement using the batched renderer - or the whole thing would be pointless xD
20130630 19:39:53 <void256> but I'm confident that you would see *some* improvement on any machine
20130630 19:40:21 <xranby> the core renderer surely moves the code-base closer for mobile ES 2 consumption
20130630 19:40:23 <void256> that the core profile batched renderer is a bit slower bugs me now a bit tho =)
20130630 19:40:38 <xranby> or ES 3 for sure
20130630 19:43:48 <void256> it shouldn't really be that difficult I think
20130630 19:44:15 <void256> one would need to copy the core profile batched renderer backend and modify it to use the ES2 Profile version of JOGL, right?
20130630 19:44:30 <xranby> GL2ES2 profile is the sweet spot
20130630 19:44:44 <xranby> it will then work on both opengl 2 and es 2 drivers
20130630 19:44:52 <void256> even better
20130630 19:44:54 <void256> :D
20130630 19:45:07 <void256> is there something else?
20130630 19:45:21 <xranby> add a small header on top of shaders
20130630 19:45:31 <xranby> that define opengl es float precision
20130630 19:45:45 <xranby> required on mobile
20130630 19:45:49 <void256> "#ifdef GL_ES\n" +
20130630 19:45:51 <void256> "precision highp float;\n" +
20130630 19:45:52 <void256> "#endif\n" +
20130630 19:46:08 <xranby> yes like that
20130630 19:46:09 <void256> I've played with ES on WebGL before :)
20130630 19:46:38 <xranby> same for int
20130630 19:46:43 <xranby> if in use
20130630 19:47:10 <xranby> mediump is faster on most mobile hardware
20130630 19:47:48 <xranby> but highp is safer
20130630 19:47:57 <xranby> especially for use by the vertex shader
20130630 19:47:59 <xranby> http://ramisantina.com/blog/2013/06/mediump-vs-highp-precision-on-embedded-gpus/
20130630 19:48:30 <void256> hmm
20130630 19:48:57 <void256> final GL gl = GLContext.getCurrentGL();
20130630 19:49:18 <void256> if I only use GL can I use ES too?
20130630 19:50:46 <void256> ah I can't
20130630 19:50:52 <xranby> depends on the caps you requested
20130630 19:50:53 <xranby> use
20130630 19:50:54 <xranby> GLCapabilities caps = new GLCapabilities(GLProfile.get(GLProfile.GL2ES2));
20130630 19:50:58 <void256> final GL gl = GLContext.getCurrentGL();
20130630 19:51:00 <void256> gl.getGL3().glPrimitiveRestartIndex(value);
20130630 19:51:43 <xranby> and inside the GLEventListener use
20130630 19:51:56 <xranby> GL2ES2 gl = drawable.getGL().getGL2ES2();
20130630 19:56:25 <void256> s/getGL3/getGL2ES2/
20130630 19:56:34 <void256> lets see how far that gets us :>
20130630 19:56:46 <xranby> find and replace is nice
20130630 19:57:23 <xranby> If we want to stay android compatible then we should switch use from GLCanvas to a NEWT GLWindow glWindow = GLWindow.create(caps);
20130630 19:57:43 <xranby> since android do not support AWT
20130630 19:58:00 <void256> I tried that but didn't understand enough of NEWT so I had issues and gave up :(
20130630 19:58:27 <xranby> after you have create the GLWindow use glWindow.setVisible(true);
20130630 19:58:34 <void256> could you change the runner thing to NEWT on your own?
20130630 19:58:51 <xranby> i think so
20130630 19:58:59 <xranby> will test
20130630 19:59:14 <void256> is there some drawback in using NEWT over AWT?
20130630 19:59:32 <xranby> only differences
20130630 19:59:46 <xranby> like input is handled by NEWT
20130630 20:00:27 <void256> so changes to JoglInputSystem too :(
20130630 20:00:37 <xranby> of course
20130630 20:01:30 <xranby> android... don't handle awt input ... and on the raspberry pi we use opengl before x11
20130630 20:01:53 <xranby> thus we have designed newt to provide input under these kind of circumstances when awt is not available
20130630 20:02:40 <xranby> the input system is similar to the awt inputsystem with some differences
20130630 20:02:49 <xranby> like we dont provide typed events
20130630 20:02:53 <xranby> for keyboard
20130630 20:03:14 <xranby> to reduce the amount of events the application needs to handle
20130630 20:03:30 <xranby> n-axis scroll wheel support
20130630 20:03:40 <xranby> for mouse
20130630 20:04:03 <xranby> think android touch gestures
20130630 20:07:21 <void256> ok, there are no VAO on ES2
20130630 20:07:31 <void256> but I think I can work around that
20130630 20:37:26 * hharrison (~chatzilla@anon) has joined #jogamp
20130630 20:37:53 <xranby> void256: I have a NEWT running now.. with mouse input.. using the core renderer fps : 60 (2.14008 ms)
20130630 20:40:58 <xranby> void256: https://github.com/xranby/nifty-gui/commit/ca9e68c096ff6a5074095b9603bc590a6850c2ba
20130630 20:41:06 <xranby> void256: you can try my 1.3 branch
20130630 20:41:26 <xranby> and check if the core renderer is any faster now
20130630 20:45:18 <xranby> hmm i have missed some cleanup step
20130630 20:45:21 <xranby> at shutdown
20130630 20:51:00 <xranby> ok added System.exit(0) at window dispose
20130630 20:51:21 <xranby> void256: using NEWT its about 1ms faster each frame!
20130630 20:52:19 <xranby> https://github.com/xranby/nifty-gui/commits/1.3
20130630 20:55:54 <void256> :D
20130630 21:06:06 <void256> I can confirm it works on mac as well :)
20130630 21:06:14 <xranby> cool!
20130630 21:06:25 <xranby> it say NEWT Window ... etc on top?
20130630 21:06:52 <void256> yep
20130630 21:07:37 <xranby> awesome.. then we only need to get the GL3 core -> GL2ES2 port to have it running on ARM Linux
20130630 21:07:56 <void256> yes - nearly done
20130630 21:08:28 <void256> I mean ... I am nearly done with the GL3 core -> GL2ES2 step
20130630 21:08:31 <void256> :>
20130630 21:13:56 <xranby> kudos :)
20130630 21:14:01 <void256> not yet
20130630 21:14:08 <void256> it complains about the shaders
20130630 21:14:24 <void256> just need to make them es compatible :>
20130630 21:14:39 <void256> hmm
20130630 21:15:08 <void256> can I run es shaders using GL3 or would two different shaders be best?
20130630 21:15:32 <xranby> i would like to consult sgothel here.. but he is not around :/
20130630 21:15:43 <void256> I simply use two different resources
20130630 21:15:54 <void256> would be the best I think
20130630 21:38:59 <void256> ladies and gentlemen
20130630 21:39:03 <void256> looks like it works ;)
20130630 21:39:37 <void256> now someone needs to test that on an actual es device =D
20130630 21:40:01 <xranby> void256: amazing.. have you merged my newt changes?
20130630 21:40:31 <void256> yes, I've pulled them but not yet pushed them
20130630 21:40:37 <void256> will do so in a moment
20130630 21:40:49 <void256> I've added a new parameter "es2" to the demo to enter es2 mode
20130630 21:41:29 <void256> or is there a way to detect with what profile I actually run?
20130630 21:41:37 <void256> when I use GL2ES2 profile?
20130630 21:42:02 <void256> basically I only need to know that to select which shader code to use >_<
20130630 21:42:24 <void256> but I guess you would be fine with the "es2" command line parameter ;)
20130630 21:42:32 <void256> so I'll commit that now
20130630 21:43:52 <rmk0> void256: can call 'isGLES2()' on the GL interface you're using
20130630 21:44:08 <void256> O_O
20130630 21:44:10 <void256> nice
20130630 21:44:17 <void256> will try that now
20130630 21:47:10 <void256> doesn't seem to work
20130630 21:47:21 <void256> when I use GLProfile.get(GLProfile.GL2ES2)
20130630 21:47:42 <void256> if (gl.isGLES2()) returns false it seems
20130630 21:47:47 <void256> which doesn't help me
20130630 21:47:56 <rmk0> isGLES2Compatible(), perhaps
20130630 21:48:03 <void256> no wait
20130630 21:48:15 <rmk0> since you're asking if you've got something that works like ES2, as opposed to really being a pure ES2 implementation
20130630 21:49:09 <void256> nope that is false as well
20130630 21:49:16 <rmk0> ...
20130630 21:49:59 <rmk0> ... weren't you actually expecting it to be false?
20130630 21:50:41 <void256> yep
20130630 21:50:45 <void256> the thing is
20130630 21:51:05 <void256> when it is false it is using the GL3 shader code
20130630 21:51:30 <void256> which - at least on mac - it seems not to work when running GL2ES2 profile
20130630 21:51:40 <void256> it complains that my shader code is not known
20130630 21:51:47 <void256> since it is using #version 150
20130630 21:52:05 <rmk0> sounds like you're getting the GL 2.1 "legacy" profile on OS X
20130630 21:52:19 <void256> actually thats true
20130630 21:52:22 <void256> GL2ES2
20130630 21:52:44 <void256> ah, it doesn't matter
20130630 21:52:55 <void256> I add a "es2" option to the demo to force it
20130630 21:53:02 <void256> and the default "core" mode uses GL3
20130630 21:53:12 * rmk0 tries to stamp out 2.1
20130630 21:54:20 <xranby> rmk0: hehe.. ES 3 and hence GL3ES3 will set you free
20130630 21:54:59 <xranby> in the future that is
20130630 21:57:02 <void256> xranby: https://github.com/void256/nifty-gui/commit/d95de8b7e4893fd820740197c1e2f5ddaf374f56
20130630 21:57:07 <void256> there you go :)
20130630 21:57:15 <xranby> \o/
20130630 21:57:30 <void256> besides "core" and "batch" there is a new option "es2" now for the examples
20130630 21:57:50 <void256> if (Mode.ES2.equals(mode)) {
20130630 21:57:51 <void256> return GLProfile.get(GLProfile.GL2ES2);
20130630 21:57:53 <void256> }
20130630 21:57:58 <void256> which will run with GLProfile.GL2ES2
20130630 21:58:43 <void256> if I use "es2" on mac it will crash because it will still use the GL3 shader code unfortunately but I think on a real ES2 profile device it should use the es2 shader and will be fine (hopefully)
20130630 21:59:02 <void256> "core" will use GLProfile.GL3
20130630 22:02:24 <rmk0> void256: you are aware that GL2ES2 means the common subset of 2.1 and ES2, yes?
20130630 22:02:29 <rmk0> that's why OS X is giving you 2.1
20130630 22:02:38 <rmk0> you can specifically ask for ES2 with the GLES2 profile
20130630 22:03:12 <rmk0> would probably personally ask for GL3 or GLES2, and try to avoid 2.1 contexts
20130630 22:03:22 <rmk0> GL3 core, that is
20130630 22:03:55 <xranby> i am running the maven3 setup git clone and mvn install script on my ac100
20130630 22:05:36 <void256> rmk0: I am kinda aware of that ... but the javadoc for GL2ES2 says: "Interface containing the common subset of GL3, GL2 and GLES2.". Asking specifically for ES2 would be better but would require me to copy/paste a lot of code which otherwise would be the same when using GL2ES2?
20130630 22:05:36 <xranby> https://gist.github.com/xranby/e09daa4997cdd19b474e
20130630 22:05:52 <void256> xranby: aaaand? O_O :D
20130630 22:06:01 <void256> xranby: does it work? :)
20130630 22:06:04 <void256> xranby: does it work? :)
20130630 22:06:05 <void256> xranby: does it work? :)
20130630 22:06:05 <xranby> ... building...
20130630 22:06:07 <void256> xranby: does it work? :)
20130630 22:06:08 <void256> xranby: does it work? :)
20130630 22:06:09 <xranby> compiilng
20130630 22:06:10 <void256> :>
20130630 22:06:34 <void256> crashing?
20130630 22:06:36 <void256> :>
20130630 22:06:38 * xranby hold thumbs maven will not eat up all remaining disk space
20130630 22:07:07 <xranby> running tests
20130630 22:07:15 * void256 holds breath
20130630 22:08:02 <xranby> processing lwjgl nifty setup...
20130630 22:08:07 <void256> o_O
20130630 22:08:09 <xranby> building jogö2
20130630 22:08:18 <void256> lwjgl?
20130630 22:08:21 <void256> wtf? =)
20130630 22:08:28 <xranby> mvn install
20130630 22:08:31 <xranby> does it all
20130630 22:08:33 <void256> ah ^^
20130630 22:08:34 <void256> right
20130630 22:08:45 <rmk0> void256: what i meant was, if GL3 is supported, ask for a context using the GL3 core profile. if ES2 is supported, ask for ES2 using the GLES2 profile. you can "cast" either of the resulting profiles to GL2ES2
20130630 22:09:22 <rmk0> if you open a context using the GLES2 profile, you may get different results than if you'd opened it with GL2ES2
20130630 22:10:40 <void256> oh, I see
20130630 22:10:53 <void256> thanks for the clarification! that makes sense :)
20130630 22:11:18 <void256> and you are right if I ask for GL2ES2 I get
20130630 22:11:20 <void256> opengl version: 2.1 ATI-1.8.18
20130630 22:11:24 <xranby> building jogl examples...
20130630 22:11:24 <void256> on mac :/
20130630 22:11:33 * void256 hold breath again
20130630 22:11:39 <void256> *holds
20130630 22:13:11 <xranby> aaand !!! i have visuals :D
20130630 22:13:17 <void256> OMFG
20130630 22:13:36 <void256> \o/
20130630 22:14:06 <xranby> amazing
20130630 22:14:11 <xranby> preparign scrfennshots
20130630 22:14:27 <void256> :D
20130630 22:14:47 <void256> tweet them mentioning @niftygui ^^
20130630 22:14:49 <void256> rmk0: how do I do that? :) I mean how do I check if GL3 is supported to decide on the profile? I only know the GLContext.getCurrentGL().isGL3() way?
20130630 22:15:12 <void256> rmk0: which I can only use AFTER I request a profile or am I missing something?
20130630 22:15:55 <rmk0> how are you initializing things at the moment?
20130630 22:17:24 <rmk0> i mean... presumably you select a profile and then later on, something calls your GLEventListener
20130630 22:17:42 <void256> rmk0: https://github.com/void256/nifty-gui/blob/1.4/nifty-examples-jogl/src/main/java/de/lessvoid/nifty/examples/jogl/JOGLNiftyRunner.java
20130630 22:17:46 * rmk0 eyes it
20130630 22:18:02 <void256> WAIT
20130630 22:18:06 <void256> thats the wrong link
20130630 22:18:19 <void256> rmk0: please use this one https://github.com/void256/nifty-gui/blob/1.3/nifty-examples-jogl/src/main/java/de/lessvoid/nifty/examples/jogl/JOGLNiftyRunner.java
20130630 22:18:22 <void256> :)
20130630 22:18:38 * rmk0 eyes it instead
20130630 22:18:54 <void256> xD
20130630 22:19:32 <rmk0> oh... getProfile
20130630 22:20:09 <rmk0> can call... GLProfile.isAvailable(GLProfile.GL3), for example
20130630 22:20:18 <xranby> http://labb.zafena.se/jogamp/niftygui/nifty-gui-ControlsDemoJOGL-GL2ES2-ac100-tegra2.jpg
20130630 22:20:28 <xranby> http://labb.zafena.se/jogamp/niftygui/nifty-gui-1.2-tutorial-GL2ES2-ac100-tegra2.jpg
20130630 22:21:03 <void256> NICE
20130630 22:21:05 <void256> :D
20130630 22:21:05 <xranby> the rover is watching
20130630 22:21:12 <void256> and nice car ^^
20130630 22:21:23 <xranby> under construction
20130630 22:21:59 <xranby> void256: hey! you made it! awesome
20130630 22:22:06 <void256> rmk0: thanks :)
20130630 22:22:17 <void256> xranby: nah, you did the newt stuff :)
20130630 22:22:25 <void256> but great that it works :D
20130630 22:22:57 <xranby> void256: next step is to test it on hmm.. a nokia n9 phone :D
20130630 22:23:05 <void256> (and that sven and you don't have to bug me about it anymore ^^)
20130630 22:23:12 <void256> nice xD
20130630 22:23:32 <xranby> i only have to figure out what to extract out from maven
20130630 22:23:47 <void256> extract out?
20130630 22:23:58 <xranby> i suppose there is a target directory with jars that I may copy to the phone
20130630 22:24:20 <xranby> as long as i can run java -cp ... on the phone i am set
20130630 22:25:03 <void256> ah, right
20130630 22:25:08 <void256> maven can tell you
20130630 22:25:18 <void256> if only I can remember how to do that ... hmm
20130630 22:27:09 <void256> mvn dependency:build-classpath
20130630 22:27:47 <void256> should give you a Dependencies classpath: string ... a very long string ;)
20130630 22:29:57 <xranby> its running at 26fps on this macine
20130630 22:30:42 <xranby> thus.. if we can get it to run on a tegra3 it may be faster etc
20130630 22:31:03 <xranby> on the screen with the bubbles
20130630 22:31:19 <void256> would be interesting to further analyze where the time is spent
20130630 22:31:24 <void256> using some opengl profiler
20130630 22:32:17 <xranby> i have to find a good one for use on es devices
20130630 22:33:27 <void256> I only know the apple tools :/
20130630 22:33:49 <void256> well, it basically still needs to send the vertices to the GPU each frame
20130630 22:33:52 <xranby> its possible that ARM or Imaginative Tech got some good tools
20130630 22:33:54 <void256> I guess this might kill it
20130630 22:34:10 <xranby> if tested on their GPU's
20130630 22:34:26 <xranby> right now i am on a NVidia tegra 2
20130630 22:35:08 <void256> is that tile based eventually?
20130630 22:35:38 <void256> many ES2 hardware is tile based
20130630 22:37:27 <xranby> i dont knwo..
20130630 22:37:32 * xranby preparing next test
20130630 22:37:41 <void256> well, I have to go
20130630 22:37:51 <xranby> void256: good teamwork!
20130630 22:38:03 <void256> xranby: kudos!
20130630 22:38:25 <xranby> void256: i posted on twitter yes
20130630 22:38:34 <void256> I already retweetet ^^
20130630 22:38:44 <void256> thanks
20130630 22:48:54 * void256 (~void@anon) Quit (Remote host closed the connection)
20130630 23:05:58 * hharrison (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130621124006])
20130630 23:22:03 * xranby (~familjen@anon) Quit (Ping timeout: 268 seconds)
20130630 23:44:35 * [Mike] (~Mike]@anon) has joined #jogamp
20130701 05:05:39 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20130701050539.html