JuliaGraphics group

[Robert Ennis]

Hey everyone,

Simon and I have been talking about all of the different graphics projects that have been springing up. We're thinking that it might be worthwhile to start to gather things together into an umbrella group and unify the work. We would like to propose a JuliaGraphics group that would include packages like the following:

GLUtil.jl

GLWindow.jl

GLFW.jl

SDL.jl

Processing.jl

I've also just read Kevin's post about a computational geometry package (https://groups.google.com/forum/#!topic/julia-dev/vZpZ8NBX_z8) and that would probably fit into this group as well, serving as a unifying layer for working on geometry and then visualising it. What does everyone think?

We're also planning on moving the OpenGL package over to the JuliaGPU group within the next day or two and then putting the stellar results of Simon's hard work into it.

Best,

Rob

[Stefan Karpinski]

Having an organization does seem like a good idea. It's inexplicably effective for fostering collaboration.

[Kevin Squire]

That sounds good to me!

[Robert Ennis]

Sounds great! Simon has started a JuliaGraphics group at https://www.github.com/JuliaGraphics

Looking forward to what comes out! :)

Best,

Rob

[Robert Ennis]

Also, Kevin, I'm assuming you will want access? For that matter, anyone that wants to contribute should just write in! :)

Best,

Rob

[Steve Kelly]

This sounds great! I have been working on polygon clipping (set operations) and mesh slicing. I would like to get them registered soon, and if we could integrate them into a larger ecosystem, I think that would be really helpful.

https://github.com/sjkelly/PolygonClipping.jl
https://github.com/sjkelly/MeshSlicer.jl

That said, maybe we could create a JuliaGraphics and JuliaGeometery group?

Best,
Steve

[Stefan Karpinski]

Can you guys add @JeffBezanson, @timholy and @vtjnash – I know they are all pretty invested in this area. Obviously, many others are too :-)

[Tim Holy]

Would this also include
Gtk.jl
Tk.jl
Cairo.jl
Winston.jl
Gadfly.jl
Gaston.jl
ImageView.jl
Plotly.jl
...
The list is potentially quite extensive!

--Tim

[Stefan Karpinski]

All the more reason to have these packages under an organization, imo.

[Robert Ennis]

Stefan - Jeff, Tim, and Jameson have been added. Glad to be working with all of you! :)

JuliaGraphics is admittedly a large group heading and would also include those packages, I think, Tim. We could always consider the possibility of sub-dividing it (JuliaPlotting, JuliaGeometry, JuliaWindowing, etc.), but I get the feeling that it is currently manageable and may remain manageable. Perhaps, the split that Steve has recommended (JuliaGraphics/JuliaGeometry) is a good one to start with, since it separates the considerations of computational geometry that would find application in many fields and is more mathematically "pure" from front-end visualisation, which depends more on hardware considerations and personal preference. The two do share a lot of overlap and are intimately intertwined, but I figure that the conceptual distinction is good. What do others think?

Best,

Rob

[Stefan Karpinski]

It seems to me that since these higher level plotting packages are some of the main drivers of what the geometry support needs to look like, keeping all of this in once place until that shakes out is a good idea.

[Kevin Squire]

Would we include Steve's PolygonClipping.jl and MeshSlicer.jl packages in the Graphics group, then?

[Kevin Squire]

And Meshes.jl?

[Kevin Squire]

That would be great, thanks!  @kmsquire is my github id.

Cheers!

[Iain Dunning]

IMO, the point of Julia organizations, or rather the benefit of them, is primarily discoverability, and secondarily quality.

So, again IMO, any packages included in this repository should be stable, well-supported across platforms, good tests that pass, etc.

So something new, like Processing, or with poor support for its wrapped binary, like SDL, should NOT be included. Instead, the organization website should point to them, and it should be considered a goal to move them into the organization proper.

This is the "JuliaOpt" philosophy and I think it has served us very well - your results may vary.

[Iain Dunning]

Another thought: for things inside an organization, every effort should be made for interoperability between packages. As packages join the common standard, they get into the organization. This isn't hard-and-fast though, e.g. NLopt.jl doesn't really interop with the rest of JuliaOpt (yet) but is obviously a high-quality package that is key part of it.

[Robert Ennis]

Completely agreed and thanks for the suggestions.

The packages were only listed to indicate the types of things that might be included in the group. One of the main motivations of starting the group is to get us to focus and work together on polishing these packages, making them stable across platforms and fully tested. The current approach of three different people working on their own OpenGL implementations is part of the reason why these packages are lagging behind the rest of the community's efforts. OpenGL is a huge beast for one person to implement and fully test across platforms in a reasonable amount of time, although Simon is succeeding in proving me wrong on that point. :P

We only feel the need to have some sort of "common meeting area" for all of us to collaborate and generate interest among others, and probably don't want it easily accessible to the average user just yet.

