Missiles

[Accu-Accelerated]

I'm thinking of making some models to replace the ugly Friend or Foe missiles, porcupine mines, cluster bombs, mines, and those wierd Rlaan hellspawn missiles. What are the specs missile models? (Maximum polygon count, textures, other stuff?)

[klauss]

IMHO, missiles should be completely revamped to allow:

1) propellent trail
2) exhaust flare
3) automatic HUD highlight of missiles in flight

Right now, missiles are really ugly, but mostly because they're invisible. At least a trail (1) should be visible. (3) Would be expected in any modern ship, since missiles are a real threat. The HUD should point out clearly where they are, even if you don't target them. Current airplanes do so, in a sort of way, so why not future spaceships?

I think 1) and 2) could be possible by using new models. I would suggest a very low poly count, no more than 15-20 (Just throwing a number), since most of the time they'll be just a dot. Just in case there are slow-moving missiles, a 100 Poly LOD could be created (which would almost never be used).
The most visible part of a missile would be the exhaust and its trail. Not the missile itself.

[chuck_starchaser]

And if I may add, there is no air in space, so space missiles need not be aerodynamic or feature wings or ailerons; though they'd probably have an elongated shape to fit launcher tubes. But for maximal storage efficiency, I'd say they'd have a square or rectangular cross-section; which is all the better as per simplicity of design, poly count, and smoothness of LOD transitions.

EDIT:
We could actually speculate about a shape that follows function: Missiles would probably be modular, and look it. You could basically combine any engine with any fuel section, with any type of payload, with any type of computer, with any kind of sensor type, as long as the added lengths of the modules don't exceed the length of the launcher's reload path. All these sections would vary in length but look pretty much the same, except the first and last. The sensor would have all kinds of funny shapes depending on type. Most would be spherical and be mounted at the end of a rod projecting forward from the rest of the missile. Why? Cameras would be mounted so they can turn around in any direction, inside a glass bubble for a first layer of protection. Radar sensors would probably use phase arrays (synthetic aperture) with near 360 degree FOV, which are spherical, most of them (note big soccer ball looking things on Navy ships). The reason for mounting the sensor at the end of a rod is to increase FOV and to reduce diffraction interference by the rest of the body.
Then the last section might be different due to the engine being there, which generates heat, and has to be able to turn in order to maneuver.
So, I'd say...

Code: Select all

Front
 __          _   _________   _____
/  \        / \ /         \ /     \ /\/\/--
|  |-------| C |  payload  | fuel  | eng.  |
\__/        \_/ \_________/ \_____/ \/\/\--

EDIT2:
As for texturing and color, I'd say they'd be intentionally made hard to see, and probably the best way to camouflage them would be to make them mirror-like; which in fact is the easiest texturing one can ask for: Essentially, environment-mapped by the existing skybox (the galactic background). Or else they'd be black or dark grey, if they use radar-absorbent materials.

EDIT3:
Klauss, unfortunately, in space you don't get smoke trails, though. The reason smoke trails form in an atmosphere is that the hot exhaust is slowed down in its expansion, by collisions with the surrounding, atmospheric gases, and then dissipates slowly, by convection and turbulence. In the vacuum of space, though, the exhaust gases continue to expand indefinitely at the full exhaust speed. If you've ever seen video of a rocket engine in space, the exhaust looks like bright semisphere or cone, sort of spherically decreasing in brightness away from the source, without backward curving or trailing. For the same reason, BTW, there should be no smoke in explosions, but simply a bright shockwave decreasing in brightness as it expands indefinitely at constant velocity.

EDIT4:
Once atmospheric flight gets implemented, though, it might be nice to have some limited atmospheric combat as well. Plasma and charged particle guns would be useless, but lasers and some missiles (aerodynamic ones) would still function, as would rail-guns. Then we'd have real sound from other ships, and smoke trails.

[Accu-Accelerated]

Also, I was thinking that porcupine mines would be spiky? But what about an irregular design that deflects radar, or maybe a mine disguised as /mounted on a small asteroid, maybe with some antennas sticking out of them.

As for friend or foe missiles, I would probably just maybe have a very simple texture, most of it just being mirror-like (specularity-wise), and maybe for modular components, they would be bands of slightly different colors. There could be a nozzle at the end of the missile for control, sensors at the tip. Maybe the tip of it would be colored slightly. The missiles, of course, probably won't have to be aerodynamic, but the problem is, then people won't think it's a missile...

