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
