Version 3.1.9

William Bittle // Mar 29, 2014 6:39:14 PM

This release of dyn4j includes some major bug fixes for the SweepLine class and other related convex decomposition classes.  It also includes some enhancements to the World.detect methods.  See the change detail in the release notes.

A new release of the Sandbox was published for this release for a small bug fix.




[RELEASE] JogAmp 2.1.4 & JiGong at FOSDEM 2014

xerxes // Feb 1, 2014 2:30:16 PM

The JogAmp community held a Ji Gong freedom talk that reminded people to exercise the 4 freedoms granted by the free software licenses in front of the free java developer room audience. The talk also proposed and showcased technical enhancements for High Availability JVM Technology on All Platforms.
Slides from the Ji Gong talk can be obtained at: https://jogamp.org/doc/fosdem2014/

During the same week JogAmp released version 2.1.4 of its high performance java opengl audio & media processing librarys.
This release includes some new highlights:
* Android OpenCL test apk's. This enable you to compile and test an OpenCL JOCL application on desktop and then deploy on Android without using any OpenCL SDK for the phone, the JOCL binding will locate and bind the OpenCL drivers at runtime.
* Enable use of custom mouse pointers and window icons using the NEWT window and input toolkit.
* Multi window support on the Raspberry Pi including mouse-pointer use directly from console!
Complete list of bugs resolved for this 2.1.4 release can be found at:
https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.1.4

JiGong-Panorama-extracted-from-video Panorama-of-JiGong-JogAmp-talk-audience-at-FOSDEM-2014-Free-Java-Devroom 14020010 14020025 14020026 14020034 14020069 JamVM-OpenJDK8-FOSDEM-2014-panorama 14020032 14020027


Version 3.1.8

William Bittle // Dec 23, 2013 3:31:24 PM

This release of dyn4j is a maintenance release to fix a bug in the Vector2.distance(double,double) method.  It also had a few methods added to the Body class to get BodyFixture(s) at a given world space point.  See the change detail in the release notes.

A new release of the Sandbox was published for this release due to changes in WebStart security and an API change by JOGL.




The #JogAmp #JiGong project will package @OpenJDK + #IcedTea-web to enable good deployment on mobile phone platforms.

xerxes // Aug 6, 2013 8:56:07 AM


Ji Gong project announcement




Project: Ji Gong

xerxes // Aug 4, 2013 10:41:28 PM

JogAmp Ji Gong project announcement

"Ji Gong shall enable the VM technology across platform and devices."

Sven Gothel Aug 04, 2013; 9:45am "
Bug 790 <https://jogamp.org/bugzilla/show_bug.cgi?id=790>
Bug 698 <https://jogamp.org/bugzilla/show_bug.cgi?id=698>

+++

Current Ji Gong Dependency
including the OpenJDK API subset, etc:
<https://jogamp.org/bugzilla/showdependencytree.cgi?id=790&hide_resolved=1>

+++

1st Milestone - Core JRT for all platforms ..

<https://jogamp.org/bugzilla/show_bug.cgi?id=791>
<https://jogamp.org/bugzilla/show_bug.cgi?id=792>

Calling for volunteers.

We are looking for sponsors!

+++

Preface

========

OpenJDK and its chair decided not to go mobile?

Bug 698 was written due to the "Fear, uncertainty and doubt" (FUD)
strategy of Oracle of not giving express permission to use OpenJDK
in compliance w/ the 4 freedoms of software (FSF definition).

On the contrary, Oracle gives a patent grant for using OpenJDK for desktop only,
implying mobile use may be prohibited.

This implication is highly likely non-sense, especially in the light of
the latest Oracle vs Google case where Oracle was not able to
substantiate a patent infringement by Google's Dalvik VM.

However .. the current situation lacks of:
- OpenJDK builds for Windows, OSX, Android, ..
- IcedTea-Web builds for Windows, OSX, Android, ..

As Xerxes put it: The horse is bound to a chair and is not running ..

Project Name

============
Ji Gong <https://en.wikipedia.org/wiki/Ji_Gong>
"Unlike a traditional Buddhist monk, Daoji did not like following traditional monastic codes. Daoji had a penchant for openly eating meat and drinking wine; his robes were often tattered and dirty from travelling from place to place, and stumbling while intoxicated. However, Daoji was kind hearted and was always ready to lend a helping hand to ordinary people. He would often treat the sick and fight against injustice. The monks, bewildered and fed up with his behavior, expelled Daoji from the monastery. From then on, Daoji roamed the streets and helped people whenever he could."