Cluster bombs- A cluster of small bombs, but how should they be arranged? It would be cool if they were box-shaped for storage, but then arrange themselves automatically into a more cluster-like shape after they are launched. I don't think this is possible though... and the geometry for modeling would be a hassle too.

Rlaan Hellspawn- Now what are they supposed to look like???? What do they even do? (I think they are like litte robotic drones that fly around and automatically shoot at enemies?) I have no idea... And how are you supposed to model them, they are like a sphere, but if you shoot at it, half of the sphere gets destroyed and there's actually a little box inside it...

[chuck_starchaser]

Also, I was thinking that porcupine mines would be spiky? But what about an irregular design that deflects radar, or maybe a mine disguised as /mounted on a small asteroid, maybe with some antennas sticking out of them.

Sounds pretty cool. Remote controlled mines, another possibility...

As for friend or foe missiles, I would probably just maybe have a very simple texture, most of it just being mirror-like (specularity-wise), and maybe for modular components, they would be bands of slightly different colors. There could be a nozzle at the end of the missile for control, sensors at the tip. Maybe the tip of it would be colored slightly.

Yes, yes, yes and yes.

The missiles, of course, probably won't have to be aerodynamic, but the problem is, then people won't think it's a missile...

I think A) After they see a few they'll get used to them, and they'll begin to make a lot of sense to them, and B) Some missiles could be aerodynamic and be advertised as atmospheric-compatible.

Cluster bombs- A cluster of small bombs, but how should they be arranged? It would be cool if they were box-shaped for storage, but then arrange themselves automatically into a more cluster-like shape after they are launched. I don't think this is possible though... and the geometry for modeling would be a hassle too.

The densest packing for spheres is tetrahedral, but this is assuming a box size much larger than the spheres themselves. (Just one interesting piece of trivia: The fact that the densest packing of spheres in 3 dimensions is tetrahedral is intuitvely and empirically true, but has never been formally proven.) For small boxes, a cubic pattern may be best. For a long box, it could be anything, depending on width and height. But then again, the bombs need not be spherical. They could be cubic, or like smaller long boxes. Also, there's a great benefit to exploding a bomb near or in contact with a target, multiplicative; and I would assume all bombs would have at least a bit of fuel and guidence to allow them to approach a target. If so, the distinction between a missile and a bomb would be quantitative rather than qualitative.

Rlaan Hellspawn- Now what are they supposed to look like????

Got me, I'm more of a Privateer/WCU guy, haven't played VS too much.

EDIT:
We really need a 3D texture for rocket engine exhaust. Needs to be volume texture so that it looks right at any angle. Shaped like a wide angle cone and voxel brightness that diminishes by the square of the distance. Then we'd alpha blend it additively, like (ALPHA, ONE). But only for rocket engines (solid or liquid fuel); ion engines should have no exhaust, as those ions come out too fast to be visible. Ion engines should show like a very bright blue grill only, IMO. (But then again, I'm not even sure they are ion engines; I just assume from the fact they are always on.)

[klauss]

Klauss, unfortunately, in space you don't get smoke trails, though. The reason...

Got me. I didn't think that much, I just thought the exaust gases would expand linearly as they push linearly, and inertia would take them there, but... who can argue with real life pictures?

We really need a 3D texture for rocket engine exhaust. Needs to be volume texture so that it looks right at any angle

It's not necessary to make it 3D. If you use parallel-to-viewport slices, and texture them with a 2D symmetrical texture (like a gas blob, kind of a fading circle), you get the same effect for much less. It's just a matter of fiddling with it until you get it right. The 3D version would be the brute-force version, which would be costly although much more flexible and accurate. But that flexibility and accuracy costs you a lot of compatiblity: many cards don't support 3D textures very well. I think 3D textures cannot be compressed in some cards, for instance.

[chuck_starchaser]

I tried to think of a way using several planes. The problem I find is this: If you're looking at it from the side only, even just one plane would do the trick, with the right alpha gradients. Same if you're looking at it from behind the missile. BUT, if you want to be able to look at it from both directions, from each direction you'll be seeing the plane for the other direction edge-on, which would be a horrible artifact.
One possible way to handle it using planes might be to have one plane from the side, one from behind, and another at 45 degrees, but then to fade them in and out as your viewing angle changes, so that edge-on planes are fully faded out. The disadvantage, of course, is that there's probably no hooks presently in the engine to specify such behaviors at resource level, like from XML; but maybe we need such hooks...
I was talking to Hellcat about having a skybox for planets with bright blue skies, which box is faded out invisible when you're outside of the atmosphere, but fades in gradually as you descend through the atmo. He liked the idea, BTW, but it will need a hook for software to control alpha and color for the cube box's textures.

