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:
- 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.
- 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 -
- A 35k model with textured materials
- A 56k model with textured materials
- A 35k model with procedural materals
- A 56k model with procedural materials
- A 12k sphere with basic lambert
- 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.
Most of you know this - but to get everyone on the same page - I only
use my iPhone for this photojournal. I have a set of lenses (from Photojojo)
that stick onto my case using magnets to enhance some of the photos. I
tried to tag any posts that use one of those lenses- macro, 8x zoom, 2x
zoom, wide angle, and fisheye.
In any case, Sunrise Stanford has it's own dedicated blog now. I hope you enjoy some representations of the beauty I see in the world around me.