I need to provide some 3D rotation of images, like credit card (please check the video in the link)
I want to know is it feasible or not, in the case of Android. If yes, how can I do that.
The card must have some thickness.
It definitely is feasible, but you will have to do some studying:-).
Start here: http://developer.android.com/guide/topics/graphics/opengl.html
But you may also achieve your goal by just using the video you have posted in your link.
Some context would be useful such as will this be a loading screen? Something in video? etc?
For instance, if you are trying to make a website style layout and have the card up at the top always spinning, I would advice against that on any mobile device as its a waste of performance.
If instead you are using it as a loading screen then again I would advice against it as you are going to spend a lot of time initializing open gl and loading the texture and mesh for the card as well as any lighting you need and then initiate animators and do the spinning etc.
As previously stated OpenGL would be a way of doing this; however, this is not a simple few lines of code. This would be quite the undertaking for someone unfamiliar with OpenGL and 3D modeling to accomplish in a short time frame.
Question: do you require a native Android app, or would it be alright to use Flash Player? You can find tons of interactive 3d geometry demos on http://wonderfl.net - I forked one that had a plane, switched it to a cube, and you can download the results -
3d box on wonderfl
Not OpenGL - the example I found was Papervision3D (which is out of date a couple of years) - but software rendering is fine for 12 triangles. You, of course, would have to import your card faces as texture images if you want to make it look like a credit card.
Related
I'm working on a robot that is controller via the VR headset and sends a real-time video feed to the headset.
I've chosen to go the native way on Android and now have everything I need to receive the video stream and encode it (using GStreamer) and also to send the control data to the robot via UDP.
The last thing to do (and the one I most struggle with as I nave no prior experience with computer graphics) is to draw the image (encoded camera feed) to the screen. In the last few days, I've been reading stuff about how Vulkan and OpenGL works, I've also went through the examples provided in Oculus Mobile SDK (mainly VRCubeWorld_SurfaceView) but that's way to complex for what I need, I've tried to simplify it so I could just draw two images, but then I thought.
Do I even need any of that? And this question might sound stupid, but I really don't have any prior experience doing this.
I mean, the example is using OpenGL to basically compute all the layers of the 3D scene, apply colors and then fuse them together to get a final frame that is passed to VR_API via the function:
vrapi_SubmitFrame2(appState.Ovr, &frameDesc);
Can I just take those images, and somehow force them into the frameDesc structure to skip the whole OpenGL pipeline? If so, can anyone knowledgeable enough point me to a working solution?
I don't need any kind of panning over the images, just to render them. Later I'll be using head sensor data, but it won't actually do anything with the "scene".
So I'm doing a 3D game for kids for Android and iOS in Unity, but i'm new in game developing and it's been really difficult to plan the assets.
We need to create 2D animations (paper like characters) and the characters have to be really detailed with great animations.
We have been thinking of several options:
We could create frame by frame animations but our designer says there has to be at least 24 images per second (because of 24 fps per second) with this the app will be very big.
Other option is to create 2D models in Blender and animate them there, but it's a lot of work and could take a lot of time.
The last option is to have the pieces of the model an animate it throughout code but it's a lot of work and I believe the quality of the animations would be low.
What's the better way to create 2D animations in Unity?.
Thank you!
Have you explored the 2D sprite engines that are available in Unity? Whoever said "Unity isn't really an engine designed to work with 2D stuff" is talking guff. I have just started working on a hobby 2D game and am using a Unity plugin called Orthello (see WyrmTale website for info). It handles sprite sheets, animations, collision detection and more without you having to write loads of code to do this. The learning curve is a bit steep and the examples on their website aren't the best but I found replicating the sample solutions that come with the download the best way to get something working.
There's also a similar tool called Sprite Manager 2 but you have to pay for that (I think). Check out the asset store for more information.
I would be really interested to hear if Orthello is what you're looking for and how you find working with it - please let me know via http://markp3rry.wordpress.com if you can.
Just because the app runs at 24fps doesn't mean you can't just display the animations for more than one frame of the main loop. It might not be smooth, but then again looking at the sprite sheets of games like super street fighter it doesn't look like they're at anywhere close to 24fps (the sprite sheet for Dhalism in SF3 Alpha is a 210kb .gif file on my computer, and there's less than 252 frames of animation on it. Likewise, the total storage space take up by every character sprite in Dustforce takes up a mere 7mb, though those sprites are just 192x192, maybe too low-res for you. They do look like paper though). I doubt that anything involving blender would take longer than hand animating -- Blender does key frames for you.
I am looking at making a simple game. Without giving out the entire story, I need to draw two pieces of fruit (with arms and legs), who do different movements. They can do a few different actions (less than 5) and they also react to each others actions.
I'd like it to look simple. Very 2D, kids sort of graphics. Maybe shaded, but nice bright happy colours.
Let's say an action is to 'throw ball'. I'd like to see a semi smooth arm action. Smooth if possible.
So, I found a tutorial, which used sprites, and a PNG with 3 different states of a person walking. So, very basic. And I was able to make it walk across the screen, leading each part of the PNG for each state, and iterating through that over and over again, while moving the image.
I got pretty happy with my progress, and would like to base my game on that sort of model - but ... is using sprites, and loading areas of the PNG to make the image move correct? My PNG would be large if I want maybe 20 images just to throw the ball.
But if that's the right way to go, then great! It seems you can go with OpenGL and all that, but that's for 3D graphics right? Using sprites, and a few PNG with images would be OK for perforamnce and all that?
OpenGL is a valid choice for 2D or 3D, you shouldn't have any performance issues.
It will work fine for your game, and would likely be much smoother than trying to use android animations, which are not hardware accelerated on Android 2.x.
I'm working on a live wallpaper that incorporates some water ripple effects on touching the screen but I'm a little stuck.
Would it be better to create multiple images and loop through them to create a ripple animation or would it be better to distort the bitmap a bit before I place it on the canvas?
This is a video of a very nice ripple effect done through OpenGL.
I don't have any experience yet with OpenGL and was wondering if it is still possible to create a 2D water effect on the live wallpaper?
I wanted to implemented a realistic ripple effect in Android too, so will share my experience:
As a reference implementation i took Sergey's Chikuyonok JavaScript port of Neil Wallis Java algo. Here's a playground where you can experiment with original JS code: http://jsfiddle.net/esteewhy/5Ht3b/6/
At first, i've ported JS code to Java only to realize that there's no way to squeeze more than 1 fps on my Huawei U8100 hardware. (There're several similar attempts on the net with the only conclusion: they're ridiculously slow).
BTW, this SO answer was quite useful to get basic understanding of how to code an interactive graphics in Android: https://stackoverflow.com/a/4946893/35438. I've borrowed fps counter from there.
Then i decided to try Android NDK to reimplement original algo in pure C (my first encounter with it in 10+ yrs!). Despite NDK's docs being somewhat confusing (especially as to requirements and prerequisites), it all worked like a charm, so i was able to achieve up to 30 fps -- it might not be too impressive, but still, a radical improvement over Java code.
Finally, i've put all my work online: https://github.com/esteewhy/whater , so feel free to play with that. It contains:
Interactive bouncing ball code mentioned above (just for the reference).
Water ripples Java port (slow like hell!)
Water ripples C implementation (needs NDK to compile and JDK to create .h file).
(The project is not "clean", i.e.: all binaries are there, so can try to run it "as is" even without NDK.)
You can find an example of a touch ripple effect here:
https://github.com/MasDennis/RajawaliExamples
It utilizes the rajawali OpenGL ES framework/library. You can download the rajawali examples app from the market to see how it looks. Browse through the "src" folder and you will see the TouchRippleEffect activity and renderer. Hope that helps.
I'm no expert in this, but I believe the typical way to do water effects in OpenGL is with a fragment shader. With a static image as a texture, your shader can vary the texture coordinates used for sampling that image, to distort it in arbitrary ways.
Calculate the pixel's direction and distance from the center of the circle, and adjust the texture coordinate toward or away from the circle's center based on a sinusoidal function of the distance, and you should get a nice ripple effect.
Judging by the description of that YouTube video you linked, it sounds like that's done by using a grid of triangles and adjusting the texture coordinates only at the vertices. That should work too, but it won't look as good unless you use a rather fine grid. Doing it per-pixel with a fragment shader is the ideal, but I don't know whether that would cause performance problems on a phone's GPU.
I am a fairly "newb" Android developer, and I would like one of my first projects to be a live wallpaper, however I am conflicted on whether I should be focusing on Canvas or OpenGL for it. Being new to this I know I should master Canvas first since it is easier to use, but I prefer to learn from real world projects that I have an interest in, even if it's a little backwards at times.
I have used both before in very basic ways, and I understand the general concepts to them, but I am not sure how they transfer over to the realm of live wallpapers. I figure that the full blown speed of OpenGL isn't required on a live wallpaper, since running it at max FPS would just run down the battery more than it necessary, but at the same time I am worried that using Canvas would cause lags and stutters when doing things like changing home screens.
I have been leaning towards using OpenGL ES 2.0, both to keep performance optimal and because my initial ideas for the wallpaper involve a lot of layering that I am not sure Canvas is capable of, but I'd like a more experienced developers opinion on whether or not all of the extra work involved in using OpenGL (especially in relation to live wallpapers, from what I've read) is worth it.
If you can get away with just drawing to a canvas (e.g. cube example in SDK), that's much less work. Because of the simplicity of the animation (no bitmaps), the cube is able to achieve a high frame rate without difficulty.
If you want to use OpenGL, you will need to use a supplemental package, such as GLWallpaperService, AndEngine, or RenderScript.
http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live-wallpapers
http://www.andengine.org/forums/tutorials/live-wallpaper-template-t258.html
Browse the Android source code to see how the stock wallpapers (e.g. Grass, Galaxy) are implemented using RenderScript. This link may work, but no guarantees: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.1.1_r1/com/android/wallpaper/ (then scroll down to the wallpapers)
Moonblink has discontinued his project, but if you're really keen, you can try researching his work (Substrate) starting here: http://code.google.com/p/moonblink/source/browse/wiki/Setup.wiki
I ended up using OpenGL as halfway through the project, canvas drawing proved to be too slow for what I was trying to achieve. Using OpenGL caused a massive performance boost. Unfortunately I had to refactor my code, so I would reccomend using OpenGL from the start. Dirty rendering is supported by OpenGL as well as the wallpaperservice's structure doesn't rely on the way you render things so you would still be able to create a wallpaper that doesn't drain the battery. Actually a well programmed wallpaper doesn't render when it's hidden. As the wallpapers shipped with android don't follow that pattern, live wallpapers now have the bad name of being battery suckers. Really a shame..