[Halleck]

You should have a look at how engine exhausts are currently handled in VS. I'll post a shot in a second.

EDIT: here


This looks similar to what klauss was describing.

[chuck_starchaser]

Ok, thanks Halleck. This wouldn't work for what I had in mind, though. It would work for side views, sort of, but not for rear views...
Consider this:

Code: Select all

   /1
  /2  1
 /4 2  1
/8 4 2 1
\8 4 2 1
 \4 2  1
  \2  1
   \1

Now, the numbers are misleading, as they decrease exponentially. The actual formula would be inverse distance squared for brightness *per unit volume*.
The view above is like a cross section view from the side, but the actual 3D shape revolves on itself, like a cone.
Two planes, one horizontal and one vertical, viewed from the same angle as in your picture, would look like wings. And additional planes at 45 degrees would look like additional wings...
That trick *barely* works for present exhaust because the exhaust goes pretty straight back.
Now, from that same angle, transversal planes would do the trick, but would look terrible from the side.
I think we'd have to produce planes for viewing angles at 0(back), 30, 60, 90(side), 120 and 150 degrees (almost front), and alpha-blend between pairs of them by extrapolation; or else just use a 3 D texture.
Or else do some dynamic rendering trick...

Or, well, there's another angle to exhaust: The part of the exhaust moving sideways wastes energy, and better efficiency would be had having a narrower angle cone; but for some reason it appears very difficult to produce narrow angle exhaust rocket engines. I read something about it somewhere, but I don't remember. Maybe the problems will be solved in a thousand years, but even if we make the cone narrower, it only lessens the problem, and then we have the problem that it should curve when the missile turns. I think I'd rather come up with a solution for the normal, wide angle exhaust that's the standard in space now.
Turning issues are unnoticeable with a wide angle.

[Halleck]

You know, the current method actually looks decent from the back, unless you push in like I did (to reveal the cross section). Here is how it looks 95% of the time, and even this is unnaturally close:

(Click to enlarge)

[chuck_starchaser]

Yes, it's true, and I must confess, I never noticed those planes. But with a wide angle cone, I'm sure they'd be very noticeable.

I'm almost tempted to make it a single plane, always facing the camera and looking like a spherical exhaust. It would only look funny from the side, and even then it might be interpreted as a lense flare effect and forgiven.

Mind you, it could be done with 3 planes: The two that show on the picture, and one more plane flat against the engine exhaust, so long as there'd be an OGL render mode that automatically fades a plane as it turns towards view on edge. The exact opposite of specular reflectivity. I don't remember there being anything like that in OGL tho.

I mean like

view
|
|
|
|_angle a
|_|________________ plane

alpha *= {sin(a)}^2 //Yes, I mean sin, not cos, so a plane that would be seen on edge would just disappear... but if it faces you it looks fully there.
If such a render function exists, it would benefit the present exhausts as well.
Or, it could be coded as well... Doesn't even have to be a per pixel thing either; just dot product between view line to center of plane, and the plane, multiplies material's alpha. Not sure where I'd plug it in...

[Halleck]

If you look closely, you will see that it is three planes! I Haven't looked at the actual code, but from closely examining it in-game I have arrived at the conclusion that it's drawn like so:

And that's just the visible area- the geometry is probably much simpler (actual rectangular planes most likely)
EDIT: Just noticed that the circle (in red) actually has a bit of a depression in the game- more of a shallow cone than a flat circle really.

[chuck_starchaser]

EDIT: Just noticed that the circle (in red) actually has a bit of a depression in the game- more of a shallow cone than a flat circle really.

No, it's got to be just planes, probably just an optical illusion. The inside of the engine in the ship mesh has a depression I believe, which you're seeing through the transparency of the "red" plane.

[Halleck]

Nope, it's a cone. A profile shot reveals all:

Note the crescent- that's the side of the cone. It's easier to see in-game than through screenshots. If you want to check yourself, just switch to ghost cam (f6), use the qzsf keys to control your spin, and f11/f12 to zoom in and out. I was using the schroedinger as a reference model since its exhaust is large and highly visible.

(Plus, hellcatv confirmed that my model was accurate.)

[chuck_starchaser]

I see it, and still not believe it... Why would they do that. Anyways, I'll check it in the game tomorrow. It's almost 3 am and I start work at 6
And I have like 17 apps open I don't wanna crash... l8r

