Special Aircraft Service
the SAS Hangar => The Lounge => Topic started by: WxTech on March 01, 2020, 04:40:09 PM
-
Number one: Ship wakes
Generally, the cavitation wakes ('foam' trails) behind ships in our game are given a slight continued widening until disappearing. In reality such wakes do no such thing. Because they're comprised of air bubbles, they do not continually expand in areal coverage due to the friction against the surrounding water. Rather, they essentially remain in place (outside of the initial turbulent mixing). And so real cavitation wakes maintain a basically constant width.
The .eff file responsible should therefore have the finishing size of the .tga the same as its starting size. To have this expansion occurring looks cartoonish; a constant-width wake looks far more realistic.
Number two: High clouds
Of late there has emerged an aesthetically pleasing approach to representing the high level clouds. And that's by the wide use of photos of clouds comprised of water droplets. Such clouds as stratocumulus and altocumulus look more interesting than cirriform (ice crystal) clouds due to their greater optical depth and shadowing.
But here's the problem from the science standpoint. They're necessarily placed at the same 7km altitude as the stock cirrus clouds, where ice crystals dominate and water droplet-based clouds seldom occur. (The in-place water drop clouds being cirrocumulus and aircraft contrails, and the intruders being the rising tops of towering cumulus and cumulonimbus.) This incongruity rubs this old met man the wrong way ;) . It's so odd to see the kind of denser cloud found at 1-4km being raised to the regime of the cirrus.
Another incongruity. For those cloudy sky graphics that show much cover by optically dense cloud, the treatment of ground (and other objects) illumination as being like that for thin cirrus is a bit jarring.
I did try for a while some number of these cloud graphics, but have gone back to the more proper and correct cirrus. To this end I have begun to make 2048 pixel cirriform images (just one so far), not having found any made elsewhere.
-
You are right! I didn't even know! In fact, the trail is straight and seems to widen only in perspective when viewed from behind.
(http://www.sonar-info.info/p96/f1.jpg)
Left: ship; right: submarine [Source: http://www.sonar-info.info/p96/96pagina.html]
(https://www.lucadea.com/wp-content/uploads/2019/05/La-scia-della-nave-960x900.jpg)
(https://footage.framepool.com/shotimg/qf/657702059-autotraghetto-visions-of-greece-mar-egeo-greco-scia.jpg)
I personally believe that there are more important gaps to fill (for example, the absence of propwash on aircraft), however it would also be nice to see this visual defect corrected.
-
Number two: High clouds
Of late there has emerged an aesthetically pleasing approach to representing the high level clouds. And that's by the wide use of photos of clouds comprised of water droplets. Such clouds as stratocumulus and altocumulus look more interesting than cirriform (ice crystal) clouds due to their greater optical depth and shadowing.
But here's the problem from the science standpoint. They're necessarily placed at the same 7km altitude as the stock cirrus clouds, where ice crystals dominate and water droplet-based clouds seldom occur. (The in-place water drop clouds being cirrocumulus and aircraft contrails, and the intruders being the rising tops of towering cumulus and cumulonimbus.) This incongruity rubs this old met man the wrong way ;) . It's so odd to see the kind of denser cloud found at 1-4km being raised to the regime of the cirrus.
Graphics Extender can also render them at different altitude ;)
https://www.sas1946.com/main/index.php/topic,63186.msg695780.html#msg695780
-
The bow and stern wakes are made by the ship traveling through the water and therefore spread out. The turbulent wake is, as previously pointed out, is made by the propellers and are contained within the other two wakes.
As far as cloud rendering I believe the game's original vision was fighters at medium to low altitude.
-
Greybeard,
If you have the effects folders extracted (or have some comprehensive mod invoice living them), you can look for the .eff files using the wake graphic, and then make the second value for size equal to the first.
Silbenli,
That's a good thing, being able to define the high cloud height. But the matter of cloud depth, or thickness, remains as before. That is, it's treated as a zero-thickness sheet, with a bit of 'fog' effect fakery to suggest passing through cloud. This works well enough for the generally sheet-like cirrus type clouds, but not for optically dense, water droplet-based cloud forms that typically have some vertical depth to them.
-
Number three:
There are numerous buildings and objects that have accrued over the years for which shadows were not supplied. This is an easy thing to fix, if all such were extracted and rounded up as a group. The work involves basically copying the existing vertices, and would go quickly. Depending on the number of objects, a small 'task force' could be set up to spread out the work...
Number four:
Some buildings have as the lowest LOD a simple flat polygon that *rests on the ground* (the same height as the 'floor'.) This is bad, for it causes flickering at longer view distances, due to the 'conflicting' with the terrain texture upon which it sits. The solution is to raise this polygon at least a couple meters; the actual characteristic roof height is generally fine.
As for the aforementioned shadowless objects, these annoying specimens--of which I think there are fewer--should be collated for a final fixing. Another simple task, in most cases involving merely raising the (usually) Z value of 4 vertices for the farthest LOD.
-
Number five:
Ship and vehicle smoke. I find that the best effect involves a relatively quick initial vertical rise followed by a slowing down so that the smoke trail becomes largely horizontal. A smoke column from a moving vehicle that continues to rise at about a constant rate makes for an oddly straight, fairly steeply angled trail that's kind of cartoonish. Like the way a child might represent it.
Real exhaust gases, due to turbulent intermixing, tend to cool quickly enough that their buoyancy is of small magnitude. Moreover, resistance to the convevtive rising of such small cells by the surrounding air dampens said vertical motion. And so these effluvia rise at slow rates, dissipating largely in place with respect to the air flow within which they are carried. Indeed, with a reasonable breeze and the resulting turbulence induced by the ground/water, the smoke stream often is disturbed to the point where parts can be driven toward the surface.
-
Number six:
Ground illumination from rockets. The game uses a simple--indeed, odd--method of 'simulating' ground illumination from rocket motors. And that is to NOT treat the source as being located at the flame itself, but rather to place a light source *always* on the ground/water, directly underneath, irrespective of the putative source height. This results in two bad phenomena for a source some distance above the illuminated surface:
- The intensity of surface lighting is too strong.
- The gradient of illumination is too marked.
This suggests to notably reduce the strength of the effect. To the point, ideally, of invisibility (hopefully) during daytime while retaining some visibility at night.
I've made my own first, not yet aggressive enough stab at this, which definitely looks better. But I'd like to further refine it.
-
In regards Number Five, does the game use to same effect for non moving burning vehicles?
-
Smokes for burning objects in general do tend to be given a gradual upward acceleration, in order to attain some height without requiring too-long live times (or comically rapid ascent rates.). As we know, longer live times result in more particles, which can tax the old game engine in busy scenarios. It's eminently easy to have many more damage smoke sources than smoke stack smokes, and so more care in keeping damage smoke particle counts low is good practice.
Ideally, fire-sourced smoke should also become less buoyant with time/height, with the result of the smoke column becoming more horizontally oriented. As opposed to the current and common manifestation of becoming more vertically oriented. But as noted, this would require longer live times if the column is to not fade out before attaining any kind of decent height/range from the source.
-
Number seven. Gunsight reflector plate specularity.
Gunsight reflector plates should as a general rule be given zero specularity. Why? Because the only way they can reflect light from an external source to the pilot/gunner is *through* the sight *and* the floor of the plane beneath. Notice how sun glare off such a reflector occurs only when the plane is diving vertically or inverted? In other words, when the direction to the Sun is below the belly of the plane, where the light path is coming up through the floor and the sight, so as to be reflected to you. That's so wrong. Having Sun glare from such an impossible direction is a needless impediment.
All my sights do not do this horribly incorrect thing. To that end, I make the textures for the reflector plate as a separate entity. Indeed, both the flat reflecting surface and the edge of said plate are given separate textures with their own lighting parameter values. If a stock sight has its reflector built into the texture for the rest of the sight, a new .mat file could be created, and the mesh have the relevant reflector elements separated out and assigned to this .mat.
-
Number eight. The color of fog/haze.
Fog which appears in early morning and for the poorer weather settings is too damn blue. I'd love to see this made more neutral. For that matter, the less opaque haze is perhaps too blue as well, although not as awfully bad as that cursed fog hue.
In one of the classes I found a line which seems to define the RGBA values for fog, but no change could be effected here. I suppose it's locked in a .dll.
Number nine. Overall twilight sky transition.
The sky remains too bright throughout much of the deeper twilight times, then suddenly darkening very near the transition to night. It's not coordinated with the Ambient and Diffuse values calculated for landscape/cloud illumination. The result is odd swaps in the contrast between cloud and sky brightness, with one being too bright and then suddenly the other being too bright. Another element that seems to be tied up in a .dll.
Number ten. Sun and Moon glow when these bodies are beneath the horizon.
These glows (yellow for the Sun, cyan/blue for the Moon) remain too bright when their source is well below the horizon. Particularly for the Moon, and especially when it's just a crescent! Another inaccessible .dll thing.
Number eleven. Star visibility.
Stars seen from ground level practically upon the Sun dipping below the horizon? Right. Stars being seen at high noon from a mere 8km altitude? Right. And I'd argue the points are shown as too intense, at night as well. Another inaccessible thing squirrelled away in a .dll.
-
Number eight. The color of fog/haze.
Fog which appears in early morning and for the poorer weather settings is too damn blue. I'd love to see this made more neutral. For that matter, the less opaque haze is perhaps too blue as well, although not as awfully bad as that cursed fog hue.
In one of the classes I found a line which seems to define the RGBA values for fog, but no change could be effected here. I suppose it's locked in a .dll.
Number nine. Overall twilight sky transition.
The sky remains too bright throughout much of the deeper twilight times, then suddenly darkening very near the transition to night. It's not coordinated with the Ambient and Diffuse values calculated for landscape/cloud illumination. The result is odd swaps in the contrast between cloud and sky brightness, with one being too bright and then suddenly the other being too bright. Another element that seems to be tied up in a .dll.
Those issues are pretty much solved in graphics extender when using precomputed atmosphere.
-
Yep, I know il2ge has the fog/haze thing licked. One thing which that great hraphics updating now highlights rather badly is the small sizes of many maps. I wonder what fraction of folk are using the graphics extender regularly at this time? Perhaps many are like me, awaiting the maturing beyond the WIP stage? ;)
-
Number twelve. Smoke effect treatment when Effects=2 vs =1 in conf.ini.
I'm inspired to visit this after just watching a new YouTube video done by Supersensitive, featuring a number of new ships. In it, the smoke from stacks exhibits an unrealistic brightness difference from sunny to shadowed side.
Because of the frame rate hit and the worse flickering of smoke particles when Effects=2, I still have Effects=1 in my conf.ini. When I did try the =2 setting, I observed that the particle brightness gradient based on light source direction tended to be much exaggerated. That is, the sunlit side was overly light in tone. This was of course due to the .mat tile parameters for Ambient and Diffuse for the smoke graphics generally being appropriate for 'solid' objects.
Smoke clouds are not solid objects. Light penetrates them, and the way scattering operates throughout results in a cloud having a rather 'flatter' brightness gradient between illuminated and shadowed sides than occurs for an object that has a discrete, opaque surface.
This means that smoke effects should really be structured differently based on whether Effects=1 or Effects=2. For the former, the .mat files can have both Ambient and Diffuse set to 1. But for the latter, one or both of Ambient and Diffuse should be set to less than 1. I've not done any experimenting, but feel that about 0.5 could be a good starting point, with 0.7 perhaps being a maximum.
To begin with, Ambient could be left at 1, or perhaps just a bit less. Try Diffuse of around 0.5. The idea is to obtain a reduced range in brightness between sunlit and shadowed sides, but retain a global variation between bright day and dark night.
Now, it could well be the case that the Ambient/Diffuse settings made for the more sophisticated Effects=2 lighting model would work well enough for Effects=1. Although it might require to have either the .tga overal tone or the .eff Color values set a bit differently in order to achieve the desired general lightness/darkness.
If I ever get round to trying this out (certainly if deciding to adopt Effects=2), I will report results.
-
Back to my #5 (Reply #6).
Yesterday I did some tweaking on just about every smoke effect related to ground source emission. My methodology is this. I want the smoke to rise initially at its maximum velocity, and gradually slow in its vertical ascent from there. This is to give the more realistic appearance of wind speed increase with height, causing the smoke column to become gradually more horizontally oriented with height.
Something like a two-fold rang, in the emission velocity e.g., 5 to 10 m/s, supplies a nice undulation in the developing smoke column. The range in angle of emission is relatively small, from 0-10 degrees for smaller particle starting size to 0-30 degrees for the larger starting particle size.
A small value is given to the VertAccel parameter, this being 0.1 at most, often zero. GasResist is also kept small, with 0.01 being common. These have to be balanced in order to get the gradual slowing down as the particles rise.
At this moment, I've found that the Wind value of 15 (which is in m/s) gives a very good looking result. I will try to slow this to about 10 and see how that looks. But I feel that the larger number will likely be the better. Even though this means a 30 knot wind speed, decidedly on the high side.
Some smokes, such as from ship funnels, do not look good at the 15 m/s velocity. I might 'cheat' in such cases, setting values about half that for the 'full speed' smokes (which is the majority.)
I elected to do a deeper fix for the smokes related to crashed aircraft (the long-lasting column). In Explosions.class this smoke group had the vector normal oriented along the ground. I added a couple lines of code to orient this vector for emission vertically. I might have have been able to compensate in the .eff file by setting the angle of emission centered upon, say, 90 degrees. But I like consistency, where all ground smokes from damage/fires have the emission vector centered on the vertical.
Once I arrive at a happy solution, I'll make this stuff available. If different game versions or effect packs result in lack of conformity, at least the file content can be applied where suitable, and used as a template for other effects I've not addressed.
-
Since adopting 4.12.2, I've got to dislike the inclusion of the Bomb250Water effects EVERY TIME a plane crashed into water. All occurances looked just like the bigger bomb/shell impacts with water, which repetetiveness got tiresome. I've got rid of the bomb250 effects here (by REMing out with the /* */ block), and included the random occurrence of a selection of land aircraft crash effects so as to suggest the occasional explosion. Of course, I've tuned the effects themselves to my preference. From Explosions.class:
public static void AirDrop_Water(Point3d point3d) {
if (Config.isUSE_RENDER()) {
float f = 4.0F;
float f_77_ = 1.0F;
o.set(0.0F, 90.0F, 0.0F);
l.set(point3d, o);
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Water/Base.eff", f);
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Water/Fontain.eff", f);
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Water/Spray.eff", f);
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Water/Soot.eff", f);
/* Eff3DActor.New(l, 1.0F, "effects/Explodes/Bomb250/Water/Fontain.eff", f);
Eff3DActor.New(l, 1.0F, "effects/Explodes/Bomb250/Water/Fontain2.eff", f);
Eff3DActor.New(l, 1.0F, "effects/Explodes/Bomb250/Water/Fontain3.eff", f);
Eff3DActor.New(l, 1.0F, "effects/Explodes/Bomb250/Water/Fontain4.eff", f);
Eff3DActor.New(l, 1.0F, "effects/Explodes/Bomb250/Water/Fontain5.eff", f); */
// Add NEW land effects
if (World.rnd().nextFloat() < 0.3F) {
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Land/Base.eff", f);
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Land/Burn.eff", f);
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Land/Dirt.eff", f);
if (World.rnd().nextFloat() < 0.5F) {
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Land/Smoke.eff", f);
if (World.rnd().nextFloat() < 0.33F) {
Eff3DActor.New(l, f_77_, "effects/Explodes/Aircraft/Land/Smoke2.eff", f);
}
}
}
SfxExplosion.crashAir(point3d, 2);
ExplodeSurfaceWave(1, 110.0F, 6.0F);
}
}
Rather more variety now!
For those not conversant with interpreting code:
The first 4 Water-based effects are always executed.
The next 5 Bomb250-based effects are ignored (I could have deleted them, but retain them here to show what was.)
The next 3 Land-based effects are executed 30% of the time.
The second-to-last is executed 15% of the time.
The last is executed 5% of the time.
And so there can be 4, 7, 8 or 9 effects being generated simultaneously.
-
About the damage fire and smoke for ships' guns, from peashooters to the bigguns. I just succeeded in cracking the decompiler errors I've been suffering for BigShipGeneric.class with help from Mike. My goal was to increase the duration of time over which these effects would be in action. The stock interval is rather brief. Here's the relevant part of said class, from 4.12 (the last half is not pertinent here).
The original values of j2, which are in seconds, are 'REMed' out with "//" characters. (I prefer to leave original values in my Java, so that I know what I'm evolving from.) The smoke durations have been more than doubled for the smaller smokes, and almost doubled for the bigger ones.
The duration of the associated fire for the destryoed gun is now 0.75 times the smoke duration, not the former 0.5.
The smoke effects themselves have been altered to reflect the longer time over which to disperse in size.
if(dsmoks != null)
{
for(int k = 0; k < dsmoks.length; k++)
{
if(dsmoks[k] == null || dsmoks[k].pipe != null)
continue;
int k1 = dsmoks[k].part_idx;
if(parts[k1].state == 0)
continue;
String s1 = parts[k1].pro.baseChunkName;
Loc loc = new Loc();
hierMesh().setCurChunk(s1);
hierMesh().getChunkLocObj(loc);
float f = parts[k1].pro.stre.EXPLNEAR_MIN_TNT;
String s2 = "Effects/Smokes/Smoke";
boolean flag2 = true;
if(parts[k1].pro.haveGun())
{
s2 = s2 + "Gun";
int j2;
if(f < 6F)
{
s2 = s2 + "Tiny";
j2 = 15; //6;
} else
if(f < 10F)
{
s2 = s2 + "Small";
j2 = 20; //8;
} else
if(f < 14F)
{
s2 = s2 + "Medium";
j2 = 25; //12;
} else
if(f < 18F)
{
s2 = s2 + "Large";
j2 = 30; //16;
} else
{
s2 = s2 + "Huge";
j2 = 35; //24;
}
dsmoks[k].pipe = Eff3DActor.New(this, null, loc, 1.0F, s2 + ".eff", j2);
Eff3DActor.New(this, null, loc, 1.0F, s2 + "Fire.eff", (float)j2 * 0.75F); //fire duration factor was 0.5, now 0.75 of smoke duration
continue;
}
s2 = s2 + "Ship";
if(f < 6F)
s2 = s2 + "Tiny";
else
if(f < 10F)
s2 = s2 + "Small";
else
if(f < 22F)
s2 = s2 + "Medium";
else
if(f < 30F)
s2 = s2 + "Large";
else
if(f < 50F)
s2 = s2 + "Huge";
else
if(f < 100F)
s2 = s2 + "Enormous";
else
s2 = s2 + "Invulnerable";
if(this instanceof TankerType)
{
dsmoks[k].pipe = Eff3DActor.New(this, null, loc, 1.1F, "Effects/Smokes/SmokeShipTanker.eff", -1F);
Eff3DActor.New(this, null, loc, 1.0F, "Effects/Smokes/SmokeShipTankerFire.eff", parts[k1].pro.dmgTime);
} else
{
dsmoks[k].pipe = Eff3DActor.New(this, null, loc, 1.1F, s2 + ".eff", -1F);
Eff3DActor.New(this, null, loc, 1.0F, s2 + "Fire.eff", parts[k1].pro.dmgTime);
}
}
}
-
As part of my ongoing tweaking of effects, I've been delving into Explosions.class. Looking into the aspect related to ships, I found that there is a test condition for bomb and rocket explosions whereby the height above ground/sea is checked in order to invoke the additional effects for land or water effects. The more powerful the explosive, the higher it can be above the surface and still cause the triggering of the basic land/water effects.
This is why for bigger bombs particularly, a well laid egg on the deck of a ship can still result in the same geyser of water effect as when the bomb misses. Here are the stock heights, by bomb group, as established in the "generate" method, followed by my own new provisional values:
RS82 5m 1m
BOMB250 10m 2.5m
BOMB1000a 20m 4m
BOMB1000 50m 5m
I also created a new instance for Explode10kg, assigning 1m.
I always though it odd that a bomb detonating on or inside some sizable vehicle or structure should be accompanied so often by the additional earthen or water geysers. Now I know why. Reducing these distance-from-surface thresholds makes more sense to me, for a couple of physical reasons. And at the very least it goes to reducing the number of particle effects, a boon for carpet bombing and generally busy bombing action.
-
A new effect I just cooked up. It puts 4 dozen water spashes, within 150m of the explosion, to represent high velocity shrapnel from big bomb blasts upon water craft. This is a 2000 pounder.
Note that there is no accompanying water geyser with the bomb detonation due to my tighter constraints on their invocation, as laid out in the previous post.
(https://i.imgur.com/npVhTIV.jpg)
In the generate method of Explosions.class, here's the code I added for BOMB1000a (from the line commented upon as //NEW - add 48.....:
} else if (f < 3000.0F) {
if (point3d.z - Engine.land().HQ_Air(point3d.x, point3d.y) < 4.0) { //was 20
if (Engine.land().isWater(point3d.x, point3d.y))
BOMB1000a_Water(point3d, 4.0F, 1.0F);
else
BOMB1000a_Land(point3d, 4.0F, 1.0F, bool, bool_135_);
}
BOMB1000a_Object(point3d, -1.0F, 2.0F);
if (Engine.land().isWater(point3d.x, point3d.y)) { //NEW - add 48 small water hits randomly placed around explosion
int j = 48;
for (int i_99_ = 0; i_99_ < j; i_99_++) {
Point3d point3d_99_ = new Point3d(point3d);
double d = World.rnd().nextDouble(0.0, 300.0) - 150.0; //-150 to 150
if (d < 30.0 && d >= 0)
d = World.rnd().nextDouble(0.0, 3.0) * 30.0; //30 to 90
else if (d < 0 && d > -30)
d = World.rnd().nextDouble(0.0, 3.0) * -30.0; //-30 to -90
point3d_99_.x += d;
d = World.rnd().nextDouble(0.0, 300.0) - 150.0; //-150 to 150
if (d < 30.0 && d >= 0)
d = World.rnd().nextDouble(0.0, 3.0) * 30.0; //30 to 90
else if (d < 0 && d > -30)
d = World.rnd().nextDouble(0.0, 3.0) * -30.0; //-30 to -90
point3d_99_.y += d;
Loc loc = new Loc(point3d_99_);
Point3d point3d_100_ = loc.getPoint();
World.cur();
point3d_100_.z = World.land().HQ(point3d_99_.x, point3d_99_.y);
o.set(0.0F, 90.0F, 0.0F);
l.set(point3d_100_, o);
Eff3DActor.New(l, 1.0F, "Effects/Explodes/Debris/WaterFrag/Fontain.eff", 2F); //brand new folder/effects
Eff3DActor.New(l, 1.0F, "Effects/Explodes/Debris/WaterFrag/Fontain2.eff", 2F);
}
}
-
If one wanted to go whole hog, a similar shrapnel effect for low aerial bursts could be implemented. Such as flak bursting about wavetop-skimming Betties. But of course, for more common events that can occur in quite rapid succession, the particle count could can grow frightfully. The counter strategy would be to keep the live time for the splash particles as short as acceptable (perhaps 0.5 to 0.7 second), and to build each splash upon the minimum number of particles (like just one.)
-
Very cool
-
I should point out that this 'water shrapnel' effect algorithm is simply copied and adapted from the code that generates the few small additional fires near the main one where aircraft have crashed on the ground (in the AirDrop_Land method of the same Explosions.class.) It goes to show that even an incompetent non-programmer (well, I did work with BASIC decades ago) can look to existing code snippets for adaptation to a new purpose.
My part of the algorithm for moving any particles initially located within 30m of the blast (and hence likely to be inside the ship) to farther away--with further randomization--is probably crude, if it can be condensed to a shorter construct. But it works.
-
A new wrinkle on an existing effect... Adding random fire and smoke to plane crashes into water. I've got rid of the previously always-included 250kg water geyser effect group. I've retained and augmented the basic water splash, adding for some relatively small fraction of events the new fire and smoke effects along the lines seen for land crashes. They're not always the same; sometimes just a smoky fireball, others the addition of a heavier smoke cloud and smoke column and fire burning on the surface.
Just as the basic splash has about died down, we see the smoky fireball rising.
(https://i.imgur.com/gBc6wRn.jpg)
Another event, a bit later on, after the smoky fireball has disappeared and a short duration fire and smoke column are seen. This screenie is before I just now added a bit of code to add 2, 3 or 4 extra fires.
(https://i.imgur.com/hNX9kZo.jpg)
[EDIT: The Java code which was formerly here has been fixed and augmented. Look a few posts ahead]
-
From what I've seen on film, if the plane was on fire or the wing separated and was dumping fuel on impact, there would be fire on the water as the fuel would burn off. Some just had water splash and others had a large blackness to the splash.
Either way, I look forward to you releasing this.
-
To illustrate my approach to plane damage smoke construction, I utilize the effect pairs of type SPD and TSPD as intended; particles for the former and trails for the latter. This is an economical way to double (or more!) a smoke trail, with very minimal impact to the graphics engine.
Moreover, the way particles fade is a bit too abrupt in many instances, and especially so for smoke trails like these. The embedded trail, when extending to well past the termination of particle visibility, helps to further blend the smoke trail into a more gradual disappearance.
Here's a Wildcat with damaged oil cooler. Note that I like a slightly bluish hue for such smoke. The trail stream extends for about 2X the length of the particle stream.
(https://i.imgur.com/ZBg3VTX.jpg)
-
Another smoke trail illustration, using the aftermath of a mid-air plane explosion. All smoke streams here have embedded trails. They're not of high opacity, being fairly subtle compared to the denser particles. But in spite of the gaps between particles, particularly earlier on when smaller, the embedded trail goes some way to 'filling in' the otherwise empty space, giving better continuity and a fuller appearance.
(https://i.imgur.com/PkZ3ehz.jpg)
-
Tweaked the crashed plane flames on water effect. Now have several fires, instead of just one. Here you can see part of the victim's fuselage next to the fires.
(https://i.imgur.com/3T7nVsq.jpg)
The previous post in which I included the Java was not yet tested code; that's been deleted. I've fixed and further enhanced it, as below. In addition to adding more fires (total of 4, 5 or 6), I made them and the attending smoke column last a bit longer (up to 20 sec). And they can't cluster as tightly as before, where it could be the case that all lay essentially on top of one another.)
This is in the Explosions.class, 4.12. It should work in any game version if added to its Explosions.class, and if the specified effects exist, of course. The AircraftSmokeBoiling.eff is my own original effect, used with land crashes and here.
public static void AirDrop_Water(Point3d point3d) {
if (Config.isUSE_RENDER()) {
float f = 6F; //4.0F;
float f_77_ = 1.0F;
o.set(0.0F, 90.0F, 0.0F);
l.set(point3d, o);
Eff3DActor.New(l, f_77_, "Effects/Explodes/Aircraft/Water/Base.eff", f);
Eff3DActor.New(l, f_77_, "Effects/Explodes/Aircraft/Water/Fontain.eff", f);
Eff3DActor.New(l, f_77_, "Effects/Explodes/Aircraft/Water/Spray.eff", f);
Eff3DActor.New(l, f_77_, "Effects/Explodes/Aircraft/Water/Soot.eff", f);
SfxExplosion.crashAir(point3d, 2);
o.set(0.0F, 0.0F, 0.0F);
l.set(point3d, o);
ExplodeSurfaceWave(1, 110F, 6F);
if (World.rnd().nextFloat() < 0.33F) {
l = new Loc(point3d);
Point3d point3d_87_ = l.getPoint();
World.cur();
point3d_87_.z = World.land().HQ(point3d.x, point3d.y);
o.set(0.0F, 90.0F, 0.0F);
l.set(point3d, o);
Eff3DActor.New(l, f_77_, "Effects/Explodes/Aircraft/Land/Base.eff", f);
Eff3DActor.New(l, f_77_, "Effects/Explodes/Aircraft/Land/Burn.eff", f);
if (World.rnd().nextFloat() < 0.5F) {
Eff3DActor.New(l, f_77_, "Effects/Explodes/Aircraft/Land/Smoke2.eff", 10F);
Eff3DActor.New(l, f_77_, "3DO/Effects/Aircraft/FireGND.eff", 20F);
Eff3DActor.New(l, f_77_, "3DO/Effects/Aircraft/AircraftSmokeBoiling.eff", 20F);
int i = World.rnd().nextInt(3, 5); //add 3 to 5 extra fires, randomly placed
for (int i_88_ = 0; i_88_ < i; i_88_++) {
Point3d point3d_88_ = new Point3d(point3d);
double d = World.rnd().nextDouble(0.0, 16.0) - 8.0; //= -8 to 8
if (d < 2 && d > -2)
d = 2;
point3d_88_.x += d;
d = World.rnd().nextDouble(0.0, 16.0) - 8.0; //= -8 to 8
if (d < 2 && d > -2)
d = 2;
point3d_88_.y += d;
Loc loc = new Loc(point3d_88_);
Point3d point3d_89_ = loc.getPoint();
World.cur();
point3d_89_.z = World.land().HQ(point3d_88_.x, point3d_88_.y);
Eff3DActor.New(loc, f_77_, "3DO/Effects/Aircraft/FireGND.eff", 15F - World.rnd().nextFloat(2F, 5F)); //live 15-18 sec
}
}
}
}
}
-
On the subject of smoke columns and fires from crashed planes. For the land variant I notably reduced the time over which these effects live. The stock class has them living for 1200 seconds, or 20 minutes (a bit less for the extra fires scattered near the principal one.) I cut this down by half. My reasoning is that so many other smokes will end rather on the early side compared to the crashed plane stuff, which seems to be putting too much emphasis on the downed planes. I prefer nearer to consistency in the game world.
I suppose I could make many or most other smokes/fires last a lot longer, as some effects modders appear to have done. In the interest of not pushing the game engine 'beyond breaking point' ;) where possible, I prefer a less demanding effects scheme.
-
I mentioned how I removed the always-occurring 250kg bomb blast water geyser effects for planes crashing into water. Here's the basic splash effect, augmented a little. The plane and the splash (the latter of which is at just about maximum size/height) are at the same distance from the viewer, and so are at the same scale.
(https://i.imgur.com/LgSwWZz.jpg)
-
Looks good. Could the " grey cloud " be a bit darker? It's hard to tell from old black and white WWII films of planes hitting the water but it looked to me to be a bit black.
-
To which image are you referring, Bombs?
The one immediately preceding your post is of the basic splash, which is always present, but *without* additional dark smoke and fire that's randomly added.
A few posts earlier we see the much darker smoke column and rising 'ball' of smoke. They *are* fairly dark, but against the dark water seem a bit lighter by contrast. Note that screenie was grabbed *after* the basic white splash had subsided already.
-
My mistake. I thought you added some color to that splash in the pic above my post. I'll shut up now. LOL :)
-
No, don't shut up! ;) Asking questions in the spirit of honest inquiry is crucial. If nothing else, it ensures than any misperceptions I might unwittingly convey, and which others might scratch heads over, have a chance for clarification.
And don't be scared to offer critiques or suggestions, either.
-
All these changes looks really GREAT! ;D ;D ;D
-
No, don't shut up! ;) Asking questions in the spirit of honest inquiry is crucial. If nothing else, it ensures than any misperceptions I might unwittingly convey, and which others might scratch heads over, have a chance for clarification.
And don't be scared to offer critiques or suggestions, either.
Ok :) I look forward to more of your work and hope you release it. Let me know if you need a " test pilot " :)
-
Years ago, in my investigations of clouds when trying to understand how the various sub-images were selected from the clouds4x4.tga and then sized grouped and rotated, I did an experiment. I made up a test 'clouds4.4.tga' graphic having 16 coloured letters. The little inset shows what it looked like. I reversed the .tga after making it because of the game drawing the images as mirror-reversed.
(https://i.imgur.com/5tOvsxJ.jpg)