Very new to Unity myself and am running in to a couple of problems. For a school project I have to make a small game. My team has created a level in Google Sketchup, which I have exported to a 450mb FBX file. When I try to import this FBX into Unity the program seems to hang and pictures a loading bar that does not seem to move, but just says ‘hold on’ (see attachment).
I am working with Windows 7 on my Acer laptop with the following specs:
i5 intel processor
NVIDIA GeForce 1 GB
6 GB RAM
A good playce to start is to find out why your File is 450MB in the first place. That’s way too high.
Use Sketchup only if you are going to use cubes and cube-like shapes. Curves and cyllinders … everything round essentially coming from SketchUp is way too high poly to be used in Unity.
[edit] ESPECIALLY if you are trying to create Colliders for this 450 MB file as well.
Colliders for a level should ALWAYS be as LOW as possible. Waaaaaaaaay lower than your geometry. At times only cubes or single polygons to block the player.
Thanks Motionblur. I suppose I could turn of colliders, it’s not really needed. How big should the FBX file be at the most? Like I said I am new to Unity and Sketchup, so any help would be great! Thnx again!
Mh, just that i have asked, can it be that you have the textures embedded into the FBX file? That could explain the exorbitant big file size too. Keep them separated i would say. This saves you headaches when you want to modify the textures at a later point. And gives the importer less work to do at which it could crash. My guess is that you simply ran out of memory during the import. Unity is 32 Bit …
The second point is Sketchup. It is known for being super fast for modeling, but also known for making not really good and clean geometry. Lots of unnecessary edges and vertices. I would suggest to remove all those unnecessary geometry in a modeler like Blender. You may even be faster to recreate the geometry in Blender. Sometimes faster is slower …
Keep in mind that Unity is a game engine. Means you have to display the content in real time. Which requires around 50 frames per second to look fluid. Not a 3D modeler that eats megapolys for breakfast, and where you render several days for a single image.
There is no real value at which you could rely at. This variys from game to game. And its not mb, its polycount. The general advice is: As high as necessary to display the needed geometry. And as low as possible to be displayable in realtime. That`s so called Low Poly.
A game character is usually between 5.000 and 10.000 polys. But it can also be at 500 polys or 50.000 polys when the project requires it. Same for level geometry. It highly depends of what you want to achieve. And its not only the graphics that counts here. Its also the shaders. And the code. And the resolution. And the target platform. All those things that makes a game. The overall goal is always to keep the frame rate at a playable level.
I would say have a look at the example files that comes with Unity. This will give you a starting point how game content looks like under the hood.
It’s not a matter of filesize actually. It’s a matter of polygons and splitting your model into as many reusable chunks as possible if you want to work memory friendly. Also if you want to use occulsion culling you should split your model into small chunks.
What Tiles said is also an important thing to consider - make sure your textures aren’t embeded into your file. I still guess that you polycount is too high, though.
For advanced (and I stress advanced - the videos do NOT cover any basics) modularity - http://eat3d.com/udk_modular
This is Tor Frick’s Modular Masterclass in UDK. Create one scene completely modular with only ONE texture. Lots of fantastic information in here. Worth every dollar.
