Request: Instance friendly turret workflow

[EatThePath]

Background: In blender my preferred workflow for turreted ships is to have one collection with the turret's 'prototype' in it, then use collection instances to place copies around the ship. This means I can then refine both the ship and the turret in their proper context. However the way blender and FSO both handle object names makes it a hassle to make these objects actually real functional turrets at the end of the process.

The proposal: In blender, an empty with special name prefix, say $multipart or something, parented to the detail 0, sets the origin of the turret. Parented to that would be optional a properties or metadata empty or empties, and objects with special names. Any properties a turret needs and aren't provided explicitly would be implicitly inferred. rotation axis and so forth would be deteremined from the rotation values of the base empty, with the assumption that an unrotated turret is a forward facing turret on top of the ship. Personally I would even prefer it if the system took the position of the arm as the initial position and rotated it into the upwards facing position FSO expects because then I can model a ship as it will actually be seen, not with it waving it's muzzles in the air awkwardly. Moving on, parented to the turret would be one object that rotates and one that doesn't. $base and $body perhaps. And parented to the base would be an $arm and to it firepoints. On import to poftools, all the special-named children of the empty would be renamed. For instance, say I have

detail0
    $multipartleftpulse
        $basestuff.0012
        $body.0012
           $arm.0012        

after import I would have

detail0
    leftpulsebase
    turretleftpulse
        turretleftpulse-arm

Arguably the turret should be a child of the base submodel. I can see pros and cons to that and have no strong feelings on which way it should work.

I hope this is clear, if not I'll clarify as best I can.

[Baezon]

Firstly, I'm not sure I understand the exact problems caused by naively doing the instancing and exporting? Let's clarify that first.

Secondly, your proposal seems very complicated, for what seems to be simply copying an existing turret into the position/orientation on a set of empties which reference the turret in some way, is that more or less what you were suggesting?

[EatThePath]

The issue with it at present is that when you 'make instances real' all the resultant objects keep the names of their original prototype objects, with blender's standard disambiguation suffixing. I'm uncertain if all the informational empties in a turret play nice with this, I feel like there were issues the last time i tried it but that was a while ago. If turretpulse.002 has a #turretpulse-properties.002 object does it work right? Is turretpulse-arm.002 properly detected as it's arm? what if every single turret has a #t-gun-point0.00X firepoint?

But either way if I want to give all my turrets names more useful and clean than "turretpulse.004", and I do, then I need to manually rename a lot of resulting objects. Maybe if the name detection is more permissive than I think it is, then maybe it's manageable as is, but if not then it quickly becomes more tedium than I'm able to easily make myself push through.

[Baezon]

All the 'semantic naming' for pof-tools is very lax. A properties node need only start with '#' and contain 'properties' a gunpoint need only start with '#' and contain 'point', a multipart is defined by having its gun points additionally contain 'gun' (making the empty's parent's parent the base, etc).

While I understand that fixing all those ugly names is tedious, this is fundamentally an issue with blender's automatic naming when instancing. Detecting and changing such names is simple, but I don't really want to mysteriously 're-interpret' the object names in different ways; object names should really be straightforward and intuitive, you get the names they had before, that's what people will expect. At most, I'd be open to having this as a selectable option. Automatic conversion of blender disambiguated names to... not have periods, I guess?

EDIT: An exception might be the text of properties. I've already run into issues where, of course, several subobjects can have the same line of text, and therefore get blender disambiguated. I will probably forcibly strip any trailing '.###' on those lines.

[EatThePath]

I can understand the concern about not wanting to be too magical about handling object names. My only real counterpoint there would be that both poftools and FSO's handling of names already feels that way to me, but that's mainly by virtue of not being clearly documented anywhere. Maybe an alternative would be a 'propagate name' feature in pof-tools? You rename the base of a multipart, push the button and everything parented to it gets a standard name structure? Though I haven't even dabbled in destroyed turret meshes to know what would be useful there...

There's also the other aspect of my request, which is essentially taking orientation of the object and setting fvec and uvec based on it. I'm not sure how possible that is since I don't really know what the coordinate systems and data in the gltf intermediate stage look like, but I do know that the ships I want to make only rarely have axis-aligned turrets and trying to manually determine and set all their vectors is something I very much don't look forward to.

[Baezon]

A better UI for the fvec and uvec, and for indicating 'semantic links' based on the naming is definitely planned regardless. It's possible to extract an fvec and uvec from the orientation itself, and this is probably right in most circumstances, but it's essentially saying that rotating an object into place, is the same thing as defining it's rotation axes. I'm not sure if I'm explaining it well, but essentially the fvec and uvec are fixed to the orientation of the object itself, which isn't necessarily the case. I dunno, it's probably ok, I can't really think of a situation where that wasn't true.