Merge branch 'develop' of https://github.com/openframeworks/openFrameworks
Merge branch 'master' of github.com:openframeworks/openFrameworks
use cc.openframeworks.ofapp as identifier on osx
update shaderY to work on non-intel cards
update shader to work on non-intel cards
ofxiOSUIImageToPixels is referenced in the header did not exist in the implementation file, so ive removed it.
ofxiOSUIImageToOFTexture did exist in the implementation file but not in the header, so ive added it to the header.
Merge branch 'master' of https://github.com/julapy/openFrameworks
Merge pull request #2691 from julapy/master

ofxiOSUIImageToOFTexture fix inside ofxiOSExtras
fix issue with uninitialised modelview matrix if fbo did not begin() with setupScreen==true

by default an ofFbo begins with setupScreen==true, which means it's setupscreen method will be called when the fbo begins. This method will also initialise the modelview matrix uniforms for the default shader for that fbo.

if the ofFbo is started with begin(false) the modelview matrix values will remain un-initialised. This can lead to difficult to debug issues, since as soon as the internal matrix stack gets touched through any matrix operation, anything will look like normal.

This issue will only appear if you do the following:

myFbo.begin(false);
ofPushMatrix();
// the following line will not draw as expected, since modelView Matrix not yet submitted to shader
ofDrawGridPlane(1000, 20, false);
ofTranslate(10,10,10);
// from here on, anything draws as expected.
ofRotate(0,1,0,0);
ofDrawSphere();
ofPopMatrix();

This PR fixes this issue by submitting the matrix stack initially, when we set the fbo as our current render target.

This PR might have a positive impact on #2593

Signed-off-by: tgfrerer <tim@poniesandlight.co.uk>
Merge pull request #2692 from tgfrerer/fix-fbo-initial-matrix-upload

fix critical ModelViewMatrix issue when ofFbo::begin(setupScreen==false)
feature add read-only access to current Matrix Stack

this is a clean PR and a replacement for PR #2479.

Original PR message:

having access to the matrix stack is really useful - the canonical example would be: if you want to push a normalMatrix to the shader (calculated once per frame on the CPU, used as a const many many times on the GPU):

	ofMatrix4x4 modelViewMatrix = ofGetGLProgrammableRenderer()->getCurrentMatrix(OF_MATRIX_MODELVIEW);
	ofMatrix4x4 normalMatrix = ofMatrix4x4::getTransposedOf(modelViewMatrix.getInverse());
	mShd1.setUniformMatrix4f("normalMatrix", normalMatrix);

Otherwise, you'd have to calculate the normal matrix in the vertex shader (per-vertex) or even in the fragment shader (per pixel!):

	mat4 normalMatrix = transpose(inverse(modelViewMatrix));

Matrix inverses are amongst the most costly GLSL operations.

Signed-off-by: tgfrerer <tim@poniesandlight.co.uk>
add ofGetCurrentMatrix

* adds getCurrentMatrix to ofBaseRenderer and all its direct heirs

* adds ofGetCurrentMatrix which will return the current matrix state

* this will, in order not to over-optimise the code, return an ofMatrix4x4 by copy instead of a const ofMatrix4x4 & - I trust modern compilers will automatically move these things and find the code easier to optimise this way anyway.

Signed-off-by: tgfrerer <tim@poniesandlight.co.uk>
add changelog entry

adds changelog entry for ofGetCurrentMatrix, since this affects core API

Signed-off-by: tgfrerer <tim@poniesandlight.co.uk>
fix ofMatrix3x3 incorrect multiplication
changelog
Merge pull request #2700 from jnakanojp/master

fix incorrect ofMatrix3x3 multiplication
Merge branch 'master' of github.com:openframeworks/openFrameworks
adding glEnable(GL_PROGRAM_POINT_SIZE);

Fixes https://github.com/openframeworks/openFrameworks/issues/2711 and I can't imagine we'd want pointsprite w/o a size, seems like an easy source of confusion since so many examples use it.
Merge pull request #2712 from joshuajnoble/master

Enabling GL_PROGRAM_POINT_SIZE in ofGLProgrammableRenderer
Added a check if a given parameter exists before trying to cast a value to it. Fixes #2713