Ogre Forums

Hey,

I'm looking for a way to define a transform (position/rotation) in a mesh, preferably defined at export time in a 3D package, that I could later use as an offset for e.g. a particle system or child mesh spawn. I'd like to avoid manual x/y/z declarations if possible.

I've had a read around the forums about TagPoints, found this
http://www.ogre3d.org/forums/viewtopic. ... ts#p532733 and this http://www.ogre3d.org/2016/01/01/ogre-p ... #more-2519 among others, but I've not found anything I could use to bake this information into a mesh and then read it back at runtime.

Ideally I'd want an option to retrieve this info straight form an Item/Mesh, so I can spawn a child scene node exactly where "Artist" imagined it.

If I understand it correctly, TagPoints are designed to be attached to bones (at least that's how it is shown in the examples and how I use them). So, if you have a skeleton in your mesh - just add a bone for the "socket" (or use one of already existing bones) and that's it.

Not sure if there is an easy way to do it without a skeleton though.

Hrenli wrote:If I understand it correctly, TagPoints are designed to be attached to bones (at least that's how it is shown in the examples and how I use them). So, if you have a skeleton in your mesh - just add a bone for the "socket" (or use one of already existing bones) and that's it.

Not sure if there is an easy way to do it without a skeleton though.

That's the point, I want to avoid skeletal animation because I'm planning on building an RTS-style game, so it'd be much cheaper for me to have non-animated objects.
Think Turret on a tank. I might give it a test anyway now that HLMS automates skeletal animation. And since I'm still trying to figure out mechanics and how unit-spammy I want it to get, we'll see if the performance hit will be big enough to look for alternatives.

Back when I started the 2.0 refactor (yes, 2.0, not 2.1) one of the proposed ideas was to add "metadata" to the mesh file formats to solve problems like this one.

What you want could be solved with Skeleton/Bones, but what you're saying is that a Skeleton is overkill and could affect performance (because a skeleton needs to be allocated, Items may need to prepare shaders for skeletal animation, Bones occupy memory, bones need to have their transforms updated) when all you want is just a marker that says "here goes the particle FX spawn point" or "here's the unit spawn point", the mesh is probably not even animated via skeleton animations.

Metadata requires more of exporter support rather than mesh format support, and therefore unfortunately I didn't get to implement something like this (yet, but it's low priority).

You'll have to get creative to get this information out of your modelling program:

• You could have them by placing separate objects like cubes or spheres in 3DSMax/Blender/Maya and export them separately. Then load the meshes and retrieve their location
• What I did in Distant Souls: I was using Blender so I wrote a small script to export the AABB of the dummy objects (which were identified thanks to a custom naming convention) and get the AABB regions I later pasted to Lua code for my engine
• Alternatively use a skeleton, but do not link the exporter to the mesh and export it separately with the same name (or with a different name but using some name convention, for example always end with "_helper" e.g. MyMesh_helper.skeleton). That way you can load the Skeleton at runtime by hand (via SkeletonManager), grab the information you need, and later dispose the skeleton if you want. Even if you have many Item instances, you only need one Skeleton instance (get the Bone's full transform via Bone::_getFullTransform and multiply it by the Item's node->_getFullTransform). And furthermore since the mesh is not actually linked to the skeleton, the overhead would be minimal.

Maybe not the answers you were hoping for, but you should be able to workaround your problem.

dark_sylinc wrote:-nom-

Hey,
Thanks for the comprehensive answer. I can imagine I'm a bit of an edge-case here.
I like the dummy skeleton idea, I'll deffinidely experiment on that front.
While on topic of animation, just so I can settle this in my head for the future, would you recommend skeletal animation or manual SceneNode manipulation for things like vehicle wheels?
It shouldn't be too heavy for normal stuff like cars, but I'm thinking tanks with their 12-20 wheels might enter the extreme range if I want to have e.g. 50 of them on the screen.

I think I could get a chance to resolve 2 problems with 1 solution using skeletons, even more so considering manual hierarchy animation would require a bunch of meshes. Well, I'll keep exploring on object-to-object basis then and give some feedback. Unless I forget or get bored with the project

Quick update:

30x30 grid of tanks, all randomly updating their 900 tag points (1800 nodes total) every frame on top of my inefficient half-graduate-level-v1-material-based 100x100 terrain still gets me in the 160FPS range on average running on a Ryzen 7 1700 and a GTX1080.
Note that a single tank in same setup gets me anywhere between 190-250FPS

Side question: is there a way I could potentially multi-thread anything to improve performance? As mentioned before, I am running some questionable v1 and compositor code that hogs graphics system update at 2.5-3ms even with 1 tank, but it looks promising so far!