Hence Daoji does people good while not necessarily conforming to certain arbitrary rules,
while maintaining sanity and being kind hearted.

The character is quite popular in the Asian culture.

Project Spirit

==============

This project shall match the kind direction of it's name giving character,
while also serving w/ JogAmp's goals of being a technology enabler.

Ji Gong shall enable the VM technology across platform and devices.

This project must not necessarily being maintained by the JogAmp community.
On the contrary .. we would prefer this effort to be done from the original authors,
i.e. OpenJDK and IcedTea-Web.

However, until the goals below and this spirit of a free solution is being picked
up, we may continue pushing it forward from here.

Note: Bug 698 sadly wasn't being replied to by neither Oracle nor the OpenJDK team.
Of course, no surprise here, since for Oracle it might be a conflict of interest
due to their 'goals' to market their ARM hotspot proprietary solution
and the OpenJDK team consist mainly of Oracle and RedHat members.
The latter focuses on server solutions and is highly cooperating w/ Oracle.

Project Goal

============

- Availability of the GPLv2 based OpenJDK runtime environment (JRT/JVM)
- Desktop (Linux, Windows, OSX, ..)
- Mobile (Android, other phones and tablet OS [maybe even iOS])
- VM CPU support:
- Intel/AMD 32bit and 64bit
- ARM based CPUs [Hotspot client/server n/a at time of writing. May need to use JamVM or AvianVM, ..]

- Optional AWT/Swing/etc - maybe added at a later time

- Web Plugin based on IcedTea-Web (JWeb)
- Capable to run w/o AWT using a pluggable windowing subsystem implementation
- Optional AWT/Swing/etc - maybe added at a later time

+++
" Quoted from:

JogAmp forum: Project: Ji Gong http://forum.jogamp.org/Project-Ji-Gong-td4029738.html




[RELEASE] JogAmp 2.0.2; JOGL 10y celebration & SIGGRAPH 2013 BOF

xerxes // Aug 4, 2013 1:09:42 AM

JogAmp JOGL, JOCL & JOAL provide cross platform Java™ language bindings to the OpenGL®, OpenCL™, OpenAL and OpenMAX APIs. JogAmp is a convenient enabler to give Desktop and Mobile applications access to hardware DSP & GPU units using a modular cross platform API.

Release announcement for JogAmp 2.0.2

This JogAmp JOGL version 2.0.2 release marks the end of the first major JogAmp release cycle that started with the v2.0-rc1 around two and a half years ago, "End of RCs ..". JogAmp JOGL is a modern successor to the no longer maintained JOGL 1.1.1a. The 2.0.2 release added support for OpenGL versions up to 4.3, and OpenGL ES versions 1, 2, and 3.


Get in touch if you want to setup your own local JogAmp JOGL, JOAL and GlueGen source-code 10 year anniversary party. The JogAmp team is ready and here to save you!

The JogAmp team hosted one, awesome, party at the JogAmp BOF @ Siggraph 2013!

This years SIGGRAPH JogAmp BOF was dedicated to all the many amazing projects using JogAmp. We did try our best to demo as many projects as possible that we where able to fit into our session. One dude (MIT researcher) put it well, it was like "drinking from a fire-hose"; enjoy the demo flood!
Kudos to Qun who recorded the show! Here is a convenient time line to the many sections and topics covered during the talk:

00:02:00 Welcome to the JogAmp BOF
JogAmp Fast Media & Processing Across devices – Desktop & Mobile SIGGRAPH 2013 – Anaheim July 24, 2013
Presented by: Alan Sambol, Harvey Harrison, Rami Santina, Sven Gothel, Wade Walker, Xerxes Ranby, Dominik Ströhlein, Erik Brayet, Jens Hohmuth, Julien Gouesse, Mark Raynsford & Qun
00:02:46 10 Years
2003-06-06 to 2013-07-17

- LEGACY -

