Re: [eavp-dev] Official p2 repository for EAVP

[Jay Jay Billings <jayjaybillings@xxxxxxxxx>]

Havard,

Thanks very much for the email. I have CC'ed the EAVP dev list on this because that is really the better place for these questions to go since I probably can't answer them all.

I have answered your questions in-line below. Please let me know if you have more questions!

On Fri, Jun 3, 2016 at 4:44 AM, Håvard Heierli-Nesse <Havard.Heierli-Nesse@xxxxxxxxxxxxxxxxxx> wrote:

Hi again!


We're well on our way to use EAVP for visualization in SIMA. But... we've had a LOT of problems with resolving target platform in the last few days. We're building with Tycho, and we've used both the http://download.eclipse.org/eavp/builds/master/ and the http://download.eclipse.org/eavp/builds/next/ URLs. Seems there are only nightly builds available, which means that we'll have to regenerate our .target files on a daily basis (and even then it seems target platform gets resolved with a slightly wrong qualifier number from time to time - which may be an issue with our setup).

What is the correct (official) repo for EAVP? We're currently on 2.1.8.201606030708 (master)

You should most likely be on master. If you set the version to 0.0.0 in your target, it should get rid of some of the issues that you are having. Master is the "stable" branch of EAVP.

All branches at github.com/eclipse/eavp are official, but "master" is the most stable. All changes are merged in the "next" branch, tested and finalized, then merged into "master" every few weeks or so.

 

Going forward, it's obvious that EAVP lacks functionality that we need. The attatched picture shows a prototype for a vessel (in this case a scooter :-) ) in animated long crested waves. Currently we're using FXCanvas, and the actual 3D model (scooter, Wavefront .obj file) and the sea surface are plain JavaFX objects (TriangleMesh).

We'd like to take advantage of using a framework with the renderer actually abstracted away, so ideally we'll need something that can render shaded (and even textured) TriangleMeshes. It may be a good idea to adopt the VertexFormat in javaFX so that it's possible on an abstract level to specify whether or not you want color, texture cooridnates or normal for your vertices in the mesh. I think Robert mentioned that you haven't implemented shaded meshes yet.

The big idea behind EAVP is that renderer's should be abstracted away as much as possible. You should just be putting data on it. That being said, we have obviously only covered our own use cases, and have a lot of progress to make before we reach that vision. I would appreciate it if you could work with Robert to open some tickets on what you need from EAVP.

 

We'll probably do this abstraction for our project - either by doing our own abstraction in an EAVP context, or by actually making our own branch of EAVP and add the changes there (which will enable us to do a pull request back to the EAVP project). The last of these options may be the best one, but it'll also be the most "hassle" since I'm not really sure about your thoughts on the long term architecture of EAVP (I haven't found any documentation on this ;) ).

I would greatly prefer and welcome the latter. :-) We would love to have you contributing to the project! Getting more community involvement was the whole reason we split this off from ICE.

I am desperately behind on writing documentation on EAVP's architecture. Robert and I just started putting together the paper on it yesterday. Everything that we do is based on the rule that the squeaky gear gets the grease, so if we have clients that are pushing for an architecture doc so that they can contribute back to EAVP, we just need to know that and we will bump up the priority of that paper.

At the moment, we are focused on two things:

1.) Cleaning up the ParaView and VisIt support -  Robert has mostly finished this.

2.) Reworking the Geometry and Mesh support - We expect this to take the whole summer as it will cover both the data and view models, and add functionality for 3D mesh editing.

 

I guess the basic idea is that we should use the org.eclipse.eavp.viz.modelling bundle for modelling - to create whatever amazing stuff we want to render, and then it's passed down to the classes in the renderer spesific bundles to actually be displayed.

Yes, that is the basic idea. What we want to do is have a rich data model that describes your geometry, mesh or post-processing visualization in enough detail that nearly any back-end implementation of IVizService can handle it.

 

If we are to branch out from EAVP - which branch should we base everything on? master,next or some other branch?

If you are going do development, you should create a branch off of next. Our convention is <name>/<description>, so if you were going to work on triangle mesh support you might call your branch havard/tmesh. Please check out our "CONTRIBUTING" document for more information on how to take contributions. Also, if you decide to contribute to EAVP, I would be happy to talk to you about full committer status.

 
I'm more than happy to meet with you over a video conference to get you started on development. I'm sure we can get you pointed in the right direction!

Jay

--

Jay Jay Billings

Oak Ridge National Laboratory

Twitter Handle: @jayjaybillings