Simon, Yuri, and I have already started discussing the need to make these packages interoperate, since this is crucial for good graphics support, and we hope to expand this discussion to the rest of the community, so that we can plan for the future.

Thanks & best,

Rob

[Tobi]

Isn't the primary (and very important) benefit of a group that multiple people get push rights?

I kind of like Iains opinion to first push "high quality" or "core" packages into the group. At this point I think the most important thing is to get the OpenGL family in. Here, a crucial question is wheather ModernGL should be renamed OpenGL and be made the "official" package. I am not so sure how important "old style" OpenGL is seen in the community.

Cheers,

Tobi

[Andreas Lobinger]

Is this expected to stay as non-public? If yes, please add me from github lobingera.

[Robert Ennis]

I'm personally fine with holding off on pushing the group any further, if the community feels that this is a bad move.

Regarding the level of OpenGL support, I agree that fewer people are probably interested in older OpenGL functionality, although it should probably be available at some point, if for some weird reason an old scientific visualisation needs to be run quickly and people don't have the time to update it to modern OpenGL. Plus, if they are running an older version of OS X 10.6 or they have an older graphics card, there may not be support for OpenGL 3 and up. Anyway, I think most of the systems that Julia runs on should support OpenGL 3 and up, which is what the ModernGL package targets, so that sounds like a good first move. However, people in a previous discussion on this list decided that it would be best for the core OpenGL package to go into the JuliaGPU group, since the main OpenGL routines are rather low-level. I can't seem to find the thread now, but are people still in agreement on that?

Best,

Rob

[Kevin Squire]

On Wednesday, July 9, 2014, Robert Ennis <renn...@gmail.com> wrote:

However, people in a previous discussion on this list decided that it would be best for the core OpenGL package to go into the JuliaGPU group, since the main OpenGL routines are rather low-level. I can't seem to find the thread now, but are people still in agreement on that?

Is it possible for a package to belong to more than one organization on GitHub?

 

[Stefan Karpinski]

There are multiple benefits of GitHub orgs for collections of related projects:

1. management – it's easier to grant people the necessary commit rights.
2. visibility/discoverability – all the relevant packages are in one place.
3. communication – all org members by default see all the issues and discussions on all the org projects.
   

I think management was the initial motivation for creating orgs and visibility and discoverability are also very good. But the real killer feature of orgs is the enhanced communication within the org community. I think this is what has the seemingly magical effect of turning a hodgepodge disparate packages into a coherent whole.

[Stefan Karpinski]

No, I'm fairly certain that's not possible.

[Kevin Squire]

In general, I've really liked working on github.  The one downside is that there isn't an (obvious) integrated way to have non-issue related conversations or newsgroups.

One option is to continue having this conversation here, on this thread or in julia-dev generally, but do people think it worthwhile to set up a julia-graphics Google group (or something similar)?

Kevin

[Stefan Karpinski]

I'd say let's just have it here. This is really important for the language ecosystem and I think it will get more attention on julia-dev.

[Simon Danisch]

I'm pretty open to any solution.
For me, it's just important, that we work together and pull into one direction.

It would be a pity, if all the cool graphic packages people develop are redundant in the end, or don't work well together.

I think it would help, if everyone that is involved in graphics can give a small summery of his work, motives and future plans, to find overlapping areas and evolve a long term strategy.

One of the things we all need to agree on, is the choice of a fixed size array library.
I'm using immutable arrays so far, which is working out pretty well. But sometimes, the immutability is a little bit troublesome, especially for matrix math.
I lost a little bit track of the related issues... Is there any active work going on in this area?

Also, if numbers are involved anywhere they should be parametric. Right now, I still can't use Color.jl elegantly, as its  all Float64 values, which then can't go to video memory without conversion.

OpenGL imposes some restriction here and there, so if you're working on a Geometry package, which ultimately should be visualized in OpenGL, there might be some design choices to keep in mind.

I'll write down some tutorials for GLUtils soon, to clarify how things need to look.

I hoped to push out my packages yesterday, but I got a little distracted by refactoring.

But I got pretty close to finish a very flexible shader generation pipeline with Mustache, which enables a lot of cool interactive use-cases. This was also the bit missing, to publish the surface /instance rendering API. 

If you've any questions, feedback, ideas, inspirations, please write me =) I'm interested in anything OpenGL related, that helps to make JuliaGraphics modern, fast and flexible!

Especially some collaboration would be cool. I piled up quite a few topics, which I'll can't implement without completely loosing focus.

Maybe I should introduce an "up for grabs" section.

Best,

Simon

[Tim Holy]

On Friday, July 11, 2014 06:05:00 AM Simon Danisch wrote:
> One of the things we all need to agree on, is the choice of a fixed size
> array library.
> I'm using immutable arrays so far, which is working out pretty well. But
> sometimes, the immutability is a little bit troublesome, especially for
> matrix math.
> I lost a little bit track of the related issues... Is there any active work
> going on in this area?

