I'd like to call your attention to the new glNext_ANGLE branch available here
. This branch adds support for ES 3 as well as ANGLE to glNext.
(Almost Native Graphics Layer Engine) is a Google open source project
that implements OpenGL ES 2/3 in terms of DirectX 9/11. Its primary use
case has been WebGL in Chrome on Windows, but it obviously has utility
outside of that. I'd say Cinder's interest in it is twofold.
First, for widely deployed applications like games or screensavers,
OpenGL can be a nonstarter on Windows. Drivers are traditionally poor
for consumer GPUs and users rarely update them. This is especially true
on XP. Additionally, ANGLE is a promising direction for WinRT support in
Cinder and is likely to succeed the current DirectX implementation.
Here is the CubeMapping sample, but running in DirectX (w/o requiring
any code changes):
In addition to these changes, the glNext_ANGLE branch implements OpenGL
ES 3 support, which can be utilized both via ANGLE and iOS. For devices
that support ES 3, this opens up features like transform feedback and a
GLSL implementation very close to desktop core profile. Also many
features (like instancing, floating point textures, etc) which were
proprietary extensions are now standardized.
By default ANGLE utilizes ES 3. To downgrade to ES 2, you'll need
to define CINDER_GL_ES_2 in your preprocessor definitions for both
Cinder itself and your application (and of course rebuild both having
done so). For iOS, it's the opposite; to use ES 3, define
CINDER_GL_ES_3 on both Cinder and your app. ES 2 is the default on iOS
because many iOS devices don't support ES 3 yet, so it's
something you need to opt in to.
This is an iPhone running the ParticleSphereGpu sample, which makes use
of Transform Feedback:
Right now the following _opengl samples support OpenGL ES on both iOS
ParticleSphereGpu *iOS ES 3 only
ParticleSphereCpu *iOS ES 3 only
PickingFbo *iOS ES 3 only
Other changes in this branch include
• A Vbo::mapWriteOnly() which abstracts API-dependent variations
in mapping VBOs in the standard write-only case
• A gl::Fbo::Format::depthTexture() convenience method,
demonstrated now by the FboBasic sample. This was always possible to do
with Format::attachment() but is now simpler and deals with some of the
ES 2+ vs. GL issues
• Under the hood we now use glTexStorage* when it's available.
We support gl::Texture::Format::immutableStorage() to take advantage of
this. When you're able you should from a performance perspective -
the FBOs do automatically for texture attachments.
ANGLE is designed to be used as a pair of DLLs, libGLESv2.dll and
libEGL.dll. For now you'll need to setup ANGLE configurations in
Visual C++ manually, though eventually I'd like to add this to
TinderBox. Here are the instructions:
* Add CINDER_GL_ANGLE to the Preprocessor Definitions
* Add the relative path to Cinder's include\ANGLE directory to
C/C++ | General | Additional Include Directories
* If it's present, remove the OpenGL32.lib from Linker | Input |
* Change cinder-$(PlatformToolset)_d.lib to cinder-$(PlatformToolset)-ANGLE_d.lib
* Build Events | Post-Build Event:
xcopy /y "..\..\..\..\lib\msw\x86\libGLESv2.dll" "$(OutDir)"
xcopy /y "..\..\..\..\lib\msw\x86\libEGL.dll" "$(OutDir)"
xcopy /y "..\..\..\..\lib\msw\x86\d3dcompiler_46.dll" "$(OutDir)"
The final step automatically copies the relevant DLLs to your output
directory but it is not strictly necessary. Also note that it copies
d3dcompiler_46.dll. This is the DLL necessary for targeting DX 11, which
is likely what most Cinder developers' machines support. However if
you would like to support DX 9 fallback, be sure to copy
d3dcompiler_43.dll as well. This is untested for now but should work.
This branch represents substantial changes to quite a bit of our GL
code, though primarily in implementation, not interface. If you're
able to test your existing projects against it it would be appreciated.
Nice! Just ran the ParticleSphereGPU demo on an iphone 5s and it is
working well. Some big features here to add to the list..
I think gl::getVersion() needs to be updated for es3, looks
hard-coded to return pair<2,0>.
One other thing, looking at the gl.h preprocessor craziness, seems
like it might make sense to move that to a separate file (included
from gl.h), as that header is peered through quite a bit when looking
for method signatures.
Awesome. It'll be nice to have TransformFeedback and UBOs on iOS! I
just updated the NanoVG block to take advantage of this.
I'm noticing a weird issue when running the samples in landscape
orientation. It looks like the backing framebuffer is being allocated
for portrait mode and then stretched. You can see this if you open up
the GPU frame inspector:
Screenshot of cube sample in landscape mode:
The same application (still in landscape) in the GPU frame inspector:
I probably should have reported this as a GitHub issue, and I'll
move it over there if I can't figure out what's up in the next
few hours. Maybe it's just a matter of recreating the framebuffer on resize?
Are the 5 ANGLE integration steps above still required? It seems
like Tinderbox now covers the project settings no?
I'm hoping that I can use ANGLE to
run a Cinder app in a VM, as VMWare Fusion only supports OpenGL 2.1
but dxdiag reports DX11 support (feature levels 9.3,9.2,9.1). I built
the Debug_ANGLE solutions of Cinder and the BasicApp projects, but hit
an exception when the renderer is initialized, inside
RendererImplGlAngle, eglInitialize() returns false - I'm not sure
if that is just further VMWare Fusion'ness or a legit issue.
To answer my own questions: nope, it doesn't appear as though the
manual steps above are required any longer - a project created by
Tinderbox seems ready to go.
The eglInitialize error I was seeing seems to be caused by the
default display attributes as VMWare Fusion supports Feature Level 9.3
at most which needs special handling. Following some of the MSOpenTech
sample code as a guide, if eglInitialize fails, I fall back to using
the Feature Level 9.3 attributes and paired with defining
CINDER_GL_ES_2, everything works.
The MSOpenTech project wiki mentions several other quirks
associated with OpenGL ES 2 conformance issues on D3D11 FL 9.3:
as such, will Cinder's ANGLE use 10.0 as a minimum or is there
some interest in a PR with the FL 9.3 support? Chrome itself runs
WebGL content just fine via ANGLE in VMWare Fusion - the WebGL
Conformance Test Runner v1.0.3 results don't seem markably
different from those of Chrome on OS X with 27575 tests of 27966 passing.
Just to update the above, @pizthewiz submitted a PR for this, which is
merged now. If you do need to run on Feature Level 9.3 hardware, this
should work now thanks to his work. You will have to
define CINDER_GL_ES_2 and rebuild Cinder, in addition to defining the
same in your app.