[klauss]

I tried to think of a way using several planes. The problem I find is this: If you're looking at it from the side only, even just one plane would do the trick, with the right alpha gradients. Same if you're looking at it from behind the missile. BUT, if you want to be able to look at it from both directions, from each direction you'll be seeing the plane for the other direction edge-on, which would be a horrible artifact.

Didn't read all the posts yet, but let me clarify:

Each slice must be computed every frame. That's why the texture should be symmetrical. Each slice is renderd as a quad parallel to the viewport. Like the halo: it's always facing the camera. What changes somewhat is the texturing. Texture coordinates are computed such as to accurately draw a slice of the implicit 3D texture (which due to symmetry needs only a 2D texture). I'll try to create a sample of it, running, in OpenGL, when I have the time. It'll be fun.

[chuck_starchaser]

okay, we had the same idea, then.

[chuck_starchaser]

klauss, I'll try to modify the program I used to generate atmospheres, to generate views of chemical rocket engine exhaust. Maybe you can figure out where to plug them into the engine..

EDIT:
No code at all yet, but some header file comments...

Code: Select all

#include "save.h"

/*
exhaust() shows the exhaust of a chemical rocket engine
from a view angle passed in degrees as the parameter.
The view angle starts at 0 degrees (view from rear) and
ends at 90 degrees (view from side). The view from 100
degrees (slightly frontside from the side) is the same
as the view from -80 degrees; which is like the view from
80 degrees flipped around.
The algorithm is a sort of volumetric ray-trace:
A ray is projected from the camera for each pixel, and it
"accumulates brightness as it penetrates space volume.
The volume it penetrates is 3D array of 16.777 million
monochrome cells. This array is first allocated and all
cells set to zero. The engine exhaust disk is placed at
the center, and then the cells in the volume are iterated
through and given values that follow from a function whose
input is the distance to the center. The function takes 3
concerns into consideration: Abundance of bright particles
being inversely proportional to square of the distance;
cooling of the particles as they radiate energy; and loss
of left-over, un-burnt fuel, which becomes more noticeable
at more peripheral distances. The first two considerations
are multiplicative, whereas the third is implemented as a
subtractive hack on the multiplication result.
This 3D array is computed once.
When the raytracing is computed, --for each pixel in the
final image--, the start and end depths are calculated
based on the view angle, distance from exhaust and limits
of the exhaust cone angle (+/- 60 degrees), but then the
limits are blurred by 4 pixels to avoid excessively sharp
edges to the cone on side-view.
Also, the intention is to compute images for four angles,
namely 11.25, 33.75, 56.25, and 78.75 degrees; and then
alpha blend 2 such pictures at any view angle as per the
interpolation between those angles and the true angle.
At 90 degrees, however (side view), the 78.75 degree image
is averaged with the 101.26 degree image (inverted 78.75),
which gives us a slightly blurred side view, again.
EDIT:
I think I'll have 2 floats per voxel: One for brightness
density, and one for temperature, so that the final depth
integration can integrate RGB components separately.
The fuel exhaustion hack amounts, basically, to letting
the peripheral sphere reach a value of zero, by linearizing
the last part of the function.
The engine disk spans 16 pixels across at the center (eight
pixels radius), and this is what scaling should be based on
at all times. Engine power modulation, if used, should just
modulate the over-all brightness or alpha.
The final png images generated are black body radiation
colors from white to black, on black background, and are
intended for additive blending glBlendFunc(ONE,ONE).
Future work: sub-pixel accuracy: Repeat 4 times with 1/2
pixel offsets and average.
*/

[klauss]

Go on with it since it's good for testing exhaust shapes, but the idea is to use a different renderer ingame. Such raytracing is too costly to do it each frame. Instead, almost the same effect can be achieved by stacking facing quads of slices of such 3D volume. Imagine that as raytracing in parallel: each pixel advances a bit each time a quad is drawn. Only that way, the GPU can make use of its extensive parallelization. But the issue of 3D textures is still there. As you adequately computed, a 256x256x256 grayscale texture would need 16777216 bytes, which is too much for a simple exhaust. We could also use a 16x16x16 texture, which would take 4K bytes only, and would still be good (since the function you described is highly smooth). So, it could work with 3D textures. But since lots of cards don't support 3D textures well, and since the function you describe (except for the cone) is completely symmetrical in all 3 axes, using 3D textures is overkill.
I'm not sure yet how to do the cone thing, or better yet, how to create arbitrary shapes. I'm thinking about that.