ImmutableArrays is by far the best choice for now. I had a proof-of-concept
that, because of your message, I just turned in to a "real" WIP pull request.
https://github.com/JuliaLang/julia/pull/7568

--Tim

[Jay Weisskopf]

1) I will happily transfer GLFW.jl out of my namespace and into an org.

2) I would prefer an org with a tight focus on the OpenGL API and ecosystem (e.g. JuliaGL) versus a broader one (JuliaGraphics). If the org is too broad (and "graphics" is an incredibly broad category), it will accumulate many unrelated packages. Many unrelated packages means many org notifications for things I'm not interested in (that will force me to mute the org, which seems counter-productive :-)

3) Why move OpenGL.jl into JuliaGPU? That group seems focused on using the GPU for computational horsepower, not graphics.

4) I think dropping support for OpenGL 2.0 and below is reasonable. Packages should make it easy / default to do things the "right way". Perhaps it could still be supported via a separate LegacyGL package.

[Jay Weisskopf]

I almost forgot the most important point:

5) The logo for a prospective JuliaGL org should be three Utah teapots colored and positioned in the same manner as the Julia logo!

[Stefan Karpinski]

On Sun, Jul 13, 2014 at 12:00 AM, Jay Weisskopf <jays...@gmail.com> wrote:

I almost forgot the most important point:

5) The logo for a prospective JuliaGL org should be three Utah teapots colored and positioned in the same manner as the Julia logo!

If and when there is a Julia Moscow meetup group, its logo should be the Julia logo but with minarets for dots, a la St. Basil's:

[Stefan Karpinski]

On Sat, Jul 12, 2014 at 11:57 PM, Jay Weisskopf <jays...@gmail.com> wrote:

2) I would prefer an org with a tight focus on the OpenGL API and ecosystem (e.g. JuliaGL) versus a broader one (JuliaGraphics). If the org is too broad (and "graphics" is an incredibly broad category), it will accumulate many unrelated packages. Many unrelated packages means many org notifications for things I'm not interested in (that will force me to mute the org, which seems counter-productive :-)

This is exactly what I want – not the muting bit, but the spamming bit. All the graphics stuff is way too disconnected and a bit disorganized now – having some more cross communication is a good thing. Note that you can mute specific repos in the org, rather than muting the entire org.

 

3) Why move OpenGL.jl into JuliaGPU? That group seems focused on using the GPU for computational horsepower, not graphics.

I agree – JuliaGPU seems not to be for visualization mainly.

[Tim Holy]

I tend to agree with Jay. Some day there will be ~1000 packages on graphics
alone. I like the idea of keeping the focus on OpenGL.

--Tim

[Simon Danisch]

I also agree with Jay.

We wanted to move OpenGL to JuliaGPU, because we agreed, that we should make CUDA, OpenCL and OpenGL all work together flawlessly.

But I think, that's not the only step that can be taken to focus on a good interoperability, so we might as well just move it to JuliaGL.

Right now it seems, that there is no real consent about a JuliaGraphics organization. We simply might need some more time to decide how to organize this in the best way.

What we should work on immediately is the missing cross-communication, though.

Maybe we can just leave this in julia-dev and open a few more threads to not loose focus in one big discussion where everything gets mixed together.

I was thinking about a mailing list called Julia-Graphics, but that might loose the advantage of having a lot of (new) people in the discussion.

[Aerlinger]

Would love to join the group as well if you'll have me. :)

[Jay Weisskopf]

I created a JuliaGL group a few days ago and made Simon and Robert owners (sorry if I missed somebody). I transferred GLFW.jl to the org and verified that Pkg.add didn't break. I'll let Simon and Robert "vote with their feet" and move their repos over if they wish. Ultimately, I'd just like GLFW to live with OpenGL, SDL, and family - I don't really care which org it goes under, whether it be this one, JuliaGraphics, or something else.

[Jay Weisskopf]

I probably should have included a link :-)

https://github.com/JuliaGL

[Paulo Roberto de Oliveira Castro]

Why don't we move OpenGL.jl, SDL.jl, GLFW.jl and GLUT.jl to the new JuliaGL umbrella? I think it's a very nice way to keep things organized and somewhat tied.

[Jay Weisskopf]

I transferred ownership of my GLFW.jl repo to the JuliaGL org a couple months ago.

[Simon Danisch]

If the owners want to transfer their ownership, I wouldn't mind.

But the packages are sort of deprecated and most of the important packages are already part of JuliaGL, namely ModernGL and GLFW, which are currently your best bet for using OpenGL with Julia.

Maybe I should also transfer GLAbstraction and GLWindow, which offer a solid set of functions that you need for creating OpenGL accelerated graphics. 

I simply haven't done this yet, as there was no real demand for it.