It got windy and I had to climb on the roof to fix some broken tiles by sticking them together with No Nails glue.
In other news, I have mostly been integrating Steamworks with Torque, in all those hard to reach places I haven't used before like Stats and Leaderboards and getting multiplayer achievements to fire.
To be continued ... as I forgot to do this earlier and there's only 12 minutes of the year left ...
Before we start, we should address the fact that I have communicated with the STATE APPARATUS and the APPARATCHIKS of whom have actually communicated back within the space of 60 DAYS ... which must be some sort of new world record in getting any response out of a CIVIL SERVANT - who incidentally - are still all off work, riding their tax payer bought Pelatons at home whilst the STATE APPARATUS demands everyone else goes back to the office.
We desperately need that extra 150 quid off you to squander on some bollocks
Okidoki, vidya gaemz.
Steam has started releasing information about the Steam Deck, videos and guides are available here. Looks like competition for handhelds (eg: Switch and only Switch 'cos nobody else wants to do hardware anymore), but then do we all remember how exciting Steamboxes sounded? Maybe the handheld market is less crowded (eg: Switch and only Switch 'cos nobody else wants to do hardware anymore).
Anyhoo, the upshot of all this is that I no longer feel compelled in SPACE YEAR 2022 to bother about any display size under 720p vertical.
So I have been testing out some Steamworks features on the new game, which I have not actually uploaded yet to steamworks, but am just doing it locally with Steam loaded. This gives the rather odd result of a blank page with my game title showing online and recording my progress in-game.
Fixed a bug where I accidentally dropped napalm on the player and not the enemies ...
Having decided that this all looks a little awkward online as only I can see my own game's presence anyhow, I decided it might be an idea if other people - eg: potential customers - could also see my game's presence, and thus we set about designing some box art for the Steam store page.
Soon(ish)™
This required me to remove the towel that is semi-permenantly draped over the display tablet that lies on the desk (it's an upturned A0 drawing board wedged against a window sill to take the weight of all the screens on it) and recharge the pen to get some reponse out of it.
Being a classically trained figurative oil painter (not that I've done any of that in 10 or 15 years ...) I do still find the methodology of digital painting to be a bit ... odd. Is it better to greyscale the form of the painting and then add another layer for blocking colour with some sort of transparency, or should I add colour with tone and shading for each stroke - which seems a right faff. Also I am not terribly enamored with the digitally replicated paint brushes as it's not really how physical medium works - at least not oil painting, especially when the brush leaves layered marks but I need to move the screen/canvas over to another part of the image without breaking the flow ...
Anyhow I have decided on a composition that looks like it can work by cropping with all of the sizes that Steam Capsule images require, and I havr blocked in some very rough tonal marks to find form and some basic colours. This in itself has made me wonder whether it would be better keeping the colouration simple as in a 3 layer comicbook style or more a more complicated and painterly style. Of course I might just do both and see.
Need to change that hair colour ...
In other news the UK had a storm which was actually a real storm rather than the usual crying wolf about some seasonal gales. Whilst a fence panel went down, the broken tiles which I had glued together with NoNails survived. One of the few weekends that hiking had to be called off due to safeguarding the house and general threat of death.
I am 50% prepared for Xmas which means I have alcohol, toilet paper and a sawn-off shotgun to protect it all. Still waiting for variant Ligma ... 😜
If you have fully recovered from that horrifying experience, let's talk PBR. But first ...
Not really that different, but my aeronauticals/dogfighting game is on haitus. After working on it for a full year, I have moved back to my previous game of catgirl carnage swag it up. The reason I spent the last year on the arcade aircraft game was that I needed a break from the twin-stick shooter featuring leggy ladies with fluffy ears due to burnout - see the blog entitled, "A change is as good as a rest" from last year.
Well it's been a change rather than a rest and I managed to create a full working concept for arcade style aerial combat, which I expect to return to sometime in the future. However, for now it's back to all-action catgirl shooty collectathon because it's a lot closer to completion than aeronauticals and since it's been a whole EIGHT YEARS since Airship Dragoon was launched and it's almost embarrassing that I have failed to ship anything in that time.
I've got a new app id from steam and have been busy installing steamworks for the game on my local PC. This has taken a bit of extra work, mostly due to the fact that I couldn't remember anything about getting a game working for Steam because I haven't done it in said 8 years.
Originally catgirl twin-stick swagathon shooter was called AoT ("Always on Time") ... which I dropped and renamed it "Swag It Up", a rather more to the point title. Don't go looking on Steam yet, I haven't sorted the store front out yet so it's not listed, I have just integrated steamworks locally for testing.
Now for that PBR ...
Now the engine has a new asset browsing system, which is apparently all the rage and the cool kids can't live without it. Obviously I hate the entire thing but that's the future for you; I was promised flying cars and holidays on Mars, instead I get texture memory leaks and assets overloading their materials from their own asset file instead of using my predefined materials - which are still the ones that show up in the material editor even though the other ones are the ones getting loaded.
I redesigned my swag markers
Once I had found all of this out it was simply a case of opening each asset's file and removing the material reference that was interfering with my existing materials. This was somewhat of a pain in bum due to me having huge numbers of assets/models, all of which had to be individually and manually edited.
Shiny PBR is shiny
So next up is to finish off the remaining PBR conversions and then go about porting the actual game logic to the latest Preview4 engine build. I think I will however upload the current working Dx11 but not PBR version of the game to steam for initial online testing.
The main thing to get done is sorting out the Steam store page and get it listed. This requires a trailer video and some screenshots, but most importantly I need to draw some good store front box art to advertise the game and also use as a main menu background. I also need artwork for the character portrait selection screen.
As for aeronauticals, it may well return one day and be completed and shipped. So here's a full video of the first mission.
Happy Halloween and don't have nightmares about global debt.
So it has been an ENTIRE YEAR (from 1st October 2020) of working on my aeronaut/aeronauticals/dogfighter game that was loosely inspired by Ace Combat with 1930s aircraft and a lot more tightly inspired by Descent: The Great War space combat simulator but with gravity.
How it started (after a month or so anyhow) ...
And, how it's going ...
So ... that's been a bit of a change then ...
First up, I've created a brand new class of object, aeronautVehicle, that derives off vehicle class, which derives off rigidShape which is the thing that controls the physics, and shapeBase class ... which everything and it's dog seems to derive off if you want it be any form of a dynamic object.
This meant that I had to work out how an aircraft actually flew worked. Obviously this would be incredibly boring so instead I worked out how an exciting arcade style flight model worked basing it on ideas and physics values that I mostly pulled out of my bum.
Actually that's not entirely true, I did detailed research for months previously, basing everything on real world values and compiled lengthy text files on how the whole thing would work; eg: hitpoints were based on empty aircraft weight divided by length per area element (wings, tail, etc); and thrust was based off maximum take-off weight divided by kilo-watts of power per engine (or something like that) with modifiers for total aircraft area versus air friction... eg: fat aircraft would lose speed faster than smaller ones, etc, etc.
Similarly gun damage was based off calibre, calibre per 10mm modifier, number of guns, and some other stuff, with more guns increasing both damage and overheat timing.
The real problem was creating an Ai system to fly the aircraft against the player. Not only did they not have to crash into anything --- which ended up being much harder than you'd think --- they also needed to act as if they were a real pilot, so I ended up making 12 (?) evasive maneuvers that they could pull when neccessary. Stalling ended up being a huge issue depending on speed and attitude of the aircraft and tightness of a turn. I ended up creating a class of super-Ai pilots who I never stood a chance against, and had to dial the whole OP back, discovering that the margin between genius Ai flyer and absolute idiot was very small.
Damageable elements reduced performance of the aircraft's speed, turning, rudder, etc, and the whole thing had to modeled in 3D and textures to give the player good visual feedback as to what is happening to their aircraft.
PBR was a thing ... a thing which I did not know what ORM stood for and so ended up putting the rough and occlusion maps into the wrong channels because that is how they are set out in the materials editor.
My grasp of networking certainly improved, I had managed to create a co-op mode - based on seperate instances on the same box because I only have the one machine - and I soon realized that I wasn't supposed to just fill the whole of pack/unpack with all of the read/write data because much of that was on the server anyway. Trailing definately need to be on both or either Ai/players would trail and the others wouldn't depending on how they were handling their aircraft. Huge amounts of pack/unpack were commented out and the weird jittering my AI aircraft had been doing in debug mode stopped.
I created a crude lobby system were the level loaded without the mission starting except a briefing to give the player the details of the mission via a seperate file and to choose their aircraft and paint schemes. The player would then wait in this psuedo-lobby for other clients to connect or start a co-op multiplayer mission alone and newly connected players could drop in and out. Debriefing required a bit more voodoo as shifting large amounts of player-mission contextual descriptors - that's text - required some fancy thinking to avoid abusing huge numbers of server to client calls - something that I had been very keen on working smoothly and with the least possible amount of bandwidth.
Creating missions was a series of timed and triggered events based on what the player and Ai pilots were doing. This required lots of scripting due to the lack of physical triggers which a player could walk into on a more normal character based game of the types I had previously demoed or developed.
And so that is kinda of it. After a year of development I have a fully functioning dogfighting game that plays halfway between an arcade shooter and simulator with a mission complete with playable roster of aircraft, briefing, debriefing and drop in and drop out online co-op mode. So naturally it's time to relegate this to the backburner and go return to my previous game project (and really tidy up it's networking) as I want something that can at least be released for Early Access early(ish) next year and Freespace-style dogfighter will require the most work whilst topdown catgirl mayhem is around halfway complete but needs "fluff" adding for the player's ease of life for the first few levels.
Having mostly been a single player player ... stops, rereads that, nah we're good ... the concept of networking multiple clients wasn't something that I had particularly much experience with. This was most obvious when reviewing my C++ code and seeing that I had literally packed/unpacked everything of my custom aeronautVehicle class regardless of whether it required it or not. On further inspection only rigidBody attitude and whether it should be emitting vapour or not really needed to passed around every frame the engine updated. This could probably explain the jitteriness of Ai and other client aircraft movements.
Debugging ... (don't @ me!)
After quite a bit of faffing around I not only managed to get 4 player Co-Op mode working but had it so that other remote human clients could arrive after the mission had started, and replace the allied AI who had already spawned in their place. The Ai would smoothly disengage, move away and fade out before being deleted, hopefully out of view of other players.
Any later joining client would have to pick the remaining available flights/callsigns that human players were permitted at the briefing screen. Initially I had listed each and every callsign individually, but once I had the whole system up and running, I decided it would be better to simply list available wings and the number of taken and free roles within them. This would cut down on the possibility of scrolling through vast numbers of disabled buttons.
Co-Op Mode! Player 1 and 2 look at each other during a flypast.
The briefing screen also acted as a rather rudimentary lobby. Players could arrive and choose their flight roles, aircraft and paint job, and then wait for the server to fill. Once two or more players had arrived and selected their aircraft and were ready to sortie, a countdown timer would start and automatically trigger the mission so they weren't waiting around for ever. A lone player, waiting on the server on their own could start the mission with Ai wingmen, and future arriving players could drop in and drop out as replacement, as explained above.
One of the things which had proven to be an issue with the networking was briefing. Sending huge amounts of text over a client connection seems like rather a bad thing and I have been desperate not to abuse seven shades out of the commandToClient. This is the reason that I haven't got a large and indepth mission briefing description working yet. I am considering creating it as a seperate GUI file and sending that directly to the player in the same way mission download should work. I do however have a quick description of mission objectives created, pulling them directly out of the mission file.
Lies, Damn Lies And Statistics
The post mission debriefing screen lists all the statistics that pertain to the player. All allied aircraft are listed as well as their victories, recorded as kills and assists, and their final state which descibes their damage. Added to this is the individual client's performance which ... when I iron out the bugs ... will list the types of kills and assists they scored as well as how accurate they were with their weapons. Right now ... it's a tad buggy ...
More Lies And Bugs Than Statistics ...
Here's a video of the old way I selected playable flights with the multiple buttons at the beginning, and shows how the briefing screen works for aircraft and paint scheme choice.
And so that was the month that was. August, it was wet and cold and not
much of an end to summer. The summer fan is dismantled and stored for
next year, and the Autumn duvet is already on the bed for maximum comfy.
What's a plane game without a pre-mission briefing and selection screen? Lacking that's what. So here it is.
Choose Your Fighter! Literally in this case ...
Here is where you get to choose stuff for the forthcoming mission. The overview screen is where the menu is, as well as a reminder of the mission objectives and the important specifications of the currently chosen aircraft, which boils down to maximum level speed, stall speed, and at what speed the ailerons completely lock-up and you wish you weren't in a 90 degree vertical dive whilst holding down the turbo button.
The aircraft selection screen details all pertinent statistics of the aircraft, displayed as a percentage bar based on the min-max of all other aircraft;
(range max - range min) * (value - min value) / (max value - min value) + range min = percentage
All except, that is, for Lock Start which is based on percentage of Max Speed, and Lock End which is based on Max Speed * 2.
The Fastest Paint Job Changes In The West
The Insignia screen is where the player can choose their aircraft skin. I was going to call it Paint Job but insignia seemed more fitting. In fact I had a good trawl through the thesaurus for flag, badge and logo before deciding on insignia.
Any skin which can be carried over to other aircraft will be added to newly selected aircraft back in the Aircraft Selection Screen, or default to Dazzle Camo if not.
I am splitting aircraft up into distinct roles (fighter, interceptor, striker/bomber) which have differing effects for lock-up, turbo (WEP; War Emergency Power), stall turns, etc, and am naming these after cavalry units.
So, still to do for the pre-mission screen;
Create a Briefing overview where the player can select which aircraft they want to conduct the mission as. Different wings of aircraft will have different roles as mentioned above. Really hate escorting strike aircraft to attack a target? No problem, fly the strike aircraft and have the Ai do the escort mission. This style of play also lends itself rather well to online multiplayer co-op mode.
Create a Payload Selection screen that allows aircraft that have external hardpoints to fit bombs and rockets. Also need to create a system for the use of bombs and rockets, as we only have primary and secondary guns coded at the moment.
Integrate all of the player choices into the actual mission when it starts.
And here is the whole thing as it currently stands in video. There are three aircraft and about ten skins each.
And that was the month that was. It started with me in shorts getting sunburnt and has ended with me soaked to the skin and wearing a jumper. Classic British summer.
So this month I have been coding a "Mission Events System" loosely based on how Descent: Freespace did it.
Chief amongst this creating a system that read all of the spawnPoint data which held all the info for various events, and anything inside the mission's own custom event file, then tried to organize all of that into something which wasn't gibberish.
I can give you a quick rundown ...
//this is where the mission relevant data is started //all missions related events are controlled from here //before we spawn the player we need to load the MissionEventFile (MEF) and all it's functions //to do this we need to find out how many players we have //treat this number as 1 for single player game and start the mission with the first client joining //MissionEventFile holds the missionEventList (arrayObject) and all mission event functions //spawnPoints inside the missionEvents folder are for spawning and events //spawnStart; //1 timed or immediate spawn from player arrival; 1 = spawn immediately //spawnNear; //object that we should spawn near, if spawnDistance > 0; this overrides our spawnPoint location; defaults to player //spawnDistance; //distance from spawnNear object in kilometers; //dataBlock; <<<<< spawnDatablock //literally datablock name for player; eg: F11Goshawk, etc. Never AiF11Goshawk though, Ai gets added later //dataType; <<<<< spawnClass //type of datablock; eg: aeronautVehicle, etc. Never AiAeronautVehicle though, Ai gets added later //startingThrust; //starting engine setting as F32, default 0.6 //team; //0 greenFor(neutral); 1 blueFor(ally); 2 redFor(enemy); 3 yellowFor(aggressor); //skillLevel; //Ai skillLevel 1-10; modified with difficulty //callsign; //name for vehicle or wing of aircraft based on wingNum and isWing number; //eg: solitary isWing0 "bob" //eg: isWing 2, wingNum 3 "bob3_2" //isWing; //0 = no not a wing only 1 vehicle or was a wing which has already been reduced to 0 //1+ = is a wing, this number goes down everytime the wing is destroyed //wings respawn with wingDelayMin/Max time when reduced to wingMin number of remaining aircraft //a new arrayObject is created for the wing and all aircraft are added to this from that wing //eg: callsign "bob", arrayObject "bob_wing" //wingNum; //number of aircraft in the wing //spawnedNum; //number of the aircraft spawned in a wing, ++ until > wingNum then back to 1; this is set by scripts not editor //wingDelayMin; //minimum number in seconds for the wing to wait before spawning another wing and reducing isWing value by 1 //wingDelayMax; //maximum number in seconds for the wing to wait before spawning another wing and reducing isWing value by 1 //wingMin; //number of surviving aircraft when a new wing will spawn with wingDelayMin/Max. Default is 0, but best set to 1; //mainTask; //mainTask; 0 do waypoints; 1 dogfight anything; 2 strike target; 3 escort; //mainTaskTgt; //object for mainTask, can be vehicle, arrayObject list of targets, waypoint or path //eventTrigger#; //type of event to happen //onArrive - has spawned //onDepart - has departed //onDamagePercent - damage has gone below threshold //onDestroyed - uses callback onDisabled and onDestroyed for second check //onWaypoint - has moved to waypoint position //onPathComplete - has completed the total path //eventObject#; //object id; eg: onWaypoint = waypoint id; default blank/0/"" is spawnDatablock's object //eventDelay#; //delay in seconds from the eventTrigger# being completed //eventResult#; //result of the eventTrigger# occuring //script name; function to be activated from missionEventFile (MEF) //eventTarget#; //target of the event to do something, specifically used for spawn; //if no target then it should refer to a local wing or aircraft //eg: scorpio wing now spawns in 10 seconds due to eventTrigger1 "onWaypoint", eventObject1 "player", eventResult1 "spawn", eventDelay1 10, eventTarget1 scorpio wing
So that's my own comment notes in the file, though some of that has since been changed ... probably.
Part of this is "wings"; groups of aircraft that spawn together and can respawn in "waves" when their number has been depleted to a certain amount.
Contextual Messaging about Events in the top left
And what are events without victory and defeat conditions? Not very interesting that's what.
Events - hurray you didn't bugger it all up!
So with all of this in place it was time to create something which looked like a proper game mission. And here it is!
Here's a quick overview of what happens:
Victory Condition: All enemy are destroyed
Failure Condition: All allied reinforcements are destroyed
Player Spawns Event
First enemy wing SCORPIO spawns with a delay in response
Enemy wing SCORPIO is destroyed
Allied wing of reinforcements spawn in response to SCORPIO onDestroyed
Enemy wing LIBRA spawns after delay of reinforcements arriving. Also enemy wing TAURUS spawns with an even longer delay, near reinforcements.
After losing 3 out of 4 reinforcements I go and help out the last one before completing the mission.
In this playthrough the reinforcements were not very effective and got pounced on early by the enemy fighters, in other tests they accounted for some kills and assists.
When the mission is over status of all aircarft is printed to the console, detailing kills, assists, damage and the such. Eventually this will be part of a debriefing screen.
This month I have mostly been dealing with explosions.
And vapour trails and general special effect type stuff.
And I found out that the PBR I had been using had broken metalness which was fixed on a newer engine version, so I had to redo all my PBR maps again, after having to redo all my PBR maps again last month because I had Occlusion and Roughness in the wrong RGB channels ... but back to those explosions.
Right back at the beginning of Unnamed Victoriana South China Seas Dieselpunk Dogfighter I created a system of damaging individual aircraft parts, thus degrading performance related attributes like turning, speed, etc. Now I neeeded to actually make it look like something was happening when this actually happened. I threw in a small explosion with a nice little puff of dark smoke to let everyone see that a damage limit had been reached. When this happened a mesh element would be swapped for a more damaged version so that the player could visibly see their aircraft being steadily shot to pieces.
Here is test to show all the parts of an aircraft that can get blow clean off
I came up with a somewhat hacky solution of hiding the destroyed area and then spawning the blown off part of that area as a static object, so that I could use the same skin texture as the aircraft and give it a spnning animation, and mount that onto a projectile that was gravity heavy.
And of course if an aircraft takes way too much damage all over rather than having a single part get blown off, it just explodes. Whilst some of the debris is made up of model meshes, most is in fact animated sprites for small metal plates tumbling through the air.
Explosion!
I also made some Dazzle Camouflage skins for the three aircraft types I had previously modeled.
Dazzle Camo; The Rule Of Cool
This brings us to actually sorting out some sort of gameplay mission, and for that I started working on an Event System. I have been thinking of taking a cue from the old space shooter Freespace and FRED, FReepace EDitor, as to how missions are put together. It had a drop down editor for logical arguements which acted as cues for events, thus preventing someone from filling it with absolute gibberish. The premise is quite simple, if x happens do y. Most of this is about spawning new waves of enemies or ships as well as keeping a general tab on mission objectives.
I have come up with a system based on using scriptObjects in the mission for each aircraft or ship or active thingy, all stored in a named folder in the mission editor for ease of finding, which then accumulate to an array on the load game event, waiting for the events to be checked against array list and ticked off one by one.
The idea is that something occurs - eg1: player connects - the Event System looks to see if anything else needs to be done - eg1: enemy aircraft wing spawn 15 seconds later.
eg2: Enemy are down to 25% numbers, second enemy wing spawns.
eg3: Second enemy wing is destroyed, large enemy formation arrives. Timer starts for player to survive for 120 seconds.
eg4: 120 seconds later, allied wing of reinforcements arrives.
eg5: All enemy destroyed, mission accompished.
And so on and such forth. Minus timers the Event List is entirely passive and is just checked against when something happens that was stored in the array from the aircraft scriptObjects in the editor. This seems to be the best result for low overhead.
So, that was the month that was, and next month we will hopefully have a fully working Event System and actual playable mission which I intend to be a homage based on the first mission of Freespace: The Great War.
The pub is open and the wind is cold. It's a Bank Holiday weekend, of course the weather is going to be terrible. I had a huge scone with jam and cream.
This month I have been modeling planes, 3 of them, and 9 different skins for 9 different factions. Part of the way through I discovered that the PBR map - known as a ORM map - actual stands for the order in which PBR goes into the channels and that I had got my Rough and my Occlusion the wrong way round. This explained why my ambient occlusion didn't look very ambiently occluded ... Having fixed this for all 4 damage levels, I could continue modeling new planes.
The Nakajima Type 91-1 actually did come in orange. I have no idea what Japan thought they could hide this amongst, perhaps tubs of satsumas? Here it is with the Tokugawa Shogunate emblem replacing the Japanese flag due to Deepest Lore™.
This thing really doesn't look safe and has a pretty poor damage rating, but it is agile.
Previously I had completed the Curtiss F-11C Goshawk and so set about making various skins for it. You will probably spot the theme of 19th Century Qing Dynasty due to Deepest Lore™. Here comes a lot of image spam.
Chinese Republican "Dare To Die Corps"
Cuba because it was an actual thing so I though why not ...
Qing Dynasty
Kansu Braves - referred to by the Western MSM as "The 10,000 Islamic Rabble" but was actually the Qing's elite fighting force of Islamic soldiers sworn loyalty to the Empress Dowager.
The Taiping Heavenly Kingdom - a ... wait for it ... Theocrat Anarcho-Communist Absolute Monarchy led by a guy who declared himself the younger brother of Jesus. Unlike Jesus he murdered 20 million people in 14 years.
Black Flag Army - Cantonese bandits who created hell for the French in Indochina.
Fists of Harmonious Justice - Boxer Rebellion
Five Banner Alliance - more anti-Qing, anti-foreigner secret society
Damage models for the Yellow Flag Army, pirates of Canton - sporting the pirate flag from AIrship Dragoon
Plikarpov I-15bis from the Imperial Russian Air Service, poor maneuverability but fantastic quad Maxim machine guns.
Polikarpov I-15bis in Chinese Republican colours
Overhead damage models of the I15-bis (top) and F11C Goshawk (bottom)
Testing vapour trails, which needed a bit of "fixing" for the source code
Here's a video of me testing vapour trails in combat.
And that was the month that pubs finally reopened.
Next up, more skins for the Nakajima, and perhaps one more aircraft before attempting to make an actual game senario with it all. Toodlepip!
Placeholder aeroplane, which I downloaded from some modding site that I can't remember, has been replaced by my own aircraft model.
It's an F11C Goshawk biplane, which is now itself a placeholder for all other aircraft which I haven't yet modeled.
I also coded a damageable area system to give the model a visual personification (don't really think that was the word I wanted but hey ...) of the GUI damage system.
Model now displays damaged areas the same as the HUD damage indicator bottom right
Initially this was just meshes that used the same colour system as the GUI/HUD damage indicator for area based damage so that I could see that it was working. The idea is that the aircraft model is made of multiple meshes, engine, body, tail, wings 1, 2, 3 etc and these meshes are displayed hidden depending on how much damage each individual section has taken. There are 5 levels of damage, the first being undamaged and the last being destroyed. Eventually when an area is completely destroyed it will spawn a debris or rigidShape of the part of the plane which has been shot off. Eg: the top wing will appear to rip off and the aircraft will plummet to the ground.
I also use this show/hide mesh system for the muzzle flashes of weapons. Previously I had simply hidden the meshes inside the model at a hugely shrunk scale, and then animated them into full size.
Next up was to test the PBR and make up some textures. I knocked up a very quick normal map and some metal and roughness maps. Initially they were rather dark, eventually I discovered this was due to too little roughness so that the metal map was rather overwhelming things.
Ignore the catgirls at the back, just comparing PBR ...
After a bit of faffing I got PBR materials working, and thought that the whole looked pretty good actually.
Not bad if I say so myself
After this I proceeded to test the damage system with bullet holes. Here I noticed a fair bit of stretching which could only be remedied by completely redoing the UV mapping.
And here is a test of an AI air battle using the PBR textures. In the end I get my top wing shot off, which disappears as there is currently no debris object for destroyed areas.
So, that was the month that was.
Next up are redoing all the texture maps, albedo - which I never seem to be able to spell correctly, never had this problem when it was called diffuse - normal, metal, roughness , AO and of cause all the accompanying damage meshes and maps. After that, on to more model aircraft.