Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[slibenli]

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.

[WxTech]

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?

[WxTech]

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.

[WxTech]

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.

[WxTech]

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:

Code: [Select]

    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.

[WxTech]

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.

Code: [Select]

        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);
                }
            }

        }


[WxTech]

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.

[WxTech]

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.




In the generate method of Explosions.class, here's the code I added for BOMB1000a (from the line commented upon as //NEW - add 48.....:

Code: [Select]

} 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);
}
}


[WxTech]

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.)

[SAS~Bombsaway]

Very cool

[WxTech]

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.

[WxTech]

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.




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.





[EDIT: The Java code which was formerly here has been fixed and augmented. Look a few posts ahead]