Really don't worry about your visible meshes - they're fantastic and the polycount is not a worry at all!
I wonder - do you understand how to model the collision separately from the visible mesh? It seems to me that you simply duplicate the basic mesh and turn that into the collision mesh, which works but makes for a complex collision.
I think this is something that it's worth getting to understand, because it really will help your models.
if you use the blender poly reducer several times, rather than just trying to get completely reduced straight off you can get more control and subtlety, I normally find.
x
edd
Fair point - and the other thing I often need to use is vertex group weighting to try and protect pieces of the mesh - which is well worth the effort for the visible mesh but a PITA when just doing collision!
Quote:Originally posted by morcroft
...you simply duplicate the basic mesh and turn that into the collision mesh, which works but makes for a complex collision.
.
Yes, i do the same.
That's your problem, then. You only need a tiny fraction as many polygons for the collision mesh as you need for the visible mesh - all you're doing with a collision is making things bump into it!
Just as an experiment, next model you make, try making a cube that roughly fits around it, and then use _that_ to make the collision.
Try it out in-game. Swing a sword at it. Go into the console (` key) and type tcg (toggle collision geometry) and see how good it is as an approximation of the object. See how simple the vanilla collisions are.
Also, the way you are making collisions won't work with havoked objects. You have to use a different technique.
I don't work with havoked objects.
Anyways thanks for this small advice. I'll use this technic for do collision in the future.
Vintra
Don't get me wrong by the way: a cube is almost certainly not the right answer either: it'll be too simple. The right level of detail is generally somewhere in between, but you may sometimes find it easier to subdivision a cube to get the right shape. Or not: it's all part of the modelling art.
Quote:Originally posted by morcroft
Hmm - I don't know of an equivalent in Blender. I basically more or less remodel in low-poly which is slow... slow.... slow! There's a poly reducer which is pretty good but fiddly, and doesn't hug the outline well enough for collisioning. There's also a cube / sphere / convex poly generating "hull" function, but won't do Mopps, and I find it has a bit of a habit of creating internal faces. Maybe I need to go do some research.
There's also the "static triangle mesh" in Blender:
http://niftools.sourceforge.net/wiki/Blender/Collision
.....but I don't know if that is a MOPP'ed version or what. I don't use Blender.
The above collision tutorial may or may not be out of date. If you want a definite answer, you can ask someone over at Niftools forums:
http://niftools.sourceforge.net/forum/
It's just that I could have sworn Blender can do MOPPs now....
Koniption
Hi KP - yes, Blender with NifTools does a perfectly good Mopp - which is indeed the "static triangle mesh" - Niftools sorts out the mopp in the background on export. And yes - that's the tutorial I used initially.
The issue under discussion is that Vintra has been using his full-poly visible model mesh to export as the mopped collision, which led to a collision mesh of 1184 mopped triangles.
Perfectly valid, but do you agree with me that this is too many triangles for a collision?
How long will be talking about this? ?(