I am just looking through all of the iOS performance tips regarding OpenGL ES 2.0 drawing and I am just wondering: "do they all apply equally to Android development?"
Are the processes the same irrespective of Android and iOS and are they just 'pure' OpenGL tips?
Specifically, does this tip apply to Android development too? Because it would change the way I currently create my attribute data:
When you are designing your vertex structure, align the beginning of each attribute to an offset that is either a multiple of its component size or 4 bytes, whichever is larger. When an attribute is misaligned, iOS must perform additional processing before passing the data to the graphics hardware.
As a line of principle, the same best practices apply to both platforms since some of them are "common sense" approaches (i.e. batching is one of them).
On the other side, the same golden rules do not necessarily apply to all android devices and I would like to explain what I mean.
the point is mainly due to the GPU architecture. If you read the best practices for the IOS devices, for sure they are referred to the PowerVR GPUs (excellent GPUs) which have certain characteristics that not necessarily respect the one of the other GPUs you will find in the Android massive number of devices.
For instance, in the Android market you will find for sure GPUs being part of the Adreno family, the Mali family and so on.
This means that, in order to benefit the best from all these devices, you should write the code according to the manufacturer's best practices.
This means that you should study the SDK's reccomendations of each one of them.
So, to cut a long story short, some of those best practices apply to android as well, some other, could collide with the GPUs specifics of some mobile devices.
Related
I believe that openGL ES 3.2 (and 3.1 + Android Extensions Pack AEP) support it, but I've heard that some GPU's with previous versions (specifically 3.1 without AEP) also have this particular extension.
My question is: how can I tell which GPUs have that particular extension, enabling one to render to a float texture?
I've searched manufacturer sites, but haven't been able to find this info (maybe I'm looking in the wrong place?)
I'm also a little wary, I heard that one manufacturer added this ability in their driver... but I wonder if that is a software solution (and therefore much slower, defeating the purpose).
Further to this, of course it's possible to do the encoding decoding in your own shader - but wouldn't this incur significant overhead? Or, maybe it's fine?
[BTW: the reason I'm asking is I want to purchase a phone to play around with general-purpose computing on mobile GPUs, and the latest phones are much more expensive]
Many thanks for any help! I've been trying to find this on-and-off for months...
Float rendering support is mandatory in OpenGL ES 3.2. It is not required for OpenGL ES 3.0 / 3.1 / 3.1 + AEP.
For earlier implementations you want to use a platform exposing the EXT_color_buffer_half_float and/or EXT_color_buffer_float extension.
Note that floating point rendering is relatively expensive due to the additional bandwidth, even when supported natively in the hardware. For higher dynamic range consider using something like RGB10_A2 if you can, it's smaller and faster (and supported in 3.0 core).
I am starting to build my first Android app. I have reached the point where I need to start adding custom graphics and Art to make it look good. However I have also realized I have no skills or knowledge in this area at all.
What practical steps can a programmer take to develop the basic skills necessary to draw/render the kind of small, low resolution artwork suitable for mobile devices (I don't want to be able to paint a full painting or anything)?
I am particularly interested in any tools that may be of assistance, either software or devices like drawing tablets, as well as guides and tutorials.
NOTE: I know this is not strictly a programming question, and there are probably other Art forums out there, but I want to specifically hear from other programmers in a similar situation how they have acquired the skills to make mobile art.
When it comes to the tools and soft, there is nothing better than Adobe Photoshop (it's very expensive but you can download CS6 beta for free for limited time now) with a Wacom tablet (Bamboo would suffice here, or Intuos if you have too much money).
Colors are extremely important and color palettes are hard to do for a beginner. It's not simply a matter of combining two or three hexes. Check out Adobe Kuler and ColourLovers for a little help with that.
Also if you don't like beginning the work from scratch, there are plenty of PSD templates, just like this one.
And looks are nothing without feeling, so UX (user experience) is extremely important, it's also an art:). Personally I find the tips in Android Design Guidelines very useful, even if they cover mostly ICS features. You can copy most of the functionality to the pre-Honeycomb apps. There are also lots of tips on UX in the SmashingMagazine.
I've been digging since while for 3D graphics tutorials for Android. I tried raw opengl (es). I also tried min3d. I found out that things can be very complex or very easy if someone else did the math for you. Min3D is really great and easy to use, but is also really minimalistic. I can't find how to make lights actually cast shadows (and I doubt it's supported), I can't find how to make the surface reflect, how to change the surface to diffuse more or less.
Is there any library that has scene handling and supports shadows (also shadow cast by diffused light), control materials to achieve different levels of diffusion, reflections and transparency.
Note: I forgot to mention I need free framework.
Since the answer of Eric convinced me that realistic 3d is hard to achieve on mobile devices I would accept answers that explain how to fake these effects (or links). Again effects I need are:
shadows
reflections
from glossy material
from matte material
transparency (I think that's in the min3d examples, but it's here for completeness
I've seen shadows in 3d android games, although I'm not 100% convinced that are real (cast by objects).
I can't think of any libraries that meet your requirements for a mobile platform, but there are several middleware products to choose from:
Unity3d : http://unity3d.com/
Unreal SDK : http://udk.com
Ogre : http://www.ogre3d.org/
All of these offer scene management, lighting, material management, etc... yet, I doubt any of these are a silver bullet for what you are asking. Regardless of pricing and licensing - upto 3500 dollars for Unity3D pro mobile - you will still have to do a serious amount of coding yourself and often in a language you may not be familar with.
Also, keep in mind that a lot of the gfx in opengl-es based products (mostly games) are often faked. While it's perfectly possible to have dynamic lighting, shadows and transparency, these things can be crippling for your performance if you have a lot of geometry. After all, a phone or tablet is not the powerhouse that a desktop cpu/gpu is these days. Not yet anyway.
Another thing to note: I'm not sure what level of realism you are trying to achieve, but all the things you mention are typically associated with raytracing/raycasting. And that's a whole other bag of tricks as you can forget about real-time interaction, especially on mobile devices.
No way around it: coding and creating with real-time graphics in mind is hard and it's even harder on mobile platforms.
I want to transplant a 3D program written in OpenGL on windows platform to Android, but I wonder if it can run smoothly on general Android platforms, so i want to estimate how much hardware resource is sufficient for it to run smoothly. It is some kind like the hardware requirements for a software or 3d game that a company will recommend the users. I don't know how can i get a hardware requirements of my program when transplant to Android.
i used gdebugger and it gave me some information but i don't think that is enough for me. Anyone here have some idea or solution? Many thanks in advance!
If your program is simple enough, you could write up some estimates about texture fill rate, which is a pretty basic (and old) metric of rendering performance. Nearly every 3D chip comes with a theoretical fill rate, so you can get the theoretical numbers of both your desktop system and some Android phones.
The texture memory footprint is another thing that you can estimate, especially using gdebugger. Once again, these numbers are known for most chips.
This is a quick way to produce some numbers, obviously without any real life performance guarantees.
The best way would be to test it on an actual device, and get an idea of what hardware works well. You could distribute a beta app and get some feedback too.
Depends on feature set that you use. For example, if you use FBO, the device will have to support framebuffer extension. If you use MSAA, smooth line, the device will have support corresponding extensions.
After listing down your requirements, you can use glGet to check for the device suppport
http://www.opengl.org/sdk/docs/man/xhtml/glGet.xml
i am developing an android app using OpenGL ES for drawing and i use the draw_texture extension as it's the fastest.
I read you have to query the string to check and see if the drawing method is supported on the phone and degrade gracefully if not. My main concern is, how common is it really to have a device which doesn't support this?
I mean, drawing textured quads (the only method standard in OpenGL) is so slow the game would hardly be enjoyable on these devices.
I'm just curious if it's worth the time to support these devices.
I don't know an example of Android device lacking the draw_texture extension, but it is highly likely that such devices actually exists in minimal amounts. It's definitely not worthed to dedicate effort in supporting them, but on the other hand it is nearly trivial to switch between drawTex and quads, especially if your code supports rotated sprites.