00:04:15 GLG2D
"GLG2D OpenGL accelerated Graphics2D
GLG2D is a Graphics2D implementation that uses OpenGL to implement basic Java2D drawing functionality."
00:05:07 Java3D
"I'm not Dead!" Java3D is back! Demo of: Vzome, SweetHome3d &
XTour
00:10:40 Jake2
Port of id Software's Quake II to Java by bytonic software.
JOGL enables Jake2 to run on mobile ES2 and desktop GL2. Demo: NApplet

- GAMES -

00:12:51 libGDX
"Desktop/Android/iOS/HTML5 Java game development framework" The JogAmp JOGL libgdx backend add support to libGDX for, Raspberry Pi, desktop and mobile using one single libgdx backend. The JOGL backend, a team effort of the JogAmp community
00:16:46 jMonkeyEngine
"Modern Java 3D" Currently Julien Gouesse develops a JOGL backend for jME3 with support of the jME team
00:17:40 Catequesis
"Catequesis is a survival horror game based on 90's RPGs gameplay, with a really strong and immersive story & a 8 bit graphic style. This game will be released for Android, PC, Mac & Linux." Monsieur Max is documenting the technology behind the Catequesis game at his tech inside blog.
00:18:55 Ticket to Ride
DoW's classic game designed by: Alan R. Moon now available on google play and steam; during the BOF we also showcased the game running on GNU/Linux.

- UI -

00:20:54 nifty-gui
Demonstration of Nifty Gui running unmodified on both desktop OpenGL and mobile OpenGL ES using the new JOGL GL2ES2 port
00:25:29 Graph API
Graph is a JogAmp JOGL implementation of Rami Santinas GPU based Resolution Independent Curve Rendering
00:26:58 MyHMI
"MyHMI is a Java based object oriented software framework for industrial graphical user interfaces development."

- Art / Science -

00:34:49 Kohlenstoffeinheiten
The winning 4k demo from Revision 2013 made by Akronyme Analogiker / DemoscenePassivist
00:36:39 jSpatial
The jspatial package implements a set of spatial data structures.
00:37:50 GeoGebra
Dynamic mathematics & science for learning and teaching
00:41:03 jReality
"jReality: a Java library for real-time interactive 3D graphics and audio
jReality is a Java based, open-source, full-featured 3D scene graph package designed for 3D visualization and specialized in mathematical visualization."
00:42:23 BioJava
The goal of the BioJava project is to facilitate rapid application development for bioinformatics.
00:43:28 WorldWind
NASA World Wind SDK for Java. With this, developers can embed World Wind technology in their own applications.
00:44:51 Processing
Processing 2.0 PShader tutorial: http://processing.org/tutorials/pshader/
00:47:32 JaamSim
https://github.com/AusencoSimulation/JaamSim includes a Collada loader
00:51:05 C3D
"C3D Studio - Visual 5D Framework
C3D Studio is a 3D based visual framework for developing visual project control solutions for construction projects." Slides: http://jogamp.org/doc/siggraph2013/bof/jogamp-siggraph2013-bof-c3d.pdf

- JogAmp -

00:57:09 JOCL

00:58:48 JOAL

01:01:27 GLMediaPlayer

01:03:50 JOGL / GLProfiles

01:05:18 JOGL / NEWT

01:08:55 JogAmp Platform Agnostic

01:09:55 JogAmp Deployment / Maven

- Finale -

01:10:48 Thank You / Q & A

01:19:46 End Sequence

Slides from the BOF is available at the jogamp.org site: http://jogamp.org/doc/siggraph2013

Thank you all for taking part into the realisation and use of JogAmp, the platform independent API, for GPU and DSP access across devices!

Cheers and have a great day!




[SECURITY] JogAmp 2.0.2-rc12 JOGL JOAL JOCL & Gluegen Released!

xerxes // Jun 27, 2013 5:51:01 PM

JogAmp is the home of high performance Java™ libraries for 3D Graphics, Multimedia and Processing.
JOGL, JOCL and JOAL provide cross platform Java™ language bindings to the OpenGL®, OpenCL™, OpenAL and OpenMAX APIs.
Running on Android, Linux, Window, OSX, and Solaris across devices using Java.

Release announcement for JogAmp 2.0.2-rc12

"You're encouraged to stop using the now-ancient 2.0-rc11!"

This 2.0.2-rc12 release include the largest security review in the 10-year history of JOGL

  • Security Fixes

    • Dynamic Linker Usage / Impl.
    • ProcAddressTable field visibility
    • Perform SecurityManager checks where required
    • Validation of property access
    • JAR Manifest tags:
      • Codebase
      • Permissions
      • Sealed
    • Use latest Java7 toolchain
      • Generating Java 1.6 bytecode
      • HTML API doc

