I have a chair model that I’ve been working on. I modeled the bottom of the chair as a separate object from the back. My question concerns how I should go about combining these objects. Note, in case it matters, I am intending this chair to be used as an asset in a Unity3D game.
From what I have been able to tell, my options are to just join the two meshes, which is by far the quicker and easier of the two options, or to make the mesh continuous on the vertex level (either by doing it by hand, or using a boolean union modifier).
(My chair model, with the vertices shown after a join)
Everything I have read online suggests that making the mesh continuous, eliminating intersecting faces, is the “proper” way to do it. What I can’t seem to find is the reason why. Is there some reason that a mesh must be continuous? I’m not dealing with co-incident faces, so z-fighting isn’t the issue, nor do I have any completely hidden faces. I could see strange artifacts potentially occurring if I were to animate this object, but I am not planning on doing that. I could also see the argument of texture alignment being difficult (since you won’t know what portions of the uv map aren’t visible) but I’m not concerned about that.
Searching these forums (and Google) I was only able to find one other thread that asked the same question. The response said to not worry about non-continuous meshes. This is, however, the only post I have found to suggest that. All other modelling threads I’ve looked at regarding joining objects have said to make the mesh continuous. I guess what I want to know is the “best practice” position on this, and more specifically the “why”.
Ricky; He’s talking about a game asset to be used in a project he’s creating in Unity 3D, he won’t be using the internal render engine.
Generally, I would make the mesh continuous whenever possible, as it would generally make it easier to texture along with the fact that some features and functions in game engines may have an easier time and be more predictable (those that rely on or use backfaces or volumes to do their work).
Now the general thing is is that cobbling a mesh together out of different face groups may be attractive to beginners and make the modeling process faster, but there are cases where it may not work so well which depends on what type of logic you’ll have in your game.
the main idea was about bad object topo for the mesh
criss crossing faces is not in general a good practice even if it can work or render well
it’s better to take good habits as soone as possible and make clean nice topo for object
the worst and bad example i know of is Suzanne but who cares
as long as it render well!LOL
When you’re making model assets for a game, the face count can be very important at some point.
In the case of the chair by example, making it a single mesh will result in more triangles than making the chair made of separate meshes.
So depending on the complexity of your game scenes, you may sometime prefer to not make all the assets of a scene “continuous”
Actuary this is not a good example. Because geometry is easy to build and the face count can be reduced quite easily without having intersecting geometries:
But in your example riddix you’re not making the same chair as in the 1st post, you have made a different type of chair and so the face count is much lower there.
If you try to make the same chair as in the 1st post with a “continuous” mesh you will see the triangle count being really higher than if using separate meshes.
But that’s an example for this kind of simple chair, a game usually have a lot of object that can be seen (of course depending on the genre) , their face count add to each other when in the player view and when it comes to something more complex, the difference in face count between a fully “continuous” mesh and one made of separate parts can be quite large when you need to cut the whole scenes face count to keep the framerate managable.
It certainly seems like there are two positions. The question is whether to optimize the mesh layout (which would call for a continuous mesh, but a higher poly count) or to optimize the poly count (which results in fewer faces, but potentially intersecting faces). I’m intentionally avoiding the issue of co-incident faces since that will most likely cause z-fighting and should be avoided regardless of which method is pursued.
In regards to the chair being a poor example, as Sanctuary mentioned, that chair is different from mine. In particular, your up-rights and crossbeams are flush with the edges of the pieces they connect to. by indenting them some, it can require many more faces to make this mesh continuous.
Actually, in this case it’s still not bad since everything is in squares, but allow me to provide a more complex example:
This is a hook on what will become a coat rack. The main cylinder, hook body, and ball are three separate objects that, for the purposes of Unity, should all be considered the same object. Now, this is something I just started, so the face counts are still a little high, particularly on that sphere, but it illustrates the issue quite nicely I think since, unlike in the chair example, you can’t simply extrude these details out.
The hook body was created using a bezier curve converted to a mesh, so manually extruding it from a subdivided face on the cylinder would be painstaking at best.
@ridix, i still see lot of geometry which can be removed from your model. But your point is valid. Continuous mesh is the best way to achieve better results.
@Drakmyth , for rendering , game engines usually try to read every polygon of a model. If it finds a mesh with open end or with a polygon, hidden in another mesh (if you try to close the mesh) then it put stress on game engine. but it was a problem in yesteryears, now game engines internally cull these type of open end and polygons. but still continuous model is rendered faster then open , piece by piece models.
In Unity3d, It’s always a good idea to create your whole scene in external editor, join the meshes (non-movable, no-physics etc models) and import them all together. This way, Unity3d works real faster with lower over head.
I’m building my entire scene in Blender (the objects shown previously are part of the same scene) less for reasons of performance and more for visualization and spacing. If it just happens that this is the best method for performance too then that’s awesome. Now, when you say join all the meshes, are you suggesting within the same object (as in my chair and coat rack examples) or all the objects in the scene together into one mesh? I would assume the former, as the latter would be extremely complex and difficult to texture, not to mention less flexible both in Blender and in Unity (though this is what it sounds like you mean by your wording).
I had assumed that hidden faces and non-continuous meshes were limitations of GPU’s long since past, as I had never experienced any trouble with them myself, but I couldn’t find any kind of explicit proof of that, and the thoughts on the matter I could dig up suggested that those limitations were still extremely in effect. Knowing how a GPU works, I can understand why a continuous mesh might have better performance than a non-continuous one, but if there is one thing I’ve learned while attempting to make games (both in Unity, and in XNA before that) it’s to never over-optimize. Don’t try to fix performance issues until there actually are performance issues. Is the performance of a non-continuous mesh with two vertex islands any worse than two separate, continuous objects?
Yes, you guessed it right. But separate pieces as per usage. like walls & Roof together, chairs & tables, Windows & Doors. Don’t forget to change the pivot point to 3d cursor (0,0,0). in this way, when you import your meshes in unity3d, you just need to put them on (x,y,z= 0,0,0). (It is just unity3d thing, but in UDK this doesn’t matter).
Well, clean geometry is always a good idea. but if you look at UDK built in models , most of them have open ended polygons. like a walls, pillars , domes etc. but it still renders fast and overhead is low.
Static models should be one object just like collision models. You may not find issues with it now but you may later or in another project. You wouldn’t really save much in the budgeting by not doing it anyway.
