Apple deprecating OpenGL


#1

The brains trust at apple have decided to deprecate OpenGL in favour of metal. What are the implications of this as it pertains to cinder?


#2

Disappointing but not shocking I suppose - Apple implicitly deprecated it through neglect a while back. I imagine we have some time before we have to solve this completely. Curious what others’ thoughts are - Bill Lindmeier has already done quite a bit of work on Cinder-Metal:


#3

In my case I tend to develop on the mac and ship on windows, so the platform agnosticism was the major benefit. As awesome as cinder-metal looks, I personally would prefer a more api agnostic renderer layer a-la bgfx so that i’m not writing platform specific code that won’t ever ship, but i appreciate this may not be a common scenario.


#4

Currently a lot of cinder isn’t really that agnostic though. I think maybe an open-source version of MoltenGL would be good approach.

Very sad and annoying news though. I love using my mac for simple 3D graphics animations. I guess I should try out metal at some point anyway


#5

On a side note, does anyone know how metal is for creative coding?


#6

Cinder-bgfx sounds like a good plan to solve the gfx API hell once for all.


#7

I realise I’m late to the party and I’m not familiar with bgfx but I do like the sound of it. Our whole studio develops on Mac to deploy on Windows or sometimes Linux. So we’re in the same boat as @lithium.snepo


#8

Our whole studio develops on Mac to deploy on Windows or sometimes Linux.

I would always recommend developing any application in the same environment you intend to deploy it in, or as close as realistically possible to it. This way you’re much more likely to encounter any issues you’ll run into early on, and your developers will be fluent with that OS. Also these days, there’s not much of an excuse to be developing C++ on OS X other than laziness or unwillingness to learn how to work on a Windows box and with Visual Studio, all the tools are there and free now.

Concerning OpenGL on OS X, Apple decided a long time ago they weren’t going to add crucial features like compute shaders, SSBOs, and debug breakpoints, I jumped ship then and haven’t looked back.

I’m not sure if a bgfx renderer for cinder makes sense, or what you would gain in many custom scenarios like when you need custom shaders. If for some reason I needed to deploy on OS X / iOS (which I don’t really have), I think I’d be more likely to want to use the Cinder-Metal block and either a) abstract my rendering directly or b) only deploy there.

cheers,
Rich


#9

Also these days, there’s not much of an excuse to be developing C++ on OS X other than laziness or unwillingness to learn how to work on a Windows box and with Visual Studio, all the tools are there and free now.

This is a ridiculous statement.


#10

Care to elaborate?

I should perhaps clarify and say “… to be developing a Windows C++ application on OS X …”, but I’ll leave my original statement as is because I believe it to be true anyway. :slight_smile:

cheers,
Rich


#11

Yeah, I agree that that statement is a bit much. I can understand the perspective if c++ windows applications are the only thing you are ever developing although I personally do not enjoy visual studio (and becoming familiar with it is unavoidable when deploying on windows).

But I don’t think that’s the issue here. Surely one of the major benefits to cinder and similar frameworks is that it’s cross platform. It’s never as simple as write once and deploy everywhere but if we had to write vastly different rendering code for each platform or custom build all our own abstractions for this that would be a real bummer.

I’m not sure what the best solution is here, but it would be great if cinder was able to find a way to maintain a largely cross platform graphics layer.

cheers,
nay.


#12

What usually happens to me is that due to bureaucracy the ‘deploy’ machine get’s late to the party. It’s handy to start developing and doing tests in my day-to-day mac, and I never use that open-gl witchcraft so usually things are ok with the higher level api that cinder abstracts.

An example was a recent job that I did for a major telecom here: https://www.youtube.com/watch?v=Iwf7qOS2n7E
It had to run on mac, windows 10, windows 7 at every ad agency that the telecomm has a contract. It uses a lot of ci::audio stuff and basic open gl operations that cinder abstracts ( yey! ), and I had a harder time solving linker problems that any other thing (thanks cinder :slight_smile: , bohoo c++ :man_facepalming: )

I’ve never used bgfx, but I have been keeping an eye on it. It’s tag line is Bring Your Own Engine/Framework and it has a nice list of supported platforms and languages, A couple of interesting projects are using it:

https://hugoam.github.io/mud-io/
https://www.amethyst.rs/

In my opinion if cinder steers towards a “Bring your own render (metal, vulkan, dx13, headless…)”**, aka: the missing part for bgfx together with a nice higher level cross platform api like we have now with opengl it would work for projects like the one I showed. Where it doesn’t need a lower graphics api, but doing without everything that cinder brings to the table would be a pain ( text, audio, cairo, color etc… ).

Also, as a side advantage in a perfect world, is that some of the cinder workforce would be able to focus less on opengl on every plataform and work on other features.

Anyway, just some thoughts, unfortunately this lower level stuff is beyond my current knowledge but I imagine that doing a cinder-bgfx would be an insane amount of work, like I imagine that making the current gl:: api was…

** I know that you already can ‘plug’ your render into cinder (there is a directX, metal block, vulkan), but my guess is that is not so trivial and documentation is scarce in that matter


#13

You really need to stop being lazy and unwilling to learn on a windows box. There’s no reason to develop c++ on OSX, didn’t you get the memo?


#14

I did, and I spent to much time thinking about a Clippy joke.

But I get @rich.e’s point, and I’ll rephrase that: If you are developing for X platform ( windows, mac, whatever ) but developing in Y you should work and develop on X as soon as possible, not because of laziness, but to keep you sane and not crazy


#15

Curious to see where these efforts to bring Vulkan everywhere will land. Maybe this this could play well with Hai’s existing vk:: work.


#16

MoltenVK (licensed under Apache 2.0) might be worth exploring.


#17

Re-bgfx: Bgfx is for sure an interesting and impressive project but the whole “Bring Your Own Engine/Framework” is to take with a grain of salt. It should probably be more something like

“Bring Your Own Engine/Framework but you will also need my custom memory allocator, my re-write of STL containers and basic types, my image loading library, my math, threading, filesystem, etc…”

So definitely a really cool Gfx API abstraction but because of so many overlap I don’t think it would be such a good fit for Cinder. There’s also quite a bit of overlap between the long list of dependencies and third-party code that Bgfx uses (See here, here and here among others.)

That said it’s a very cool project and not so time consuming to integrate to Cinder (I have some abandoned code sitting around somewhere if someone really really want to go down that road).

API agnostic layer: Not sure about the developing on Mac/Windows thing and if it matters but I’m pretty convinced that the future of Cinder will have to be through a graphic API agnostic layer. It will definitely take time but I don’t think we can escape doing it forever.


#18

This is what I meant when i originally mentioned bgfx. I think cinder and bgfx are orthogonal in a lot of ways, but its common interface to a multitude of rendering backends was the feature I would like to see brought over.