https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.0.2_of_JOGL
Security fixes are marked in red on the above bug tracking page.
JogAmp send out thanks to the FuzzMyApp security researchers for healthy communication that triggered the security review work.

If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place inside the JogAmp forum & mailing-list and the #jogamp IRC channel on irc.freenode.net.


Meet us @

JogAmp @ SIGGRAPH 2013



mediump vs highp precision on Embedded GPUs

Rami // Jun 12, 2013 6:55:24 PM

There are a lot of  tests on GPU performance, in terms of how many operations per sec (rendering, float arithmetic, etc..), but not a lot on quality and precision. Most would argue that such a benchmark is not very relevant, well that is true in general cases but not all (actually its like having 5k resolution on a 4 inch device; but that is another story). In this post I am discussing the “special” cases where it does matter, focusing on mediump vs highp in fragment programs as well as vertex programs.

Since OpenGL ES specs loosely define the float precision requirements and leaves to the vendors the freedom of implementing it,  resulting in having no two devices with same precision. To most applications this is not an issue, but dealing with large CAD data-sets and requiring consistent behavior on all devices such inconsistency becomes an issue especially that this relates directly to the performance.

Testing our application with a Nexus 10 device, that includes the new Mali-T604, encountered a weird bad quality of rendering (second image below). Weird since I had very high hopes for this new device, and the same impl is giving very good quality on its predecessor Mali-400 and on Tegra 3.  Searching/experimenting to find hints to this issue, I came across a blog post by Stuart Russell which compares different devices regarding float precision; and a very informative post by Tom Olson describing the float precision on Mali-T604 and why it’s different (which gave the hint/answer to my problem) .

Problem: used to depend on mediump precision on all devices since highp was not available on some of the devices I tested; and since it is not performing well on others even if it says they do.  After reading those posts decided to do a similar benchmark but on mediump with the available devices at hand . The shaders are similar to the ones described in the referenced posts, with one modification: color is passed from vertex shader to get an idea on the precision in vertex shaders as well.

Results:


Turns out that on Mali-400 MP, Tegra-3, and Adreno 320 the mediump precision is higher than what you expect: (which is 210) and is lower using Mali-T604 especially at the vertex shader. Thus getting a new inconsistency in the data passed from vertex to fragment; which is another reason for the variations shown in the benchmarks.

This inconsistency removes the idea that highp is not really needed on embedded device. And brings another problem on the table, why should we force the highp path in a case that is not needed or in a case where the precision diff is not much (based on the user data). But how can we tell, with no way of querying this precision. If an implementation does declare highp but with insignificant diff with mediump, it would be nice to be able to decide what to choose to enhance performance.

Discussion: The snapshots below show that  highp (vertex shader) had no visible effect on Mali-400MP (as well as tegra-2, tegra-3, adreno 320..),  but on Mali-T604 it had a major effect (from corrupted scene to a very accurate rendering) .  But which implementation is better, cant really tell. But based on specs, both are correct!

Solution: not optimal, but gives correct and “consistent” results

Knowing that my input data is variable (so need for highp or mediump is based on the model), moved to using highp in the cases where it is supported in the fragment language; with the consequence of  having un-profitable computations on devices that declare highp but without giving highp.

Finally, since the main variation is found between devices that implement highp in fragment vs those who do not, found the below declaration a compatible way to have “just enough” precision. Thus on mali-400 and tegra-3 we will continue to use mediump as for Mali-T604 it will use highp in the vertex shaders.

//declared in vertex shader

#ifndef GL_FRAGMENT_PRECISION_HIGH
precision mediump float;
precision mediump int;
#else
precision highp float;
precision highp int;
#endif

Results:

mediump on Samsung Galaxy S2 with Mali-400 MP

mediump on Samsung Nexus 10 with Mali-T604

mediump on Samsung Nexus 10 with Mali-T604

highp on Samsung Nexus 10 with Mali-400 MP

highp on Samsung Galaxy S2 with Mali-400 MP

highp on Samsung Nexus 10 with Mali-T604

highp on Samsung Nexus 10 with Mali-T604




Call for Compliance of Java(tm) Technology with the 4 Freedoms of Software

