New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ofCamera is not aware of ofOrientation #931
Comments
For iOS this means that unless you are setup in the default portrait orientation ofCamera and ofEasyCam are basically useless as they don't take into account the viewport shape or the orientation of the screen. We should look at adding in the orientation code from: ofGLRenderer::setupScreenPerspective |
would be great to get some thoughts on this: @elliotwoods @roymacdonald @julapy my feeling is that we shouldn't have duplicated code in ofGLRenderer::setupScreenPerspective and ofCamera::begin - we could move to a internal ofCamera or have ofCamera call a new ofSetupView function? maybe the latter is better in this case as it would allow ofCameras to be rendered by other renders? ie: ofSetupView is called by ofSetupScreenPerspective ( simplified ) Internally ofSetupView passes off to render->setupView which in turn handles orientation and rendering commands. This could be done in a way that is backwards compatible with our existing system. |
i think this will be solved with the gles2 branch, there we have an orientation matrix that is multiplied to the modelview everytime that one is uploaded. i want to refactor that code and some more matrices related code out of the gles2 renderer so it's used by both gl and gles2. that will help to solve also the problems with the vertical flip |
Also, for those who are interested, over in gles2/raspberrypi/e-linux land, we are updating examples as needed to get rid of all native matrix-related gl-calls in favor of the new matrix math future-gl-safe system metioned by @arturoc system. We are also replacing all openGL "immediate mode" calls (yes, there were still a few left :)) with oF-wrapped gles2/future-safe calls. |
@arturoc will that work for non gles2 ? just to confirm - the idea is to remove all gl calls from ofCamera? |
yes it will work with non gles2, and yes actually ofCamera doesn't have any gl calls anymore, well as soon as this PR: #1666 is merged but that's included in the gles2 branch already so it can wait anyway the idea is that when you set the orientation with ofSetOrientation there'll be an orientation matrix somewhere (right now in the renderer) then when you do any modelview transformation (translate,rotate...) or upload a new modelview that will get multiplied by the orientation matrix so the camera will work with that, of course as long as you use OF calls |
sounds great. that might get trickier as for positioning y becomes x etc |
not sure but i think it should: all the movements of the camera are store in a 4x4 matrix and uploaded to the graphics card in begin() using ofLoadMatrix which in turn multiplies it by the orientation matrix so it whould work |
ahh okay great. |
just a quick test using the iOSES2ShaderExample - if I modify it to use ofEasyCam it behaves (mostly) as expected. it seems that the orientation is not quite correctly handled yet in #1668 to test try replacing this gist with testApp.mm in iOSES2ShaderExample and then uncomment line 13 see the screenshots here ( i had to rotate the horizontal one so you could see where the text was being drawn ): The only difference between the two is: ofSetOrientation(OF_ORIENTATION_90_LEFT); |
this is currently only working in gles2, in old opengl there's no way to avoid people from mixing ofPush/Pop/LoadMatrix with the gl versions which will mess things up, i think opengl1 should stay as it is and in the new renderer, since we have to manage the stacks ourselves anyway, we can intercept these calls and multiply by the orientation matrices i've just merged this #1846 with that we could make ofLoadMatrix multiply the matrix by the orientation in old gl too so at least cameras will be aware of orientation |
cant we have an event sent each time the orientation changes, either by manually calling ofSetOrientation or when the device reports an orientation change? this way ofCamera can listen to the orientation changes and call ofSetupPerspective. mouse interactions (in the case of ofEasyCam) should be fine as the mouse is already rotated in the glut mouse callbacks. |
I think this would be good to get in pre ES 2.0 I think it shouldn't be too hard to fix! |
i don't think it's necessary to have an event, and it'll complicate things even more, we just need to check the orientation when setting up the matrix, in the gles2 version there's actually a matrix for the orientation and all the projectionmodelviews are multiplied by that, it's only a matter of adding that at a global level but only for the case of ofLoadMatrix or have the camera ask for the orientation or the orientation matrix when setting up the matrix |
btw, won't using ofxiPhoneSetOrientation solve that? in android this works cause the orientation is managed by the device can't we make ofSetOrientation go through ofxiPhoneSetOrientation the way it's done in android |
@arturoc I was thinking about something like that when i mentioned the event thing, but rethinking it with out the event what you say seems quite plausible. |
as far as I am aware ofxiPhoneSetOrientation doesn't work because all that code is in the core setupScreenPerspective and ofCamera has its own screen setup code. |
not sure what that function does but doesn't seem to be related to
which seems to be setting the application orientation through iOS native there's a flag, ofDoesHWOrientation() which is read by ofSetOrientation |
that said it would be useful to implement the plain orientation method so the camera is aware of it but it's kind of a complex change if we do it for every renderer not only GL and would be a good occasion for refactoring the matrix management in general (ie: the vflip...) so i would prefer to not do a quick patch that will make the code more complex/messy than it is right now |
this is the code I was talking about: we used to be doing this separately in ofxiPhone but it was consolidated with desktop so that you can easily run screens in vertical orientation with just one line of code. I believe this: just changes the status bar orientation - you are still give a vertical openGL world even if the orientation is set to horizontal. I'm definitely for adding a way to set orientation for ofCamera / ofEasyCam. Anyway I'm happy to help - we could push this back to 0.7.5 - but would love to get this resolved soon. |
mmh ok, then the best way to do it i think would be to add a check in ofLoadMatrix (in the glrenderer by now) where if the matrix mode is model view then it modifies the uploaded matrix accordingly to apply the orientation. i can then generalize that for all the renderers in the gles2 branch |
btw, i was looking at this sometime ago and i don't see why do we need to pass the orientation in the setupPerspecive method. Won't it be better to just use ofSetOrientation and then use ofGetOrientation from setupPerspective? what happens if you set a perspective with ofSetOrientation and then use a different one in setupPerspective? |
"what happens if you set a perspective with ofSetOrientation and then use a different one in setupPerspective?" ha - no idea. it might allow for some interesting perspectives :) |
ps - I moved this back to 0.7.5 - so we have a bit more time to get a good working solution. |
:) ok perfect. |
Hey guys, |
this is simple enough to merge it even if we do something else, only thing can you check ofDoesHWOrientation and not multiply by the orientation in that case. |
great - thanks @roymacdonald - I'll test this today and confirm it works. btw - does it make sense to apply the rotation when the orientation is no orientation? |
Hi, I was trying to fix this, but as I saw that arturo's programmableGL |
I've noticed a few issues in the programmableGL branch in terms of orientation and cameras - so lets keep this issue open till all the issues are patched. it is much better though than how things were. |
@ofTheo what are those issues you've noticed? on iOS devices it doesn't work. There is only one "odd" thing that happens with the camera position. As it is calculated using the viewport, and the fov, the fov remains constant so the camera moves over it's z axis depending on the orientation. This behavior is correct but I'm not sure if it is what one would expect. From a user point of view, I'd expect that the camera stays in the same place and that I'm able to see more to the sides or up/down when I rotate the device. Should we do something with this? I think I know how to implement this. All the best! |
i think the problem with iOS is that there's different methods to handle the orientation and probably need to be changed to mirror how ofSetOrientation behaves right now. the renderers are the same for every platform, ofGLRenderer by default but you can set programmable in main before setupGL. Surely @julapy has a clue of what can be going on |
will look into this a bit later today. On Mon, Jun 17, 2013 at 7:14 PM, arturo notifications@github.com wrote:
Lukasz Karluk | Interaction Design |
@roymacdonald - what I've seen since the new branch is merged in is:
Actually most likely because the ofSetOrientation is not being applied to the app as a whole. I just checked on desktop and this issue doesn't seem to be present. note in the image that the star and shapes are stretched in the x axis. |
ive been looking into the orientation issue on iOS and i think the problem may be inside the orientation matrix is now only made up of rotation, but it doesn't translate the screen after rotating it like it did previously. to see the difference, look inside
|
this is because the orientation now is done in the projection matrix not in the model view so the code is way simpler but works the same, this works on desktop so it must be something else |
OK. Found the problem. |
perfect! |
great. |
yeah now that orientation in managed by the new renderer, there is also a bunch of defines, but yeah a good place to start is by going through the examples and make sure they are only using, |
@julapy I already tried |
im more like 3rd or 4th generation ofxiPhone dev :) its passed through a lot of hands... i can go through and deprecate all |
@julapy OK. I'll check the examples tomorrow. |
Hey, |
hey @roymacdonald, |
yeah, was going to say. its totally fine to change this in the examples to the newer system. |
ohh sorry! I've been a bit feverish all day long and only making mistakes. I did a cli find and grep that thew nothing but I misspelled something. I'll fix all those and PR. |
@julapy this is not fixed yet, right? Otherwise I think we can close this now. |
i was thinking of removing those when ofxiPhoneSetOrientation and ofxiPhoneGetOrientation have been removed, but yeah i think you're right... since nothing is using those defines any more, its probably better to remove them. |
please don't remove them! ( the OFXIPHONE_ORIENTATION_LANDSCAPE_LEFT etc ) I think marking ofxiPhoneSetOrientation as deprecated is enough. |
OK, closing this then since all other issues in here seem fixed. |
No description provided.
The text was updated successfully, but these errors were encountered: