FR: Omnisprite option for weapon projectiles

[Kestrellius]

Laser bitmaps behave like directional billboards, rotating to face the camera only around a single axis -- the direction of movement. However, it would often be useful to have bitmaps attached to projectiles which behave like omnisprites, rotating around arbitrary axes to face the camera and having a constant upward orientation with respect to it. This is especially useful for effects like lens flares.

Current options for doing this are limited and hacky. Therefore, I request a dedicated feature for attaching static or animated omnisprite bitmaps to weapons, completely separate from (and therefore usable in addition to) the projectile's model or laser bitmap. The ability to control the size of the bitmap would be desirable for obvious reasons, as would the ability to adjust its location relative to the weapon's center.

Proposed syntax:

$Omnisprite bitmap: string +Omnisprite center: vector +Omnisprite radius: float

[The-E]

Could you clarify what an "Omnisprite" is supposed to be? I tried googling the term, but it didn't seem to be an established technology.

Also, regardless of what it is, it is very definitely not useful for lensflares. As I understand your description here, this technique would help in dealing with particles in 3D space; lensflares are always and exclusively 2D (because they're a simulation of imperfections on a camera lens), and the techniques useful for generating them do not require any 3D properties.

[Kestrellius]

There doesn't appear to be any established terminology at all for the distinction between what I'm calling "directional billboards" and "omnisprites", which is why I'm making up words. I'll try to be clearer. Unfortunately, it's a difficult set of topics to articulate.

An "omnisprite" is what things like particles, muzzleflashes, and fireballs are in FSO by default. The sprite always faces the camera, it respects no axis limitations, and the orientation of the 2D bitmap remains constant relative to the camera. If you're looking at the sprite and you roll, the bitmap rotates with you.

This is useful for lens flares (or lens-flare-adjacent phenomena; I am using "lens flare" here perhaps somewhat loosely) because, as you say, those aren't 3D objects. An example: say I want a laser with a cross-shaped lens-flare-like effect at its head. If I put that cross shape in a laser bitmap, it won't work correctly, because it'll be oriented along the laser's length and it won't rotate with the camera.

But if it functions like an "omnisprite", then the cross flare will work exactly as intended. It will always appear the same from the perspective of the camera, never rotating, varying only in position and size as the projectile moves. I suppose a lens flare being subject to change in size with distance isn't physically accurate, but it's a decent approximation of the way a light source will decrease in apparent brightness as it gets farther away, and I think it's fine for the type of stylized effects we tend to use in FSO.

[Baezon]

I was thinking "static bitmap" but that's also bad because it could easily be an animation instead...

[Baezon]

Alternatively, this could be a special case of laser bitmap where length = 0 (which currently gets silently discarded and not rendered). I'm thinking that if a laser's length is 0 then laser bitmap and glow are rendered like a flat billboard with a head_radius radius. It would be documented of course, but this way makes good usage of the already existing framework, and would not require any extra data.

[Kestrellius]

Well... The issue I have with that is that I would definitely in many cases want to have both a standard laser bitmap and an "omnisprite" bitmap.

[Baezon]

Well... without other changes as well, those two types of sprites would not be aligned anyway, remember that laser sprites start from its position, extending forward, while these would be centered on its position.

[Kestrellius]

Bumping. IceCreamMan has expressed a desire for this behavior, so that's one more person who wants it. Also, I am now fully on board with Baezon's idea of using length zero to activate it.