Find Mesh Location

I’m working with many objects whose transforms are all set to (0,0,0) but whose meshes appear in very different places, sometimes thousands of units away. (I need to keep them this way in order to maintain their relationship to each other.)

However, I need to access the location of their meshes in order to do things like temporarily move the individual objects, rotate them on their axes, or highlight them. I’m currently using capsule colliders to estimate where the meshes are located, but, since their shapes are nonstandard, this strategy is imprecise. The way I’ve tried to use them, mesh colliders slow the game down way too much, and don’t help me with accessing the objects’ locations in scripts. Any tips? Thanks!

When asking questions and you find yourself saying “I have to do it this way” when you know it’s a non-standard approach, it really pays to explain why. You’re basically saying you don’t want to use transforms, but you want all the convenience functions that transform manipulation offers. This makes no sense without context, so our inclination will be to warn you against the strategy.

My guess is you can have exactly what you’re asking for with sufficient planning, but it will be orders of magnitude more complicated and expensive than adjusting your strategy to use transforms as intended.

At least one order of magnitude more expensive, because you’re already running some kind of transform operations once per object by virtue of using gameobjects to begin with.

I’m sure there’s some kind of approach you could use to manipulate these meshes as though their origins were centered on their geometry (as nature intended! :wink:

If the meshes begin life centered, scaled, and oriented in a standardized way around their origins, you can just track the changes in these three properties yourself.

If you can benefit from moving, parenting, or otherwise manipulating an object or 3D data, remember you can do so in the space of a single frame, then return that object or data to its normal context.

Say you’re locked into this weird approach: do you really need a gameobject per mesh, too?

Here’s the point: if you’re locked into a weird design restriction that is truly inescapable for some reason, certain elements of conventional wisdom can become untrue, and it’s time to reanalyze everything in support of the weird design.

For instance, you can look into Graphics.DrawMesh, which would allow you to ditch using your GameObjects’s renderer altogether. That at least would presumably save you a layer of unnecessary complexity. Ditching the use of gameobjects per intuitive “object” is another strategy that would appear to be open to you, and can be a major optimization if you’ve got tons of very simple objects.