When to make a separate object?

[Moiety Jean]

Hi again!
I'm hoping for some advice with a complex terrain mesh. When is it good and bad to create a separate object to convey portions of a landscape? Like, say I have a portion of a grassy plain that will jut up into a cube shape (with the same textures), or a portion of a hill that will suck inward to a cave shape (with different textures). Would it be advisable to make that cube portion or that cave portion a separate mesh that lines up just perfectly with the mesh of the plain or the hill?
I'm asking because I'm getting into some very complex protrusions and concavities that collapse into windows and doorways, and I'm concerned that I will end up with too many faces in one object (the object basically being the ground you run around on, up and down and through spiralling areas) if I don't divide it up. I read somewhere that there is a limit to the number of faces an object in an age can have.. is this right? Does it help to separate portions of the complex structure into their own meshes, or does this start to cause problems such as avatars falling through micro-separations between walls and floors, etc?

[Chacal]

It is a good idea to separate complex objects because there is a limit on the number of vertices on an object.
Also it could make it easier to apply materials and textures.
It should not make players fall throught the cracks because visible objects shouldn't be used as physicals anyway, you should have invisible colliders for the walkable areas with no cracks in them.

[Grogyan]

I had to cut several objects down because the plugin complain, and all were just shy of 10,000 vertices, I even had to break them down into objects with less than 5000 vertices, I believe that to be the limit.

One trick you can use though, is add a "decimator" modifier to the object to reduce the vertice count.

[Moiety Jean]

Thanks, guys, this is helpful to know.
My mesh consists of many tube-like shapes that split and converge again, so decimating them will probably be something I end up doing by hand, very carefully, to keep my shapes correct. My actual mesh is quite basic, but I need a subsurf modifier to smooth it into curves. Once it's done and I've removed as many vertices as I can stand to lose from the original mesh, I'll apply the subsurf and then begin removing surplus vertices by hand again. Unless there's a better way..

I sure picked a complicated design for my first age. But I think it will be worth it, and it hasn't given me more trouble than I've enjoyed handling so far.

[Zander]

visible objects shouldn't be used as physicals anyway, you should have invisible colliders for the walkable areas with no cracks in them.

Er. So when I make a landform and set the bounds so that I can walk on it, that is in fact wrong? (Or is it just a short cut because it's easier than something that I'll learn later on?)

[andylegate]

I've always used setting the bounds to static triangle mesh with no problems whatsoever on objects that the avie walks on, climbs on, and collides with. The only time I used invisable colliders is when I don't want the avie doing something, like climbing up a cliff, etc, then I put one in to block 'em.

If something like a terrain is very huge and has a ton of verticies, I simply break it up into smaller sections. No cracks appear as long as I don't move things around. IF I do move things around, then visable seams can appear, but that is easily taken care of by moving each vertex of one mesh over to the matching vertex of the other mesh, result is a seamless looking mesh.

This results in large Ages and objects, that are really smaller objects, but look whole in game. It also has the advantage of making your Age run smoother in Uru with less or no performance problems.

Our Age of Zephyr Cove that we submitted to the RAD is like this. It's HUGE, but because I cut things up, it runs smoothly even on lower end computers.

I've never liked putting in a bunch of invisable meshes for 2 reasons:
1) I might forget something and then I have avies walking through things or falling through the ground.
2) To me it's a lot more work, in that you have to duplicate your meshes, move them to another layer, get rid of any materials you may have applied, etc, and then add logic property to it to make it a collider.

That's just me though. There's no harm in trying different ways or even mixing them up as long as you get the desired result of what you want, and what works for you.

[D'Lanor]

I've always used setting the bounds to static triangle mesh with no problems whatsoever on objects that the avie walks on, climbs on, and collides with. The only time I used invisable colliders is when I don't want the avie doing something, like climbing up a cliff, etc, then I put one in to block 'em.

I found invisible colliders useful to enhance camera avoiding. I have a fence in my age that I don't want people to look over. PyPRP automatically puts the camera avoid flag on the fence but the camera will still go over it from certian angles.

So even though the object is a simple cube I gave it a separate collider which is much higher than the fence itself. Now the camera does not peek over anymore.

[Chacal]

visible objects shouldn't be used as physicals anyway, you should have invisible colliders for the walkable areas with no cracks in them.

Er. So when I make a landform and set the bounds so that I can walk on it, that is in fact wrong? (Or is it just a short cut because it's easier than something that I'll learn later on?)

Like many things, it depends. But I'd go with your second "shortcut" explanation.

1- It is a question of control. D'Lanor explained about cameras, and there are other reasons you would want control over the avatar. For example, if you have several obstacles the avatar could get entangled in, say a hallway with columns along the wall. You would want to help the player by putting colliders preventing him to get stuck in the columns. See what Cyan did in the concert hall foyer with the columns between the windows. Another example is stairs. It is very difficult to go up and down stairs with bounds. What you do is make a simple collider ramp. Also, because of the way collisions are detected, you will often end up with part of the avatar inside a wall or sticking out of it unless you use a collider to prevent the avatar from getting too close to the wall. This is not noticeable in single-player but will become a problem later.
2- It is a question of quality. Having a single seamless collider ensures there are no gaps an avatar could fall through.
3- It is a question of maintainability. Simple colliders are easy to change later if tests show a problem. It is more difficult to change visible objects, with all the texture problems that will cause.
4- it is mostly a question of performance. The game engine is always calculating whether or not the avatar is colliding. If your terrain and your objects are simple, it is OK to set bounds directly on them. If not, the game will get slower because the calculation is taking too long. In that case it is better to use a simple invisible collider, which has much less vertices than the visible objects. Also, from what I've seen from the prp structure, invisible collider objects (Physicals) are much simpler objects than DrawableSpans, which probably has an impact too. All this gets worse in multiplayer because each player will see other players stutter and warp around because of the poor performance.

So for simple test Ages like you're doing right now, it doesn't matter much, but if you start building a real Age for eventual inclusion in the game you will end up using invisible colliders. In all Uru Ages, only in Relto does Cyan use the visible ground as a collider. There are reasons for that.

[Aloys]

As Chacal mention this is less of a problem in single-player Uru. In multiplayer games collisions are a real performance killer, and one of the major source of lag.
As long as we keep doing single player Ages and rather 'simple' Age I think we can safely use collisions on visible objects. It might impact quality and performance slightly, but much less than in multiplayer. I guess it comes down to personal preference in our current situation. If after April 4 we start doing multiplayer Ages however collision will become a much bigger concern.

With Ahra Pahts in the beginning I had hoped that I could get away with using the visible objects as colliders because they are very simple meshes for the most part. But then collisions issues started appearing left and right and things became unmanageable.. I remember spending several days to create separate colliders meshes for the whole city.. What a nightware it was. It would have been much faster and would have avoided many problems if I had done it right from the start.

[D'Lanor]

Here is another reason for using colliders: kickable objects. I found that if I tried long enough I could push my kickables through visual objects with collision. That issue was gone once I gave these objects separate colliders.