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?
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:
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.
1 Like
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
On a side note, does anyone know how metal is for creative coding?
Cinder-bgfx sounds like a good plan to solve the gfx API hell once for all.
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
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
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.
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. 
cheers,
Rich
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.
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 , bohoo c++ 
)
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
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?
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
1 Like
Curious to see where these efforts to bring Vulkan everywhere will land. Maybe this this could play well with Haiās existing vk:: work.
1 Like
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.
1 Like
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.