I am also considering going the C route - although even there one must beware of Endian issues in future products.
However, I started the thread because I was hoping to do it in Java. Endian issues could be handled by just having to sets of data, and reading the right one. However, its unclear to me the relationship between native C arrays (which underlies the glSurfaceView API) and the Java code needed to fill them. I currently use several lines of java to take a byte array and make it into an Int array, which is rather mysterious to me. There is a method to just wrap an array, but its never worked for me. Can anyone shed clarity on this? On Sep 7, 2:43 am, Robert Green <rbgrn....@gmail.com> wrote: > Lance, > > That's a good idea, though often times for 3D Models you'll need a few > different object groups of given name to be loadable. You can simple > insert them into a HashMap and serialize the whole thing. It > deserializes surprisingly fast, especially if all you're storing are > ints or floats for the data. > > If your data is less structured or more linear, you could certainly > write up something to generate a java source file with the data in it > like you said. It's probably going to load nearly the fastest, though > it requires a little more programming than serialization does. > > I'm moving on to proprietary binary file formats in C now though since > they are the smallest and I ran into a major asset size issue on > Deadly Chambers which wouldn't have happened had I used my own format. > > On Sep 7, 2:48 am, Lance Nanek <lna...@gmail.com> wrote: > > > One bizarre option you might want to consider is pre-generating Java > > files with arrays in them. It benchmarked faster than reading files in > > via Java NIO when I tested it for my purposes. I'm only doing 2D, > > though. I use a script that takes a bunch of individual graphics files > > and puts them into a couple atlas textures, then pre-generates the > > texture coordinates for the two triangles needed to draw each graphic. > > So each pre-generated atlas texture has a pre-generated Java file with > > an array of all the useful texture coordinate sets for it, and > > constants for the offset into the array to use to get them for a > > particular graphic. > > > On Sep 6, 7:33 pm, SChaser <crotalistig...@gmail.com> wrote: > > > > My app has large vertex arrays that are pre-computed before I even > > > build the app for distribution. I'd like to store these in assets > > > (recognizing the size limits of asset files) and read them in with > > > minimal computation. > > > > Can I store them in binary, and just read them into an NIO buffer, and > > > then wrap it for GL, or do I have to go through the whole compute > > > intensive (?) process of reading it in, making a byte array, and > > > converting that to an integer (in this case) array? -- 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
