Hi Jay,
Good idea we would certainly try to use this. We have a JavaFX prototype but the scene graph is not rich enough in Java8 – does anyone know if JavaFX 3D will
be improved?
Matt
From: science-iwg-bounces@xxxxxxxxxxx [mailto:science-iwg-bounces@xxxxxxxxxxx]
On Behalf Of Jay Jay Billings
Sent: 11 March 2015 20:54
To: Science Industry Working Group
Subject: Re: [science-iwg] New visualization project idea
Thanks very much, Scott. I'll certainly look into it!
Jay
On Mar 11, 2015 1:45 PM, "Scott Lewis" <slewis@xxxxxxxxxxxxx> wrote:
FYI,
If you use OSGi Services to implement your services, then one thing of likely use to you would be the OSGi Remote Services specification/standard (chap 100 and 122 in OSGi Enterprise spec). Since before the beginning, the ECF project has provided a CT-tested
impl of this standard [1]. I participate on the EEG, which defines the RS specifications.
Using Remote Services would make it easy to distribute your services...in a standardized and open way. Other advantages for you and consumers of such services:
A) Leverage existing and new distribution systems. For example: existing or new REST APIs [2], new transports like MQTT [3], or websockets [4]. ECF Remote services would allow you to use any such alternative distribution systems *without modifying either
the service API or the implementation*
B) Flexibility to use non-Eclipse-based OSGi tech (e.g. Karaf, many others) for server implementation. Even use services exposed by non-OSGi, or even non-java servers [5].
C) All technical advantages of OSGi services (dynamics, injection, service versioning, service dependencies, separation of concerns, service-level security, etc), and for Remote Services (extensibility of discovery and distribution, standardization of remote
service meta-data, standardized management agent) for free. See [2].
If help is desired for designing or implementing such services to allow for eventual distribution please let me or other ECF committers know [6].
Scott
[1] http://wiki.eclipse.org/ECF#OSGi_Remote_Services
[2]
http://wiki.eclipse.org/Tutorial:_ECF_Remote_Services_for_Accessing_Existing_REST_Services
[3] https://github.com/ECF/Mqtt-Provider
[4] https://github.com/ECF/Websockets
[5] https://github.com/ECF/Geonames
[6] https://dev.eclipse.org/mailman/listinfo/ecf-dev
On 3/11/2015 11:44 AM, Jay Jay Billings wrote:
Thanks Philip!
One of the reasons that I developed this service based approach is that we need a common look and feel for using different visualization tools/engines more than we need standard graphics. I think it is important to promote this kind of diversity because
different communities want different graphics.
Jay
On Mar 11, 2015 10:25 AM, "Philip Wenig" <philip.wenig@xxxxxxxxxxxxxx> wrote:
Hi Jay,
I like the idea.
Having a standardized way to display 3d models in RCP would be a great step forward. Especially as I think that a rich client and/or server solution still offers benefits over a webbrowser when rendering heavy load 3d models.
Other projects/companies are maybe also interested, as we recently had a discussion with Martin Pernollet and others:
http://jzy3d.org
http://jogamp.org/jogl/www
http://www.comsol.com
Licesing issues are another problem maybe :-).
Best,
Philip
Am 11.03.2015 um 16:53 schrieb Jay Jay Billings:
I wanted to share with you a new idea for a visualization project that several of us have discussed recently that would provide visualization capabilities that meet the needs of Science, LocationTech and IoT.
I ask for your candid feedback.
Andrew and Ian, could you please forward this to the LocationTech and IoT working groups? I would like to get their feedback but I am not on their lists.
A few months back I started speaking to my staff about "spinning off" some of the visualization bundles that we have in ICE into a new project because it would make it easier for DAWNSci to use them. Actually, I think it was Matt Gerring's
idea... At any rate, I started talking about it more after I designed some service interfaces and utilities over Christmas break. Since then, Jordan Deyton has taken this further and provided a couple of implementations of these interfaces for VisIt and Paraview.
(I only did one for CSV plotting.)
To cut a long story short, Torkild and I immediately started talking about this idea of spinning these viz capabilities off at the bar on Sunday night because it might help him out. On Monday night we had a very good discussion about visualization
capabilities at the joint Science+LocationTech+IoT birds of a feather meeting. Each of the groups need good visualization capabilities and it seems that both within and across the groups we have technologies that we need/could share. For example, IoT could
use help visualizing time-series data, which both Science and LocationTech do. We had another discussion about it over dinner on Monday night and finally at lunch yesterday Tamar Cohen got us started on a discussion about 3d visualization for what I consider
to be input or model generation or "front-end" tasks as opposed to post processing. That is, things like constructive solid geometry and mesh editing. Part of this discussion focused on whether or not we can replace JME3 with a JavaFX-based alternative since
JME3 was not approved through the CQ process because of underlying contribution tracking issues with LWJGL.
I think given the awesome discussion surrounding this that we need to go ahead and put together a cross-working group 3d visualization project with initial committers from all three working groups and an initial
contribution from ORNL and any others who have something they want in there from the start. I am happy to do the leg work to write the proposal and lead the project until it is off the ground, but in the long-term I think we need to find a "viz person" to
lead it.
I suggest that we reach out to Nebula as well and determine how this project relates to their existing Visualization effort, which contains the SWT-XY-Graph bundles that most of us use. I should mention that during our discussions we discovered
that there are some issues with those bundles that are directly affecting several of our projects in Science.
Let me take a minute to describe the initial contribution that ORNL would make. We would move two pieces from ICE into this new project (assuming that is allowed by the Foundation). First, we typically use third-party
visualization tools like VisIt and Paraview, so what we have developed is essentially some OSGi and Eclipse infrastructure for dealing with "the plumbing" associated with connecting external tools and native capabilities. The idea is that given a particular
visualization tool, we just realize these interfaces and then publish it as an OSGi declarative service. At that point, the tools can be used to draw on SWT Composites anywhere in the workbench instead of in a single perspective or spot. They also publish
their preferences in the Preferences menu and Jordan has connected everything to secure persistent storage for handling passwords to remote visualization clusters.
See the attached picture of a fuel pellet mesh embedded into an Eclipse Form Editor. It was rendered with VisIt in an external process and piped back to ICE. Previously we could only do this in a dedicated "Visualization Perspective."
Second, Jordan has also started developing a JavaFX-based replacement for our JME3 geometry builder and mesh editor. This includes, as I understand it, extensions to the JavaFX scene graph to provide cameras
and other classes that are similar in function to those of JME3 and not currently available in JavaFX.
I would like to sum up this very long email by again asking for your thoughts and comments. I see this as a good and necessary step that will only be successful if we work together.
--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
--
~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Philip Wenig
http://www.openchrom.net
https://www.xing.com/profile/Philip_Wenig
http://de.linkedin.com/pub/philip-wenig/2a/4a8/877
~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
|
