I kind of rewrite export script for Blender that gives you your object's vertices and texture coordinates (when you do uv unwrap) as a float array. You can find it here: http://halmi.sk/uploads/android.zip Unzip and put it into Blender's script folder. Then select your object, and from menu select File->Export->Android. I'm just starting with opengl, so maybe it's not the most efficient way to import object into Android, but so far it worked for me.
Weston Weems wrote: > This is exactly the sort of discussion I was hoping to have. > > I didnt actually expect to find allt he tools working for me out of > the box, but rather hoped to help piece together bits that anyone > could use to help expedite it. > > I appreciate your time... and if i come up with some tools that help > out, you guys will be the first to find out about it. > > > On Mon, Mar 15, 2010 at 1:04 PM, Robert Green <rbgrn....@gmail.com> wrote: > > Ronnyek, > > > > There are a few methods of picking a 3D object from a 2D coordinate. > > The ones I know of are (in order of popularity): > > 1) gluUnProject to get a ray, then use a collision detection > > algorithm to check against your object bounds > > 2) Use the color/depth buffer > > -- This involves a special little bit of work. > > -- When a touch comes in, on the next draw, you render the pickable > > objects without textures, lights, etc, each with a unique color. Keep > > your Z-Buffer on and you will have colors that represent the objects > > which are ordered front to back. You then check the framebuffer to > > see which color is at the touch point and you will then know your > > object. Erase and do your normal rendering after. > > 3) You can implement something like gluUnProject yourself if you > > create your modelview matrix look-at in a separate matrix. It's not > > as hard as it sounds. You can create your vector starting with 0,0,1 > > then translating based on the touch x,y and field of view, then > > finally multiply it by that matrix and you've got it. I'd rather just > > use unproject, though. > > > > As far as loading models and 3D data... > > The fact of the matter is that there are so many different file > > formats, each with its own tradeoffs. If you want static geometry, > > you can just write an OBJ loader. It's not very hard and I actually > > posted code to my first one: > > http://www.rbgrn.net/content/313-light-racer-3d-days-1-2-learning-opengl-es > > > > Animations... > > If you want animations, things get harder. You have to pick a tool to > > use to make your animations, then you have to figure out if that tool > > exports a format that you can find or write importing code for. Good > > engines write their own importer/exporters for their own formats. Why > > no universal format? Different formats allow for different features. > > Since each game specializes in some way, it's hard to make it > > universal. It gets worse - you can't just "import into opengl." > > Opengl is great, but it deals with primitives. If you want to > > animate, you need to understand some 3D geometry foundation because > > you have to know how your animations really work, down to the vertex. > > > > I ended up using Blender/MD2 as my tool and animation format. You'll > > see all of this in our upcoming game next month. MD2 is nice because > > it's very easy on the CPU if you write an interpolator in C and use > > fixed point math for it. The loader took a few days to figure out but > > there are docs online that go over the file format in detail. The > > problem with it is that since it doesn't use bones, you can't combine > > top/bottom animations and you can't just reskin. You also can't mount > > weapons easily (though we did it with some nasty hacks). > > > > As for levels.. I haven't found an optimal solution yet. We used > > blender and manually partitioned out space into visible areas, > > separated by visibility portals. I wrote a visibility portal > > occlusion algorithm so that we only draw the areas that are currently > > visible. We create a separate collision mesh which I load into an > > octree (native code is a must for this stuff) and perform collision > > tests on (also always in native code). The advantage to this is that > > it uses off-the-shelf tools and formats. The downside is that since > > we don't use a proper level editor, we don't get nice things like > > built in entities, surface types, etc. We had to hack it all in. > > > > How long did all of this take us to learn and do? I started learning > > OpenGL ES last september and really started this game in November. > > That puts us around 5 months on this title and we're still a good > > month away from being done with it. Too long for my tastes but it > > does take a lot of time to learn how to do all of this stuff so I'm > > glad I invested the time to learn. > > > > On Mar 15, 1:00 pm, Mario Zechner <badlogicga...@gmail.com> wrote: > >> Hi, > >> > >> let me start by answering your questions: > >> > >> 1) What you refer to is usually called picking and involves a bit of > >> math. Your initial goal is to get a ray (defined by a starting point > >> and a unit length direction) from your touch coordinates. This can be > >> done via GLU.gluUnProject (http://developer.android.com/reference/ > >> android/opengl/GLU.html#gluUnProject(float,%20float,%20float, > >> %20float[],%20int,%20float[],%20int,%20int[],%20int,%20float[], > >> %20int)). With this ray you can now check wheter an object in your > >> world has been hit. Usually your objects will have something called a > >> bounding volume like a sphere or an axis aligned bounding box (nice > >> keywords for google). All you then have to implement is a ray/bounding > >> volume intersection test which tests the ray against all your objects' > >> bounding volumes. Among the objects that intersect with your ray the > >> one nearest to the ray's starting position will be you touched object. > >> Simple eh? :) > >> > >> 2) There's no support for any 3d formats in Android out of the box and > >> i guess that will stay this way for good reasons. > >> > >> 3) That's a matter of taste i guess. I myself use OpenGL for > >> everything. Others add standard GUI widgets on top of the > >> GLSurfaceView. The later is a bit easier while the former is more > >> flexible. Chose your poison. > >> > >> 4) That would be cool, maybe we can collaborate :) > >> > >> Additionally i want to link to Robert's great introductionary text on > >> Android game programming you can find > >> athttp://www.rbgrn.net/content/54-getting-started-android-game-development. > >> Make sure to also check out the other articles on his blog. > >> Furthermore i'm currently writting a small and hopefully easy to use > >> game programming library for cross plattform development myself. It's > >> called libgdx allows you to code up your games on the desktop with > >> standard Java emulating OpenGL ES via Jogl and seamlessly deploy them > >> to an Android device without changing a line of code. I'm currently > >> giving it the finishing touches, the only thing missing is the OpenGL > >> based GUI system i rewrote from scratch as well as the Audio classes. > >> If you want to collaborate just drop me a line, the more hands the > >> faster the lib grows. You can find info on the lib > >> athttp://www.badlogicgames.com > >> andhttp://code.google.com/p/libgdx/. > >> > >> Hth, > >> Mario > >> > >> On 15 Mrz., 17:28, Ronnyek <wwe...@gmail.com> wrote: > >> > >> > >> > >> > Hi, I'd like to just start off by saying I've done a bit of research > >> > into 3d development, and am confident in simple lets build some simple > >> > 3d objects, and render them... would be easy. > >> > >> > I also have a very long history writing software, understand how games > >> > work internally etc. I understand 3d concepts, 3d space, shapes, > >> > camera, lighting etc... but I do have a couple questions. (and no I > >> > dont expect anyone to hold my hand through it, more than happy to put > >> > the work in) > >> > >> > 1) Initially I wont need it, but how do you handle for touch > >> > interactions with a given 3d object on screen? I've heard of doing > >> > things like mapping screen vertices to objects and when you touch in x > >> > region, you are touching x object. Is there an easier way? > >> > >> > 2) I intend to take a 3d format and import into my app, and there is > >> > plenty of documentation on the formats I intend to use, so I can write > >> > an importer... but does android 2.1 support anything out of box? > >> > >> > 3) For basic menus and screen overlays, are those typically drawn with > >> > opengl stuff too? Or a diff sort of view layed over the top of > >> > glsurface? > >> > >> > 4) I don't know if I'd say I want to build a 3d engine for android, > >> > but I definitely think writing some useful utilities and wrappers and > >> > converters to simplify some of the most common bits, and perhaps > >> > document my efforts in blog, might be helpful to others. These bits > >> > I'd like to make opensource.. any recommendations on features you'd > >> > all like to see? (or maybe this is reinventing the wheel) > >> > >> > I appreciate everyone's time, I assure you I've done some research... > >> > and want to help prevent future newbies from running up against the > >> > same problems I am. (trying to build wrappers and helpers and > >> > converters etc) > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
