In case this is possible, it would be nice to see some examples!
Thanks,
rui
This question asks something very similar, and as I state there it's trivial to have OpenGL ES content coexist with UIKit controls. The OpenGL ES content lives within a CAEAGLLayer that backs a UIView, which is part of the normal view hierarchy. You can easily overlay other UIViews on top of it.
For an example of this, you can look at the source code to my Molecules application, where I place two UIButtons on top of my OpenGL ES view.
In my benchmarks, you lose ~1-5% of your OpenGL framerate by placing other views on top of the OpenGL ES view, which is not too terrible. What you don't want to do is make your OpenGL ES context non-opaque and try to overlay that on top of other view elements, because you'll see a significant drop in rendering speed then.
Yes, it's possible, after all OpenGL ES context is inside just another UIView subclass. Thing is that Apple doesn't recommend mixing Cocoa Touch objects and OpenGL ES views due to huge performance degradation.
Related
I need to make a design decision of how to approach an app which needs to render few 3D objects on top of an image texture.
Result needs to be rendered and saved as an UIImage.
Graphical design (client) expects standard UIKit controls to manipulate 3D world.
OpenGL view (CAEAGLLayer layer) needs to be inside UIScrollView for cheap and natural scroll and zooming implementation.
There are just few extra controls to manipulate rotation scale and transition of the few 3D objects.
There is not many triangles expected (100-200 at most) and 2-3 textures (1 mask). It does not even have to be refreshed constantly, just when some transformations and zoom changes.
CAEAGLLayer does not need to be opaque.
I would go with Core Animation solution but rendering 3D transformed CALayers to CGContextRef is not supported (neither is masking).
What is real performance cost when putting CAEAGLLayer inside UIScrollView and mixing it with few UIKit views?
How much triangles per second can I expect to be rendered with smooth frame rate (30fps will do), so I can make the best decision possible?
I know there are similar questions out there already, but none of the answers provides specific numbers, which could help with estimating expected rendering results.
Per Allan Schaffer, who gives the WWDC and WWDC on tour OpenGL speeches, OpenGL itself is not so much a special case — it's that anything that changes will cause everything on top of it to be recomposited. I spoke to him specifically about an app with a live updating video view underneath a live updating OpenGL view and he said that sort of thing is the pathological worst case. It's generally not that expensive to throw a few quite static views on top, such as using a UILabel to display the current score over an OpenGL game.
In your case, I think you can probably largely avoid the problem. Don't put the GL view inside the scroll view, but rather make the scroll view non-opaque and put the GL view behind it. Catch scrollViewDidScroll: (and the corresponding zoom messages) and make related OpenGL adjustments. I can speak from experience and say I've done exactly that on an iPad 1 with no performance issues. Particularly for the sort of model you're talking about I don't imagine a problem.
is it possible to integrate cocos2d with Normal iphone or tabbarcontoller application?bcos I want to ingrate animation of cocos2d with tabbar application?
You don't need multiple EAGLViews. You just need to add the UIToolbar as a subview of the openGLView of CCDirector. Then make sure your Cocos Layers have are vertical offset so they don't overlap.
Yes it's possible if you tweak a bit cocos2d in order it can manage several EAGLViews (so far there is only one eaglview).
[edit] Managing several opengl views is not the only method (it's case 4 in the doc below).
Flower Garden (appstore game) merges uikit and opengl layers (it's not made with cocos2d but it doesn't change anything to the problem, it's EAGLViews on top of UIKit). They've published an excellent presentation here :
http://gamesfromwithin.com/wp-content/uploads/2010/03/GDC10_uikit_opengl.pdf
In our current app, some consultants wrote code in OpenGL to make things look nice. Basically mimicing a UITableView, goes horizontal instead of vertical, and of course prettier. I was reading through a Core Animation book and they said that with Core Animation, you could mimic Apple's Cover Flow navigation. To me, that looks nice enough.
Does anyone know if any of that is done in OpenGL or just Quartz and CoreGraphics?
Secondly, (here's the open-ended question), but if we were to redesign something to mimic Apple's cover flow, assuming it was not in OpenGL ES, would that be less memory intensive and perform better? It seems like our app runs out of memory rather quickly in its current state since it's pushing a lot of data through the horizontal table.
The content of a Core Animation layer (text, shapes, images, ...) is rendered with Quartz, but the rendering of the layer itself is done by OpenGL, so rendering performance shouldn't be a problem.
Core Animation might use less memory, because it can release the content of invisible layers (or table cells in your case).
I get how to do a 1 screen opengl view.
But....
How about multiple opengl(1.1) view(s) for a game or drawing program?
For example:
After the drawing program starts up and someone does a 3 finger touch, it would bring up a toolkit of sorts on the top third of the screen for making drawing adjustments.
Or a game that has an animated splash screen the going to the actual game. Info button and other choices done in opengl as well.
The main point being I want to do all in opengl and need to know how to do multiple opengl views.
Thanks for any advice!!
It's not hard to implement multiple OpenGL ES rendering surfaces, you simply need to create multiple views that have CAEAGLLayers backing them.
Generally, multiple OpenGL ES layers are not recommended for performance reasons. You generally want to have one opaque fullscreen OpenGL ES layer for all of the content that needs this. Anything you can render in multiple contexts should be able to be drawn in a single one.
However, all of the things you describe can easily be done using standard UIViews and Core Animation. Overlaying UIViews on opaque OpenGL ES content only leads to a ~5% reduction in rendering framerate in my tests, which I consider perfectly acceptable. This is what I do in Molecules, and you can check out the code for that application to see how straightforward it is to layer these controls on top of OpenGL ES content.
I'd recommend going this route, because re-implementing buttons and other UI elements will take far more code in OpenGL ES than just using the native controls. You'll be sinking a lot of time into reinventing the wheel that could be used to improve other areas of your application.
I would suggest don't use multiple views too. Instead, just set your viewport differently each time and draw with a different LookAt position.
I'm pretty new to the iPhone platform, so I'm wondering what the best way to switch between OpenGL rendering and a UIView might be?
Any comments much appreciated!
There's no need to switch modes at all. OpenGL ES rendering on the iPhone is done in a CAEAGLLayer Core Animation layer. This can be used as the base layer for a UIView, which means that you can combine all the UIView layout and touch handling with your 3-D rendering. This UIView can be fullscreen or placed anywhere on the display. UIViews also can be made subviews of your 3-D view, therefore they can appear above your rendering.
The OpenGL ES Application Xcode template gives you an OpenGL layer within a UIView instance and is a good place to start. For a more complex example, I can direct you to the source code for Molecules, my 3-D molecular viewer. In that application, I use a lot of the view functionality for touch detection and place an info button in the lower right as a subview. I even replace that view with another to produce a flip animation when going to the application's settings.