Mobile VR: Wrong Choices in Art Pipeline That Caused Problems

—- There are a bunch of decisions that I regret, that could have been avoided if I knew it ahead of time. Here I share with you, by far the worst decisions that I made for Project Voyage.

The consequences of not keeping the same unit across different softwares

The intention was good: because we are making an educational experience, we originally wanted all the things to be real-life size. So I think OK, if that’s the case, it would be an enormous number of scale in maya. I also felt that if everything’s done in that way, it would be easier to manage the size of the assets. Ok I think, and I made the whole scene about 100m by 100m.

However, it created a lot of problem in our pipeline. Basically, when imported into unity, the size is HUGE, and we didn’t notice that at first.

  1. Clipping problem: Far plane, near plane.

When we render the scene, we found that on Pixel, the overlapped faces had weird behavior. It is flickering, and seems that unity could not tell which plane is in front of the other. It is Z-fighting in Pixel. ( Do we have image?)

The reason we found was that, unity is calculating the scene with the ratio of the far plane and the near plane. It divides the space according to that ratio.

(Image Illustration)

Because we needed to see far away, the far plane for us was about 10000. Also, we needed to see the Google Daydream controller, our near plane need to be about 0.02. Because the ratio is too large, it could not render properly. (More tech details)

So our kind programmer made the scene size 0.1(I need to check) and keep on working.

2. Unity crashes every time I try to bake light map

But seems that 0.1 isn’t small enough. When we finally chose to use forward rendering and were ready to try baking light map in unity, it always crashed during the bake time. I found that if I scale the scene down, it could bake the light map (but still it had weird black color) so the scale was the problem.

Also, because by that time, all the things has been set up according to that scale, and it would take a long adjustment time to make everything correct, we decided not to use maya to bake light map instead. Though the shadow baked by maya was beautiful, and I can have full control of every aspect, it created about 2 hours extra amount of work every time we changed the scene, and it was not applied on the small assets (trees, animals and plants were only baked with ambient occlusion). And also! If our programmers move the assets around in the scene, the light map will not be correct. This is painful: in order to make things perfect, we found a way to export Unity scene assets into an fbx, and we are still experimenting with it, hopefully it will work.

3. Affecting the Doppler Effect of sound

(Maybe talk more about how scale works in Unity)

Accidentally Freezed the Transformation of the whole SCENE

When I realized, I had already pressed the button. When finally put everything inside the scene, I selected the scene and chose freeze transformation. It cleared up all the TRANSFORMATION information on all the objects: which means, how much the objects has been rotated & scaled from & translated from the original models has been lost…

Be careful about these small things. This is very important to scene management. Extra time was wasted.

  1. No longer easy to replace the models by a click

When our other artist want to make small modification of the tree models, we could have clicked ‘replace A with B’ button and magic would have happened. However, because I freezed transformation, we would need to import the new tree, transform it into new position, and then adjust the scale and rotation.

To mend that, we tried snap tool, and some simple scripts, which kind of helped, but all these time were not necessary. It could have been easy.

 

Leave a Reply

Your email address will not be published. Required fields are marked *