Sven // Mar 7, 2013 3:31:49 PM

While being asked about JavaFX and whatever other Oracle, Google or
whatever technology, all I can say: I don’t really care – as long it’s free
and complies w/ the 4 freedoms of software.

Lately Oracle even made the proposal JEP 178: Statically-Linked JNI Libraries,
allowing Java applications using JNI within a statically deployed runtime. Read: May work on Apple’s iOS.

IMHO the real issue of being able to deploy ‘Java Tech’ on any platform including mobile/embedded devices is not whether Oracle allows static JNI linkage,
but to allow deploying a custom JRE in the first place.
It is Oracle herself who restricts her patent grant to non embedded devices, hence ‘Java Tech’ does not comply w/ the 4 freedoms of software, see:

Call for Compliance of Java Technology with the 4 Freedoms of Software

IMHO the most advancement Oracle could make to ‘Java Tech’ would be
a general patent and license grant, so you actually would be able to
legally use and deploy your Java’ish builds anywhere and be free
without the hassles and fears of a multimillion dollar battle.
Let it be a build based on OpenJDK, Apache Harmony, DalvikVM .. or whatever :)

Just my 2 cents ..

[Java is a registered trademark of Oracle, Incl.]




Valentine news update, v3 is the new <3, #OpenGL ES 2/3 drivers and #OpenCL #ARM special

xerxes // Feb 14, 2013 1:07:29 PM

OpenGL ES 2 drivers

Excellent post by cnx-software listing all the reverse engineering effort put into bringing opensource ARM GPU drivers to GNU/Linux.
http://www.cnx-software.com/2013/02/14/open-arm-gpu-drivers-fosdem-2013-video-and-call-to-arm-management/
The post links and embeds libv's excellent FOSDEM 2013 reverse engineering ARM GPU driver talk.
The lima and freedreno reverse engineered drivers are both now known to be able to run Quake 3. The lima driver is now actually faster than the closed source ARM Mali driver!

http://libv.livejournal.com/24092.html - Hey ARM!
We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore.

It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder.

So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.

-- libv.

OpenGL ES 3 drivers

Intel have taking the lead and released all their OpenGL ES 3 driver code into Mesa
http://linux.slashdot.org/story/13/02/13/1756208/intel-supports-opengl-es-30-on-linux-before-windows
http://www.phoronix.com/scan.php?page=news_item&px=MTMwMDg

http://cgit.freedesktop.org/mesa/mesa/log/?h=gles3 - this is how you should work, kudos to Intel.

OpenCL ARM GPU drivers

Android have for a long time refused vendors to ship ARM OpenCL drivers on Google approved Android devices.
http://code.google.com/p/android/issues/detail?id=36361 - Android lead Declined Support for OpenCL
Over night everything changed:
Google ships secret #ARM #MALI T-604 #OpenCL driver in Nexus 10 to accelerate Renderscript.
http://www.youtube.com/watch?v=GrqKJehawr8
http://beyond3d.com/showthread.php?t=63071
The OpenCL SDK for ARM Mali is now available! http://bit.ly/YOS1YA #opencl #gpu @ARMMultimedia
OpenCL drivers for Samsung Exynos 5 board landed here: http://streamcomputing.eu/knowledge/sdks/samsung-exynos-5-board/
Also the Zii labs ZMS line supports CL http://codedivine.org/2013/02/01/renderscript-from-the-perspective-of-an-openclcudac-amp-programmer/
Amazon android line is rumored to support CL as well...

So with all these new news surfacing it looks like ARM devices running the new T-604 MALI GPU will have OpenCL drivers especially the Google Nexus 10 tablet that is reported to include the drivers in the stock install!
So this means we now have a good way to hardware accelerate FFT on ARM using OpenCL!
I want to use #OpenCL on #ARM to do fast live music #FFT analysis for better jazz music on the go
http://www.jazzperiments.com/jazzperiments.html

JogAmp update

JogAmp have implemented OpenCL bindings on GNU/LInux and packaged .apk for Android feel free to jump in and help with testing on real devices!
The current priority list for JogAmp OpenCL and OpenGL ES 3 integration is found inside the forum: http://forum.jogamp.org/JInput-Delivery-tp4028209p4028210.html

Cheers and have a great twitter valentine tweet day!
v3 is the new <3
Xerxes