Hm... idea... half-facing instead of facing...
I'll try this weekend...

[chuck_starchaser]

No no no; sorry I wasn't clear. The software I'm working on is a console app to generate images of the exhaust from different angles. At run time we select the two images whose planes are closest to facing the camera, and interpolate in alpha.
Once I'm done with this software, it will probably take *minutes* to compute 4 images, at angles between 0 and 90 degrees; --namely at 11.25, 33.75, 56.25, and 78.75 degrees; and where 0 degrees would be rear-view, and 90 degrees would be side-view. Those 4 images will be 256x256 and will be mostly white to black gradient but with a bit of subtle yellow to red hues toward the periphery. No alpha. And we'd blend them (ALPHA, ONE), where alpha is one for a plane directly facing the camera (zero for the other), or some other balance depending on the angle.
Oh, yeah, also: We won't need to mipmap them or filter them at all, just point sampling will be fine. And I could also arrange the four onto a single 512x512 png, if it helps reduce loading time and simplify image specification.
EDIT:
I think that another feature the exhaust is going to need is scaling randomization from frame to frame, like between 0.98 and 1.02, say; otherwise it might look too static.
I also hope that missiles do turn the nozzle in order to change directions...

[chuck_starchaser]

Alright here's the missile exhaust ("flame"). The 16 sub-images correspond to successive viewing angles, starting from the view behind the missile (0 degrees) and ending with the view from the side (90 degrees), in 6-degree increments. Fine enough, IMO, that we don't even have to interpolate between two of them --just pick the nearest. And they are fuzzy enough we don't need to mip map. Just point sampling is enough on the way down. Each sub-image is 128x128 RGBA, so on expansion of the image we should filter. Alpha is at 255. We should blendfunc(1,1).
Note that the four images in the main diagonal --from top-left to bottom-right--, represent 0, 30, 60 and 90 degree views.



The intended application is as follows:
1) compute dot product between view line from camera to the missile exhaust nozzle, and the main axis of the nozzle.
2) compute arc-cosine to get the angle
3) if angle > 90 degrees, angle = 180 degrees - angle
4) image number = (angle + 3 degrees) / 6 //+3 for rounding
5) texture map the picture with blendfunc( ONE, ONE ) onto a camera-facing billboard whose center is about 2 inches behind the nozzle, and rotated so that the left side of the image points in the direction of the exhaust, and away from the missile.

NOTES:
The size of the billboard should be such that the length of the side is 8 times the diameter of the missile's nozzle.
Do NOT modulate brightness or alpha. The fact that light reaching us decreases with the square of the distance is already accounted for by the decrease in apparent size of the billboard as the missile moves away. If missile thrust is modulated, maybe use the square root of the modulation and apply it to both brightness *and* billboard size.
It would be nice, when a missile is passing close, to put a light on it, so that the cabin interior may be illuminated by its exhaust.
The code used to generate the above image is at http://www.deeplayer.com/dan_w/goodies/exhaust.cpp

[Wisq]

Keep in mind that you'd still want aerodynamic missiles if you ever intended to use them within an atmosphere (as per the planetary flight thread).

I like the other ideas, smoke trails included, even if they're not right for space. (Maybe spark trails? I dunno.)

[chuck_starchaser]

Keep in mind that you'd still want aerodynamic missiles if you ever intended to use them within an atmosphere (as per the planetary flight thread).

True. Nothing prevents us from having atmo capable and non atmo capable missile categories, though. A non-atmo missile could carry a much larger sensor array, for example, and would have the ability to turn its engine on and off, since it can count on inertial, frictionless flight and can therefore save fuel and have greater range.

I like the other ideas, smoke trails included, even if they're not right for space. (Maybe spark trails? I dunno.)

Sparks are short lived; but we could have flare/chaff-trails to confuse anti-missile missiles, and PD weapons.

BTW, the exhaust technique described above is somewhat obsolete as we are probably going to use a shader program for it.

[Wisq]

Any means to draw the eye to the missiles is an improvement in my books. Makes space battles appear a little more epic.

Being on the end of a smoke trail is the obvious one; the eye is drawn to a jet by its contrail, not by it being shiny. But other methods can be nearly as effective or even moreso, especially against a black background.

[klauss]

Hud-enhancement is my idea.
Like a special targetting box around visible missiles.
Can be made as fancy as you want. Even artificial trails can be rendered.