Trenchbroom: Add "Model Display Offset" to FGD model definition

[itslunaranyo]

Models can be displayed in Quake with a late offset applied at runtime independent of the bounding box (for getting around min-corner .bsp model issues when angling/rotating these items, and the fact that lots of legacy maps exist that all place those items with their min corners as origin). TB has no way to support mirrored behavior so that in-editor preview stays consistent with item appearance in gameplay.

The simplest solution worked out with eric would be an extra optional term in .fgd model definitions.

model({
   "path": ":maps/b_bh100.bsp"
   "offset": "16 16 0"
})

defining a single xyz translate to be applied to the model after other transformations (including rotation by the angle keyvalue). This would let rotated items with min corner origins appear centered on the wireframe bounds without having to manipulate those bounds, which need to be consistent between .fgd and the bounds hard-coded into a mod's progs.dat or other gamecode.

[eGax]

I would like to see this also. Hammer & Jack support this very same offset in their fgds.

[ericwa]

Do you have an example handy of the hammer/jack syntax @eGax ? Would be good to ensure compatibility

[eGax]

Turns out it just seems it is JACK that supports offset. Here is an example snipit from it's quake3.fgd:

@BaseClass size(-16 -16 -16, 16 16 16) offset(0 0 16) color(96 96 255) base(Target, Targetname, Respawn, Modes) bobparms( 180 8 0 ) = Ammo []

[ericwa]

The bad news is JACK's offset() doesn't do what we thought here. From what I can seem it only affects how JACK places models in Entity mode when you click in the 3D view (when there's a model loaded, JACK ignores the size(..) attribute, unlike TB, and it seems to use offset() to decide where to place the entity when you click in the 3D view).

[kduske]

Models can be displayed in Quake with a late offset applied at runtime independent of the bounding box (for getting around min-corner .bsp model issues when angling/rotating these items, and the fact that lots of legacy maps exist that all place those items with their min corners as origin).

How does the engine determine this offset?

[itslunaranyo]

It's at the discretion of the mod game code, but in general: post-spawn setorigin() to add the offset shifts the entire entity (with model), and subtracting the same offset from mins and maxs shifts the bounding box back again, so only the appearance has changed. (It is a little dirty, but then again most things accomplished through progs.dat are.) With models whose origins are at the min corner, this offset is dependent on the angle and determined with some light trigonometry that I wouldn't expect TB to emulate, which is why I'm redoing the box item models in Copper to be centered on (0,0,0) so the offset can just be a flat (16,16,0) in all cases.

AD avoids the legacy item origin issue by just abandoning backwards compatibility entirely. Quoth addressed it with a special-case worldspawn key to specify centered or non-centered items, and while I dislike adding secret magic "make something work" booleans like that I also dislike being asked to add pet features for individuals, so I'll understand either way. :)

[kduske]

Ok, so it‘s definitely an fgd property. We can go with the original idea of putting it in the TB specific model definition, just maybe give it a more descriptive name than „offset“.