Just realized that this post was about indoor scenes. But the same should hold true.
Although I’m not a unity engine developer, so I can’t comment on how internally unity handles culling and object rendering in their engine. I can only offer what I would assume their engine does on some level.
A giant full scale city as a single object is not a good idea. In doing it this way you are not allowing object level culling to occur as your entire city will be deemed within view. Then the entire vertex buffer and index buffer would be submitted to the gpu every frame for rendering. Depending on the size/complexity of your model, this could be a big problem. It also hits the collision detection pretty hard.
Break your large model into smaller objects that can be instanced/scaled and rotated to create uniqueness with the same assets. Then not only will your memory be smaller, you will most likely see better performance as you are not saturating the gpu memory bus and you can allow for advanced instancing on the gpu.
If you collide with this object, it most certianly will operate more efficiently by breaking it up. Most engines use a spatial partition to quickly rule out objects that should not be checked for collision. If you have a large model, it will be checked once in the bounding area, and then again once per poly to determine collision.
I just asked because I’m gonna be one of the many people buying Unity 2.5 for Windows, and I was going to spend my time creating the assets for the game, so hopefully by the time 2.5 is released all of the games assets will be completed.
I also asked because I wanted to make sure I was creating everything correctly, so I wouldnt run into trouble when I purchased 2.5.
So if anybody wants to give me any tips or pointers about level/map, character, and 3D asset creation for use in Unity so I dont run into problems down the road, I’m all ears!!!
Uhm … well. That’s kind of a large question to answer in a short post. The best thing to do is start reading the introduction. I assume that a few things will change since there’s UI improvements coming with V2.5 but the general workflow is explained very well there.
If I may speak from my own experience: I couldn’t use Unity the first week I got my hardware and started reading the manual. Actually when I first got unity to actuall boot up I had a running start and lots of things went much smoother than when I was installing a new programm and simply trying to do things without even knowing WHAT I was doing
For a very good introduction go here:
Read the user Guide for a good overview and the FAQ to see how to import from your application.
I was mainly looking for little tips that more experienced Unity users have discovered through their working with the engine. Like little quirks that may not be documented.
For example: Do maps/levels need to follow the “Sealed World Rules”. Little things like that.
Nope. As for other tips…hmm, well, Unity uses view frustum culling, so you might consider making a portal culling system using triggers, in which case you’d definitely need to break the level geometry up into more than once piece.
How extensive should I break up the level geometry?
I’ve read Unity manual part about the optimal polys per object/section be between 1500 - 4000 in terms of optimization for the GPU.
So in the following situation:
Case #1 would seem logical because each room and the corridor would be separate objects. But in terms of optimization (and perhaps performance) Case #2 would be ideal.
So which one should I strive for? Or should it go even further than Case #2 and have even more sections.
On a side note, does breaking up level geometry (like in Case #2) negatively affect applying shaders (such as Normal/Bump mapping) to it?
I ask because I know some engines are finicky with applying shaders to level geometry and require something like Case #1 in order to correctly use pixel lighting with the shader.
It’s kind of a balance…the more sections you have, the more draw calls, which reduces performance. On the other hand, you can have issues with too few sections over too large an area (especially with pixel lights), so I’d say break it up a reasonable amount, but not too much. There aren’t any issues with pixel shaders when doing that.
just out of curiosity what 3d modelling software are you using? I’m a 3d max person myself so I could offer you some key pointers with regards using max models etc
I am building a large scale city (with interiors - i assume loaded in as needed), roughly 20sq miles worth (a circle btw). Initially I am only focusing on 4 smaller areas within the perimeter, but for the purposes of construction in regards to :
heightmap data - unity brought the entire height map of the area no problem. The loco engine, weather package (skybox + particles), and terrain are running above 60fps on average , but there’s no city on it yet. heh
road data from openstreetmap - i’ll be building the city in another program and then exporting it via obj and then adding detail where needed. The bitch is that the hight map would have to be broken up and brought in for each area to get the road/lot/building geometry to follow the elevation.
to make 4 separate areas that should fit together in my mind seems harder than making the entire city in one project and then breaking them up after the fact. or possibly obscuring the other 3 quadrants of a city while the player is in the 1st.
I also read somewhere that the only things that hit the card are in the cameras view. Right now my draw distance is super high, but once the city starts getting placed wont the fog combined with a shorter draw distance and buildings breaking the line of site so you can’t see from one side of the terrain to the other be workable?
Wondering what you cats think.
Appreciate any word, ez.
Especially as “in cameraview” means: independent if it is blocked by something else or not.
And especially this does not split your models in smaller parts, so you better ensure that your terrain / world consists of smaller parts if you don’t use Unity’s own terrain.
another important point is the memory usage: your level will be loaded in there, not only whats in view but whats in the level