9/12/12

iBooks and 3D models...

I have come to the conclusion that the iBook authoring tool (and iBooks in general) are just not logical.  I'm trying to accept that, so I can move on and not suffer the same aggravation level that I do now.

I put out a notice, a plea for help really, on a couple of the forums that I follow that deal with new technologies and 3D models.
"So, this might be a long shot... but I'm hoping that some of you may have been working/experimenting in other delivery methods for 3D models. "

However, this is not really an issue that I think has come up for many people in the iBook arena. (At least not the ones I know.) And conversely, those that are used to working with real time 3D models are not really working with iBooks.  It's a subject that I can't address at work for the time being, but it's still very much so on my mind.

Screenshot of the DAE file from the iBook

So, we at Stanford have the "problem" that we are media rich for the anatomy section.  Large images, renders, movies and 3D models.  Now, it's that last one that is really giving me fits.  2 reasons:
  1. Because we are hoping to get this book to run on all three versions of the iPad, the 3D models have to be pretty low res to fit.  Luckily, they were designed with real time in mind, so it wasn't that big of a leap.  But, they are still causing the iPad1 to crash.  At least... I'm 80% sure it's the models.  Everything works, as long as the user is patient.  But what user is actually patient with anything?  Otherwise, the book crashes, and not always with a series of replicable actions.
  2. Animations are supposedly able to be included in the DAE format.  I can't seem to get this to work... anyone know if animations driven by a rig are needed, or if it's only key framed animations?  I'm using the OPENCollada plugin to export the model, which supposedly supports animations...
    EDIT: I gave up on animations.  I would be happy with just a consistent working 3D model.

In any case, I've taken the models down so that they are at least between 30K-60K, if not lower.  (this is for the entire hand - as seen in the screen shot above.)  But I think it's the number of materials associated with the model that might be killing the iPad1, even if the DAE file isn't huge (ranging from 5 to 16mb... and it's actually the larger one that performs better).  Unsurprisingly, transparency and normals maps don't work in the DAE format, so it's only the muscles that have individual striation textures.  I have on run some test variations with completely unreliable results thus far.

While both models 'white out,' only the one of the left does so consistently.  Despite being the same number of polygons and same number of objects.  The only difference is about 5 more materials in the model on the left, which lends credence to the material level theory.

So, when I was testing, I ran into an interesting issue.  There is a threshold where a model causes the iBook to crash every time that page is brought up, a point where the model just 'whites out' and disappears, and finally the point where a model shows up just fine.
I set up this test in a 'test' iBook - which may be part of the problem, but I wanted to remove that as a variable for now.  From the various testing I have done, it seems that the overall load on the book has an impact on whether the 3D models will work as well.  When I went to some 2K graphics for some of the interactives, the model performance decreased significantly. ):  In any case, my testing models -
  1. A 35k model with textured materials
  2. A 56k model with textured materials
  3. A 35k model with procedural materals
  4. A 56k model with procedural materials
  5. A 12k sphere with basic lambert
  6. A 50k sphere with basic lambert
Overall, I have a feeling that it's not the count - I have models that I was testing (for limits) at 165K that show up just fine on the iPad1. In the actual book, even.  No issues, doesn't crash, etc.  But it only has some basic procedural color maps on it.  Which is why I started thinking it wasn't the size of the model, but the number of textures.  I included the sphere because I also started wondering if it was the number of models within the 3D DAE file as well.

However... all of the models in the above testing scenario worked.  The only one that 'whited out' occasionally was actually number 4... which makes no sense to me.  What so ever.  I would have thought it was going to be number 2, if any of them.

I put each of the models on their own page in the test book, but the model that constantly whites out in the actual book is right next to another model that works all of the time (also, making no sense, as it is the same model with slightly different textures, but the same number).
I decided to reduce all of the models in the actual book anyway.  Previewing the book with the reduced models in it didn't have an affect on the usability.  If anything, it went down.  So strike that.  The client doesn't want to really change the look of the models, so I am trying to not loose all of the textures on the hand.  I may need to go to a single model with a texture atlas instead of individual models though...
What aggravates me the most about all this is the lack of consistency.  If a model crashes the book, it should be that model that needs to be addressed.  But, there is not a series of replicable actions that I can get to crash the book.  Heck, I can't even get the same model to not work every time.  This is the source of my frustration.  If I knew which models needed looking at, I could fix them.  Otherwise, I'm shooting into the dark and hoping to hit a bulls-eye.

No comments: