Special Aircraft Service

the SAS Hangar => The Lounge => Stainless' new Flight Simulator => Topic started by: Stainless on February 27, 2015, 08:17:59 AM

Title: Weekly progress report
Post by: Stainless on February 27, 2015, 08:17:59 AM
In this thread I will do a weekly report, just to prove I am still alive and working.

This week I have written a bump map shader for HIM meshes. Once we find a way of generating the required bump map texture, we can add some additional detail to our meshes.

I have also fixed a bug in the flight dynamics model with regards to turbine engines, which took a hell of a long time to find and two minutes to fix.

I am now trying to work why the forces at take off are revolving around the CofG. It's another bug to hunt down.
Title: Re: Weekly progress report
Post by: Stainless on March 01, 2015, 01:59:27 AM
I have now put all my current code onto assembla.

If anyone wants access, PM me with your assembla username and I'll give you access.
Title: Re: Weekly progress report
Post by: Stainless on March 06, 2015, 02:41:12 AM
A good day.

I finally found my bug  :)

It wasn't anything to do with the FM, it was in the display code. The display code assumed that the output quaternion returned euler angles in degrees. It returned radians.

Fixing that and my F4 flew!  :P

Well for a little while. As soon as the gear left the ground, the right wing tip dropped. I tried to compensate with the ailerons, but that just made it worse. So I pulled up to grab some sky while I tried to figure out what was going on, but by the time I realized I had the keyboard mapping wrong (roll left is roll right, roll right is roll left) I was in a spin. Before I could remember which keys I had mapped to the rudder, I had totally lost control and she augured in.

Still, SHE FLEW!

So more work to do, but real progress.

Also I have had a slow week at work, I had a lot of jobs to do which involved building the entire game from scratch (takes about three hours  ??? ) and then doing some tests. This gave me a lot of free time.

I came across a flight dynamics model called Yasim. The code is a hell of a lot simpler than my code, no where near as detailed, but also a hell of a lot faster. So I have started to port that to C# as well. This will give you a choice of flight models to play with and also reduce CPU load on lower end machines.

A good week.
Title: Re: Weekly progress report
Post by: Maty12 on March 09, 2015, 02:55:54 PM
Stainless, any chance we can get a list of aircraft you plan on including?
Title: Re: Weekly progress report
Post by: Stainless on March 10, 2015, 03:27:56 AM
All of them from here.

The same file formats are used, just the animation and flight model code is different.

The animation code is so similar to the Java you use now that it will be trivial to migrate.

The flight model is completely different, but so logical it will not be an issue.
 
Title: Re: Weekly progress report
Post by: Stainless on March 12, 2015, 04:16:02 AM
Well this is doing the rounds of the office.

I thought I'd post it here as well since it seems to be giving everyone a good laugh.

It's a publicity shot from about 1989, when I worked at Gremlin Graphics.

Anyone going to take a shot at spotting me? "Where's the wally writing a flight sim"  :(


(http://s3.postimg.cc/dts10zuoz/original.jpg) (http://postimg.cc/image/hddyqsxen/full/)
Title: Re: Weekly progress report
Post by: Stainless on March 14, 2015, 01:25:15 AM
It was from 1987 apparently.

The bottom left image, from left to right.

Shaun Hollingsworth, me, Fungus The Bogeyman, Pete Harrap, and Ben Daglish.

Next image on the right, Steve Kerry, Chris Kerry, Jason Perkins, ....

Also around Chris Shrigley,  Rob Toone, and Tony Porter. I can't remember the names of the rest.
Title: Re: Weekly progress report
Post by: Stainless on March 15, 2015, 02:54:22 AM
New version of the mod tool up with support for bump mapping

http://stainlessbeer.weebly.com/downloads.html (http://stainlessbeer.weebly.com/downloads.html)
Title: Re: Weekly progress report
Post by: Stainless on March 20, 2015, 08:34:27 AM
This week hasn't been exciting, just lot's of debugging to try and figure out why it's not flying as expected.

I have added a gui to Testflight and started to add test scripts, but nothing nice to look at.

I will be asking for help with the gui though. I hate the grasphics I am using and need a GA to fix them.
Title: Re: Weekly progress report
Post by: Radoye on March 20, 2015, 09:03:39 AM
Gremlin Graphics.

Holy crap, that name brings back some memories!  ;D

(http://www.mobygames.com/images/shots/l/224411-wanted-monty-mole-zx-spectrum-screenshot-ghosts.png)
Title: Re: Weekly progress report
Post by: Stainless on March 20, 2015, 10:27:18 AM
Tell me about it.

I was there!   ???

Title: Re: Weekly progress report
Post by: Stainless on March 26, 2015, 03:31:26 AM
Big day.

The wind tunnel is really working. I found I had no lift, no matter what speed the aircraft was flying at. A quick look at the F4 Lift() method and I noticed that I was looking up the lift due to alpha coefficient, but not multiplying it by q_w...  ???

Fixed that and she flies.

Also noticed I was using the spoiler position instead of the speed brake position in the drag calculation.

Things are really looking good now.

Title: Re: Weekly progress report
Post by: Ghost129er on March 26, 2015, 05:34:06 AM
Great news and good job Stainless! Glad to hear that! I'd hand you a KitKat, but I don't think that's physically possible from all the way here..

Cheers!
Title: Re: Weekly progress report
Post by: Stainless on March 27, 2015, 03:34:04 AM
Huge day.

I used the wind tunnel to spot a couple of bugs in my F4 code. Interestingly it wasn't a bug in my FDM, just in the F4.

Now she flies like a fighter.

I HAVE WRITTEN A FLIGHT SIM.  ;D

Ok, it's a crap one. No weapons, no terrain, no game, but I can take off and fly and land so ... it is a flight sim.

Nearly broke my arm patting myself on the back. Got some funny looks on the train as well.

Party time, excellent.
Title: Re: Weekly progress report
Post by: hello on March 27, 2015, 07:12:15 AM
Congrats! Looking forward to your next step. Which will be .... ?
I am checking this section pretty much every day.  8)
Title: Re: Weekly progress report
Post by: Stainless on March 27, 2015, 10:05:46 AM
Next step....

I guess the next logical step is to do an in cockpit view and fly the plane a bit.

See if anything else feels off.

If I can do some circuits and land, then I'm ready to move on.

Then I will need to put in another aircraft, this time a propeller driven aircraft so I can test the other engine code.

 
Title: Re: Weekly progress report
Post by: Chaoic16 on March 27, 2015, 01:40:48 PM
CONGRATUATIONS!!! You have NEVER ever given up with your strong passions in this simulation development.  It is going to be very interesting to see what goes on from now on!

Let's rock and roll!

:D :D :D
Title: Re: Weekly progress report
Post by: Stainless on April 01, 2015, 03:48:52 AM
I have come to the decision that it is impossible to fly to an accurate flight plan using a keyboard. Especially on a train.

Since I really want to be able to fly very accurate flight paths so I can test the accuracy of my FDM, I have been forced into starting to write the AI.

At the moment I only have simple commands in, the F4 closes it's cockpit, starts engine, lights afterburners, and pulls back on the stick at the correct time to take off.

I am going to add a lot more commands so that I can put together standard maneuvers and record the data generated for comparison with real life.

For the modder, I am going to extend the test tool to allow you to create AI scripts for your aircraft. So when you do a mod you can use the tool to create a script to do the pre-flight checks and all none standard actions. Once it's done you can easily run a test script to test it works and get back data you can check against real world data.
 
Title: Re: Weekly progress report
Post by: Stainless on April 05, 2015, 03:56:40 AM
First test video

The video grabber is crap, can't handle 60hz, but at least it's something to show you all.

I should mention that unlike other flight sims I have looked at, my auto pilot FLIES the plane. If the nose needs to come up, it moves the elevator, roll it moves the ailerons. No cheating here.

https://www.youtube.com/watch?v=ZhPF4GvytrQ&feature=youtu.be (https://www.youtube.com/watch?v=ZhPF4GvytrQ&feature=youtu.be)
Title: Re: Weekly progress report
Post by: DD_BadAim on April 06, 2015, 06:16:55 AM
One man can indeed change the world! BTW Tiger Balm works great on those muscle strains in your arm and shoulder. :)
Title: Re: Weekly progress report
Post by: Stainless on April 10, 2015, 02:35:25 AM
This week has been frustrating.

I have put in the cockpit, but it's not going smoothly.

I added the cockpit him and all it's resources and it displayed in the wrong place. So after a lot of digging around in my code, I went back to il2modder and loaded in the F4. Marked the location of the cockpit. Then loaded in the cockpit.

It was in the wrong place ( and rotated slightly out of plane).  Not my code. I threw a few fucks into the air and added a cockpit position variable to the game, worked out where it should be and set the variable.

Now I had the problem that the aircraft mesh was being drawn as well as the cockpit. So I went back to il2modder and worked out which bits of the aircraft need to be hidden when in the cockpit and added support for that.

Tested that and the correct parts of the plane disappear nicely, along with the cockpit.....  WTF!

Was trying to fix that when some thoughtless woman brought her two young children onto a commuter train and let them run riot.  :(

Why do they do it?

It's more expensive to use the commuter trains, it's more crowded on a commuter train, they have all day to inflict there badly behaved brats on the world, why do they do it in my coding time?

Luckily I didn't have a gun.


Title: Re: Weekly progress report
Post by: DarkBlueBoy on April 10, 2015, 04:47:19 AM
Awesome job Stainless. Don't let the brats grind you down. The joys of school holidays I would suggest. :)
Title: Re: Weekly progress report
Post by: Stainless on April 13, 2015, 06:47:57 AM
Had some time to work on it yesterday and got the cockpit in.

Wired up a lot of the dials and got things animating nicely, but was a bit annoyed with "jaggies" on the edge of dials. So I tried to turn on full screen anti-aliasing. However it seems it is bust in XNA.

Great.

So I went back to adding more instruments and quickly hit an issue.

The cockpit I am using doesn't have some of the instruments I really wanted to use. Particularly engine oil pressure. At first I just thought "no biggie", but then I started to think about damage indication.

I really don't want some kind of artificial display, something like a text string coming up over everything saying "engine damage 10%" I hate that.

So it becomes really important to have all the cockpit instruments up and running. Engine damage usually shows itself in engine temperature and oil pressure. I want the hydraulic system to be able to be damaged, so you need hydraulic pressure displayed.

Cockpit instrumentation is a lot of work for a modder though. I can hook any instrument up easily, but if the instrument isn't animated, I'm screwed.

Not sure what to do about it.

Ideas?
Title: Re: Weekly progress report
Post by: SAS~Tom2 on April 13, 2015, 07:45:07 AM
..my idea..take a break, enjoy some good tasty non alcoholic or alcoholic drink of choice and get some distance to the prob. :P That often helps me.
Title: Re: Weekly progress report
Post by: Stainless on April 20, 2015, 02:39:45 AM
Well this week I have spent most of my time looking at radars for a change.

That's going well as you can see in another thread.

I went back to the in cockpit display and had another look at that as well.

I realised that I had cocked up with placing the 3d mesh for the cockpit. The position is relative to the airframe, so I had to transform the position of the 3d mesh into the aircrafts frame of reference before I displayed it.

That was a simple fix and now the cockpit is locked in place regardless of aircraft attitude.

The camera position is relative to the cockpit. So now the cockpit is in the correct place all I have to do is transform the eye point into the cockpits frame of reference and we are all good.

Except it doesn't work. The camera starts off in the right place then drifts through the cockpit floor as the aircraft pitches up. WTF!

This is what has been happening a lot on this project. The big complicated things go smoothly, the little simple things go wrong and take ages to fix.

I'll bang my head on the wall a few times and figure out what's wrong.

Usually works, but it's not very good for the wall.
Title: Re: Weekly progress report
Post by: Stainless on April 21, 2015, 02:46:04 AM
Fixed it. Proper face palm.

The joys of multi-threaded coding.

What I was doing was


So I was drawing everything from the position the camera was 16.7 mS in the past.

Doh!

Multi-threading is excellent and allows you to use all the cores on the cpu, but it can bite you in the ass.
Title: Re: Weekly progress report
Post by: Stainless on May 01, 2015, 02:32:25 AM
This week I have mostly been focused on airports.

This is going well and has formed a cunning plan.

I am now starting on actual game code.

The plan is to create a single patch of terrain based on satellite data for a region that contains an airport. Generate the airport from an apt.dat file. Stick the Phantom at the start position.

Then let you fly it.

The plan is to have this done by the end of June and release it for you to play with.

The main thing that can go wrong is not actual coding, it's input devices. It's very difficult to fly on keyboard, damn near impossible, so I'm going to have to support joysticks etc.

However I don't have any joysticks.

Might be a problem.

 
Title: Re: Weekly progress report
Post by: Stainless on May 15, 2015, 04:47:36 AM
Most of this week has been taken up sorting out the airports.

It's damn frustrating.

I am so close, but I still have errors. So I looked hard at the data and noticed strange artifacts in the apt.dat file. Coincident points and bezier curves with mad coordinates.

So I downloaded flightgears world editor, it supports the same files, and looked at it in that. The data is fine.

So I have to have misunderstood the documentation. To solve this I have downloaded the source code to flightgear and I am going through the airport stuff with a fine code comb.
Title: Re: Weekly progress report
Post by: Stainless on May 23, 2015, 01:59:05 AM
This week has been a clean up week.

I've re-factored the code into core libraries and separate applications. The main libraries are


I've created a common asset collection which contains everything needed to do basic rendering.

I've also swapped from bitmap fonts to signed distance field fonts to improve text rendering.

And I've added a new skydome, this can be turned on or off with a render setting. It calculates the sun position from the modified Julian date, and view point altitude and renders atmospheric scattering using pre-generated mie and rayleigh scattering textures.


(http://s9.postimg.cc/wf5tpzjzz/morning.jpg) (http://postimage.org/)

(http://s3.postimg.cc/4zutstz0z/noon.jpg) (http://postimage.org/)

(http://s7.postimg.cc/8z61ek71n/sunset.jpg) (http://postimage.org/)

(http://s29.postimg.cc/dj74dtzuf/night.jpg) (http://postimage.org/)


I'm in the middle of adding the moon, planets, and stars. I have all the data I need so shouldn't be a major issue.

Title: Re: Weekly progress report
Post by: asheshouse on May 25, 2015, 08:52:35 AM
So this will be a planetarium as well as a flight simulator. :)
Title: Re: Weekly progress report
Post by: DarkBlueBoy on May 26, 2015, 12:26:35 AM
Looking good Stainless. :)
Title: Re: Weekly progress report
Post by: Stainless on June 07, 2015, 02:05:20 AM
This week I haven't got a lot done. Train troubles and problems at work limited my free time a lot.

As well as Madness playing Fratton Park, which did a lot of damage to my liver.

However I have made progress on the airports. I have partially decoded the crap that the original coder created and have fixed most of the curves. I still have a few to figure out though.

I have also spent a lot of time thinking about terrain. I worried that I may have to switch to c++ to get a terrain system in without killing myself.

If I switch to c++, I can use one of several CLOD systems which are out there. None of them can be used out of the box, but all have source code available. So modifying them for flight sims is possible.

Starting from scratch in C# is what I was planning to do, but it's a hell of a lot of work.

Not sure yet.

Title: Re: Weekly progress report
Post by: Stainless on June 14, 2015, 12:30:45 AM
Another week gone, and I'm still fighting with runways. It's become an obsession.

The problem is that after the file format was specified, the editor was changed to make it easier to edit the runways. The new format wasn't propagated into the file format, instead the curves were encrypted into the data stream.

For example this section.

Code: [Select]
120 Center Line on to Runway
111  53.24967380 -004.52905004 1 101
112  53.24938951 -004.52935506  53.24931939 -004.52963229
111  53.24938951 -004.52935506
112  53.24938951 -004.52935506  53.24942883 -004.52907179 1 101
115  53.24925237 -004.52879055

The first line specifies this is a linear feature called "Center Line on to Runway"

It starts at Latitude  53.24967380 Longitude -004.52905004 and is a solid white line.

Then it curves to  53.24938951 -004.52935506  with a bezier control point at 53.24931939 -004.52963229. No problem there.

Then it goes weird. The next two points are at the same location as the start point. Total bollocks. This is what the coder inserted to encode his changes.

Looking at it in the world editor it's this line


(http://s13.postimg.cc/vfpv4b4nb/wed_1.jpg) (http://postimg.cc/image/5wxiral37/full/)


What I end up with in my code is.


(http://s24.postimg.cc/hfkemhqd1/airport_6.jpg) (http://postimg.cc/image/uwhd5d0oh/full/)


ahhhhh

WTF has he done. I'm just guessing at the moment




Title: Re: Weekly progress report
Post by: Stainless on June 22, 2015, 07:56:06 AM
This week I have taken a rest from my airport obsession. I will come back to it, but for my sanity I had to take a rest from it.

Instead I worked on the AI, mainly so I can flight tests accurately.

The original autopilot code I put in was very basic and imprecise. So I have redesigned it to use a phase locked loop.

Say you want a rate of climb of 300 FPS, the AI will make a guess at the right elevator setting for the current aircraft state, then it stops time and does a few simulation loops to refine the guess.

Once it has a good estimation of the control position required, it sets the control and starts time again.

The end result is that you should get a very good flight path, but without cheating. Most simulations cheat. They don't "fly" the plane, they just make it do what they want.

 
Title: Re: Weekly progress report
Post by: max_thehitman on June 22, 2015, 08:47:58 AM
You are doing some amazing work good friend. You are really good at this thing.   8) A very talented artist!
I congratulate you!

I would like to thank you once again for creating that little gadget you did a few years back which
reads the Mesh file (.Him file) of a game 3d-model and creates an instant UVW mapping for us skin-painters.

It saves ALOT of guess work on painting a 3d-Model when there is no UVW mapping file available to us for
painting those skins.
I have been amazed seeing that many of our IL2-1946 models have so little areas to paint on the skins, but the
original artists have spent way too much time painting areas on the skins, which will NEVER show up on the
model when it appears in the game. It was because they had no UVW mapping skin to actually notice where
the skin is mapped at in the model.

I will post for you a screenshot of a Soldier model we have in the game and its original skin. You can notice that the
original artist painted so much on the skin, but it will never be seen in the game...

(http://i972.photobucket.com/albums/ae203/IL_2_MAXtheHitman/UVW_Gadget_Stainless_zps1tq7jmtm.jpg~original)

So I thank you very much for your very handy STAINLESS gadget. You should post it up again for other artists to use, if
they don't know about it yet.


Cheers
MAX
Title: Re: Weekly progress report
Post by: Stainless on June 23, 2015, 02:35:04 AM
I have been thinking of changing that code.

I often use a tool called UVMapper, which is very useful as you can load in an object and drag the UV coords around.

Do you want me to add that capability to the tool?

Title: Re: Weekly progress report
Post by: max_thehitman on June 23, 2015, 05:19:04 AM
I have been thinking of changing that code.

I often use a tool called UVMapper, which is very useful as you can load in an object and drag the UV coords around.

Do you want me to add that capability to the tool?

Hello again Stainlesss,
If you find this capability useful to you, it might also be useful to me and other skin-artists.
I have never tried it before.
Sounds interesting.

This little "Stainless UV_mapper" of yours , to me, is a real great program and very useful for my skin art.
It saves time on painting and knowing EXACTLY what to paint, for that skin to look its best in this game and on the 3d-model.

Skin textures in any game are very important part of what makes it appealing and look more realistic as possible.
Some 3d-models may have less polygons and some may look like "LEGO toys", but if the texture and paint on it is done properly,
it will look great. IL2-1946 is a very old game, but it still has a lot of potential.


Title: Re: Weekly progress report
Post by: asheshouse on June 23, 2015, 09:18:30 AM
Sounds like a very useful utility.
Title: Re: Weekly progress report
Post by: Stainless on June 24, 2015, 02:39:50 AM
The main use of this capability would be to allow you to add detail to particular parts of a mesh.

Say you want to add some kill marks below the cockpit, but the polygon in the mesh where you want to place them is tiny. You could drag the UV coordinates for that polygon around to give you more pixels to work with. You would then have to save the bitmap, AND the mesh, but it would work.

The problem with doing this is that the base texture is very hard to get right.

By changing the scale of a single polygon, you create a discontinuity between adjacent polygons. If you are not really careful, this will appear as a seem and look shit.

Give me some votes to see if this is worthwhile doing.
Title: Re: Weekly progress report
Post by: max_thehitman on June 26, 2015, 06:10:07 PM


Well, it sounds like a good idea, but honestly, it may not be worth the effort on your
part to go to so much trouble in doing such a thing. Personally, I am very very happy with the
original UVW-Mapper you created and I use it a lot.

Painting such tiny details on a skin is already possible if an artist knows what he is doing with Photoshop and
can read the details in the UVW_Mapping-Skin. There will always be some type of warping in the skin
details when they get wrapped around the 3d-model. It all depends on how good the 3d-model is created.

 No need to do such more work on this mod-gadget. It´s great as it is!
Thank you Stainless (http://www.freesmileys.org/smileys/smiley-eatdrink004.gif) (http://www.freesmileys.org/smileys.php)


Title: Re: Weekly progress report
Post by: Stainless on June 29, 2015, 02:29:40 AM
Okay so since I have had some requests for it, I've gone back to the effect editor.

It basically works rendering the particles in 2D, but that's not really a lot of good for look and feel. It's essential for debugging, much easier to see what is going on in 2D, but for the actual look of the effect as it would be in game, well pretty crap.

So I have added a 3D mode.

I've started by adding a sky cube and a ground plane, once I have that in as a frame of reference, I'll drop in a 3D particle system and massage the parameters to match the IL2 format.

I will need a HELL of a lot of feedback and testing to get something that looks the same in the editor as it does in the game though.
Title: Re: Weekly progress report
Post by: dyingtofly on June 29, 2015, 06:48:03 AM
Sounds great. Testing will that reguire installing of stuff or can it be done online in browser.
I have an old sluggish PC, and even older one that I hope to convert to "chromebook" & started saving for dedicated sim machine.
Thanks for your effort.
Sorry for bad English. Mike
Title: Re: Weekly progress report
Post by: DarkBlueBoy on June 29, 2015, 06:59:42 AM
That's a fair point Mike - will you let us know a recommended PC spec for testing, Stainless please?
Title: Re: Weekly progress report
Post by: Stainless on June 29, 2015, 07:36:32 AM
As long as you can run windows with .NET (I think I'm on .NET 2.5 .... but not sure) It should be fine.

The mod tool uses more grunt than the effects editor will, so if you can run that... you will be fine.
Title: Re: Weekly progress report
Post by: solotk on July 10, 2015, 06:40:03 AM
Gremlin Graphics - Now there's a great name from the past. I still think the late 80's, early 90's were the greatest time to work in the industry, before things got totally corporate :( Gremlin did some great stuff, didn't Gremlin get some covers for Zool and Lotus series from Emap and Future? Great times, brilliant parties, lots of co-operation. I miss those days. :(
Title: Re: Weekly progress report
Post by: Stainless on July 10, 2015, 08:12:24 AM
Yes.

Some of the shows were epic. We built a huge space invader for one show in London.

I gate crashed the Domark party wearing a Gremlin T-shirt.

Hired Stringfellows for the evening.

Good fun and epic hangovers
Title: Re: Weekly progress report
Post by: solotk on July 10, 2015, 08:32:21 AM
Oh Lord the epic hangovers! No meetings before 10 :) Ocean parties were epic, Microprose, EA and Virgin put on a good do too. Not so bad at ECTS which was trade only, but bloody awful at Olympia which was open to the public too , with every sound system cranked up and the lights making it feel you were a mile from the sun, hordes of kids and adults trying to rip stuff off the stand, we nailed everything down :)

Not so bad for the devs, you could hide in the bar, but on my side urrrrrgh. Counting down the hours till we could get into the Slug and Lettuce or off to the next party. Wandering round the publishers stands seeing how much money they'd spent, epic amounts in some cases, or having a drink and a convo with Lara Croft/Nell McAndrew a really really nice lady. I think she was the most popular Lara Croft, and miles better, to my mind than the one she replaced.

I'm still in contact with a lot of people from the period, some of whom are now the big bosses , but yes, we all miss those days :D
Title: Re: Weekly progress report
Post by: Stainless on July 12, 2015, 01:25:39 AM
The effect editor is starting to come together.

(http://s14.postimg.cc/qcziavw6p/effect_editor_1.jpg) (http://postimg.cc/image/vbn0pezzh/full/)

I have some real concerns though, I'm not sure what is going on with the colour equation.

When I look at effects that are supposed to be coloured, like FlareRed.eff the colours are quite low.

Code: [Select]
    Color0  0.55 0.55 0.55 0.60
    Color1  0.55 0.55 0.55 0.60

To get the effect to look "red", I have to boost the values a lot. Something is definitely wrong.
Title: Re: Weekly progress report
Post by: Stainless on July 12, 2015, 02:42:31 AM
I've dropped in a sky cube and texture patch for the 3d view


(http://s24.postimg.cc/nqlttf45x/effect_editor_2.jpg) (http://postimage.org/)
Title: Re: Weekly progress report
Post by: Dreamk on July 12, 2015, 10:37:33 AM
Stainless, there is nothing wrong, this exactly why your effect editor is needed!
I found that the same effect files gives different intensity effect (and even different shape effect) according to the way they are called by the program:
an example: the same smoke effect file for a smoke bomb, called "fumigene.eff" will give a different effect whether the bomb is in the air or floating on water.
Another example, still more striking, the same effect file called fountainwhite.eff will give totally different shaped effects whether it's called directly through a method in the specific bomb class, as an associated effect, or whether it's called through the method used in the explosion class.
Add to that that the TParticlesSystemParams and the TAnimatedSpriteParams produce different versions of the same bitmap with the same basic color parameters.
Your effects editor is going at last to enable to check all these variations and adjust new effects without going through an hellish way.
Title: Re: Weekly progress report
Post by: santobr on July 12, 2015, 04:28:36 PM
Mine FlareRed.eff
    Color0  1.00 1.00 1.00 1.0
    Color1  1.00 1.00 1.00 1.0

The red color is from the texture.

You can download the effect here:
https://www.sas1946.com/main/index.php/topic,3718.0.html



santo. :)
Title: Re: Weekly progress report
Post by: Stainless on July 14, 2015, 02:31:35 AM
Seems like I have a lot of research ahead of me.

I really don't like the sound of the variation in display results
Title: Re: Weekly progress report
Post by: Dreamk on July 14, 2015, 02:44:26 AM
The second variation I described comes from the method using "ballisticprojectile" instead of "actor"
example:
Code: [Select]
Eff3DActor.New(actor, null, rel, 1.0F, "3DO/Effects/Fireworks/WPSsmoke.eff", -1F);
and
Code: [Select]
Vector3d vector3d = new Vector3d();
                    for(int j = 0; j < 36; j++)
                    {
                        vector3d.set(World.rnd().nextDouble(-20D, 20D), World.rnd().nextDouble(-20D, 20D), World.rnd().nextDouble(3D, 20D));
                        float f2 = World.rnd().nextFloat(3F, 15F);
                        BallisticProjectile ballisticprojectile = new BallisticProjectile(point3d, vector3d, f2);
                        Eff3DActor.New(ballisticprojectile, null, null, 1.0F, "3DO/Effects/Fireworks/WPSsmoke.eff", 12000L);
                    }
Title: Re: Weekly progress report
Post by: Stainless on July 14, 2015, 03:09:42 AM
That kind of makes sense.

This is just guess work at the moment, however ....

What I think is happening is lighting is getting in the way. I would expect an actor to be lit, however lighting a particle system is impossible when using billboard quads.

A billboard quad, which most particle systems are, is always facing the camera. So the normal used in the lighting will just be bollocks.

A good test for that would be to pick an effect that has a material with sensible ambient and diffuse terms, then flay around it. If I'm right, the particles will change brightness as you orbit them.

Title: Re: Weekly progress report
Post by: Stainless on July 16, 2015, 02:29:28 AM
Can anyone give me a clue what units the various settings in an effect relate to?

Accelerations, velocities, emit rates, all that sort of thing.

I want to get my editor as accurate as possible.
Title: Re: Weekly progress report
Post by: Dreamk on July 16, 2015, 06:54:08 AM
MatName //The texture that the Effect particles use.
nParticles  //The number of particles assigned to a cycle
FinishTime //How fast to draw 1st particle (-1=draw continuously) - How fast for color one becomes color 2, at which point it ends or restarts based on the value given.
MaxR
PhiN //Angular speed (?)
PsiN //Angular speed  (?)
LiveTime //length of the cycle - The time inside which the effect 'loops', in seconds.
TranspTransitionTime
EmitFrq // Frequency emission of the particles. This number controls how fast the particles are released. A lower number releases them as a smooth stream, while a higher number disperses them more rapidly.
SegmentLen
MaxObjectVelocity //indicates how fast the smoke travels in the direction of the object that emmits it
EmitVelocity //Min / Max speed of the emission (More specifically, Min is at the base of the effect, Max is at the height of the effect)
EmitTheta // Min / Max angle of the emission (More specifically, Min is at the base of the effect, Max is at the height of the effect)
GasResist //Resistance to expansion, lower = faster dispersal
VertAccel //How fast to move up down vertically ("gain altitude")
Wind //wind is a random speed which moves particles
Size 1.0 2.0  // Size of particles, start & ending size
Rnd // helps control the depth of the effect near an object.
Title: Re: Weekly progress report
Post by: Uufflakke on July 16, 2015, 07:06:05 AM
Can anyone give me a clue what units the various settings in an effect relate to?

Accelerations, velocities, emit rates, all that sort of thing.




https://www.sas1946.com/main/index.php/topic,20628.msg228807.html#msg228807 (https://www.sas1946.com/main/index.php/topic,20628.msg228807.html#msg228807)


and

https://www.sas1946.com/main/index.php/topic,21098.msg228821.html#msg228821 (https://www.sas1946.com/main/index.php/topic,21098.msg228821.html#msg228821)
Title: Re: Weekly progress report
Post by: Stainless on July 16, 2015, 07:08:06 AM
Yes, I know what the variables are, I'm struggling with units.

EmitFrq      Is this particles per second? Or just an abstract value.
EmitTheta  Radians? Degrees?
VertAccel   Metres per second squared? Abstract value? feet per second squared?
Title: Re: Weekly progress report
Post by: Eexhaton on July 17, 2015, 04:49:29 AM
Afaik from my extensive experience with IL2 FX modding:
MaxR = Max Radius - max radius for visual to spawn from particle spawnpoint (not 100% sure)

Emitfrq - afaik particles are spawned per tick - which to me seems much more logical compared to spawn per sec.
Radius is (in IL2) always in degrees

Segmentlen is for stretched textures, shorter Segmentleng results in more often repeated textures along the particle path.
(not 100% confimred though, but from my own experience)

TranspTransitionTime is a value for transparency. How fast the texture goes from 100% to 0% opacity.

Hope this helps.
Feel free to correct any errors, it's been quite a long time for me.
Title: Re: Weekly progress report
Post by: santobr on July 19, 2015, 12:52:14 AM
EmitFrq             particles per second
EmitTheta          Degrees (0 is de direction of the hook, it is a cone)
VertAccel           Metres per second squared



santobr. :)
Title: Re: Weekly progress report
Post by: Stainless on July 25, 2015, 05:03:59 AM
Well I need to do a lot more research.

EmitFrq makes no sense if it is particles per second. Looking at effects you see things like the max particles being say 256, the particle life time 1 second. The effect life time 6 seconds. EmitFrq 6.

So it would generate 6 particles per second that last for one second. I.E. the max number of particles ever visible is 6. Can't be right.

More research needed.

Anyway here are some videos which show my progress.

https://youtu.be/FmvUGJYww0A (https://youtu.be/FmvUGJYww0A)

https://youtu.be/jC5XdRsyNyY (https://youtu.be/jC5XdRsyNyY)


(http://s30.postimg.cc/nu570bt69/Win_Forms_Content_Loading_2015_07_25_12_43_07_09.jpg) (http://postimage.org/)





(http://s13.postimg.cc/t6zf7zygn/Win_Forms_Content_Loading_2015_07_25_12_44_03_55.jpg) (http://postimage.org/)





Title: Re: Weekly progress report
Post by: Stainless on July 27, 2015, 02:32:59 AM
Nothing is making sense.

I'm seeing effects with a finishtime and livetime  of 0
effects with start and end color of transparent black
effects with max particles 120 and an emitfrq of 256

None of this is making sense.

Has anyone got a set of tested and documented effects I can use as a reference
Title: Re: Weekly progress report
Post by: Dreamk on July 27, 2015, 02:41:57 AM
Stainless - keep in mind that only the core Il2 effects can be used as a basis for trying to understand what's behind the various parameters. The other sources effects are NOT reliable.
Title: Re: Weekly progress report
Post by: santobr on July 29, 2015, 11:23:19 PM
There is nothing wrong.
When finish time is 0, it means that it will emit forever (ex: airplane damage fire and smoke).
When lifetime is 0, that effect was disabled by the autor, the same for the transparent effect.
Why?
Sometimes an effect is made by two or more effects at the same time, but the autor of the mod optimises it to less effects or particles.

Less particles than EmitFrq x lifetime means an intermittent effect. The emission will stop until the first particle disappears.

You can see intermittent fire in my video:
https://www.youtube.com/watch?v=IYgIE9TqOOo



santobr.
Title: Re: Weekly progress report
Post by: Stainless on July 30, 2015, 03:03:10 AM
I've spent some time extracting the stock effects from the game and I'm going to concentrate on those for a while. Should give me more consistent data.

I've also got a copy of Unreal 4. We are starting to use it at work, so I can have the full source code for it. Some parts of the engine are really nice. I'm going to do a test project which just imports an aircraft from this site and displays it. If that goes smoothly, then I may decide to use Unreal. Means I have to rewrite my FDM though, might be a good idea anyway. I have learnt a hell of a lot about flight dynamics since I started and could do a much better job.

Does mean I get a Mac, Android, and PS4 version for "free".... maybe worthwhile.

Also I have talked to a guy who is doing a set of Unreal plugins to support joysticks. I mean many, many joysticks. That would be something worth having. I don't want to have to buy a dozen different joysticks just to make sure they work in the game.

My main concern is terrain. Unreal gives me a good starting point. Grass and trees look very good, as does water. However the terrain is flat. I need it to have curvature.

Well we will see.



Title: Re: Weekly progress report
Post by: Stainless on August 03, 2015, 07:35:22 AM
Spent the weekend adding a "Export as FBX" command to my modtool.

I came to the conclusion that writing a plugin for UE4 when I'm not sure I'm going to use it was a waste of time.

All went well until I tested it.

The FBX files import into UE4, but the materials don't. Nothing I could do would get the materials to display.

So I downloaded a test tool from autodesk and loaded my FBX files up in that. Same thing. No textures, no materials.

No Fecking idea why.

Anybody have a good FBX text mode file with textures and materials?

Title: Re: Weekly progress report
Post by: Stainless on August 05, 2015, 02:33:00 AM
 ???

Embarrassed.

Spent ages going through the code looking for mistakes, found nothing. Finally noticed that the texture filename was wrong. I was using Material.Name instead of Material.TextureName.

 ???

Ow well.

Still could do with a fbx file with multiple materials in it for testing, but most MSH files now export as FBX files correctly.

The effect editor is coming on nicely as well.

I am now happy with the particle systems, but I need to do some more work on the smoke trail particle systems.

Does anyone know how these are displayed in game?

Are they just particles?

Or are they polygons?

I am thinking to get a vapour trail to look correct in game you might need to create a polygon from the last position to the next position. So one polygon per frame.

Need Input.
Input,
Innnnnnpppppuuutttt
 
Title: Re: Weekly progress report
Post by: Dreamk on August 05, 2015, 09:31:41 AM
vapour trail are created by changing the speed of emission of particles and their lifespan - not through polygons.
Title: Re: Weekly progress report
Post by: Stainless on August 06, 2015, 02:30:22 AM
Doesn't that look shit though?

I'm thinking that if you fly at an angle through a vapour trail, since the particles are square and view aligned, you would see them "rotate" towards you.

Is that an artifact you see in game?

Title: Re: Weekly progress report
Post by: Stainless on August 10, 2015, 02:38:36 AM
I'm now happy with the standard particle systems, they look really good.

The other two though, not happy.

The trail particle systems just look terrible, as I predicted they would, so I have had a good think about them. I am now SURE they use polygon particles.

My proof is the textures used themselves. Look at any of them and you can see they are designed to join end to end. This makes them useless as normal view aligned particles.

Unless anyone can prove to me I'm wrong, I'm going to implement a polygon cross particle system and try that. This involves creating two quads. One along the XY plane and one along the XZ plane.

The end points are calculated from the emit position and the emit velocity. so a single particle kinda looks like this.


(http://s24.postimg.cc/h9ixm2zf9/particle_shape.jpg) (http://postimage.org/)
Title: Re: Weekly progress report
Post by: Stainless on August 16, 2015, 03:33:18 AM
I almost have FBX export working, it's frustratingly close.

I have uploaded a test aircraft here....

http://stainlessbeer.weebly.com/downloads.html (http://stainlessbeer.weebly.com/downloads.html)

It's test.zip at the bottom of the page.

Can someone who has the ability to edit FBX files in a 3D editor have a look at it for me please?

What I need someone to do is import one or two of the FBX files, fix any errors, and then re-export it as FBX. From this I can do a diff and see what I am doing wrong.

What I am seeing is this.


(http://s27.postimg.cc/fzs581r5v/test.jpg) (http://postimage.org/)
Title: Re: Weekly progress report
Post by: SAS~Ghost129er on August 16, 2015, 05:57:44 AM
Found it; the UV Mapping for that particular section is buggered up. Luck isn't on your side as I suck at UV Mapping, like, big time... Maybe someone good at UV mapping can fix it though, but there's your problem.
Title: Re: Weekly progress report
Post by: just champi on August 16, 2015, 02:57:20 PM
Hi,  with all respect to Kawaii Killer, I don't see anything wrong with the mapping.
To support markings feature in stock game, some sections of a model are cloned and layered one in top of another, also they are separated as different elements in the 3D model and different materials are assigned to them.
Later in game, Java code controls the building of the mat files that in turn controls what textures are assigned to each layer so it shows the right codes for squadrons, individual aircrafts and different countries.
Textures for markings are tga's with alpha layer for masking the letters and numbers for the codes.
As these parts of the model have no texture assigned to them in the picture, they are seen in black color (in fact there are two cloned layers one in top of another for each side plus one more in the nose left side for the squadron badge)
I think the black effect is the combination of what is called Z-fighting when two or more faces of a mesh are placed at the same plane or very close together so they interfere with each other at rendering, and the fact that there are missing textures for those parts of the model.

Markings and squadron badge parts are mapped to a different texture than standard skin and they use different mapping scale, (they look waay much larger than the other parts) that's why if you see their UV's together they look like a mess.

I have not looked into it in all detail, but for what I've seen so far,
 -Material assigned to test model uses Phong shader with very high values for specular level (400, 999, waaay too much, I think?)
 -orientation of the model is vertical in viewports when imported, (like nose of airplane pointing down through the construction grid) will be better if model is aligned to horizontal grid, (preferible with nose pointing X+ world axe, but even stock models doesn't follow that convention...)
 -Also scale of the model is exported way too small, the model is minuscule, local scale shows 1 in all axes when should be 100.
That been said, I'd like to take the opportunity to give you a big thank you for all the work you have been doing so far, Stainless, my hat's off in admiration.
Title: Re: Weekly progress report
Post by: Dreamk on August 17, 2015, 02:23:46 AM
Stainless Hi, I converted the CF_D0.fbx to an OBj file using Autodesk FBX Converter 2013, and imported it in 3dmax. On At first look, the mesh is generally OK (although the smoothing was lost in the process but it's not a problem), without the  phenomenon shown on your post. However by looking element after element, it appears that  you have 2 supplementary overlapping elements on the left side, and one overlapping element (as a matter of fact this element is repeated on itself not one but twice)  that cause the glitch you see - if you remove them the mesh is fine. I re-exported the corrected mesh to obj and converted it to FBX (2013) and also to FBX (2009) formats. Here's the link of these files https://www.mediafire.com/download/9m94kka9ba4ez5x/test.7z

It's true that it is the principle used by the game for overlays but these are first mapped individually then generally slightly moved outside or inside the original element so as not to strictly overlap.

(http://s22.postimg.cc/g4ifx7k0h/test1.jpg) (http://postimage.org/)(http://s22.postimg.cc/w413grg29/test2.jpg) (http://postimage.org/)(http://s22.postimg.cc/l5ptykrgx/test3.jpg) (http://postimage.org/)(http://s22.postimg.cc/nbk4t2uxd/test4.jpg) (http://postimage.org/)(http://s22.postimg.cc/yisz16wb5/test5.jpg) (http://postimage.org/)

How is the effects viewer progressing? you solved the smoke trail problem?
Title: Re: Weekly progress report
Post by: Stainless on August 17, 2015, 02:45:22 AM
Quote
How is the effects viewer progressing? you solved the smoke trail problem?

No, I tried a simple system that just created a scaled axis aligned quad and it looks awful. So I am in the process of adding a new type of particle system that uses simple 3D meshes as particles instead of axis aligned quads.

With the FBX issue, I want to be able to export the overlays in the FBX file. I don't want you lot to have to do any work at all to get mods you have already created into my sim, or indeed into Unreal.

Quote
Material assigned to test model uses Phong shader with very high values for specular level (400, 999, waaay too much, I think?)

Yes I haven't attempted to re-scale the specular stuff yet. I will need to at some stage.

Quote
orientation of the model is vertical in viewports when imported

That's the IL2 coordinate system, it uses a left handed (OpenGL style ) coordinate system whilst most modern editors use the more common right handed coordinate system. I personally hate this, Z forward is the CORRECT way for me  :P

Quote
Also scale of the model is exported way too small, the model is minuscule, local scale shows 1 in all axes when should be 100

Again it comes back to IL2, it uses 1 == 1 meter while most editors use 1 == 1 centimeter

I am sure now that the problem is with textures, but as far as I can see I am creating them correctly.

Within the MSH file we have mesh parts. Mostly these are the main mesh, and any overlays. These use the same vertex pool through out, but use different index lists and UV pools. I have tried to re-create this in the FBX file, and failed by the look of it.


Title: Re: Weekly progress report
Post by: just champi on August 17, 2015, 04:55:13 AM
Regarding scale issues, in the info tab within FBX plugin parameters, (the one that opens in 3dsmax when importing a .FBX file), I've seen that file units are set to centimeters (just as you say) while system units are set to meters.
So it's no issue in the end, in the advanced options tab, inside Units parameters, "automatic" can be unchecked and choose the option "File units converted to... centimeters". That fixes and imports the file with the right scale.

There is also a tab called "Geometry" where you can check "smoothing groups" so they are preserved.
Also I'm not sure if it is really needed to offset the markings from the model, as markings mats have an offset property for them to render "on top" of skin texture. But it is sometimes annoying while editing them in 3dsMax because they fight with each other and doesn't look right in the viewports  >:(

Quote
Within the MSH file we have mesh parts. Mostly these are the main mesh, and any overlays. These use the same vertex pool through out, but use different index lists and UV pools. I have tried to re-create this in the FBX file, and failed by the look of it.

What I find interesting (I'm using CF_D0 part for the test as in your picture ) is that the model materials are recognized and have its own slot correctly assigned with unique ID, but last material (Overlay7 with ID 8 ) is missing.

ID    original:     test model:   

1    Glass2          Glass2
2    Gloss1D0o   Gloss1D0o
3    Gloss2D0o   Gloss2D0o
4    Matt1D0o   Matt1D0o
5    Overlay1   Overlay1
6    Overlay4   Overlay4
7    Overlay5   Overlay5
8   Overlay7

and even though the test model has the needed group of faces separated as elements, these separated elements themselves doesn't preserve ID's, their original ID are lost and all are assigned to ID 1, so only the first material (and his associated texture) is aplied to the whole model, the others materials and textures are unused.
It can be edited though inside 3dsMax, but seems like this last material and the ID assignaments for elements are missing during the exporting?

orientation of the model is not an issue "per se", can be any, but it makes very time consuming and a bit annoying if you have to rotate all the parts of the model to put them together right, and makes navigate through viewports a nightmare because labelling of viewports doesn't match anymore with orientation of the object (bottom view can be looking at the model from front, and front view is top o the model or whatever) ...and working with local and world coordinates is even more funny... :D
Anyway, that's a minor issue in the end, preserving original materials ID's seems maybe more important.
Title: Re: Weekly progress report
Post by: SAS~Ghost129er on August 17, 2015, 06:22:01 AM
Just wanted to give a shoutout thanks to 'just champi' and 'Dreamk' for their information and in sight into the problem. Never knew about that and also gave me a lot more of an understanding of what that exactly was... Much appreciated. But glad to see the problem's resolved and so (at least I hope so) :-X
Title: Re: Weekly progress report
Post by: Stainless on August 17, 2015, 08:17:08 AM
Quote
It can be edited though inside 3dsMax, but seems like this last material and the ID assignaments for elements are missing during the exporting?

If you can edit it in 3dsmax and re-export as FBX I can diff the two files and fix the problem.

That would be really useful please.
Title: Re: Weekly progress report
Post by: just champi on August 17, 2015, 12:26:36 PM
Not sure if it will be right, it seems so, I've only have touched facegroup assignaments but I haven't worked with FBX format before...
Tell me if something is wrong and I'll try to lok into it.
http://www.filedropper.com/cfd0test1 (http://www.filedropper.com/cfd0test1)
Title: Re: Weekly progress report
Post by: Stainless on August 18, 2015, 08:02:34 AM
Sorry man that was a binary mode FBX, I can't read that.

I'm good, I can read hex for many CPU's, but not for 3d meshes.
Title: Re: Weekly progress report
Post by: just champi on August 18, 2015, 08:52:17 AM
ups...  :-X
I hope this one works
http://www.filedropper.com/cfd0test2 (http://www.filedropper.com/cfd0test2)
Title: Re: Weekly progress report
Post by: Stainless on August 19, 2015, 04:34:11 PM
Effect editor

Normal effects look fine ....

https://www.youtube.com/watch?v=MOjO3QQrHpU (https://www.youtube.com/watch?v=MOjO3QQrHpU)

But smoke trail effects look shit

https://www.youtube.com/watch?v=UwLhAkxXqEI (https://www.youtube.com/watch?v=UwLhAkxXqEI)

By the way, how do you attach videos correctly?



(http://s12.postimg.cc/v2q5fn1fh/Win_Forms_Content_Loading_2015_08_19_23_47_36_42.jpg) (http://postimage.org/)
Title: Re: Weekly progress report
Post by: Cloyd on August 20, 2015, 04:34:08 AM
Just copy the link, and paste it in directly. No need to use the "insert hyperlink" button.

https://www.youtube.com/watch?v=MOjO3QQrHpU
Title: Re: Weekly progress report
Post by: Stainless on August 20, 2015, 05:14:05 AM
Thanks man, now people can easily see how shit the smoke trail is.....  :(

https://www.youtube.com/watch?v=UwLhAkxXqEI
Title: Re: Weekly progress report
Post by: Stainless on August 23, 2015, 08:19:15 AM
Okay I've put up a new version of the test.zip file on my website.

I can see the textures, but they look all wrong.

Anybody willing to have a look for me?

http://stainlessbeer.weebly.com/downloads.html (http://stainlessbeer.weebly.com/downloads.html)
Title: Re: Weekly progress report
Post by: just champi on August 25, 2015, 03:16:33 AM
I've been passing a few days of my holidays with my relatives and came back yesterday. I've had this warning when trying to import CF_D0.fbx:
Quote
[WARNING] Invalid UV index table(s) - One or more objects define the UV mapping by POLYGON_VERTEX but the index table

   has less entries than the actual number of polygon vertices. The missing entries

   have been assigned an arbitrary value. Depending on the affected vertices, the resulting

   mapping may be corrupted. CF_D0

It seems that only one single standard material (CF_D0Mat) is assigned to the whole mesh instead of Multimaterial with several slots and support for different textures, like your last example.
CF_D0Mat doesn't point to any texture but specular and glossiness values seems corrected.
No texture shows in the mesh even when manually one is assigned in the material slot.
Most of the parts of the mesh can be selectable as elements but whole mesh have ID 1 assigned only.
That invalid index table may be the culprit for some of the above, probably.
Anyway, hope it helps.
Title: Re: Weekly progress report
Post by: Stainless on August 26, 2015, 02:44:11 AM
Thanks, yes it helps.

I forgot to export the materials.

Going to add that tonight and re-test, little battered this morning.

It was the wrap party for our last game yesterday.

I can finally tell you what I have been working on for the last year.

Until Dawn.

Not the best of the reviews, but it has some videos.

http://uk.ign.com/articles/2015/08/24/until-dawn-review (http://uk.ign.com/articles/2015/08/24/until-dawn-review)

Title: Re: Weekly progress report
Post by: Stainless on August 28, 2015, 06:16:39 AM
First pass at lighting.

This is still my lowest quality renderer, designed to run on 10 year old machines with a five year old graphics card.

https://www.youtube.com/watch?v=EucE4PagQas&feature=youtu.be
Title: Re: Weekly progress report
Post by: SAS~Ghost129er on August 28, 2015, 08:24:13 AM
That.. Was beautiful.. :')
Title: Re: Weekly progress report
Post by: Stainless on August 29, 2015, 01:52:19 AM
Thank you.

However to me all I can see is the errors.  >:( 

This is the low quality renderer, so the shadow didn't move. There is no ambient occlusion. No self shadowing. etc.

But at least it's a start.

Title: Re: Weekly progress report
Post by: Stainless on August 29, 2015, 02:57:49 AM
I have published the first pass at the effect editor here http://stainlessbeer.weebly.com/downloads.html (http://stainlessbeer.weebly.com/downloads.html)

IT IS BY NO MEANS A WORKING TOOL

You can't even save the edited effect, but I need feedback.

I need to know how close I am. So I need you guys to help me.

I need you to load up some effects you know really well and see what they look like in the editor. Compare them to how they look in game and give me something to work with.

Title: Re: Weekly progress report
Post by: Stainless on August 29, 2015, 03:00:08 AM
That invalid index table may be the culprit for some of the above, probably.
Anyway, hope it helps.


I have put up a new version in the same location.

This one uses a different UV mapping mode, and has all the materials in it.

However I still don't get any textures. I am really growing to hate FBX format, but it is so well supported I suppose I have to keep plodding along on it.
Title: Re: Weekly progress report
Post by: Stainless on September 03, 2015, 07:47:41 AM
Had a brain wave and had to go back to airports

Still some issues to work out, but a hell of a lot better.


(http://s7.postimg.cc/qukfwzpp7/airport_1.jpg) (http://postimg.cc/image/hzjlmh0wn/full/)
Title: Re: Weekly progress report
Post by: Stainless on September 04, 2015, 03:27:08 AM
First pass at lights


(http://s18.postimg.cc/7yhbnf021/airport_2.jpg) (http://postimg.cc/image/qe1skte6d/full/)
Title: Re: Weekly progress report
Post by: hello on September 06, 2015, 02:14:20 AM
Progress is good! Very nice.
Title: Re: Weekly progress report
Post by: Stainless on September 09, 2015, 03:10:05 AM
Fixed a few bugs and looking ok.


(http://s16.postimg.cc/42fxwqwth/airport_4_EGPB.jpg) (http://postimg.cc/image/tl8a9rgdd/full/)

Combining this with the apt.dat file gives radio frequencies, flight paths, runway signs, everything we need.....

However the same cannot be said for the terrain. This is a terrain file lifted from FlightGear I am using as test data. It is a really good size and located at real world locations making it easy to plug into a world, but the detail is awful.

(http://s18.postimg.cc/4ncgxhtyh/airport_5_terrain.jpg) (http://postimg.cc/image/o574dfqw5/full/)

I think I am going to have to junk this line of thought and use IL2 maps.


Title: Re: Weekly progress report
Post by: Plowshare on September 09, 2015, 05:04:11 AM
Stainless:

I've been following this thread off and on for the last little while and just caught up to it.

I noticed the runways crossing; is there flickering like we get when we place runway plates over each other in Il2? Would there be some way to make a runway plate be moved up or down? So, in one case you could have PSP crossing over a dirt runway and another time have the PSP under the dirt runway (a terrible example but all I could come up this early in the morning!).

Bob
Title: Re: Weekly progress report
Post by: Dreamk on September 09, 2015, 05:23:06 AM
Stainless hi!
I'm trying to run the effect editor. I downloaded and installed it but when I try to run it it crashes.
(I have no problem with the Il2, running with WinXP SP3)
Title: Re: Weekly progress report
Post by: Stainless on September 09, 2015, 06:30:52 AM
Stainless:
I noticed the runways crossing; is there flickering like we get when we place runway plates over each other in Il2? Would there be some way to make a runway plate be moved up or down? So, in one case you could have PSP crossing over a dirt runway and another time have the PSP under the dirt runway (a terrible example but all I could come up this early in the morning!).

No problems here, that all gets taken care of when the runways are baked into vertex arrays. The hidden sections are just removed.

Title: Re: Weekly progress report
Post by: Stainless on September 09, 2015, 06:31:29 AM
Stainless hi!
I'm trying to run the effect editor. I downloaded and installed it but when I try to run it it crashes.
(I have no problem with the Il2, running with WinXP SP3)

You should get some kind of error report which will help me work out what is wrong.
Title: Re: Weekly progress report
Post by: Dreamk on September 09, 2015, 06:47:43 AM
This is what I get:

EventType : clr20r3     P1 : winformscontentloading.exe     P2 : 1.0.0.0     
P3 : 55e182a8     P4 : microsoft.build     P5 : 4.0.0.0     P6 : 4ba1e768     
P7 : 1400     P8 : 49     P9 : 0z1dql0hjhfn4d2yqn34jrlwd3o252bf 

Exception Information
Code 0xe0434352      Flags 0x00000001
Record 0x0000000000000000    Address 0x000000007c812aeb
Title: Re: Weekly progress report
Post by: Stainless on September 09, 2015, 07:03:01 AM
That's the CLR catch all exception, so not much help.

Have you got XNA 4 installed?    (the installer should have prompted you to install it, but can be dodgy)
What version of .NET have you got installed?

Title: Re: Weekly progress report
Post by: Dreamk on September 09, 2015, 09:23:02 AM
Framework.Net 4.0
I am installing now the XNA 4 but it demands to have the Visual studio 2010 installed - the only version I could find that accept to install on XP is the "ultimate " which takes 4.5GB on the disk! I'm far to be sure that it's worth it. I'll install it however anyway to test the effect editor but will erase it after that. Apparently I'll be unable to use this editor beyond testing.
Title: Re: Weekly progress report
Post by: Stainless on September 10, 2015, 02:26:32 AM
The XNA 4 runtime is all you need.

That doesn't require Vs 2010

At this stage I need feedback to try and get the look of the particle systems correct, when I have that I can finish off the editor and give you all the toys you need.

Until I have that, the tool is worthless.

Title: Re: Weekly progress report
Post by: Dreamk on September 10, 2015, 02:58:27 AM
XNA 4 is now installed but the effects editor keeps crashing when I try to load it.
Title: Re: Weekly progress report
Post by: asheshouse on September 10, 2015, 04:55:58 AM
Quote
I think I am going to have to junk this line of thought and use IL2 maps.

Biggest visual flaw in existing IL-2 maps IMO is the angular road and rail network. To look good they need to follow splines.

Other enhancements I have in mind may be unrealistic.

Ability to create cuttings and embankments (and tunnels) -- thinking rail here but also applies to road and water courses.
More realistic coastal modelling so that harbours fit into the landscape rather than sitting on it.

True sea floor model with water level changing with time (tidal effects).
Thames Estuary looks completely different at low tide. --- maybe that one is asking too much. :)

     
Title: Re: Weekly progress report
Post by: Stainless on September 10, 2015, 05:24:02 AM
XNA 4 is now installed but the effects editor keeps crashing when I try to load it.

Any error information
Title: Re: Weekly progress report
Post by: Dreamk on September 10, 2015, 07:50:03 AM
NET Runtime 4.0 Error Reporting
Application: WinFormsContentLoading.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: Microsoft.Build.Exceptions.InvalidProjectFileException
Stack:
   at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(Microsoft.Build.BackEnd.Logging.ILoggingService)
   at Microsoft.Build.Evaluation.Project.Initialize(System.Collections.Generic.IDictionary`2<System.String,System.String>, System.String, Microsoft.Build.Evaluation.ProjectLoadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(Microsoft.Build.Construction.ProjectRootElement, System.Collections.Generic.IDictionary`2<System.String,System.String>, System.String, Microsoft.Build.Evaluation.ProjectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(Microsoft.Build.Construction.ProjectRootElement)
   at EFF_Editor.ContentBuilder.CreateBuildProject()
   at EFF_Editor.ContentBuilder..ctor()
   at EFF_Editor.MainForm..ctor()
   at EFF_Editor.Program.Main()


EventType clr20r3, P1 winformscontentloading.exe, P2 1.0.0.0, P3 55e182a8, P4 microsoft.build, P5 4.0.0.0, P6 4ba1e768, P7 1400, P8 49, P9 0z1dql0hjhfn4d2yqn34jrlwd3o252bf, P10 NIL.


Title: Re: Weekly progress report
Post by: dyingtofly on September 10, 2015, 07:54:14 AM
Hi Steele
No promting on installation here either. Is this the runtime XNA your talking about ?
( Microsoft XNA Framework Redistributable 4.0 )
Title: Re: Weekly progress report
Post by: Stainless on September 11, 2015, 01:11:18 AM
Yes, that's the runtime.

When I packaged the app as an installer, it was supposed to be able to scan for compatibility problems and prompt the user to install the missing packages.

However, it is a Microsoft installer, so I am not suprised it is shit.

This looks like it is trying to use Microsoft build, which it shouldn't.

I'll look into it.

 
Title: Re: Weekly progress report
Post by: Dreamk on September 11, 2015, 07:25:43 AM
Thanks, Stainless.
Title: Re: Weekly progress report
Post by: Stainless on September 13, 2015, 03:44:54 AM
I've put up a new version of the effect editor in the same place.

Hopefully this one will at least install and run.

Just a note, the mouse wheel is the zoom feature, if you get as far as it running.
Title: Re: Weekly progress report
Post by: Stainless on September 13, 2015, 05:35:57 AM
Found a star database and implemented a star renderer. They are in the correct place in the sky based on latitude, longitude and time of day.

It's a complex renderer, optomised for speed but with enough bell and whistles so it looks good. It will have to be an optional display component, and have a max star count. At the moment it's rendering 113,000 stars.

Video doesn't do it justice.


https://youtu.be/Ny8swKTvJwM
Title: Re: Weekly progress report
Post by: Stainless on September 13, 2015, 02:51:48 PM
https://youtu.be/R5HECj5yepA

Added milky way, still needs tweaking though
Title: Re: Weekly progress report
Post by: Stainless on September 14, 2015, 04:45:10 AM
Need feedback

This is animated based on latitude, longitude and time.

Mathematically it looks correct, not sure if it looks right in game though. What do you guys think?

This was recorded at ..

Code: [Select]
playerLocation = new Location(MathHelper.ToRadians(1.2243f), MathHelper.ToRadians(50.223f), 20997036);

So that's Longitude 1.243, Latitude 50.233, altitude approx 1000 feet

https://www.youtube.com/watch?v=aOfCv9RJWJA
Title: Re: Weekly progress report
Post by: asheshouse on September 14, 2015, 08:49:46 AM
Milky Way looks too much like a cloud rather than simply a dense grouping of stars as it is in reality.
General starry sky view looks good though.
Title: Re: Weekly progress report
Post by: Stainless on September 14, 2015, 01:03:20 PM
This  is the image I am using.


(http://s13.postimg.cc/pmwnvlemf/background.jpg) (http://postimg.cc/image/sgzt91gsj/full/)
Title: Re: Weekly progress report
Post by: Dreamk on September 17, 2015, 08:37:33 AM
Hi Stainless. I've begun to test the effects editor. Will update you later in the week about the results.
Title: Re: Weekly progress report
Post by: SAS~Tom2 on September 17, 2015, 12:42:11 PM
Keep up the astonishing work, Stainless!  :)
I found the Galaxy looking good yet a bit too intense in its cloud maybe. IMHO how this shows up totally depends on the system's monitor and GFX settings. Mine e.g. is very dark and I use gapa gamma for all sorts of applications to overcome its shortcomings as well as dedicated monitor and GFX settings.
Cheers

Thorsten
Title: Re: Weekly progress report
Post by: Stainless on September 18, 2015, 02:28:03 AM
Remember this will be faded in by sidereal time, so during the day it will be invisible. In the middle of the night it will be brighter, but modified by the atmosphere.

So at 90,000 feet you might say it is too bright,(how many of us have looked at the sky from 90,0000 feet in the middle of the night ?)  but at 30,000 it should look good.

A lot to do still, but steady progress is still progress.
 
Title: Re: Weekly progress report
Post by: Stainless on October 01, 2015, 12:44:40 PM
Thanks to a lot of testing by SAS~Storebror, I have finally got FBX export working.

A new version of the mod tool has been uploaded in the usual place http://stainlessbeer.weebly.com/downloads.html (http://stainlessbeer.weebly.com/downloads.html).

It exports textures, materials, groups, and of course the mesh itself.

I had to play with the UV coordinates a lot to get it to work, and it took several attempts to get the overlays to work, but it is finally working. I think this now means we have closed the circle.

You can export from 3ds max into the game, and import a HIM into 3ds max again.

You load the HIm into the modtool, make any changes you need to get it to display properly (I often have to sort out the alpha values on textures and the lighting settings), then click "Mesh->Export as FBX"


(http://s7.postimg.cc/4tcfuop4r/ilmodder.jpg) (http://postimg.cc/image/onyhgt4c7/full/)


In the dialog that pops up. Click browse to pick an output directory. Make it a unique one as it will be full of FBX files.

You can click on the check box if you want a binary mode fbx

Then hit "do it" and sit back for a while.

When it completes you will have a directory with one FBX file per msh file, and all the textures.

The textures are converted to png files to get around the problems with IL2's none standard TGA file format.

I don't have 3ds max, that's why Mike's help was SO important, but I have tested it in Maya and apart from the glass not being transparent, it's spot on.

Have fun guys.




(http://s13.postimg.cc/m8od649rr/cf_d0_2.jpg) (http://postimage.org/)


(http://s4.postimg.cc/i85zbspj1/cf_d0_3.jpg) (http://postimage.org/)



(http://s15.postimg.cc/jjirmsq6z/cf_d0_4.jpg) (http://postimage.org/)
Title: Re: Weekly progress report
Post by: Dreamk on October 07, 2015, 05:12:06 AM
Ok - It took me some time but here is the first feed-back on the Effects editor:
First I must state that I am working with a WinXP SP3 on a 1280x720 monitor resolution, while there is a need to have at least a 1280x768 resolution to see all the effects editor window.
Opening the program and loading an effect file brings up 3 windows:
One "Spawn particles system" aimed apparently at showing the difference between effect on ground an in air (quite relevant for smoke effects that give often really different effects in ground and in air)  - is apparently not functional (at least I have not have been able to see any differences when pushing the buttons of this screen)
One "Material editor" window - with very limited functionality - shows the material name and display the bitmap used for it. I have played with the various input scales and boxes in this menu but have been unable to see changes in the effect.
One "SAS EFF Editor" window - the main one and apparently the only functional one.

A preliminary observation about the display of the effect - there is no possibility to move on the screen the point of origin of the effect, and as some display at the bottom of the screen this limits the possibilities to "play" with the effect.

One strange phenomenon about the imported material is that sometimes the Alpha property of the bitmap is respected and the the effect displays fine (RocketSmokeWhite using whitesmoke.mat for instance),
However, for some materials this is not the case and we have then to deal with black squares turning on themselves (FAB_100(Circle).eff using Smoke.mat for instance).
Some effects do not display at all though the material is loaded (firesprite.eff using rcktflamsprite.mat for instance)

The class box allows to change the java class involved - but I have been unable to see any change in the effect by doing so.

The colour boxes are fully functional

The parameter boxes:
N Particle  - functional
Finish Time - functional
TranspTransitionTime - no influence on the effect
MaxR - no influence on the effect
PhiN - no influence on the effect
PsiN - no influence on the effect
LiveTime - not sure
EmitVelocity - functional
EmitFrq - functional
Wind - functional but very low influence on the effect if any (the wind activate box seems to be not functional)
Size - functional
GasResist - Functional
Vertical Acceleration - Functional
Rnd - Functional
Emit Theta - Functional
Fixed velocity = not functional
Fake alpha box - not functional

Conclusion - a most promising tool, already useful for modifying some effects but still at a early devlopement stage.
Title: Re: Weekly progress report
Post by: Stainless on October 08, 2015, 02:54:02 AM
There is a check box called "fake alpha"

Turn that on and re-import your effect and the black boxes will go away.

At the bottom are two buttons, these switch between 2D mode and 3D mode.

In 3D mode the spawn particle system dialog spawns particle systems. Either close to the ground so you can see the effect interacting with terrain, and in the air so you can see it against the sky.

Very important to have that option if you want the effects to look correct.

I have seen many effects that don't display anything. At first I thought it was a bug in the editor, then I noticed a lot of them have things like a max particle count of 0 or a particle size of 0

I really don't know why they are in the game if this is correct.

What I need to know is, do the effects look reasonable. Do they look like they do in the game. If not then I am on a hiding to nothing.
Title: Re: Weekly progress report
Post by: Dreamk on October 08, 2015, 04:16:38 AM
When they display, the effects look more than reasonable. They are a realistic representation of what to expect in the game. I am already using this effect editor to adjust some of the new effects I a making.
 
Concerning the effects that don't display anything - it may be related to the effect duration - they include a lot of "almost instant" effects such as sparks.

Checking the "fake alpha" box indeed solves the problem I mentioned.
I have tested the 2D/3D and it's a very nice tool - just one thing - can you include a possibility to "fix" the 3D screen under a given angle at choice (it keeps rotating) it would be easier to study the modified effect.
Title: Re: Weekly progress report
Post by: Stainless on October 08, 2015, 05:10:05 AM
Yes, I can stop the rotation of the camera.

If you think it's close to what you see in the game, I can come back to it in a few days and start finishing off all the various boring editor functions.
Title: Re: Weekly progress report
Post by: Dreamk on October 08, 2015, 08:15:40 AM
It would be perfect if you find time to complete its functions. It's a tool that really can be a great help.
Title: Re: Weekly progress report
Post by: Stainless on October 25, 2015, 06:53:14 AM
This week I've done more work on the effect editor and published it.

Done more work on the mod tool and published it.

And I've worked on the flight model some more, still not happy with it yet.
Title: Re: Weekly progress report
Post by: Dreamk on October 26, 2015, 12:50:14 AM
Stainless Hi! I'll post later this week my remarks on the new effect editor. I have began to test it, but needs to do that more extensively. Thanks for all your work
Title: Re: Weekly progress report
Post by: Stainless on November 15, 2015, 02:38:54 AM
This week I have been really stuck on the FBX exporter.

It's kicking my ass.

I have no idea why it isn't working.
Title: Re: Weekly progress report
Post by: Stainless on November 23, 2015, 02:33:06 AM
Big break through this morning.

Managed to get the base meshes for all aircraft parts in a HIM to export to FBX correctly. It was a rotation order problem.

Of course it's broken LOD's and shadows, but at least I am making progress again.

New release of the mod tool later this week.
Title: Re: Weekly progress report
Post by: Stainless on December 02, 2015, 02:27:08 AM
Finally started working in terrain and hit a problem.

I'm using the western front map as a starting point and noticed a problem.

In the INI file no textures are defined for a couple of slots, but those types are used in the map_T.

So say Wood0 is defined, but Wood1 isn't.

WTF should I do in this case?

Title: Re: Weekly progress report
Post by: SAS~Tom2 on December 02, 2015, 09:56:20 AM
My tip: Pm SAS~Boomer.

IIRC, if there is a map texture slot not defined by the load.ini, it will automatically get one assigned in form of one of the textures below that slot, same if more than one is not assigned. The details, TBH, I forgot completely.

For the forest:
Usually only RGB 24 is painted, that is the texture that carries the forest as defined in the first set of wood entries in the load.ini.
But also RGB 26 can be painted on the map.
I never saw RGB 25 or 27 assigned on map_t.tga, again, someone with more map painting experience can give a deeper insight.

I also cannot remember if I ever checked on a map if missing load.ini entries are actually painted on map_t.tga.

But I know they will be filled anyway.

Hope that helped a bit increase the confusion.. :P

PS:
You will never see Wood1= and Wood3= be assigned on the Slot in a load.ini, at least I never did see that.
It is Wood0= and Wood2= that are used. On the load.ini.
Title: Re: Weekly progress report
Post by: Stainless on December 06, 2015, 11:21:59 AM
I've been working on getting an animation system working that is simple for you guys to use.

What I have come up with is a new menu on the mod tool. Fox One.

In that you have an option to add animations.

Click on that and you get a list of animations I have set up for you.

Add as many as you want to the list, setup the variables, and the job is done.

For example. Adding an animation system to an AA gun is two clicks.

(http://s4.postimg.cc/ac80gvdgt/anim.jpg) (http://postimg.cc/image/g0eb7rht5/full/)


From that you get an example animation in the mod tool like this.

https://www.youtube.com/watch?v=Qk2taPJvyrc
Title: Re: Weekly progress report
Post by: Stainless on December 14, 2015, 02:48:12 AM
This week has been about animation and a few changes to the mod tool.

The idea is I can start using the mod tool to check animations, both for IL2 and my flight sim.

As a test I added animations for ship's turrets and guns. So you can click on a mesh node, add a turret animation, tweak the values, add a gun animation, tweak the values, and see the result real time.
This allows you to fine tune animations. Making sure you don't end up with gun barrels going into geometry.

To check how easy this was to use, I did every gun on the Tirpitz and timed myself. 8 minutes 22 seconds. No bad.

I also added a mouse sensitivity setting for the HIM viewer, and the option to focus the camera on a particular mesh part as requested.

This is all part of my Entity Component System research for the flight sim.

The idea is I create a tool that let's anyone add objects to my sim.  No java coding required.

To illustrate how it will work, let's consider an AA gun.

Boot up the tool and create a new file.

Drag a "GameObjectResource" from the menu and drop it into the main view. 
      The game object resource is the thing that holds all the information about the object. It requires a single field of bespoke information which will be displayed in an input window on the right.
      That is the name of the object. Fill that in and the object exists, though at the moment it is invisible and does nothing.

Drag an "AvailabilityResource" from the menu into the main window, connect it to the GameObjectResource.
      This one has a bunch of field to fill in. Nation, start and end date, etc.

Drag a "HIMMeshResource" into the main view and connect it.
      Point this resource at the HIM file. We now have something to display, but where do we display it?

Drag a "GameObjectTransformResource" into the tool and connect it to both the GameObjectResource and the HIMResource.
      This places the object in the world and will be the thing modified by the map editor.

Drag a "AAGunAnimatorResource" into the world and connect it to the GameObjectResource.
      Now we know it is an AA gun. We can now add the values you tested in the mod tool into this resource so we know how to animate it.

Drag a "AAGunResource" into the world and connect it to the GameObjectResource
     This sets the caliber of the gun.

Drag a "DamageReceiverResource" to the world and connect it up.
     This let's you setup how much damage it can take and so on.


That's it.

You have now created a fully functioning, animated AA gun object which will be added to the game the next time you run it.

Sound easy?



Title: Re: Weekly progress report
Post by: just champi on December 14, 2015, 03:04:56 PM
Sounds AMAZING!  :)
Thanks for all the work you are putting into this, mate, you talk about things we could hardly imagine, but then you just make it happen...  o_O
Title: Re: Weekly progress report
Post by: Pursuivant on January 21, 2016, 02:31:34 PM
Remember this will be faded in by sidereal time, so during the day it will be invisible. In the middle of the night it will be brighter, but modified by the atmosphere.

Something that might be easy to do, or really hard, is have "light pollution" from the ground affect celestial objects. For example, in a dark sky clouds appear as dark patches against the stars and even the faintest stars are visible. In a badly light polluted urban area, clouds glow with reflected light and all but the brightest stars are invisible.

For flight simming, light pollution has two effects. First, it affects your ability to use celestial navigation, which was occasionally used during WW2. Second, big fires or searchlights will light up clouds (or smoke clouds), both illuminating the ground below and silhouetting passing aircraft. That aids bombers, and as well as flak and intercepting fighters.

The equation for light scattering over distance is simple, and there are simple categories to determine degree of light pollution. But, since it's a lighting effect it might make unacceptable demands on computing power.
Title: Re: Weekly progress report
Post by: Stainless on February 07, 2016, 12:08:14 PM
Disappointing day.

I decided I needed to test my prototype terrain renderer, and it's got horrible artifacts. It's fast as feck, but I'm not happy with the display.


(http://s12.postimg.cc/dlow9sfvh/terrain_test.jpg) (http://postimg.cc/image/f0qgyigyh/full/)
Title: Re: Weekly progress report
Post by: Oscarito on February 07, 2016, 12:33:43 PM
With the excepting of those grooves, the terrain looks very good!
Loved the bucolic aspect of the roads... :)
Title: Re: Weekly progress report
Post by: hello on February 08, 2016, 02:18:03 AM
Yeah, that looks really good, especially far away from the POV! Are those mountains in the background really generated by the renderer too? The artifacts up close do need some smooth lovin' but apart from that: WOW!
Title: Re: Weekly progress report
Post by: DarkBlueBoy on February 08, 2016, 02:25:57 AM
Very impressive Stainless.
Title: Re: Weekly progress report
Post by: Stainless on February 09, 2016, 02:31:08 AM
I think I may be looking at this.

I don't know if it can be made freeware yet, but it's worth a look

http://www.gamesindustry.biz/articles/2016-02-09-amazon-launches-free-aaa-game-engine (http://www.gamesindustry.biz/articles/2016-02-09-amazon-launches-free-aaa-game-engine)
Title: Re: Weekly progress report
Post by: Stainless on February 21, 2016, 06:42:21 AM
Interesting week.

I'm back working on the mod tool, but I also had some news at work.

The bad news is I have been made head programmer on the project I am working on. Which means I will be working on it until it is shipped and signed off. Bummer.

The good news is that I will be moving onto the unreal engine.

So that means I will be able to move my development for the flight sim to Unreal and use the skills I learn at work to speed up development.

So good and bad news.
Title: Re: Weekly progress report
Post by: Nonsenseonpaper on February 21, 2016, 08:27:07 PM
WOW Stainless Unreal engine that is absolutely amazing this flight sim will look better than most out there. Keep up the good work its getting more promising every week.
Title: Re: Weekly progress report
Post by: hello on February 22, 2016, 05:38:52 AM
Congratulations! ... huhh not so good ?   :(  :-|

Lets hope at least some of those commutes an still be spend coding :)
Title: Re: Weekly progress report
Post by: Stainless on February 26, 2016, 02:34:38 AM
After using a free library to display the HIM structure I realised I had no choice but to write my own rendering library, which is going well.


(http://s22.postimg.cc/fy3bwguu9/Gui_Test_Snapshot.jpg) (http://postimg.cc/image/5b9ir1mot/full/)

You have the root node which is the name of the aircraft extracted from the HIM path.

Then I create a node for each record in the HIM file. Damage meshes are included in the parent node to make the display easier to read.

Hidden nodes are displayed in red as I often see modders leave in meshes that aren't used in game. This is bad as it consumes games resources.

You can drag each node around, scale and pan the display, etc.

Next step is to allow you to double click on a node to get a similar display of all the details of a node.  Nodes for actual meshes, damage meshes, LOD's, hooks etc.

This should make it easy to navigate and understand.

Also a hell of a lot easier to see bugs.

Title: Re: Weekly progress report
Post by: Stainless on February 27, 2016, 08:25:00 AM
This is what you get when you double click on a node.


(http://s24.postimg.cc/htsonq5ad/Gui_Test_Snapshot.jpg) (http://postimg.cc/image/iw2v69o3l/full/)

You can see instantly you have three LOD's and a bunch of collision meshes

Now for animations


Title: Re: Weekly progress report
Post by: Stainless on February 27, 2016, 08:51:56 AM
This is an example with an animation


(http://s12.postimg.cc/lei857025/Gui_Test_Snapshot.jpg) (http://postimage.org/)
Title: Re: Weekly progress report
Post by: SAS~Ghost129er on February 27, 2016, 12:30:03 PM
This is perhaps one of the things I look most forward to. Thanks for the updates and progress.  8)
Title: Re: Weekly progress report
Post by: Stainless on February 28, 2016, 03:41:22 AM
Forgot damage meshes


(http://s14.postimg.cc/rafqmhsz5/Gui_Test_Snapshot.jpg) (http://postimage.org/)
Title: Re: Weekly progress report
Post by: Stainless on March 03, 2016, 05:42:37 AM
Adding some automatic layouts you can switch between.

Balloon tree.


(http://s10.postimg.cc/cjzatu8ah/Gui_Test_Snapshot_131013832091385761.jpg) (http://postimg.cc/image/c77wnnq0l/full/)


Basic tree


(http://s24.postimg.cc/ggpebfyo5/Gui_Test_Snapshot_131013833960216892.jpg) (http://postimg.cc/image/njx9r243l/full/)

Don't work very well with a full HIM so going to add some more until one works well.

Title: Re: Weekly progress report
Post by: Stainless on May 16, 2016, 02:35:43 AM
Lost a lot of time what with several events all happening  at once.

I had to get alpha submission out at work, I got ill, and my son got married, So I have been busy.

I have made some progress though. All on my engine simulation.

I now have an app that let's you design jet engines.

You enter a load of settings extracted from public data and get a simulation of any engine.

I currently handle turbojets, turbofans, afterburners, and ram jet's.

The tool then creates a image and shows you the air flow. (animated)

Here is a turbofan.

(http://s32.postimg.cc/3w5roqb9x/CF6.jpg) (http://postimg.cc/image/3w5roqb9t/full/)

A turbo jet

(http://s32.postimg.cc/m8thwtfh1/J85_operation.jpg) (http://postimg.cc/image/yaovqyopd/full/)

Afterburner

(http://s32.postimg.cc/5e1sdw9lh/f100.jpg) (http://postimg.cc/image/m1tage4cx/full/)

Ram jet

(http://s32.postimg.cc/6ly3p2t91/ramjet.jpg) (http://postimg.cc/image/oor6gap3l/full/)

You can then run some standard tests and get graphs back.

CF6

(http://s32.postimg.cc/cel6sxlzp/CF6_power_graph.jpg) (http://postimg.cc/image/monls6bv5/full/)

J85

(http://s32.postimg.cc/a0gqol5lh/J85_speed.jpg) (http://postimg.cc/image/6tm74yl5d/full/)

F100

(http://s32.postimg.cc/bikkj43v9/f100_power_v_speed.jpg) (http://postimg.cc/image/kdletmsnl/full/)

Ram jet

(http://s32.postimg.cc/5qyp0kf4l/ramjet_speed.jpg) (http://postimg.cc/image/d6xymd2tt/full/)


You can tweak all the parameters in the gui

(http://s32.postimg.cc/x59oudf2t/jet_editor_details_1.jpg) (http://postimage.org/)


At the moment I have to sort out the crap atmospheric model then I can publish it and give you some java code to use the simulated engine.

 

(http://s32.postimg.cc/g27vp58r9/J85_altititude.jpg) (http://postimg.cc/image/5s5gpwivl/full/)
Title: Re: Weekly progress report
Post by: Mick on May 16, 2016, 03:19:19 AM
At the moment I have to sort out the crap atmospheric model then I can publish it and give you some java code to use the simulated engine.

Don't know for sure what you mean here, Stainless (talking about your model or the game's one), but it is a well known fact that IL2 first being a tribute to the Russian low altitude plane that bears the name of the "sim", the atmospheric model of the game is very far from being convincing, say above 6000 m ...  ;)
Title: Re: Weekly progress report
Post by: Stainless on May 17, 2016, 02:38:15 AM
Well In this tool it appears that a jet engine does not lose thrust when the air gets thin..... but wrong really.
Title: Re: Weekly progress report
Post by: Mick on May 17, 2016, 02:54:55 AM
... and also, it is the model of a ... prop ... that the game in fact uses to model jets behaviour ...  8)
Title: Re: Weekly progress report
Post by: Stainless on May 17, 2016, 06:16:30 AM
Yes that's one thing I really want to change.

Shouldn't be hard to insert good java code to replace the hacked system we have in place at the moment.
Title: Re: Weekly progress report
Post by: Koty on May 28, 2016, 02:53:48 PM
hmm... now - is it able to do:
coaxial jet (R-11/13/25 style)
partial ramjet (R-15 style)
Title: Re: Weekly progress report
Post by: Stainless on May 30, 2016, 02:58:01 PM
It's modular so, yes I suppose I can add them.
Title: Re: Weekly progress report
Post by: Pursuivant on June 30, 2016, 10:48:55 PM
Admittedly, it's early days yet, but please consider more accurate damage models for aircraft.

Currently, IL2's system for figuring damage isn't as realistic as it could be. In particular, the way that IL2 models bullet hits to fuel tanks is somewhat incorrect. (Tanks are assumed to be entirely full of fuel regardless of fuel state. Fuel tank hits are assumed to be at the bottom of the tank. Bullets aren't slowed by punching through liquid fuel. CO2-based fire suppression systems aren't properly modeled. Self-sealing fuel tanks' ability to prevent fires and leaks is underestimated.)

IL2 doesn't model hits to electrical systems, hydraulics, radios/avionics, wheels (no flat tires or explosive blow-outs), fuel transfer systems, oxygen systems, engine boost systems, or turbochargers/superchargers. It doesn't always model hits to oil, hydraulic fluid, and coolant systems adequately. It simplifies hits to guns and ammunition, and to air crew.
Title: Re: Weekly progress report
Post by: Stainless on August 05, 2016, 03:24:33 AM
Sorry I haven't been updating this thread, I have been terminally busy with real life.

However I can show you a few things.

I've been working on terrain and have maps mostly working.


(https://s31.postimg.cc/y2pudh58b/roads_1.png) (https://postimg.cc/image/uj3wno2if/)

Still have some issues with converting the point lists for the roads into splines I can use in game though

(https://s31.postimg.cc/bif52079n/roads_3.png) (https://postimg.cc/image/54q1yr2dj/)

(https://s32.postimg.cc/61c7vqmfp/roads_4.png) (https://postimg.cc/image/q8pno1jwx/)

I've also done a quick test of unreal to see what it is like. Importing meshes is not trivial but can be done.

(https://s32.postimg.cc/juu02uko5/UE4_1.png) (https://postimg.cc/image/flpa0ohep/)

Lighting and terrain is a bit disappointing, but at least I have source code so I can improve it myself

(https://s32.postimg.cc/svb06d3lh/UE4_2.png) (https://postimg.cc/image/afqj8ypgx/)

So I am still working guys.


Title: Re: Weekly progress report
Post by: Dreamk on August 05, 2016, 06:12:34 AM
Stainless this is really great! I know I sound greedy but could you upload an update of the publish_reach.7z that includes the possibility of exporting animations? :)

Title: Re: Weekly progress report
Post by: Uufflakke on August 05, 2016, 06:14:49 AM
Sorry for nitpicking  :-[ but:

Terheuzen = Terneuzen
S-Hertogenbosch = 's-Hertogenbosch
Zlerikzee = Zierikzee
Gilze Rijen = Gilze-Rijen (the cities are Gilze en Rijen, the airbase is named Gilze-Rijen)
River Rhein = River Rijn (Rhein is German, Rijn is Dutch spelling)


Maybe I missed it in this thread but I still have no clue what the timeframe is of this sim and what area will be covered?
Northwest Europe, the Channel?
And do you have any idea when it will be about finished for testing?  :)
Title: Re: Weekly progress report
Post by: Stainless on August 05, 2016, 07:56:46 AM
The map is the western front 1940 map hosted here, all the data is straight out of the map pack.

This is so you can use all the maps you have created for IL2 in this game as well.

If the spelling etc is wrong, then it's wrong in the map pack here and you should talk to the guys who did all the hard work and put the maps together.

I have no idea when it will get finished enough for even the most basic of testing. It's a hobby project and real life gets in the way.

I will come back to the mod tool soon, at the moment I am in the middle of trying to get some very basic systems in place for the game.
Title: Re: Weekly progress report
Post by: Ibis on August 05, 2016, 07:53:55 PM
 Thank you for your efforts Stainless.
  cheers
Title: Re: Weekly progress report
Post by: Koty on August 18, 2016, 07:14:27 AM
Admittedly, it's early days yet, but please consider more accurate damage models for aircraft.


not only that, amunition as such is rather simplified - generally, every bullet acts exactly the same. Thus there is no AP or HE round. That would be nice to see.
Title: Re: Weekly progress report
Post by: Stainless on August 18, 2016, 07:35:28 AM
Has some progress this week.

I've been looking for a good landscape rendering technique and experimenting with many of them.

This week I tried streaming CDLOD and I'm impressed.

I converted the western front 1940 map into streaming sections and wrote a very basic terrain renderer.

What I wanted was.

1) Speed

   The basic terrain render has to be bloody fast. The sections near to the player have to be pretty, which means I need a fast basis to work on.
   No matter the altitude, and I tested from 0 - 40,000 feet, the frame rate was 300+ fps

2) Size

   The streamed data came to about 35 meg, tiny.

3) Curved earth

   Worked first time



It doesn't look pretty as all I did was paint the map file over the top as a texture, and there is a hell of a lot of work to do to make it pretty, but I have at least found a suitable technique.
Title: Re: Weekly progress report
Post by: DarkBlueBoy on August 18, 2016, 08:10:30 AM
Great stuff Stainless!
Title: Re: Weekly progress report
Post by: Pursuivant on August 29, 2016, 03:41:28 AM
Admittedly, it's early days yet, but please consider more accurate damage models for aircraft.


not only that, amunition as such is rather simplified - generally, every bullet acts exactly the same. Thus there is no AP or HE round. That would be nice to see.

Actually, ammo does distinguish between different types. But, you're right that .50 caliber HE doesn't have any particular explosive effect. (But, the US didn't use .50 caliber HE because the determined that it wasn't that effective compared to API).

Possibly, 12.7mm HE ammo has too powerful an effect. Certainly, there is a "break on explosion" effect which means that 12.7mm HE ammo will break wings on certain planes while .50 caliber (non-HE) will not. That's unrealistic, but it's more closely related to poor quality damage models than actual bullet performance.
Title: Re: Weekly progress report
Post by: Stainless on October 12, 2016, 02:47:35 PM
Sorry I haven't updated for a while.

Been very busy.

Two games I worked on have gone public.

http://www.supermassivegames.com/games/tumble-vr (http://www.supermassivegames.com/games/tumble-vr)

and

http://www.supermassivegames.com/games/until-dawn-rush-of-blood (http://www.supermassivegames.com/games/until-dawn-rush-of-blood)

Also I have been offered a new job. It's with tobii http://www.tobii.com/ (http://www.tobii.com/) and involves me travelling all over the world helping games companies getting eye tracking into their games.

The salary is about three times what I am currently on, and I'm not cheap already  :)

I'm still working on the flight sim, and I've even done some improvements to the IL2 modtool, but I will talk about all that later.

Cheers guys.


Title: Re: Weekly progress report
Post by: Ibis on October 12, 2016, 10:14:39 PM
  The very best of luck in your endeavours Stainless.
Title: Re: Weekly progress report
Post by: DarkBlueBoy on February 02, 2017, 01:48:54 AM
Hi Stainless! I just wondered (like many I am sure) if there was anything to report on your wonderful endeavour? Please don't see this as one of those pesky "more pics" type demands! :) All the best and hope your new job is working out well for you! :)
Title: Re: Weekly progress report
Post by: Stainless on February 02, 2017, 02:02:47 AM
My new job has taken most of my time, but I am still working on bits and pieces.

I have started collating large amounts of data on air force strengths, in the sort of detail I need. So not just they had X aircraft of type Y.

I have started a database which has every scrap of data available in it.

Commanding officers, pilots, known combats, airfields, everything.

The tool I have written to do this outputs a HTML website as well as source code. So at some stage I will publish the data for all of you to use.

I've also got heavily into Amazon Lumberyard. Even had a meeting with JC Connors who is "the man" when it comes to Lumberyard.

So I am bringing chunks of the code I have already written into Lumberyard so I can start using that as a renderer.

So in short, still working, but not a lot to show.
Title: Re: Weekly progress report
Post by: Ibis on February 02, 2017, 02:58:07 AM
 So very glad to see you are still motivated to continue
this project.
 all the best,
    Ibis
Title: Re: Weekly progress report
Post by: Pursuivant on February 07, 2017, 10:36:20 PM
I have started collating large amounts of data on air force strengths, in the sort of detail I need. So not just they had X aircraft of type Y.

Not to be a jerk, but there are plenty of airplane geeks who can get you the sort of detailed historical info you've described, and not so many people who are experienced professional flight sim coders.

Don't be afraid to ask for help with the "fluff" (historical details and ambience) and with the geeky research bits.
Title: Re: Weekly progress report
Post by: DarkBlueBoy on February 08, 2017, 01:54:34 AM
Thanks for the update Stainless. It is really great news that despite you being fully busy in real life you are still working on this. Really appreciate it.
Title: Re: Weekly progress report
Post by: Stainless on February 08, 2017, 02:06:58 AM
 :D

I have mate, I have.

If I can give real specific questions, then people really do help, and I am very grateful.

However I need a large amount of well structured data, and it's the structure that's key.

For example I asked about air force strengths at the start of the battle of Britain and I got a load of really good web links, but they are web links.

To get them into a game, they need a lot of work. I need to extract the hard data from the HTML and get it into code.

And because I need the data to be as small as it can be in the game, that means a lot of background work.

Say I know that the Luftwaffe had a squadron of Me109b's and was based at Cannes. I know the number of serviceable aircraft and the number of available pilots.

What I need to do for the game is....


Each of those will have a whole load of data attached to it.

Airfield

Squadron

And so on.

Then I can create a record for the deployment.

Which will be something like this.

Code: [Select]
struct Deployment
{
     uint  Airfield;
     uint  Start;
     uint  End;
     uint  Aircraft;
     uint  Servicable;
     uint  Damaged;
     uint  Pilots;
     uint  Injured;
};

Then, and only then, does the data become really useful.

Now if any of you are willing to help create something like this, man would I be happy.  ;)


Title: Re: Weekly progress report
Post by: hello on February 10, 2017, 03:40:25 AM
Hi there Stainless, any change of a progress report of some sort?
I have developed a habit of perusing this thread and fantasizing about what might be(come) possible.
Please help out this poor addict ;)
Best regards
Title: Re: Weekly progress report
Post by: Stainless on March 01, 2017, 05:32:40 AM
I am still working, at the moment I am spending money  >:(

I have just bought a load of books detailing RAF operations during the battle of Britain and I am in the process of converting the data into something useful.

Boring work, but at least it's progress.
Title: Re: Weekly progress report
Post by: hello on March 01, 2017, 12:01:52 PM
Good to hear and thanks for your efforts! Keeps this addict happy for a while :)
Title: Re: Weekly progress report
Post by: Cheyenne on March 19, 2017, 10:54:06 PM
Stainless here is a link to the 8th Air Force, it has all most every thing you need if you are building air fields for England.
It gives the names of the fields and most of the location and how the air fields looked, and what groups were assign there.
Hopes this helps you.  http://8thafhs.com/
Also have more infro on the Italy bases used by the 15th USAAF
Title: Re: Weekly progress report
Post by: Kopfdorfer on March 20, 2017, 07:01:44 AM
Hi Stainless,

                   I am aware of your project , though not following your progress regularly.
                   Concerning your data search , there is a site that provides a great deal of info
                   you seek in a manner that would make a significant amount of the data collection ,
                   at least in one place.
                   The site is called "History of War" , and I have found its data to be quite dependable
                   insofar as I have investigated.
                   To use it in the simplest manner , Google the Squadron you want info on ,
                   say 242 Sqdn RAF.
                   If you examine the links listed by Google you will find this one :
                   
                  http://www.historyofwar.org/air/units/RAF/242_wwII.html

                  If you know the number of the squadrons you are researching , no need to Google again ,
                  just change the Sqdn number in the address bar.
               
                  The nice thing about this site , is that is usually uses a bibliography for the source materiel
                  so you can verify it.

                  Good Luck

                  Kopfdorfer
Title: Re: Weekly progress report
Post by: solotk on March 20, 2017, 10:14:49 AM
Stainless, do you have a copy of 'RAF Squadrons' by Jefford?

https://www.amazon.co.uk/RAF-Squadrons-Comprehensive-Equipment-Antecedents/dp/1840371412

It's absolute Gold. Also anything Chris Shores has written, always comprehensive and detailed in war diary form.

Lastly, would it be easier for you to make up a template in excel form, so the information required is exactly as you need it submitted? I'd ask Ross McNeill of RAF  Commands for help there, as his group know everything about RAF operations down to it seems the atomic level! I'd ask Ross if maybe some sort of collaboration project was possible, where his people can contribute to populating the excel templates, and have use and access to the completed templates too. I also know they're working on a highly detailed airfield database project, listing every airfield used by the RAF, and the information will be suitable for modellers. I'd also speak to the 6 o'clock high guys about the same. Don't forget the very excellent forgotten airfields project by Ronald V, a very nice guy who's already done a load of legwork on airfields, including vintage imagery, layouts etc http://www.forgottenairfields.com/

Hope this helps,

Best regards

solotk
Title: Re: Weekly progress report
Post by: Stainless on March 21, 2017, 05:15:08 AM
That sounds interesting.

The only problem is I never know exactly what I need till I write the code, but I'm sure we can work around that.
Title: Re: Weekly progress report
Post by: Stainless on August 22, 2017, 02:50:11 AM
Well some progress this week, I finally had some time to just sit down and code.

For various reasons I am writing the MFD code for AN/APG – 68 radar, basically I am still working on doing a standalone MFD based on a Raspberry PI with a small display.

I got to the point where I really needed an input device, so I shelled out for a X56 Rhino HOTAS flight stick and throttle.

Amazon were amazing and delivered early the next morning.

I eagerly connected everything up and tested it all, works perfectly. (Little annoyed with the spring on the joystick, but I'm sure I can solve that issue).

So I then wanted to write the code to support it..... which is where everything turned to brown and smelly.

I first went to DirectInput. Does everything I want, simple interface, perfect.  DEPRECATED.

Well Microsoft must have replaced it with something, ahh  XInput. Great.  Nope ...  ONLY SUPPORTS XBOX GAMEPADS

Shit. A bit more digging and I found Game.Windows.Input.   Perfect....   ONLY SUPPORTED IN UWP

So..... no Windows API's for joysticks anymore.  WTF!

Dug around some more and realised I would have to nuke it from orbit and use HID (Human Interface Device Api ). Very low level and ancient. (Has it's origins in Win32).

A full day of coding later I have a HID layer working. HID just returns an array of bytes. So I then have to work out what all those 0's and 1's mean.

After several hours of experimentation, I have mapped the entire HID report and have working code.

So I wrote a test app to confirm it all works in game. And it does.... sort of.


(https://s3.postimg.cc/y593cwdz7/Inputtest.png) (https://postimg.cc/image/89pctpc5b/)

I am starting the update of the HID device on the update thread and reading it in the render thread. So I expected about 50ms of latency. Nope. At first it was over 1000ms. So I dug around in the code and found a mistake, but it's still not great. I am guessing I have around 300ms latency. Not good enough, but will do for now as I am sick of messing around with it.


Now I just need to add it into this code.


(https://s3.postimg.cc/bhtu6qyf7/mfdtest.png) (https://postimg.cc/image/afjno7flr/)


Sigh.

Title: Re: Weekly progress report
Post by: Stainless on August 24, 2017, 02:09:04 AM
Well the work this week has caused me to re-think some things.

Since the whole game is open source, I was planning to just have a C# class for each aircraft and give you examples and tutorials to help you make your own.

But I was getting in a mess trying to get the various parts of the aircraft to talk to each other (radar has to give data to the MFD, MFD has to give user inputs to the radar, and things like that)

So I have decided to go with an entity component system, and give you an editor.

So to create a new aircraft you boot up the editor, grab a bunch of components from the menu and connect them up. Save it. Job done.

I know that the number of components for a well simulated aircraft will be quite large, but hey at least you won't have to re-compile the game every time you want to test it.

To give you an idea of what I mean, with a blank screen in front of you you would start by adding a GameObjectTransform and connecting that to the root.

A game object transform is required to place the object in the world. It's just a matrix under the hood.

Then you would place a HIMComponent in the world and connect it to the root and the game object transform. So you now have your mesh and it is placed in the world.

Then you would add an AircraftPhysicsComponent to the scene and connect it to the game object transform and the root and the HIM. Now it has collision and flight capability.

Note that all connections are LABELLED and type checked. So you cannot accidentally connect the wrong things up and you cannot save the work to game with an empty connection that is required to be connected.

(You will be able to save unfinished work to a temporary workspace and come back to it).

After that it is all the details. Adding components to animate the mesh, adding an engine, flight characteristics, cockpit, etc.

Still a lot of work, but I think you will be happier doing it this way than having to write C#.

Let me know what you think.

Title: Re: Weekly progress report
Post by: SAS~Storebror on August 24, 2017, 02:17:19 AM
That sounds reasonable.
Few people have the ability and the will to dive into C# coding - even if it looks simple to you and me.
Providing a framework that sets up a predefined path to get an object into the game therefore definitely makes sense to me.
If it makes life easier on the Interface side: Even better 8)

Best regards - Mike
Title: Re: Weekly progress report
Post by: Stainless on August 24, 2017, 07:45:39 AM
I've actually started the code and I realised just how powerful this is.

Not just for aircraft anymore, you can create any game object with it.

Buildings, artillery, weapons, all can be added using the same editor.

Starting to think this was "a good idea".

Title: Re: Weekly progress report
Post by: Stainless on September 04, 2017, 04:39:51 AM
Well the editor is coming together nicely.

It has some horrible windows user interface issues I will have to find a work around for like when you drag and drop from a treeview you HAVE to select the treenode BEFORE you drag it.

Shit windows code there, but it basically works.

I just need to create hundreds of game components now......  o_O


(https://s26.postimg.cc/pbewmvfvt/gameobjecteditor.png) (https://postimg.cc/image/njlxrywit/)
Title: Re: Weekly progress report
Post by: Pursuivant on September 04, 2017, 06:13:13 AM
I just need to create hundreds of game components now......  o_O

Or, just create broad classes for game components, code the essentials needed for testing and development yourself, and let other people develop the less critical/more obscure stuff.
Title: Re: Weekly progress report
Post by: Stainless on September 19, 2017, 02:09:32 AM
At the moment I am working on radar so I can get proper radar returns on the MFD.

I have written a tool to generate the RadarCrossSectionComponent data you will need in game.

You select the base shape from the combo box (currently airframe, sphere, and cylinder), then you modify the four numeric values (Nose,Tail,LeftBeam,RightBeam) to get a shape you are happy with.

Finally you set the scalar value. This represents how stealthy the aircraft is and it's surprisingly easy to get values for this on the net.

Save it, add a RadarCrossSectionComponent to the aircraft and link it to the saved file.

You need one of these on all game objects that need to be visible to any type of radar. In the game you add up all the contributions from the airframe and all external stores to get a radar return when painted.


(https://s26.postimg.cc/4xzmlq21l/airframe.png) (https://postimg.cc/image/6pslgmled/)



(https://s26.postimg.cc/dixjqn1ll/cylinder.png) (https://postimg.cc/image/ova58faad/)



(https://s26.postimg.cc/5rgts2xg9/sphere.png) (https://postimg.cc/image/8ljz5izmd/)


I can add lots of new base shapes as I need them.

Title: Re: Weekly progress report
Post by: Pursuivant on September 22, 2017, 01:59:35 AM
Very cool that you're integrating avionics and similar things into the game very early on rather than leaving them as an afterthought. That's been a failing of other flight sims and your modeling looks like it could be a really powerful development tool. The fact that most of the technical stuff is hidden behind a GUI makes it really easy for those with limited coding skills to add content.

Presumably, you could use something similar for guided missiles, assigning a maximum lock-on range, probability of lock-on, and maximum "angle off" firing angles using a similar GUI to that created for radar.

Radio, IFF and location transponders, and navigation systems could also use the same GUI to define frequency/frequencies, "cone of effect" and range with signal strength falling off with distance/proximity to the edge of the performance "envelope". For example, for a manually-turned WW2 era RDF loop, you could give the the loop a roughly oval shape for range/strength of signal such that the signal becomes stronger when the RDF loop is turned in the direction of a radio signal on a specific frequency. Bind keys to allow the loop to be turned right/left and the player can see signal strength getting stronger or weaker as they turn the loop.

It might also be possible to integrate ECM/ECCM and anti-missile defenses into the game by assigning a frequency (or frequency ranges) to radar or similar devices. Active ECM devices could be created by using the same GUI as for radar, but with "negative" effects on lock-on and target ID when the countermeasures device is "overlaid" with the graphic for the radar. For example, if defensive flares have a maximum X% chance of breaking a lock-on by an IR missile, you compare overlap between the two graphics and then reduce chance of lock-on based on distance from the missile to the flare up to a maximum possibility of X%.

Similar variations on the radar pattern GUI could be used to determine effects of terrain on radio/radar signals and behavior of sonar, MADD, or magnetic minesweeping rings for floating or underwater targets.
Title: Re: Weekly progress report
Post by: Stainless on September 25, 2017, 05:15:03 AM
I'm trying to avoid "percentage chances".

So in the case you mentioned about flares, I would model how the seeker head is designed to work and let the physics define what happens rather than random numbers.

This has the happy side affect that good pilots live longer because they understand the systems in their aircraft and use them well.

I have just added the radar cross section component to the entity component system and later today I am hoping to modify the APG68 code to use it. At the moment it adds a target when it paints it regardless of situational parameters.

I already have the basics of ECM in, I will be looking at the in detail tomorrow (if work does not get in the way)
Title: Re: Weekly progress report
Post by: Stainless on September 26, 2017, 02:18:06 AM
Some of you may be wondering why I am working on esoteric's like the avionics.

There are two reasons.

1) I want to.

When you are doing a one man project like this you need to keep the enthusiasm going, so if somethings sets off the little grey cells you run with it.

2) Details

It is a lot easier to have information available when you need it than to realize you need it later and have to add it.

Plus, I really want to build a MFD using a raspberry PI and link it to IL2     :D
Title: Re: Weekly progress report
Post by: DarkBlueBoy on September 28, 2017, 02:46:10 AM
Your project, your rules! :D

Love the idea of using a Pi!!
Title: Re: Weekly progress report
Post by: Pursuivant on October 02, 2017, 11:44:29 AM
I'm trying to avoid "percentage chances".

So in the case you mentioned about flares, I would model how the seeker head is designed to work and let the physics define what happens rather than random numbers.

I agree that for things that the player can detect, or which directly affect mission success, random functions suck.

In some cases, just using the proper physics equations might be simpler and less of a performance hit than look-up tables, random number generators, hit point calculators, etc. In any case, it's more elegant.

The only reason why I suggested random numbers for some systems is that full data might not be available for all systems, it might not be possible to model certain systems with sufficient precision to allow physics models to fully apply (for example, rather than figuring out rate of fuel loss based on tank geometry, bullet size and tumble, tank material, G-forces, aircraft attitude, etc. you could just "hand wave" and assume that a fuel tank will lose rnd * x% of its fuel capacity per second until it slows and stops after rnd * y seconds OR loses rnd x z% of maximum fuel tank volume).

Most importantly, a heck of a lot of what happens in combat is random. Good combat pilots can take full advantage of their plane, environment, and tactical situation, but the law of averages is always waiting to get them. E.g., Bullet tumbles and shatters and it sends fragments of itself and the surrounding material into the engine intake causing progressive engine performance loss due to cascading FOD. Pilot punches out and becomes POW. Bullet doesn't tumble, stays intact, and punches through aluminum/titanium/graphite composite just outside the engine intake with minimal damage. Pilot returns to base blissfully unaware of the angels on his shoulders until his crew chief chews him out for putting a hole in HIS airplane. As Reichsmarschall Manfred Von Richtoften said in an alternate universe, "I'd rather be lucky than good."
Title: Re: Weekly progress report
Post by: Stainless on October 11, 2017, 02:18:33 AM
Yes there will be randomness where randomness is needed, just not everywhere.

I play a cricket game to relax and they have a problem with randomness. When batting you get user feedback in the form of three variables. Shot selection, footwork, and timing. These range from poor to ideal.

The problem is that you can get ideal on all three variables and still get out. You might not even make contact with the ball. This is because they have a skill system and the shot resolution takes bowler skill, batter skill, player input and a random number and combines them into a result. However they used really crap coding. So batting is crap. User input is secondary to randomness.

Anyway, I have had a full day to work on the game. I know. Miracle or what!

I have modified my IL2Modder to output in my own format and added most of the game components I need to display the mesh.

The work flow is ....

1) Load HIM in mod tool
2) Save HIM as GameObject
3) Copy directory produced to new game assets path.

You now have a stationary plane you can use in the world editor.

4) Edit the new game object in the editor and add animation, stores, weapons, physics....

You now have a plane you can fly

The tool creates all the GameComponents for you. So you have a MultiMeshComponent which you can think of as a HIM.

Connected to this is a LODGroupComponent with a load of LOD's, a HookGroupComponent with a bunch of hooks, and a CollisionMeshComponent.

In the directory you will have a bunch of binary files with all the real data, but you don't need to worry about those.

Any way. Good progress.




Title: Re: Weekly progress report
Post by: SAS~Storebror on October 11, 2017, 05:53:03 AM
Cheers Stainless!

I have had a full day to work on the game. I know. Miracle or what!
Happens to me from time to time.
As long as my boss thinks I'd be working for him, everything's fine 8)
Joking aside, one day the coffee break is 5 minutes, the other day 5 hours.
That's the good thing of being a programmer, you look the same whatever you do.

Best regards - Mike
Title: Re: Weekly progress report
Post by: Stainless on October 12, 2017, 07:50:08 AM
When I am not in some game studio in some remote part of the world, I work from home.

Comms is done by Slack and Skype or email, so as long as I respond to those in a timely manner, and the work gets done, no one needs to know how long the work takes  ;D

The trouble is I spend most of my time in foreign places, and the work I do at home (foveated rendering in VR with eye tracking) is very time consuming.

So the theory is fine even if the implementation is a bit ropey.

Title: Re: Weekly progress report
Post by: carsmaster on October 12, 2017, 08:09:03 AM
Some of you may be wondering why I am working on esoteric's like the avionics.
It is very good.
Thank you.
Title: Re: Weekly progress report
Post by: Pursuivant on October 13, 2017, 10:39:05 AM
The problem is that you can get ideal on all three variables and still get out. You might not even make contact with the ball. This is because they have a skill system and the shot resolution takes bowler skill, batter skill, player input and a random number and combines them into a result. However they used really crap coding. So batting is crap. User input is secondary to randomness.

Or the coders just imported an algorithm for batting/bowling from a baseball program where even the best hitters only hit the ball once out of every 3 times! :) In any case lazy coding which never got reality checked or playtested before it went out the door. Far too many otherwise great games have died unloved because of crap like that.
Title: Re: Weekly progress report
Post by: Stainless on October 18, 2017, 04:56:32 AM
Need some help.

Had some time to work on the radar again and added some more functionality.

I set up a test environment with a very tight formation of Mig27's in front of me and one straggler off to the side.

The radar actually manages to pick up all the aircraft, but at this range the formation looks like a single target. Nasty suprise for later.


(https://s1.postimg.cc/6fqclwaesv/RWS.png) (https://postimg.cc/image/8i659y8zu3/)

I then use the thumbstick on my X56 to bug the trailing target.

(https://s1.postimg.cc/93skafadu7/SAM.png) (https://postimg.cc/image/1thgzdisuj/)

The radar swaps to situational awareness mode. You can see the radar azimuth bars appear and the bugged target changes from a solid box to a target designator.

At the top of the screen you can see target aspect angle (7 degrees right), target heading (000) and target airspeed (400 knots). I think they are all correct.

My problem is my reference image is this.

(https://s1.postimg.cc/4sj9v8axsf/reference.png) (https://postimages.org/)

I have no idea what the last number is (-237)

I also don't know how the target altitude is displayed, which I am pretty sure must be.

Anybody able to shine some light on my problems?


Title: Re: Weekly progress report
Post by: Stainless on October 19, 2017, 07:27:28 AM
Found it, it's closure speed
Title: Re: Weekly progress report
Post by: ildifa on October 22, 2017, 04:40:51 PM
I also don't know how the target altitude is displayed, which I am pretty sure must be.

Hi! First of all, compliments on all the fantastic work you've done so far!

The target altitude is displayed just below the the bugged target, in thousands of feet
(https://s1.postimg.cc/9od0lu2fvz/reference.png) (https://postimages.org/)
Title: Re: Weekly progress report
Post by: Stainless on October 23, 2017, 05:41:00 AM
Ahh thanks, the document I am using as a reference sticks numbers on the images and then refers to them in the notes.

Thought it was another of those.
Title: Re: Weekly progress report
Post by: Stainless on October 30, 2017, 08:40:09 AM
Got the HUD started, not too bad.

And my code design made sure it was easy to do the repeaters.

(https://s1.postimg.cc/99so60jpdr/avionics_001.png) (https://postimg.cc/image/2a4eo47cjf/)
Title: Re: Weekly progress report
Post by: Stainless on November 23, 2017, 07:54:28 AM
It is really funny how things get done on a project like this.

I wanted to drop in a very simple flight model to help with debugging the radar code, so I needed to add an engine to my aircraft.

So I wrote an EngineComponent and linked it to a definition file so I could hook up the physics code that actually does all the engine calculations.

That was fine, but then I realised I needed a way of specifying which keys would map to which commands without having to edit game code.

So I added InputEventComponents and attached them to the EngineComponent. So I now have keys which can be remapped to external devices, but have default keyboard values which you define in the game object editor.

But I needed to check my engine code was working before I moved on. I was very annoyed to realise the MFD's don't have a page for engine management.

So I decided I could easily add sound effects so I could hear the engine start up.

So I added a sound effect manager, but that meant I had to have a way for you to change the sound effects attached to an engine without coding. Don't want an F16 sounding like a Fokker tri-plane.

So I added a sound effect pack system and linked that in as a parameter on an EngineComponent. So for an engine you create a standard set of wav files, put them in a directory and specify the directory in the game object editor on the EngineComponent.

Great. All works. You can now mod the engine on an aircraft without writing a single line of code.

So I tested it.

I found that the engine cranked forever. Debugged it and found that my fuel tanks were empty. So I filled them with fuel.

Debugged it again and found it cranked for about 1 second then started to spin up. When N2 got to the required level the engine ignited just as I expected.

The sound effect for EngineStart finished and the engine never transitioned to the running state. 

The first thing I did was add code to allow a sound effect to partially loop. So you specify a loop start and end position and it will play that section of the sound effect again and again.

Then I debugged why it was never going to the run state.

I hadn't advanced the throttle from 0 to idle as I was supposed to  :P

So now I have fully modable engines with sound effects and keyboard inputs.

At the moment I have just used one key for power management, and one key for the starter motor, but I can add more very simply.

Now since I have this in my mind, I'm going to add code to detect you flooding the combustion chamber with fuel before the engine starts up properly.

I suppose that one day I will put in the simple flight model, but at the moment I see engine fires and warning tones in my future.

Funny old world. ;D

Title: Re: Weekly progress report
Post by: Ibis on November 25, 2017, 05:10:40 AM
 Great stuff Stainless.
I regularly check to see if you have posted. I know nothing about coding
or for that matter modding but your work is fascinating, can't wait to
see something fly.
 Thanks you for all your effort.
  cheers,
   Ibis
Title: Re: Weekly progress report
Post by: Pursuivant on December 07, 2017, 08:58:31 AM
This is another great feature!

The ability to tweak engine performance could easily be adapted to model engine wear, with reduced performance and increased risk of failure if maintenance intervals are skipped. It can also be used to model progressive engine failure due to things like oil or coolant leaks. Additionally, it will easily allow upgrades or downgrades in engine performance based on fuel quality and octane ratings.

It will solve a lot of debates about aircraft performance since manufacturer's tests used highly tuned, new engines and tests of captured aircraft likely used aircraft with engines which weren't in such good condition resulting in different performance curves.

Finally, in a campaign mode, insufficient supplies or lack of ground crew can result in planes in a particular squadron having reduced engine performance and/or greater engine failure rates.
Title: Re: Weekly progress report
Post by: Stainless on January 12, 2018, 09:04:42 AM
I need an airport.

Normally a games company has about a dozen grizzled coders who create the engine and tools for the game.

They then have about 20 fresh faced games designers who use the tools to make the game do things.

They are supported by 70 weirdos who call themselves graphic artists.

I don't have any of that. Just me.

So I went to the data in FlightGear and looked at that. I quickly wrote a parser for the data and found they have 34074 airports in the database. So I wrote a browser to look at them.


(https://s13.postimg.cc/sd33sfaev/airports.png) (https://postimg.cc/image/oth62m7oz/)

The buttons at the bottom allow you to jump to a particular batch of ICAO codes. then you use the mouse wheel to scroll through them.

Clicking on any one of them gives you a brief summary of some of the information.


(https://s13.postimg.cc/dh4klcmav/data.png) (https://postimg.cc/image/3jtjsaeoz/)

So far I have handled parsing the signage data to create bitmaps.


(https://s13.postimg.cc/74pfazo87/signs.png) (https://postimg.cc/image/vl7l5goyr/)

Not perfect yet, but it occurred to me this might be useful for you guys. The bitmaps are in a slightly strange format, the magenta blocks indicate a change of side for the sign. So G<-29-11-> is the front of the sign and G ^ 11L-29R ^  is te back of the sign.

However they still might be useful to someone here.

Let me know if it is of use and I will upload it somewhere.

Now... onto the airport map.... much more fun....

Title: Re: Weekly progress report
Post by: Pursuivant on January 13, 2018, 03:15:15 PM
The Airport Data Browser/Parser app is a useful tool for any flight simmer interested in modern flight, not just historical combat flight sim fans. With a bit more work, it might be of interest to real pilots as well, possibly as payware.

For historical simmers, there could be a method of easily changing airport data by year/decade and quickly adding or removing airport scenery based on date. For example, you could take Berlin Tempelhoff from grass landing strip in 1920 to small 20s era airport, to Nazi showpiece in 1934, simulate bomb damage from 1942-45, then US occupation during the Berlin Airlift, and so on until its closure in 2008. Over time, navigation aids would be added or removed, landing strips opened, closed, or altered, and so forth.

In any case, there should be a method of easily adding and removing airports from the list of real-world airports. Not only does that allow for quick placement of fictional airports, it also allows creation of closed or temporary airfields, or creates the possibility of certain airfields being unavailable due to damage, enemy occupation, closed airspace, weather, etc.

Title: Re: Weekly progress report
Post by: Stainless on January 15, 2018, 02:01:22 AM
The final app will allow you to view the airport in 2D and 3D.

I need the 3D view as it will have an export button which saves the entire airport with lights, pavements, parking spaces, runway markings, signs etc as a 3D object you can edit in your favorite 3D editor.

For my game, I will need to add a date field to each airport. Can't have all the modern bells and whistles available in 1917 after all.

I am torn about what to do about the editor.

On the one hand you can use world editor from flightgear to create new airports, save them in a apt.dat file, then load them in this tool.

However that feels a little clunky.

On the other hand I don't want to spend the time writing an editor unless it has other uses than just my game.

Not sure yet, thoughts?

Title: Re: Weekly progress report
Post by: Pursuivant on January 15, 2018, 03:33:01 PM
As long as there is some method for fans to make edits to airport scenery and the airport database, that's sufficient.

An improved editor with all the bells and whistles seems like an excellent 3rd party project for sometime in the future.
Title: Re: Weekly progress report
Post by: Stainless on January 16, 2018, 03:05:17 AM
I like that idea  :)

Think that's a plan, but will it survive contact with the enemy?
Title: Re: Weekly progress report
Post by: Pursuivant on January 19, 2018, 04:43:04 PM
The "enemy" in your case is lack of time and manpower.

That means that you'll need to keep the project as "bare bones" as possible, keep notes on all the "nice to have" features that you don't have time to implement (including all my invitations towards feature creep), and make sure that the basic architecture of the program is easily "expandable," to allow easy updates and additions by yourself or by future assistants/fans.

Ideally, you'll create the broad outlines of a program which sufficiently "open architecture" and "generic" enough that it can eventually handle everything from 1890s wing-warping gliders to supersonic 21st century stealth military aircraft, but with provision for fans or developers to collectively "lock down" vital portions of the game (e.g., plane lists, flight and damage models) as needed to preserve the integrity of online play.

What's got me excited about you might be writing a ground-breaking "sandbox" flight sim, since you're building tools to give fans/less skilled developers the ability to add content to the game, or tweak its basic parameters, from the very start.
Title: Re: Weekly progress report
Post by: Unca-Fester on January 21, 2018, 10:54:36 AM

 I noticed that you're making an easy to use landscape/scenery modder as part of this new sim.  Have you thought of using Corine terrain and elevation mapping?  FlightGear uses Corine for all of the European Subcontinent and it's pretty brilliant.

  You notice this especially in the hillier parts like Eastern France, Switzerland/Austria and Northern Italy.  FlightGear uses TerraGear, a commandline/gui shell app ( depending on what OS you are using.) to generate the mesh that's rendered.  Problem is it tends to be made up of individual mesh objects as different land classes and there's a bit of an abrupt edge to the forests and cities.

  You can export out these terrain meshes using a little Blender Py. script to modify them, since FG uses a true spherical mesh for the world, each .1 degree by .1 degree mesh 'chunk' interlocks with it's neighbors and when you import/export you have to work with it based on it's local orientation.
Title: Re: Weekly progress report
Post by: Stainless on January 22, 2018, 02:36:35 AM
I've looked at it, but it has some massive problems.

What you end up with is little kind of round patches. Typically a dozen verts about a central point.

These are splattered around to form the entire terrain.

This makes it incredibly difficult to make these terrain splats into a consistent landscape. It works great for rough areas , but for low rolling hills you tend to end up with discontinuities.

 
(https://s9.postimg.cc/b37gr7itr/btg_test.png) (https://postimg.cc/image/u8aq0yxhn/)

This is a shot from my test app. Not easy to see from a still, but if you look at the water line you get an impression of what I am seeing.

I may use it as a base data server, but it needs a very different handling system to make it look as good as I want it to.


Hmmm don't know why but the image is not showing up.



(https://s9.postimg.cc/6u2qpg7z3/test2.jpg) (https://postimg.cc/image/s3qd0ao9n/)


Problem with postimg maybe?
Title: Re: Weekly progress report
Post by: Unca-Fester on January 22, 2018, 09:11:43 AM
yeah I know exactly what you're talking about.  So you can import .btg's?

 I made sim ride-able motorcycles for FlightGear a few years back, and one of the first courses I tried out was the Isle of Man TT course.   And with the roads being strips of triangles they would have all sorts of weird off camber slopes perpendicular to their length.   Especially, like you're saying, on otherwise flattish terrain.

  It is especially bad on arroyos and little valleys where the road has to pick up it's vertex cues from the landscape to either side. 

I will say there's few things in favor of FG's scenery, that there's no other sim, WWI era or otherwise, that has captured the look of the Somme Valley.    Most sims make the river as a snaking strip of water.

  It's not anywhere near that shape,  it's more of a series of hundreds of little oxbow lakes and U shaped wetlands joined by a small river, and it is accurately done in the Corine sourced mesh, it may be a bit angular in places, but from a distance it's unmistakable.
Title: Re: Weekly progress report
Post by: Stainless on January 23, 2018, 02:01:10 AM
BTG's are just one of the formats I can support, I need to make this as user friendly as possible.

It is one of the big problems in 3D for me. You get an engine or a tool that only supports one 3D file format. So you have to find converters.

This has a knock on effect to the whole tool chain. Suddenly, doing something that should be trivial becomes a nightmare.

You can see it in IL2. People struggling with plugins trying to get something they have spent many hours working on into the game.

When it comes to terrain data, I am struggling to find a really good data source. I have found lot's of satellite data and lot's of tools to work with them, but none of them are without problems.

At the moment I am working with a 10M resolution database for the gross scenery, mixed with data from google\bing\yandex\gaode\baidu when available.

But even those throw up errors. For example I grabbed maps for the UK and Europe in 10 degree of latitude\longitude chunks.

When I put them together I found they overlapped by several pixels. In my test it was about 25 miles of terrain got duplicated.

I have to make it spot on if modders are going to use it.

Title: Re: Weekly progress report
Post by: Pursuivant on January 25, 2018, 09:03:31 AM
I will say there's few things in favor of FG's scenery, that there's no other sim, WWI era or otherwise, that has captured the look of the Somme Valley.    Most sims make the river as a snaking strip of water.

I'm way out of my depth here, but my problems with flight sim terrain are, 1) the mapping algorithms are "one size fits all" rather than being scaled to the "density" of terrain features in a particular area or what you actually want to do with the map, 2) mapping algorithms prioritize relatively crude elevation data over other map features which can be much more important to gameplay.

Broad swaths of more or less accurate major natural terrain features are fine for high level flying, but for ground attack and "slow and low" flight, the "human terrain" and minor natural terrain features become more important than the mountains in the distance.

Can I land in that pasture without wrecking my plane? If so, can I avoid that line of telephone poles if I try to take off again? Is the ditch deep and wide enough that my plane will slide into it, rather than over it, when I belly land? Is the mud so deep in that bog that my plane will flip and break my neck if I accidentally make a wheels-down landing? Can I get a decent shot at that train hiding in the railway cut? Are the treelines on each side of that road far enough apart than I can land on the road or make a low-level strafing pass along its length without removing my wingtips?

I propose that, at least for maps of built-up or "subtle" terrain defined by minor shifts in elevation and closely-spaced, narrow, terrain features (e.g., treelines, hedgerows, or minor rivers), it is more logical to prioritize "linear" terrain like streams, roads, railway cuts, and property lines, and "point" features like ponds and town centers, over elevation. You make those features look and act like they're supposed to using algorithms (mostly simple fractals for natural features), and then you fill in the elevation information around them.

For example, imagine a simple map where you've got a railroad cutting straight through treeless steppe terrain linking two towns, with a road running next to the railroad which mostly follows the contour of the terrain. First, you define the railroad object, say that it can't be any wider than about 5 meters per line including embankments and that its slope can't be anything greater than ~2%. The roadway gets generated as a mathematical object which automatically creates cuts and embankments based on SRTM data.

For the road, you do something similar, but accept that you can have a greater slope before you must make cuts or embankments and that it can curve more sharply to follow the terrain. You generate it as another object which uses essentially the same processes as for the railroad. Anyone "driving" along the road will find that it "behaves" like it should.

For the towns, you place two or more base points on the map and "grow" the town's limits using a suitable fractal pattern. As long as there is solid ground, towns will grow organically, based on population, along roads and rivers, and will go around steep hills and woods before growing "into" them. Once you've got the "city limits" of each town, you can generate minor roads within it. Once you've got minor roads, you can generate property lines and then use a different algorithm to generate buildings and other features on the property. Tweak the algorithms slightly to get settlement patterns, property lines, and building patterns for different cultures and periods. Big rectangles and squares with widely spaced farmsteads for the American Midwest, centralized villages surrounded by long skinny farm fields for Eastern Europe, terraced hillside rice fields for Java.

Still other algorithms could be used to generate the shape of treelines, power grids, minor water features, drainage ditches, etc.

Once you've defined your hydrography, transport networks, settlement patterns, and major landmarks, only then do you use STRM 10m data to "fill in the gaps."

For wilderness areas, you can sort of go the opposite direction to generate minor but important objects. Start with the SRTM data, but assume that there will be significant height variation within each 10m based on the sort of terrain you're modeling. For example, for swampland that's 1m ASL on average, you could assume that you've actually got slow-moving streams every X meters (break out an algorithm for that) with +/-1 m random variations in the height of the terrain between them. The +1 m areas get generated as hummocks, the -1m areas get generated as water/rushes.

Finally, you could have "point centered" features which override SRTM data within the areas they cover. That way you can recreate historical coastlines and treelines, and add or remove anthropogenic features like towns or reservoirs based on time period.

The bad news is that datasets which map the sort of linear and point features I'm talking about are either propriety or don't exist. The good news is that terrain generation algorithms are open source, readily available, and fairly simple. The potentially good news is that you could scan or carefully photograph a paper roadmap (or, maybe even topographic maps or more abstract maps like maps of railroad networks) and use image recognition software to identify the meaning of the various "lines on the map." You could then overlay that data over 10m SRTM data to get more or less accurate maps for areas of interest. Using latitude and longitude coordinates for known "point features" you can accurately place SRTM maps without overlap.

Fans could create linear and point feature generation algorithms to expand the database of existing terrain types. Aditionally, they can import textures and digitize data from historical maps. This would quickly provide a decent database for modern populated areas as well as historical maps of areas of interest.

Perhaps this is all too "pie in the sky" to be workable, but it would represent a novel approach towards flight sim terrain generation. And, as long as the "bare bones" are in place, it might solve some problems.
Title: Re: Weekly progress report
Post by: Stainless on January 26, 2018, 02:19:45 AM
My plan is ....

1) Base database from the entire world created from mixed data sets.
        Mix of open source terrain databases and images

2) Procedural generation for terrain areas not hand detailed
        Not using fractals as they are too random, using physically based models. So rivers flow down hill, roads have pitch limits, rail tracks pitch limits, plants biospheres

3) Tools to detail areas freely available and simple to use
        Import map data from multiple sources, combine into detail textures which define roads, rail, rivers, forest, blah, blah


Title: Re: Weekly progress report
Post by: Stainless on January 31, 2018, 07:47:58 AM
Well the airport converter is coming along. Still a LOT of detailing to do, but I already have some nice results.

 Antwerp Derne

(https://s9.postimg.cc/gvnpfyyu7/antwerp_derne_1.png) (https://postimg.cc/image/qsyq916fv/)

2D map

(https://s9.postimg.cc/5jb3y7sq7/antwerp_derne_2.png) (https://postimg.cc/image/yygs77x9n/)

3D view

(https://s9.postimg.cc/obmz1t4jz/antwerp_derne_3.png) (https://postimg.cc/image/mwled33gr/)

And the same for Asmara International

(https://s9.postimg.cc/8q5nhxd73/asmara_intl_1.png) (https://postimg.cc/image/ftdixjimj/)

(https://s9.postimg.cc/upc2551r3/asmara_intl_2.png) (https://postimg.cc/image/3ri53eh3v/)

(https://s9.postimg.cc/wtwf68b3j/asmara_intl_3.png) (https://postimg.cc/image/wtwf68b3f/)


What 3D file format do most of you use?

The tool is going to output a 3D scene you can load in a 3D editor. I would like to have instanced meshes if possible. By that I mean that I output 1 mesh for a windsock and then have multiple instances of the same mesh in the file.

Anyone know of a good format to use for that?


Title: Re: Weekly progress report
Post by: Stainless on January 31, 2018, 09:38:59 AM
Now with windsocks  :P


(https://s9.postimg.cc/dvg1rchun/windsock1.png) (https://postimg.cc/image/50f7gtt23/)
Title: Re: Weekly progress report
Post by: Unca-Fester on January 31, 2018, 02:03:24 PM
Most of my stuff is either in .ac or a small amount of Open Plane Studio's export of .obj

  They both will open in Bender and AC3D.
Title: Re: Weekly progress report
Post by: Stainless on February 01, 2018, 02:28:13 AM
Both of those are easy to export, though both will have duplicate geometry for objects.

No mesh instancing
Title: Re: Weekly progress report
Post by: Pursuivant on February 01, 2018, 11:56:14 AM
Very nice!

Could I put in a plea for including a month/year data field for various airfield features as well as an add/change/remove option?

The month/year feature would allow fans to more easily "replace" modern equipment and airfield layout with historical features. The add/change/remove option would allow fans to add fictional (or future) features with the "add" or "change" options, or simulate loss of airfield features due to damage, malfunction, etc. with "remove."

Possibly, maybe, fields to set additional conditions associated with a given airfield (possibly with provision to set by day/month/year):

Runway and taxiway conditions - ice, wet (snow/rain), mud, dust, FLOT risk, rough surface, bomb damage, fire, damaged/destroyed aircraft on runway, limited visibility (fog/blowing snow/smoke), hostile aircraft in area, clear.

Nationality (determines friendly/hostile/neutral status during wartime/cold war)

Airport type and landing restrictions - public civilian/private civilian/military force (type), open/closed/closed to civilian/closed to foreign, emergency only - Filters which allow the number of available airports to be further limited based plane and pilot type. Also sets up options for different interactions with ATC and different trigger events based on aircraft and pilot type - like "do not land" warnings from a closed military airfield, followed by interceptors being scrambled, AAA defenses being triggered, etc.

ATC control radius

METARS info available? Historically, forecast data wasn't universally available.

Provision to include more and different historical landing and navigation aids - RDF, signs which identify the airport from the air, fires lit at each end of the runway, etc.

Blackout/no blackout - Determines whether airport lights are off at night by default.

Fuel types available

Repair available?

Medical aid available?

Ammunition types available
Title: Re: Weekly progress report
Post by: Stainless on February 07, 2018, 05:03:38 AM
The tool is coming on nicely.

(https://s17.postimg.cc/chp667o67/image.png) (https://postimg.cc/image/e9i5147iz/)

I have added support for runway markings, four classes. No markings, Visual, Non-precision , and precision.


(https://s17.postimg.cc/ive99hvn3/image.png) (https://postimg.cc/image/6grh9644r/)

But I am seeing weird stuff.

(https://s17.postimg.cc/ht42qzn4f/image.png) (https://postimg.cc/image/ive99j5xn/)

Do they really paint the grass?

Title: Re: Weekly progress report
Post by: Pursuivant on February 07, 2018, 03:10:13 PM
Do they really paint the grass?

In some cases, yes:

http://landinglines.com/

Maybe not for improvised or temporary military runways, but it's not uncommon for modern glider and light aircraft runways to either have painted markings or white synthetic markers which serve the same function.

Also, historically (1920s-40s) some grass airfields had a "baseball diamond" shape with the hangars at the point of the diamond, the name of the airfield outlined in white stones or paint (to allow identification from the air) and the landing strip limit lines marked in white stones or paint. I can't find a picture at the moment, so you'll have to trust me. :)

Title: Re: Weekly progress report
Post by: Stainless on February 08, 2018, 02:09:57 AM
I trust you  ;)

At the moment I am navigating the mess of landing lights.

Found a UK standards agency document on runway markings, and most of the runways I have looked at are illegal in UK.  ;D

Title: Re: Weekly progress report
Post by: Stainless on February 08, 2018, 08:01:12 AM
Well got the start of ALSF 2 in and I suddenly realised I am going to have to rethink my renderer completely.

I had planned to support about 128 lights, no I estimate I am going to have to support about 4096.......

Tiled forward lighting maybe........

(https://s17.postimg.cc/sey1xgqq7/lights_1.png) (https://postimg.cc/image/lbq6hulaj/)

hmmm image seems to have disappeared again
Title: Re: Weekly progress report
Post by: Stainless on February 09, 2018, 04:45:35 AM
Hmmmm think I may be a bit below glide slope


(https://s17.postimg.cc/lprz0pc0f/lights_2.png) (https://postimg.cc/image/chzqk04y3/)

So that's ALSF 2  done, just ALSF 1, Calvert, Calvert Cat II, SSALR, SSALF, SALS,MALSR,MALSF,MALS,ODAL, and RAIL to do.......

 :(
Title: Re: Weekly progress report
Post by: Stainless on February 09, 2018, 08:24:40 AM
In preparation for testing some lighting algos, I have added a scattered sky.

But now I am worried I have got the ALSF 2 wrong.

Should the gantries that hold the approach lights go up with the glide slope?

Doesn't look right to me.


(https://s17.postimg.cc/tey03vwen/lights_3.png) (https://postimg.cc/image/97kkbkyx7/)
Title: Re: Weekly progress report
Post by: Pursuivant on February 09, 2018, 10:00:41 PM
Should the gantries that hold the approach lights go up with the glide slope?

Yes, at least in some cases, the approach light towers get lower as you approach the end of the runway:

https://upload.wikimedia.org/wikipedia/commons/thumb/f/f3/Approach_lights_at_EFJY_20120818.jpg/1024px-Approach_lights_at_EFJY_20120818.jpg

You can see the way that the height of the light towers taper off in the side views in this illustration:

http://www.rainierflightservice.com/blog/wp-content/uploads/2011/01/approach-lights.jpg

Sometimes, the lights will follow the contour of the terrain, so they retain a more or less constant height, as shown here:

https://i.stack.imgur.com/Kd3xE.jpg

Your ALSR2 lights might look wrong because the towers might be spaced too far apart.

As for the number of lights, while your lighting looks great for a 1940s or 1950s airport, big 21st century commercial airports are lit up like Times Square on New Years Eve. If you want to be brutally realistic, you will need to step up the number of possible individual lights by a couple of orders of magnitude (8,192? 16, 384?) to cover all the lights associated with landing systems and runways for a major commercial airport.

That assumes that you're mapping each light individually. You might be able to simplify things by using the ICAO standards to generate algorithms for the appropriate number and type of lights (e.g., treating each ALSF tower or treating each line of runway edge lights as a single "light").

Figuring out the "fiddly bits" for less common or obsolete landing systems seems like another job for future fans of your best-selling flight sim. As long as you define the broad parameters, make provisions for a particular system to be added, and make it easy for fans to "mod" the basic program, that's good enough for now.
Title: Re: Weekly progress report
Post by: Stainless on February 10, 2018, 03:16:43 AM
The distance between the towers is spot on, I used the official standards document to place them. I am starting to think it's just my projection matrix is wrong.

I just used a 45 degree field of view as it is what I grew up with (easy maths , 45 degrees means you can just do a (x > z) || ( y > z) visibility check)

Think I will change it and see what it looks like.

The next thing I want to add before I start messing with the N other approach lighting systems is things like runway centre lights , landing zone lights, that sort of thing.

This will give me a really good idea of how many lights I am going to need to support in the actual game.

Title: Re: Weekly progress report
Post by: Unca-Fester on February 12, 2018, 09:34:23 AM
Both of those are easy to export, though both will have duplicate geometry for objects.

No mesh instancing

Duplicate Geometery? I'm not sure what mesh instancing is.

P.S.  Have you thought of using FlightGear's base Airport models to speed up the process of populating modern airports? Other than converting the image formats from .png to .tga, most if not all of FG airport 3D files are in .ac format.
Title: Re: Weekly progress report
Post by: Stainless on February 15, 2018, 06:21:28 AM
Yes I will probably grab some of them, but they need detailing.

AC format is easy to read.

Mesh instancing is a graphics technique used a lot nowadays. Say you have 100 lights in a scene, all with the same geometry. The same mesh.

It is very wasteful to send all the geometry to the graphics card 100 times.

Instead you send the geometry once, and send 100 world view projection matrices.

This is incredibly fast compared to the original technique.
Title: Re: Weekly progress report
Post by: Stainless on February 21, 2018, 09:22:32 AM
Well whoever suggested using flightgear as a data source sure took over my mind.

So I downloaded the terrain database, decoded the data structure, wrote parsers for all the files, wrote scanners, and display code and ran the editor.

Nothing. Not a single pixel.

I scratched my head for a while, had a cig, drank a beer, then suddenly I realised my mistake.

Each object has an elevation stored in the data. This elevation is based on the terrain. I am just using the elevation in the airport data.

The two are not the same.

So after altering the objects elevation to match the airports elevation I started getting weird objects popping up.

(https://s10.postimg.cc/psphjbumx/objects1.png) (https://postimg.cc/image/zd9467jyt/)

(https://s10.postimg.cc/rx9ukfbp5/objects2.png) (https://postimg.cc/image/o0wiofqph/)


They don't look quite correct yet, but they are there.
Title: Re: Weekly progress report
Post by: Stainless on February 22, 2018, 06:43:06 AM
These is getting extremely frustrating.

The objects are there, they are the correct size now, but everything looks just a little out of position.

Really annoying me.

I have Latitude, Longitude, and Heading.

Should be trivial, but it isn't......



(https://s10.postimg.cc/r5znyb3cp/shoreham_1.png) (https://postimg.cc/image/80weojool/)

(https://s10.postimg.cc/3rromdt55/shoreham_2.png) (https://postimg.cc/image/b7qy86gud/)

(https://s10.postimg.cc/w4n6cuml5/shoreham_3.png) (https://postimg.cc/image/yyqbqaor9/)


If anyone knows Shoreham (EGKA) could you have a look at tell me how far out I am please.

And yes I know that is a boat, not sure why it is there either......

Title: Re: Weekly progress report
Post by: Stainless on February 23, 2018, 04:01:17 AM
So this is damn frustrating

This is the official map of the airport


(https://s10.postimg.cc/z8gfh1zo9/shoreham_7.png) (https://postimg.cc/image/cjr8hhiad/)


And this is my map.



(https://s10.postimg.cc/7l3q3047t/shoreham_5.png) (https://postimg.cc/image/i7xj8fcd1/)


Pretty close.

But when you swap to 3D and look at the objects..... not right



(https://s10.postimg.cc/oye0hwwyx/shoreham_6.png) (https://postimg.cc/image/ja7pr0smd/)



I ONLY HAVE LOCATION AND ORIENTATION!!!! HOW CAN IT BE WRONG ????

Title: Re: Weekly progress report
Post by: whistler on February 23, 2018, 06:30:17 AM
If you alter the orientation slightly, do objects rotate only or do they also relocate a little? Perhaps their rotational pivot point is not at the center. But you would have figured this out already I am sure :)
Title: Re: Weekly progress report
Post by: Stainless on February 23, 2018, 08:13:08 AM
All I have is


OBJECT_SHARED lines
Adds shared objects to the tile.

Example:

 OBJECT_SHARED Models/Airport/tower.xml -122.501090 37.514830 15.5 0.00
Syntax:

 OBJECT_SHARED <object-path> <longitude> <latitude> <elevation-m> <heading-deg> <pitch-deg> <roll-deg>
<object-path> is relative to the data directory (FG_ROOT).
<longitude> and <latitude> are in degrees using WGS-84 standard coordinate systems, available from most online-maps.
<elevation-m> is in meter and relative to mean sea-level (in the fgfs world).
<heading-deg> is in degree, counter-clockwise with North being 0.0.
<pitch-deg> and <roll-deg> are in degree and optional.



Apart from the heading being in a stupid format ..... should be simple.
 
Title: Re: Weekly progress report
Post by: whistler on February 23, 2018, 10:23:59 AM
You probably have to apply a small factor to get the heading (yaw I supposed) right?
 
I would play with Models/Airport/tower.xml -122.501090 37.514830 15.5 0.10 0.10 0.10 values and see if these do what they are supposed to do. Location of the objects seem pretty accurate (from a global scale), you are just missing a small adjustment.

If you get the objects manually positioned into place, probably the values used will tell what is missing and/or where..
Title: Re: Weekly progress report
Post by: Unca-Fester on February 23, 2018, 03:24:53 PM

The heading degrees is in a counter-clockwise rotation, which I assume is viewed from above the object, this used to throw me off when trying to manually install new scenery in FG, instead of just using the UFO object installer.  90 degrees is actually 270 degrees in FG, would that be the problem you're experiencing?

  Also the weird look is because FG relies heavily on alpha masking for complex structures like truss bridge sides and power transmission pylons and such, and the .png's probably have a different alpha mask coding format...?
Title: Re: Weekly progress report
Post by: Stainless on February 26, 2018, 06:25:51 AM
There is definitely something seriously whack about this data

I added helipad's to give me some more points of reference and then overlaid a part of the official map over a screenshot from my app.

While some things line up pretty well, other things are way out.


(https://s10.postimg.cc/i0753o021/shoreham_7.png) (https://postimg.cc/image/wjea52t6t/)

The scale of all the objects is wrong. The position is wrong. The orientation is wrong.

After all I don't think you would want to work in this tower.


(https://s10.postimg.cc/5ybr9lbex/shoreham_8.png) (https://postimg.cc/image/rxi5wss91/)
Title: Re: Weekly progress report
Post by: Pursuivant on February 28, 2018, 02:14:34 PM
There is definitely something seriously whack about this data

Really stupid basic idea. Have you taken magnetic declension into account?

Other than scale and location being wrong, everything seems to be lining up on "almost" the correct axis, but at the slightly wrong angle.

Currently, Brighton City Airport/Shoreham has a magnetic declension of 0° 45' W  ± 0° 22'  changing by  0° 9' E per year but in 2016 it had a declension of 1° 2' W  ± 0° 22'  changing by  0° 9' E per year.

Calculator here:

https://ngdc.noaa.gov/geomag-web/

If you're using slightly data which uses magnetic north rather than true north that might explain the problem.
Title: Re: Weekly progress report
Post by: Stainless on March 01, 2018, 02:01:30 AM
It's a good point, but I have tried that.

Even if it was a problem, I have a single code block that converts latitude, longitude into a local world space coordinate system.

Code: [Select]
        /// <summary>
        /// Returns a new Vector2D which is the distance from the reference point in metres
        /// IE. Makes the data point local to the reference point
        /// </summary>
        /// <param name="clat">Reference point latitude</param>
        /// <param name="clon">Reference point longitude</param>
        /// <param name="slat">Data point latitude</param>
        /// <param name="slon">Data point longitude</param>
        /// <returns></returns>
        public static Vector2D ConvertToLocalised(double clat, double clon, double slat, double slon)
        {
            double m_per_deg_lat, m_per_deg_lon, deltaLat, deltaLon;

            m_per_deg_lat = 111132.954 - 559.822 * Math.Cos(MathHelper.ToRadians((float)(2.0 * clat)) + 1.175 * Math.Cos(MathHelper.ToRadians((float)(4.0 * clat))));
            m_per_deg_lon = (3.14159265359 / 180) * 6367449 * Math.Cos(MathHelper.ToRadians((float)clat));

            deltaLat = clat - slat;
            deltaLon = slon - clon;

            return new Vector2D(deltaLon * m_per_deg_lon, deltaLat * m_per_deg_lat);
        }



Since everything is in latitude : longitude, everything should be consistent. It could be wrong , but at least it should be consistent ;D


I have decided that I am going to have to write an editor for airports, which will allow you to fix problems like this.
Title: Re: Weekly progress report
Post by: Pursuivant on March 04, 2018, 12:21:04 PM
I have decided that I am going to have to write an editor for airports, which will allow you to fix problems like this.

Sympathy to you for the disruption of your plan of work.

But, I can't say that I'm that sad since an airport editor is another "tool for sandbox" which will allow fans to modify the sim. :)
Title: Re: Weekly progress report
Post by: Stainless on March 05, 2018, 03:07:51 AM
 ;)

Well it forced me to work on something I had been putting off.

If I am going to write an airport editor, I need to have terrain to put the airport on. Otherwise in game the airport could be underground or floating in mid air.

So I have started the terrain module I have been putting off for ages.

I have delayed terrain a lot because I was hoping to use a terrain system I have been thinking about for ages. Trouble is I haven't solved one key problem with it (spherical aberration due to curvature of the Earth) and so I really cannot use it for the editor.

So I will end up with two terrain modules. One for editors and one for game.

A bit of a waste of effort, but not terrible.
Title: Re: Weekly progress report
Post by: Pursuivant on March 06, 2018, 03:12:10 PM
;)
So I have started the terrain module I have been putting off for ages.

Question: Will the terrain/airport editor take surface type and condition into account?

I ask because I've never encountered a flight simulator where you can't land any sort of plane on any relatively flat piece of ground not blocked by obstacles, or where imperfect runway surface does anything other than bounce your plane around. In reality, of course, aircraft are severely limited by runway material type and surface conditions as well as the aircraft's ground pressure and surface contact area.

Slippery runways slow take-off runs and create the risk of the airplane skidding off the runway or ground looping. Heavy aircraft will quickly destroy runways not designed to bear their mass and the forces they generate when they land. Aircraft attempting to take off, land, or taxi in muddy conditions might skid, ground loop, flip over, or get stuck (e.g., the Akutan Zero). Dry conditions and dirt, coral, sand, etc. runways generate massive amounts of dust which interferes with visibility on the ground (e.g., the failed 1980 Iran Hostage Rescue attempt by the USAF/US Army), makes take-offs and landings extremely visible from the air, and can cause damage to the engines and other aircraft systems.

If you choose to incorporate ground pressure into your sim, some potentially useful simplified equations are here:

http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1044&context=usarmyresearch
Title: Re: Weekly progress report
Post by: Stainless on March 07, 2018, 02:16:59 AM
I have already got a value for runway roughness in the database.  ;D



Title: Re: Weekly progress report
Post by: kalsonic12 on March 07, 2018, 08:13:12 PM
Possibility of blown tires during rough landings?
Title: Re: Weekly progress report
Post by: Stainless on March 08, 2018, 02:02:58 AM
Yes I want all of the damage systems to be realistic.

So tires bursting on landing, damage to flight control surfaces being resolved in a realistic manor, electrical system failures, hydraulics, everything as realistic as possible.




Title: Re: Weekly progress report
Post by: Pursuivant on March 09, 2018, 06:38:53 PM
I have already got a value for runway roughness in the database.  ;D

Cool!

I was thinking that a value for runway type and surface conditions could also be a eventually be used as variables which trigger things like altered coefficient of friction, dust/snow cloud and water/mud spray special effects, and risk of things like blown tires, landing gear failure, FOD, and noseover/ground loop.

For runways which depend on seasonal conditions - like seaplane take-off areas or runways on iced over lakes, availability of runways and effects if an airplane lands in an inappropriate location could be linked to weather conditions.

Most airfield descriptions includes runway surface type and METARS or other game events can be used to infer likely surface conditions, so not that difficult to include the information in the editor.

Ground pressure usually isn't an issue when landing at an airfield, except for really big, heavy civil airliners. Even then, it mostly affects rate of wear to the runway over an extended period of time. It makes more of a difference when planes are operating from improvised airfields, for ski-equipped planes, or planes attempting to make wheels-down emergency landings in boggy, muddy, or sandy terrain. This was a big deal for WW2-era aircraft operations in some theaters. Understandable if you don't want to include it, though.
Title: Re: Weekly progress report
Post by: Stainless on March 13, 2018, 09:12:01 AM
My circuits are now committed.

It has begun....



(https://s14.postimg.cc/ge9an54u9/ae_0001.png) (https://postimg.cc/image/9nstdphod/)
Title: Re: Weekly progress report
Post by: Unca-Fester on March 14, 2018, 02:38:38 PM
Woah  your using X-Plane's Apt dat!

So can users of this editor also add their own custom fields?
Title: Re: Weekly progress report
Post by: Stainless on March 15, 2018, 03:28:47 AM
Yes, the apt.dat file gives me 34000 airports we can work with without major work, so it was a no brainer really.

What sort of custom fields would you like?
Title: Re: Weekly progress report
Post by: Stainless on March 20, 2018, 04:37:51 AM
Well a bloody frustrating day.

I found a site which said it had complete Lidar data for the British Isles. So of course I grabbed a load of it. What could be better for the terrain.  :P

So I wrote a parser and converted the data into several useful formats.... which is where things went horribly wrong.

First I noticed that because it's Lidar, it picks up buildings.

(https://s18.postimg.cc/8b6r83lgp/Lidar_1.png) (https://postimg.cc/image/hvqduzasl/)

NOT GOOD..... NOT GOOD....

Then I noticed the data was not complete at all. Large areas have not been scanned......

(https://s18.postimg.cc/7lnyvqsmx/Lidar_2.png) (https://postimg.cc/image/42215xpx1/)


So I went away and had a cig. While on the balcony, looking at the snow falling, I had a brain wave. Maybe the objects in the airport editor were in geocentric coordinates instead of geodetic.

So I wrote some code to convert between the coordinate systems, and yes they were different.... but now my objects are a few kilometres out of position instead of a few metres......

Not a good day.

Stainless needs beer badly.


Title: Re: Weekly progress report
Post by: sniperton on March 20, 2018, 05:37:24 AM
Now imagine that you're pleanning a precision bombing strike based on coordinates...
A beer won't suffice, you'll need a whiskey in addition.  8)
Title: Re: Weekly progress report
Post by: Stainless on March 22, 2018, 09:07:47 AM
Still frustrated.

I now parse the terrain files from flightgear and display the terrain around the airport.

This has shown up some more problems.


(https://s31.postimg.cc/50zl4wuyj/shoreham_9.png) (https://postimg.cc/image/r05zs4bsn/)

The white areas are patches of untextured terrain. You can see they don't join up... which they should.

You can also see a second copy of the airport, this is a BTG (terrain object).

It has a different alignment than the one generated from the apt.dat and is a different size...... WTF is going on.


Title: Re: Weekly progress report
Post by: Stainless on March 23, 2018, 06:20:15 AM
Well I got fed up with trying to figure out what the hell was going on.

So I just did a major rewrite of the code to use ECEF coordinates. So far I have done the terrain and the objects as the data for them is already in ECEF coordinates.

Already looking sensible.


(https://s31.postimg.cc/w70fotzyj/shoreham_10.png) (https://postimg.cc/image/q62qrrdc7/)

The terrain is white because the texture is set to "SomeSort" .... which seems to be a generic material.

The objects look to be sensibly aligned, and positioned. The runway in the back is a BTG file not the one I generated from the apt.dat file.

That is my next task


Title: Re: Weekly progress report
Post by: Pursuivant on March 23, 2018, 08:44:16 AM
So I wrote a parser and converted the data into several useful formats.... which is where things went horribly wrong.

Silver lining:

That LIDAR data with all the buildings could somehow be edited to allow (partial) photoreal autopopulation - at least for the UK ca. 2018.

As a temporary overlay, it can also be used to double check placement of roads, railways, etc.

Obviously, jobs for another time or even another person, but my initial reaction when I saw all those ghostly buildings was, "that looks incredible!"

I've always thought that for historical flight sims, rather than attempting to use modern STRM data, the better thing to do might be to scan in old photo recon photos or ordinance survey maps, use AI to train the computer to recognize various terrain features (and, maybe even estimate altitudes in the case of stereoscopic photos), and build a map based on that data. The map based on historical data could then be cross-checked against modern STRM data for general accuracy.
Title: Re: Weekly progress report
Post by: Stainless on March 25, 2018, 05:08:37 AM
There is a program on the history channel that has used stereographic photography from WWII to create 3D recreations, so I guess it would be possible.

IF you could get access to the stereographic data.  ;)
Title: Re: Weekly progress report
Post by: Unca-Fester on March 25, 2018, 09:11:32 PM
Yes, the apt.dat file gives me 34000 airports we can work with without major work, so it was a no brainer really.

What sort of custom fields would you like?

Well in FG you have to be adept at using the terrain editor TerraGear to add in anachronistic airfields like old WWI ones for France, even though several if not a dozen or more of the modern fields were once WWI, their size was smaller and outlines different.  I added Stow Maries to the UK, ( just the buildings, the 'field' it's located on is a crop_grass landclass mesh and works for a WWI era field.) even though it's not given a location in apt.dat, it would be nice to add custom airfields without resorting to a tedious external program.
Title: Re: Weekly progress report
Post by: Pursuivant on April 06, 2018, 06:41:21 AM
There is a program on the history channel that has used stereographic photography from WWII to create 3D recreations, so I guess it would be possible.

Most photo recce pictures from WW2 were taken using stereographic cameras, specifically so that intelligence analysts could see the combined images in 3d using stereographic imagers. Basically, fancier versions of the Victorian/early 20th century "stereoscopes."

If you had the images properly set up, you could view them through a pair of digital cameras and possibly have a computer automatically set up 3d images based on interpolating the two different images. Obviously, not a project for this flight sim but the technology seems fairly straightforward.

Even better, in addition to all the archived USAAF and RAF photo recon images from WW2, the US and UK also snaffled up all the Luftwaffe PR images after the war (Operation Dick Tracy). All those millions of lovely photos are currently sitting in national archives near Washington and London, just waiting for someone to make a detailed 3d maps of Europe, North Africa, etc. ca. 1942.
Title: Re: Weekly progress report
Post by: Stainless on April 10, 2018, 02:49:31 AM
This week I started a tool to convert IL2 meshes to game meshes.

Designed to be easy to use.

(https://s7.postimg.cc/4ihrn1ovf/conv_001.png) (https://postimg.cc/image/4ihrn1ovb/)

There are only two settings, source directory where all you IL2 mods are, and the destination directory you want to store the converted objects.

(https://s7.postimg.cc/580jzgf57/conv_002.png) (https://postimg.cc/image/yaeu2a1ev/)

Just hit load and navigate to the him file

(https://s7.postimg.cc/my28ki85n/conv_003.png) (https://postimg.cc/image/aw6uqcyx3/)

(https://s7.postimg.cc/v3kainoor/conv_004.png) (https://postimg.cc/image/l699plh2v/)

Then load it.

(https://s7.postimg.cc/k3z371b4b/conv_005.png) (https://postimg.cc/image/5xjcbt093/)

You can rotate the object with the left mouse button, and rotate the light source with the right mouse button. The mouse wheel zooms in and out.

(https://s7.postimg.cc/lj0nvrjx7/conv_006.png) (https://postimg.cc/image/xxnfw3bfb/)

Then just hit save.

The result is a directory containing a large text file which is the game object. This can be loaded into the game object editor and tweaked.

Title: Re: Weekly progress report
Post by: DarkBlueBoy on April 10, 2018, 04:28:18 AM
Bloody Hell Stainless! That is brilliant. :)
Title: Re: Weekly progress report
Post by: Stainless on July 01, 2018, 02:50:10 AM
Well I am stuck in Kiev again, this time in a shitty hotel right on Independence square.

Great for beggars and prostitutes, but not what I am after. So I have hibernated in my hotel room and wrote some code.

I have written a test host for connecting external devices to the game.

At the moment I just have a F16 early block US threat warn prime panel emulated, but I still need the test host to test that.

You setup a world in the test host with a few clicks.

(https://s22.postimg.cc/4k9tknx4x/world_setup.png) (https://postimg.cc/image/sb972rxbx/)

This is a complex threat situation with a couple of fighters in front of you, some ships to port, a helicopter to starboard. SAM and AAA around as well. Also a transport.

Then you start up the server and run up the RWR.

(https://s22.postimg.cc/qjg880bg1/stream_setup.png) (https://postimg.cc/image/cd0hcs0kt/)

The RWR registers which data streams it wants. In this case RWR data with a max of 16 data entries and missile launch data.

The test host then send the data whenever something changes.

(https://s22.postimg.cc/ph61plao1/log.png) (https://postimg.cc/image/fjv0wj325/)

The RWR emulator is written in SDL (c++) so it can be compiled to run on Rasberry Pi's and just talks to the game (or test app) over UDP on the local network.

(https://s22.postimg.cc/ehkue5zq9/f16_rwr_normal.png) (https://postimages.org/)

The buttons all work like they should do, for example hitting target sep gives you this.

(https://s22.postimg.cc/f73mqkia9/f16_rwr_sep.png) (https://postimages.org/)

When I get back to UK I will run it up on the Raspberry Pi with a 5" touch screen so you can see it live.


Title: Re: Weekly progress report
Post by: Stainless on July 05, 2018, 03:37:10 AM
Had a spare hour while waiting for  a build to complete, too early to go to the pub.

So I decided to throw together a bit of code I have been thinking about for a while.

I want the player to earn achievments. And what better way to display these achievments than with a salad bar.

For those that don't know, a salad bar is the block of service ribbons you see on the left side of a service uniform. Each little bit of ribbon indicates a medal won or an award of some sort.

I want the player to be able to have these. Note I do mean the PLAYER. Not the CHARACTER. So if you are flying as a RAF Spitfire pilot, that is your character and he can get medals which are historically accurate. You as the player do not get a medal for this.

You as a player get achievments like "FirstKill","QualifiedPilot","PassedBasicTraining", etc.

Obviously I don't want to sit and draw all these ribbons, so I randomly generate them.

I use a MD5 hash to convert the name of the achievment into a 16 byte array of bytes. Then use all these 16 bytes to create a 32bit seed for a random number generator.

So generating a ribbon from a string is always the same.

Here is an image showing a few example ribbons and the strings used to create them.



(https://s33.postimg.cc/twvnulv3z/ribbons.png) (https://postimg.cc/image/jmt8vd58b/)
Title: Re: Weekly progress report
Post by: Stainless on July 06, 2018, 01:14:20 AM
Waiting for a plane so did some coding.

More accurate test mode

(https://s22.postimg.cc/gaxg0sdnl/new_test_mode.png) (https://postimages.org/)

Added type information to display.

(https://s22.postimg.cc/6qdtdylrl/rwr_typed.png) (https://postimages.org/)


Shows two MIg 25's , an airborne search radar, an unknown airborne target, and a SA -10



Title: Re: Weekly progress report
Post by: Stainless on September 10, 2018, 02:10:03 AM
Sorry for not posting for a while, but what with work and illness I have been a little distracted.

There has been a lot of work done, just not the sort of work that I can show pretty pictures for.

Basically I got annoyed with myself and decided I should stop messing about and get stuck in with doing the deep down and dirty work.

So I have slapped myself and drank a lot of coffee, then started.

I have written my own multi-threaded renderer. The engine now does all the game update on any CPU cores that are available and builds a set of render commands.

While it is doing this, the renderer is drawing the list created last frame on it's own dedicated core.

Obviously when you are doing multi-threaded coding it is difficult to debug when things go wrong. So I have built in a profiler which displays what is running on any core at any point in time as an onscreen display.

While doing this I needed something to display, so I have written all the game components I need to display an IL2 style aircraft and extended my modtool to export everything in a game efficient format.

This code will also just plug into the aircraft converter I previously started, so when I finally give you all this to play with you can just load a HIM and press a button and the aircraft appears in the game.

I am also going to throw away the flight dynamics model I previously wrote. It was based on a publicly available open source FDM that is used in FlightGear, so it does work. However the more I look at it, the less I like it.

I am using an entity component model. So an aircraft is built up of a bunch of parts. My current FDM treats an aircraft as a single object.

What I have decided to do is create a bunch of components purely for the FDM. Think aerofoil component, drag component, thrust component.

I want to then use a generic physics model and let each component add point forces to it during the components update, then resolve all the forces at the end of a frame.

Why?

Well suppose you take damage to a control surface. With the old FDM I would have to guess how this affects the flight handling. With my system, I just modify the forces generated and let physics do the rest.

It means that when you shoot down an aircraft, it will behave realistically. Lose a wing, it will spin about it's axis. Lose both wings and you become a bomb. That sort of thing.

As a player it also means you may be able to land a badly damaged aircraft, but it's a judgement call. Should I bail out and risk the consequences?  Should I stay with the aircraft?

I think it will add a lot to the game.
Title: Re: Weekly progress report
Post by: DarkBlueBoy on September 10, 2018, 04:07:58 AM
All sounds very well thought out and I for one can't wait until such time there is more to see. :) I certainly appreciate all your efforts on this project and it promises so many amazing things!
Title: Re: Weekly progress report
Post by: hello on September 10, 2018, 12:17:46 PM
Been following this thread now for a few years...  o_O Amazing stuff! Looking forward to the moment all components come together. CHEERS!
Title: Re: Weekly progress report
Post by: Ibis on September 10, 2018, 07:11:58 PM
 I too keep checking to see what has been accomplished. Love your work.
 Thanks for your efforts.
 cheers,
  Ibis
Title: Re: Weekly progress report
Post by: Pursuivant on September 12, 2018, 04:29:28 PM
Good that you're reworking Flight Modeling to take Damage Modeling into account.

IMO, the weakest part of the flight simulation experience is "bad things happening to good airplanes". Not just combat damage, but bird strikes, hail damage, airframe stress due to everything from hard landings, to excessive turbulence, to plain old neglect.

Reworking FM to make an airplane "a collection of parts flying in formation" makes it dead simple to make trivial changes to FM such as slightly increased drag due to add-ons like antennas or RDF domes or possibly even something as simple as waxed vs. unwaxed surface or reduced quality of fit and finish found in production WW2-era aircraft vs. prototypes.
Title: Re: Weekly progress report
Post by: Stainless on September 17, 2018, 12:37:15 AM
Exactly, and because each component of the aircraft has a position relative to the CofG of the aircraft, the physics just works.

I am in Cyprus at the moment, so don't have access to my development machine, but I had a good day last Thursday and got several very important parts of the code working.

You can now just export an aircraft from the modtool directly into the game. At the moment it's just the physical appearance, all the msh files, but it's a damn good start.

When I get back I can get the collision mesh in and then the LOD's (which are trivial ) and then I can start adding physics components.

Actually making progress at last.
Title: Re: Weekly progress report
Post by: Stainless on September 17, 2018, 06:18:35 AM
Since I cannot work on the main engine while I am here, I started doing some more work on the game object editor.

I started creating weapon loadouts and realised it would be very boring and bug prone to enter all the parameters by hand. So I added the concept of presets to the editor.

This is a standard loadout with just 8 browning 303 machine guns.

(https://i.postimg.cc/6QHD48N6/Desktop_Screenshot_2018.09.17_-_13.08.20.70.png) (https://postimg.cc/JykT94nS)

The guns need to have bullet parameters attached, so I created a BulletPropertiesComponent and attached it to each gun.

This has a load of parameters which will be familiar to many of you.

(https://i.postimg.cc/Y2QbJvy4/Desktop_Screenshot_2018.09.17_-_13.08.34.20.png) (https://postimg.cc/5jNBz2J1)


I also created a couple of presets to test it is working. 303 and 50 cal. Selecting one of the presets configures all the parameters.


(https://i.postimg.cc/XvTkPWfc/Desktop_Screenshot_2018.09.17_-_13.08.42.13.png) (https://postimg.cc/p9Jj9g1p)
Title: Re: Weekly progress report
Post by: Pursuivant on September 19, 2018, 12:42:34 PM
Question: Would it be reasonable to model certain objects as "a collection of parts" as you plan to do with aircraft?

For example, a tank could be modeled as turret+gun+chassis+left tread+right tread or a human could be modeled as head+ torso+ leftarm+ rightarm+ leftleg +rightleg.

That might make certain movement and damage animations/graphics easier and might allow customization of objects by swapping out different parts (e.g., different models of tank by swapping in a different turret and/or gun, different aircrew equipment by swapping in different heads, arms, etc.).
Title: Re: Weekly progress report
Post by: Stainless on September 20, 2018, 12:00:18 AM
I am assuming most vehicles will be modelled as a bunch of parts, any vehicles that are just eye candy and serve no in game purpose could be static meshes, but that's the mission designers choice.

Tanks definitely would just be aircraft without aerodynamic components. So the turrets and tracks would be animated. Turrets can be swapped. Paint schemes swapped.

People I am going to use skinned meshes. That is a skeleton of bones which is common to all humans, a set of animations which is common to all humans, then as many skins as we need.

The animations are stored as a bunch of keyframes which you tween between using inverse kinematics.

This is a pretty good explanation https://venturebeat.com/2017/08/09/character-animation-skeletons-and-inverse-kinematics/ (https://venturebeat.com/2017/08/09/character-animation-skeletons-and-inverse-kinematics/)


Title: Re: Weekly progress report
Post by: Stainless on September 20, 2018, 01:21:41 AM
Was bored so wrote a loading screen.

Clouds are raytraced in a single shader and are moving towards you, fuel flow is the amount of data loaded per frame, fuel level is the loading progress.

Blind man would be happy to see it.


(https://i.postimg.cc/pX5r46Xv/Desktop_Screenshot_2018.09.20_-_08.19.26.58.png) (https://postimg.cc/svy3ZKhH)
Title: Re: Weekly progress report
Post by: Stainless on September 20, 2018, 04:28:13 AM
Which of course led to a new main menu system..... sigh...



(https://i.postimg.cc/ncHystxH/Desktop_Screenshot_2018.09.20_-_11.26.11.50.png) (https://postimg.cc/t7MSfw7f)

(https://i.postimg.cc/tC2LWmRF/Desktop_Screenshot_2018.09.20_-_11.26.25.11.png) (https://postimg.cc/Tp57X0DP)
Title: Re: Weekly progress report
Post by: andoodle on September 20, 2018, 10:58:30 PM
This looks good, Stainless. However, if there is one thing I wish to know, it is this: Is there a chance that there would be freeware versions of the missions, campaigns, terrains, aircraft, sea vehicles, and land vehicles (like convoy trucks and trains) based on those from IL-2 Sturmovik: 1946 and its "B.A.T." super-mod, IL-2 Sturmovik: Cliffs of Dover and its upcoming add-on (which might be based on the North Africa campaign), and the "IL-2 Great Battles" series (including "Battle of Stalingrad," "Battle of Moscow," "Battle of Kuban," "Battle of Bodenplatte," "Flying Circus, Vol. 1," and "Tank Crew: Clash at Prokhorovka")? I am sorry for asking such a lousy, and possibly-controversial, question, but I felt that I needed to get it off my chest. With that in mind, I wish to know. Thank you for your time. Carry on.
Title: Re: Weekly progress report
Post by: Stainless on September 20, 2018, 11:47:39 PM
The whole thing will be free, along with the tool chain.

At the moment it is possible to import meshes (aircraft, vehicles, buildings) from Il2.

When I get to missions I will see if I can have an option to import missions from IL2 as well.

Terrain is the big problem. It is taking me a long time to come up with a good solution as IL2 uses a system that is not very generic. I will come up with something though
Title: Re: Weekly progress report
Post by: DarkBlueBoy on September 21, 2018, 12:46:29 AM
Yet another reason why everyone in our community should get behind this! Your invested time, skills, knowledge and dedication to this project are admirable Stainless. Thank you.
Title: Re: Weekly progress report
Post by: slibenli on September 21, 2018, 01:00:16 AM
The whole thing will be free, along with the tool chain.

At the moment it is possible to import meshes (aircraft, vehicles, buildings) from Il2.

When I get to missions I will see if I can have an option to import missions from IL2 as well.

Terrain is the big problem. It is taking me a long time to come up with a good solution as IL2 uses a system that is not very generic. I will come up with something though

I don't know if my terrain code will be of any help (it's also still very messy).
I'm still in the process of making it more generic and reusable - there are still some IL2 specific bits.

Anyway here it is: https://gitlab.com/vrresto/render_util.
The involved code is mostly in:
https://gitlab.com/vrresto/render_util/blob/master/src/map_textures.cpp
https://gitlab.com/vrresto/render_util/blob/master/src/terrain_cdlod.cpp
https://gitlab.com/vrresto/render_util/blob/master/shaders/terrain_cdlod.program (and the shaders referenced in there)
And then there is the IL2-specific map loader:
https://gitlab.com/vrresto/il2ge/blob/master/common/map_loader.cpp

All quite messy, I'm afraid - especially the shader code  :-[
Title: Re: Weekly progress report
Post by: Pursuivant on September 21, 2018, 10:48:02 AM
Thanks for the explanation!

Tanks definitely would just be aircraft without aerodynamic components. So the turrets and tracks would be animated. Turrets can be swapped. Paint schemes swapped.

I assume that this also applies to ships and other potentially "flyable" vehicles.

Title: Re: Weekly progress report
Post by: andoodle on September 21, 2018, 02:45:56 PM
The whole thing will be free, along with the tool chain.

At the moment it is possible to import meshes (aircraft, vehicles, buildings) from Il2.

When I get to missions I will see if I can have an option to import missions from IL2 as well.

Terrain is the big problem. It is taking me a long time to come up with a good solution as IL2 uses a system that is not very generic. I will come up with something though

Alright, then, Mr. Stainless. Like I said, I only wish to know if I, as well as everyone else on this forum, would be able to use the things (vehicles (including aircraft), buildings, terrains, and missions) from the "IL-2 Great Battles" series (including the IL-2 Sturmovik reboot of Rise of Flight), as well as IL-2 Sturmovik: Cliffs of Dover and its upcoming North Africa add-on, as well as IL-2 Sturmovik 1946 and its B.A.T. super-mod. Sorry. :(
Title: Re: Weekly progress report
Post by: Stainless on September 21, 2018, 11:46:20 PM
Thanks for the explanation!

Tanks definitely would just be aircraft without aerodynamic components. So the turrets and tracks would be animated. Turrets can be swapped. Paint schemes swapped.

I assume that this also applies to ships and other potentially "flyable" vehicles.

Yes, anything that ends up as a mesh.
Title: Re: Weekly progress report
Post by: Stainless on September 21, 2018, 11:57:10 PM


All quite messy, I'm afraid - especially the shader code  :-[

I have grabbed a copy, will take the time this week to look at it.
Title: Re: Weekly progress report
Post by: Stainless on October 02, 2018, 03:50:25 AM
Some more progress.

I exported 2 aircraft from IL2 directly into the game just to see how close I am.

I still have some issues to clear up, but clear progress.

The spitfire 9c went across almost perfectly. I can see some alpha handling issues in the textures, but the mesh looks ok.


(https://i.postimg.cc/59ndV5Vv/spitfire9c.png) (https://postimg.cc/WtFfmktb)

The Russian SB-2M-103 did not come across as well. Not sure why yet.


(https://i.postimg.cc/3wHbpWhY/SB-2_M-103.png) (https://postimg.cc/87tHgps0)


Still a kick in the butt is a free step forward.

Title: Re: Weekly progress report
Post by: Stainless on October 02, 2018, 03:51:16 AM
Oh and the little "eye" symbol is my gaze point.

I have eye tracking and head tracking built in.
 
Title: Re: Weekly progress report
Post by: SAS~Storebror on October 02, 2018, 03:59:46 AM
Interesting progress, thanks for keeping us updated.
I guess very few people can imagine the dimension of your project.
You definitely have my greatest respect.

]cheers[
Mike
Title: Re: Weekly progress report
Post by: Stainless on October 03, 2018, 01:49:02 AM
Thanks Mike,

The alpha handling issue turned out to be a bug in Monogame, which I am using as a base layer.

Some bright spark added crazy code to zero all RGB values if alpha == 0

Compiled my own version of Monogame and the problem went away.


(https://i.postimg.cc/kGhkBMmb/Spitfir9_C_02.png) (https://postimg.cc/wRLWrp3q)
Title: Re: Weekly progress report
Post by: Stainless on October 24, 2018, 05:44:57 AM
I have changed the mod tool so it now outputs default animators as well.

So without any work, flaps , slats, rudder, props, etc. will have the correct animation components added. Started with the props, which almost worked first time.

(https://i.postimg.cc/zfLNRw1p/Desktop-Screenshot-2018-10-24-12-33-00-77.png) (https://postimg.cc/KKyw6Mjg)

Then I tried a BF110

(https://i.postimg.cc/QMR3gB8D/Desktop-Screenshot-2018-10-24-12-34-16-69.png) (https://postimg.cc/06dFPyKX)

OOOPs.

The animations can be hand tweaked later in the game object editor
Title: Re: Weekly progress report
Post by: Stainless on October 26, 2018, 04:20:27 AM
Okay , more progress.

I have changed the mod tool to export directly into GuruEngine, which is what I am calling the game engine I am writing for this game.

You have a new menu ...

(https://i.postimg.cc/SKsw1PRb/Desktop-Screenshot-2018-10-26-10-43-48-22.png) (https://postimages.org/)

Clicking on "Export to Guru" will prompt you for a destination directory, then bring up this dialog.

(https://i.postimg.cc/Y2fbg326/Desktop-Screenshot-2018-10-26-10-46-15-75.png) (https://postimg.cc/c6CRGfnC)

Clicking on the checkboxes on the left will add basic flight controls automatically. These can be tweaked later in the game object editor.

You can also add CVTAnimatorComponents. These use the  same parameters as you use in Java (just with a sign change on the angle, so -85 in IL2 == 85 in Guru )

You can add as many of these as you want. The "Variable" string can be anything though some are pre-defined like GearPosition, RudderPosition, etc.

Then just click on continue and it's done.

Works very well for most aircraft.

(https://i.postimg.cc/GtyBFzGk/Desktop-Screenshot-2018-10-26-10-58-26-31.png) (https://postimg.cc/y37YBmfd)

Though it has shown us some big problems in my lighting system. I am at a lost why, but look at the rudder. It's black. Like the normals are wrong...... agghh

Now going to add a AngleAnimatorComponent and a TranslateAnimatorComponent for things like cockpits.



Title: Re: Weekly progress report
Post by: Stainless on October 28, 2018, 05:36:57 AM
Oh I am furious with myself.

Spot the horrible bug that ruined all my lighting systems....

Code: [Select]
float4x4 WorldInverseTranspose;

No? Me neither for about 8 hours.

Correct code.

Code: [Select]
float4x3 WorldInverseTranspose;


(https://i.postimg.cc/htv6yvsG/Desktop-Screenshot-2018-10-28-11-35-38-81.png) (https://postimg.cc/18xv49Lx)


Now to add SSAO.

After I have repaired the hole in the wall my head left.

Title: Re: Weekly progress report
Post by: sniperton on October 28, 2018, 04:54:51 PM
Spot the horrible bug that ruined all my lighting systems....

Code: [Select]
float4x4 WorldInverseTranspose;

No? Me neither for about 8 hours.

Correct code.

Code: [Select]
float4x3 WorldInverseTranspose;

At least it was not a comma instead of a semicolon. Appreciate the grace of God that befell on you after only 8 hours of desperation.  8)
Title: Re: Weekly progress report
Post by: Stainless on October 29, 2018, 12:30:35 AM
 :) It was on my mind so much, I woke up at stupid o'clock this morning and applied the same fix to the main game.

I ran it up at 06:00 and thought I had broke everything.


(https://i.postimg.cc/xdZCdRnS/Desktop-Screenshot-2018-10-29-06-19-42-60.png) (https://postimg.cc/8FhDKL7y)


Then I remembered all my lighting is created by the sky shader, which uses the time of day from the world state, which is currently set to DateTime.Now.

So I looked out of the window and the sun was just coming up. As luck would have it, a passenger jet was flying overhead at about 25,000 feet and it just glowed as it picked up the first light from over the horizon.

Panic over.  :D
Title: Re: Weekly progress report
Post by: Stainless on October 29, 2018, 12:47:18 AM
AND!!! that showed up that I had forgotten to apply the world location (latitude,longitude) to the sun calculation.


(https://i.postimg.cc/y8sWpjVV/Desktop-Screenshot-2018-10-29-06-39-47-85.png) (https://postimg.cc/JGY1GbDg)

At last it is starting to look nice.

Title: Re: Weekly progress report
Post by: DarkBlueBoy on October 29, 2018, 01:56:55 AM
Great work Stainless. I can't wait to see what you show us next.
Title: Re: Weekly progress report
Post by: Stainless on October 29, 2018, 04:15:55 AM
A target rich environment.


(https://i.postimg.cc/4d37xrs3/Desktop-Screenshot-2018-10-29-10-08-05-84.png) (https://postimg.cc/bGKN6VGX)

Does anyone know the spacing for a standard German formation?

I used 20 metres, but it doesn't look quite right to me.
Title: Re: Weekly progress report
Post by: P51vsFw190 on October 29, 2018, 06:56:27 AM
Try 40 or 50 meters.

Cheers!

James
Title: Re: Weekly progress report
Post by: Pursuivant on October 29, 2018, 07:07:17 PM
Does anyone know the spacing for a standard German formation?

It could vary. The spacing within each "vic" of bombers looks right for a close formation, but it could been looser in practice especially when flying in difficult weather conditions or attempting to avoid flak. Spacing between planes in the vee might be ~25-30 m, with the trailing bombers at a 60* angle rather than a 45* angle off the lead bomber.

Spacing between elements of the formation is a bit too close - more like an airshow than a combat formation. 30-50 meters is probably closer to the mark.

Additionally, the squadron might form a "diamond" formation:           ^
                                                                                               ^    ^
                                                                                                  ^

But, for a first attempt the formation's not unrealistic, with the squadron in a sort of modified echalon right formation.
Title: Re: Weekly progress report
Post by: Stainless on October 30, 2018, 02:52:27 AM
The formation was taken from a document online, which of course means it is probably fantasy :)

Don't know how much time I will get to work on it today, but I think we need a formation designer and some fuzzy logic.

Then the formation can be fed into the AI for the bomber pilot and control inputs generated.

Finally after a lot of hard boring work, I am starting to get to the fun stuff.
Title: Re: Weekly progress report
Post by: Pursuivant on November 02, 2018, 06:04:53 PM
Don't know how much time I will get to work on it today, but I think we need a formation designer and some fuzzy logic.

Then the formation can be fed into the AI for the bomber pilot and control inputs generated.

This is a great idea since it allows others to input details later.

Just make sure that there's a method of linking formations created in the formation generator to other elements of the game, such as specific aircraft, units (by nation, air force, unit, or element), conditions (e.g., day/night, VFR/IFR), locations (e.g., geographic locations, theaters of conflict, altitudes, or map locations), time period, and possibly mission. That way all the air history geeks can fine-tune historical formations, mission builders can customize formations for specific missions, and online squadrons can design custom unit formations.

Also, make sure that there's a way of easily building larger formations from smaller formations, with users being able to specify the nature of the larger units (e.g., USAAF heavy bomber "vee" > 1944 USAAF heavy bomber squadron combat box > 12-43 to 7-44 USAAF 15th AF B-24 6-group box  > 1-44 to 7-44 USAAF 15th AF standard wing formation or 1938 IJAAF 3-plane medium bomber shotai > 1938 1938 IJAAF 3-squadron medium bomber chutai > 1938 IJAAF Hiko sentai > 1938 IJAAF 2-sentai Hikodan)

"Nice to have" would be a method of linking callsigns, unit markings, skins, etc. to particular aircraft or formations (e.g., "1st flight," "Redtail-1," "Able Box," or "357th USAAF Fighter Group")
Title: Re: Weekly progress report
Post by: Stainless on November 04, 2018, 03:23:48 AM
We might as well brainstorm this here rather than me implementing something and then having to modify it later.

I am thinking of having text files that can be-parsed in the mission builder.

So let's rough out a text file format here and anyone with any knowledge please chip in.

Let's start with the basics.

Formation nameStringThe name of the formation
Usage datesDate,DateThe timespan the formation was in use
Element typeEnumEither Aircraft, Wing, or Formation
Number of elementsIntThe designed number of elements ( not the actual number )
Element namesString ArrayThe name of each element.  Red 1, 1st flight, Able box, etc.
Element locationVector3 ArrayThe relative position of each element in metres from a key location. Probably should be lead element.
Night modifierVector3For night flying, multiply the relative location by this
Poor visibility modifierVector3For poor visibility, multiply the relative location by this


So you would start by defining a wing.

Something like

Code: [Select]
Bomber Element
1/1/1940 1/1/1945
Aircraft
3
Lead,Port,Starboard
{0,0,0},{-30,-5,-30},{30,-5,-30}
3
2


Then you would build up a combat box...

Code: [Select]
Combat box
1/1/1940,1/1/1945
Wing
4
Lead Element, High Element, Low Element, Low Low Element
{0,0,0},{-50,50,-50},{50,-50,-50},{0,-100,-100}
2
2

Then you could go for another level.

Code: [Select]
Javelin
1/1/1940,1/1/1945
Formation
4
Lead,Group 2,Group 3,Group 4
{0,0,0},{0,2000,100},{0,4000,200},{0,6000,300}
1
1

And then another level above that would give you a whole battle plan.

Would that cover everything?
Title: Re: Weekly progress report
Post by: Pursuivant on November 04, 2018, 04:56:21 AM
The variable list looks good, but the "Element location" string could either refer to a point in space some distance from the various planes in the formation or some portion of a particular aircraft in the formation (e.g., left or right wingtip, tail, nose, dorsal or ventral surface).

**
EDIT: While basing "element" location on a particular airplane, basing it on an aircraft part isn't necessarily such a good idea, since with breaking parts the "element location" could go hurtling to earth, with all the other planes in the formation following it, even if the rest of the "formation lead" aircraft is still flying.

As a related issue, the user should be able to assign conditions which cause other units in a formation or element to break or alter formation, reassemble, swap locations within the formation, or change the lead aircraft. That way you can have units automatically do collision avoidance or evasive combat maneuvers, automatically regroup when planes in the formation are destroyed or are too badly damaged to keep up, etc.

The game could also use a bit of simple "AI" to have planes automatically make simple decisions a real pilot could make, such as not following a destroyed lead aircraft, opening up the formation when there's a high risk of collision, splitting up into smaller elements prior to landing, and so forth.
**


A simple GUI that allows the user to "drag and drop" planes into a particular formation, view them from top, front and side, show distances between planes in an element, and elements in a formation would probably be the most intuitive for a non-programmer to use. Once you've got your elements arranged, there could be a simple menu you can use to name and link individual planes and elements, apply unit/or formation markings, and designate "element location" points which planes and elements formate and maneuver around.

Planes could maneuver like "particles" with the element and unit formations acting as an "emitter mesh" focused on the "element location" point.
Title: Re: Weekly progress report
Post by: Stainless on November 04, 2018, 07:20:18 AM
I think they will end up using a flocking behaviour to determine control inputs, but otherwise yes... I suppose a tool is in order.

I will just add that to my TODO list.....

One day it will get shorter  :(
Title: Re: Weekly progress report
Post by: Pursuivant on November 06, 2018, 08:23:20 PM
Just keep the formation creator relatively low on your TODO list.

I'm a walking feature creep generator and you're a highly skilled game designer and coder who's clearly smart enough to know the difference between "nice to have" and "must have."

That said, you seem to have a genius for quickly creating powerful, reasonably intuitive GUI-based tools that non-coders like myself can use to tweak the game. And, as Google CAPTCHA has amply proven, brilliant computational ideas seem to involve getting lots of other people to do your work for you! :)

I hope that once the core sim sees the light of day, it will become the most powerful and realistic "sandbox" combat flight sim available.
Title: Re: Weekly progress report
Post by: Stainless on November 07, 2018, 12:19:01 AM
Well more along the same line.  ;)

I had a few hours to spare while UE4 built a game I am working on in my day job.

So I attacked another of those awkward "nice to have" jobs. USB devices.

I had hand coded drivers for my devices, but I knew that wasn't ideal and none of you would want to do that. So I fought my way through the black art that is USB HID device handling. I have mostly solved it.

I can now scan a device and detect what user interface components it provides. Then set up a driver for it.

In short. Plug in a HID compliant joystick, throttle, rudder pedals, switch box and it becomes available in game.

There is one problem. Looking at the data there are some gaps in the bitstream. On the X56 flight stick there are 7 unused bits between the buttons and "Generic Desktop Ry".

I have assumed this is to make the value appear on an 8 bit boundary, and that is what the code does. No idea if that is correct for all devices, but it works for the ones I have to test with.


(https://i.postimg.cc/hP8bnSHT/Desktop-Screenshot-2018-11-06-12-20-25-01.png) (https://postimg.cc/KRzgryc8)

(https://i.postimg.cc/Hkp0sqgK/Desktop-Screenshot-2018-11-06-12-20-51-22.png) (https://postimg.cc/hf5Q23hb)

(https://i.postimg.cc/K8JPK0cY/Desktop-Screenshot-2018-11-06-12-21-05-87.png) (https://postimg.cc/BjPLkcKW)
Title: Re: Weekly progress report
Post by: slibenli on November 07, 2018, 03:59:00 AM
Interesting progress, thanks for keeping us updated.
I guess very few people can imagine the dimension of your project.
You definitely have my greatest respect.

]cheers[
Mike

I second that :)
Title: Re: Weekly progress report
Post by: Stainless on November 09, 2018, 07:59:24 AM
You can now set the aircraft and squadron code as well as get the correct roundel for a time period.

Haven't decided how to handle night fighters and navy yet...

(https://i.postimg.cc/63CQ0kPC/Desktop-Screenshot-2018-11-09-14-51-14-49.png) (https://postimg.cc/zbX5Dc8f)
Title: Re: Weekly progress report
Post by: Pursuivant on November 10, 2018, 10:46:14 PM
You can now set the aircraft and squadron code as well as get the correct roundel for a time period.

Looks very nice.

Haven't decided how to handle night fighters and navy yet...

What's the problem with those units?

Different camo, different lighting conditions, something else?

If you're feeling really munificent, another "nice to have" feature would be the ability for the player or mission/campaign designer to place certain "decals"/partial skins/graphic overlays on aircraft, using some combination of plane, unit, time period, pilot assigned to the aircraft (for things like nose art and other personal markings), Air Force, and nationality.

For example, late WW2 USAAF carrier-based aircraft carried their unit markings on the vertical and horizontal stabilizers and on the upper and lower right wing, and usually had the aircraft numbers painted boldly ahead of the national markings on the side of the plane and repeated in smaller "font" near the leading edge of the vertical stabilizer, just above the horizontal stabilizers. Plane numbers might possibly be repeated on the upper portion of the landing gear doors, if they faced forward when the plane was on the ground. With the "decal placement" tool you could create a rule for that system of markings for all USAAF carrier-based aircraft from mid-1944 until 1946, as well as customizing individual aircraft with kill flags just below the cockpit of each plane (based on the usual pilot and the unit's decision to use/not use certain types of personalization).

Mission builders could use a "drag and drop" style GUI to place markings and designate their meaning and the planes they apply to. Players could further customize a plane before a mission by adding distinct personal markings to the existing skin overlays. After a successful mission, a campaign builder could set things up so that the player's plane is updated with new kill or mission markings, and so that "patches" (or even unrepaired damage) appear on damaged aircraft returned to service.
Title: Re: Weekly progress report
Post by: Stainless on November 10, 2018, 11:27:05 PM
The unit identification markings will be added in the mission builder.

The way the code works is ...


I load the mesh files once per type. So if you have a formation of 100 He 111's I only load the mesh once.


For each mesh I create an instance with all the per mesh data. This includes any aircraft customisation. Markings, payload, position, speed etc


So the mission editor is going to have to handle all of this.

Just a note about the mission editor. I am creating a database that the mission builder can use. It doesn't force you to use it, but it makes life a lot easier.

You simply specify the map region and the start date, and it automatically populates the map with airfields and squadrons.

So if you create a mission in the UK starting 10,10,1944 it will add Andrews field as an airbase and move RAF 306 (Polish) squadron to it with it's Mustang 3's.

Title: Re: Weekly progress report
Post by: Stainless on November 11, 2018, 01:27:08 PM
I was pissed off by the rugby yesterday, bloody TMO, so I decided to start something that I new had too be done.

The mission editor.


(https://i.postimg.cc/NfdcB7yq/Desktop-Screenshot-2018-11-11-20-17-52-86.png) (https://postimg.cc/xcN7Pmyt)

The first stage is to define the map area.

(https://i.postimg.cc/6p8DwsJn/Desktop-Screenshot-2018-11-11-20-18-06-09.png) (https://postimg.cc/w1dWcGBj)

Then the app downloads all the SRTM data it needs, these are zipped , so it then unzips them.

(https://i.postimg.cc/CLXcGzXn/Desktop-Screenshot-2018-11-11-19-55-24-53.png) (https://postimg.cc/LnkkR6Hm)

The missing files are usually one minute height maps that are totally water.

Next stage will be to generate the mission map.... which will have to wait until I am annoyed again.

Title: Re: Weekly progress report
Post by: Stainless on November 15, 2018, 01:58:51 AM
Yesterday was one of those frustrating days you get in game development. It's worthwhile talking about as it was a good example of the sorts of things that can go wrong even when you have been writing games for 40 years.

I noticed some strange things happening in the lighting and couldn't find a reason for it. So I decided it was time to add the debug tools I have been planning for a long time.

The first stage of that was to get the collision meshes into the game. Once they are in I can do a ray collision check allowing you to click on an object and have a debug menu come up.

So I modified the modtool to export the collision meshes and the game to load them. Then I added a debug line draw and added code to draw the meshes.

Game crashed.

I looked into it and the debug line draw had over 200,000 lines in the array. Should have been about 3,000. This made no sense. So I changed the code to only draw a single collision mesh with 84 lines. I had over 5000.

WTF.

I swore a lot, then had a coffee, then had a cig, then swore some more.

Eventually I realised what was happening.

The code is heavily multi-threaded. Two cores of the CPU are dedicated to rendering and asset streaming. The rest of the available cores are used by the game update.

The game update creates render command sets which are added to a list for the renderer to handle. The renderer keeps two lists, one it is rendering and one that the update is creating and swaps between them.

The thing I forgot to do was sync the update and render loops.

The update loop is running about 60 times faster than the render loop. So every time the renderer draws the list , it has 60, yes SIXTY copies of the scene to render.

I am not seeing one spitfire and 12 HE-111's

I am seeing 60 spitfires and 720 He 111's, just on top of each other.

And it's still running at 120 frames per second.

Man sometimes this job takes years off your life.


Title: Re: Weekly progress report
Post by: Stainless on November 15, 2018, 03:32:54 AM
Collision meshes in.

They animate correctly, but interestingly it looks like the tail wheel and the flaps don;'t have collision meshes.

One step forward, two steps back.... sigh.


(https://i.postimg.cc/qR5mB5Fq/Desktop-Screenshot-2018-11-15-10-24-16-17.png) (https://postimg.cc/LYjkNN2F)
Title: Re: Weekly progress report
Post by: Stainless on November 15, 2018, 05:17:40 AM
Added debug menu


(https://i.postimg.cc/vZDW0Wty/Desktop-Screenshot-2018-11-15-12-06-56-13.png) (https://postimg.cc/9D5RMwkg)

(https://i.postimg.cc/13TD2fvq/Desktop-Screenshot-2018-11-15-12-07-10-72.png) (https://postimg.cc/NK6yrfqs)
Title: Re: Weekly progress report
Post by: hello on November 15, 2018, 05:40:13 AM
Wow, every time I visit this thread, another amazing step forward. This is one exciting project :o :o :o :o
Cheers!
Title: Re: Weekly progress report
Post by: Pursuivant on November 24, 2018, 04:25:44 AM
Collision meshes in.

They animate correctly, but interestingly it looks like the tail wheel and the flaps don;'t have collision meshes.

Probably not your fault.

A couple of years ago I did a lot of empirical testing of IL2 damage models and I noticed a number of minor collision mesh errors, particularly in the oldest models like the Spitfire Mk IX. In particular, tail wheels aren't modeled in a number of the models. It wouldn't surprise me at all if other parts of the aircraft were missed as well.

Additionally, for what appears to be a simple collision mesh there are loads of what appear to be extraneous polygons. The extra polygons might actually be damage modeling of critical internal systems, but if that's the case the DM is just wrong (e.g., cable runs modeled as simple lines and without modeling bell-cranks, pulleys and similar hardware, very crude and excessively large area covered by the internal parts of the wing cannon model).

Again, not your fault, but it offends my senses of graphic design, historical accuracy, and fair play.
Title: Re: Weekly progress report
Post by: Stainless on November 24, 2018, 11:57:54 PM
Quote
Again, not your fault, but it offends my senses of graphic design, historical accuracy, and fair play.

 ;D

I love that. I often get into arguments with games coders for whom code has to be "good enough for the job".

My school motto was "good enough isn't good enough" and I believe that, when it comes too code, good enough often comes back to bite you in the ass.

I have just had to go to Kiev for a week, left the comfort and warmth of my home, food I enjoy, beer that doesn't give me a headache, to fix problems that mostly fit into this model.

One problem was known to the coder when he left Kiev, he just didn't mention it to anyone and hoped that it didn't get spotted by the games testers. Of course it did. Games testers love finding bugs and will go to extreme lengths to produce them.

The fix took me two beers to come up with and five minutes to code.

I think I will add to the modtool an option to generate a collision mesh for a mesh part, tail wheels are really important for the physics. Without it every landing will damage the tail of the aircraft.

Title: Re: Weekly progress report
Post by: Pursuivant on November 25, 2018, 10:00:20 AM
I think I will add to the modtool an option to generate a collision mesh for a mesh part, tail wheels are really important for the physics. Without it every landing will damage the tail of the aircraft.

FWIW, the same things I said about tailwheels also apply to landing skids, which also aren't modeled for some aircraft and which would have the same effect on landing/take-off as loss of a tailwheel.

A mod tool that allows you to generate new collision meshes for parts of an aircraft which don't have them would be very cool, especially for modders who create minor variants of an aircraft where some minor system is added or removed. It would also allow somewhat easy upgrades of existing IL2 models to include new systems, like oxygen, electrical systems, radios/electronics, or hydraulics.

The downside is that giving virtually any player the ability to mess with collision meshes and DM potentially compromises the game's integrity as a combat simulation. While there have been all sorts of squabbles about FM and DM for IL2 aircraft over the years, one of the sim's strengths has always been the tight control that developers (later mod teams) maintain over DM/FM. One of the things that ultimately killed the MS CFS franchise back in the day was the ability to cheat with both hands in online play by fiddling your plane's DM/FM.
Title: Re: Weekly progress report
Post by: Stainless on November 26, 2018, 01:20:23 AM
Hmmm I hadn't thought about cheating at all.

Will have to give this some thought.

I can immediately see a way to create a hash table for certain key aspects of the simulation as part of the match making for the online version which would detect gross modifications to things like weapon damage , ammo, etc.

Might be worth while starting a separate thread for discussion of what needs to be checked.
 
Title: Re: Weekly progress report
Post by: Pursuivant on November 28, 2018, 08:31:54 PM
I'm assuming that best practice is to build in security features as you go along to preserve the integrity of FM, DM, AI behavior, access to rare or advanced equipment, terrain and weather generation, and so forth, but I'm utterly clueless in this area. The SAS mod team are the folks to talk to.

For a "sandbox" type sim like you're designing there is an inherent tension between player freedom to modify the game environment as they wish vs. screwing over other players. Obviously, cheating is no big deal for offline solo play (other than people posting and complaining about videos of grotesquely modded aircraft on Youtube), but it's an absolute deal breaker for online and/or multiplayer play.

I think the best ways to deal with stuff like that is transparency (i.e., make it hard to hide evidence of cheating) and having a "referee" who can lock down certain aspects of the sim during multiplayer play.

Depending on how sophisticated you get with FM and DM, you might also be able to have unchangeable elements of the game which are based on a given airframe's physical model so that cheating becomes impossible. For example, any attempt to soup up the FM of a Sopwith Camel to give it the flight characteristics of an F-16, or vice-versa, is inherently doomed to fail because the airframe of a Sopwith Camel or F-16 will still "fly like it looks" rather than "how it's programmed." Even with the Sopwith's engine output and mass fudged to mimic that of an F-16, you might still have problems with landing gear collapse, extremely long takeoff run, huge turning circle, lack of fuel tankage due to smaller volume, and so forth.

It might also be possible to build hard, realistic limits on historical aircraft performance into the game, with limitations to things like construction methods, drag, fuel consumption rates, compression ratios, or power/mass ratio for engines set by year. That way, if you really want to fly something that looks like an F-16 in a 1918 scenario you can do so, but its still going to behave like an aircraft built in 1918 - that is, not very well at all.

Conversely, if you want to fly something that looks like a Sopwith Camel in a 2018 scenario, but which is made with state of the art technology, you'd get something much better than a 1918 aircraft but that's still no match for an airframe designed to take full advantage of modern tech. (That said, being able to model duels between modern kit-built imitations of historic aircraft might be fun, especially if you've always thought that the Oshkosh Fly-In would be more interesting if live ammo were involved. ;) )
Title: Re: Weekly progress report
Post by: Stainless on November 29, 2018, 02:21:42 AM
The way I see multi-player is that it would be set within a time frame. So you would have various modes but the aircraft within each mode would have a set time frame designed by the host, not the game.

The host may decide to allow a very large time frame of course, but if you don't want to take on a F4 with your P47, don't join the match.

Flight dynamics will be very difficult to cheat on. Flight models are not programmed. They are derived from the air frame and it's materials. So I think some kind of moderator who has access to a database which is read by the multi-player code containing hash codes for "approved" air frames will solve all that. Does mean that someone has to be a moderator and control the database though.

Giving the host of the game a "kick him out" button is something I will have to think about. If the host was someone like Mike, then it's a no brainer. Give him the button. However if the host is a twelve year old who spends most of his time on COD telling people what he did to their mother last night and how mush pot he smokes....... probably not.

Needs more thought
Title: Re: Weekly progress report
Post by: Pursuivant on November 29, 2018, 06:13:38 PM
If the game, or important features of it, must be hosted on a server for multiplayer then it makes sense that the server owner is boss, no matter what their maturity level. "My server, my rules." Regular old analog social dynamics can take care of the rest.

For long-term multiplay, it might make sense to allow the server host to designate certain players as "trusted users" or "power users" giving them some or all of the powers that the host has. Likewise, the host could "downgrade" standard user privileges to give certain users "provisional" or "probationary" status.

For example, a power user designated as a flight instructor could be given the power to alter aspects of a given training scenario, either before or during the scenario, while a provisional user might be limited to just flying certain scenarios or certain planes.

User privileges or restrictions could be set up to last for a certain period of time, when performing certain tasks, or when running certain scenarios.

For example, violations of certain rules might result in "time outs" of increasing length, a ban on flying certain (or any) aircraft, a ban on access to certain weapons or ordinance, or a ban on using certain game features.

If you want to steal from forum hosting or online auction software, you could give users the ability to "uprate" or "downrate" certain players, or even give "trusted users" a very limited ability to punish other users who violate the rules (e.g., a one time per day ability to impose a time out on another player, set to begin at some point in the future).

On the upside, giving users the very limited ability to up-rate other players might foster online reputations for sportsmanship and skill, which could translate into real benefits within the game.

For example, players could give a "thumbs up" to a worthy opponent or a particularly courteous teammate (or opponent). Gain enough skill or positive reputation points and you might get first pick of aircraft or crew positions available for a given scenario.

Finally, while it probably won't be built into your game as long as programs like Ventrilo or Teamspeak are available, one of the most elegant and humorous methods of dealing with trolls that I've ever seen is the practice of "dis-em-voweling" whr ll f th trll's ftr psts hv thr vwls rmvd. It not only messes with the troll's ability to carry on trolling, but it also instantly advertises their troll status.
Title: Re: Weekly progress report
Post by: P51vsFw190 on November 30, 2018, 09:14:13 AM
Dis-em-voweling.....

I’ve never heard of that. That sounds like a phenomenal idea. Mind If I use it for my own purposes?


James
Title: Re: Weekly progress report
Post by: Pursuivant on November 30, 2018, 05:36:34 PM
I’ve never heard of that. That sounds like a phenomenal idea. Mind If I use it for my own purposes?

I don't care if you steal it, since I stole it from the moderators of a science fiction forum back in the day.

It's actually quite a clever moderating technique since it's been scientifically proven that it's still possible to interpret the meaning of words even if all the vowels are removed. So, if you really want to read a troll's posts you can do so.
Title: Re: Weekly progress report
Post by: Stainless on December 04, 2018, 02:25:18 AM
I have had a week of dealing with muppets.

In my day job I have to upload my work to a perforce server in Sweden. So I have had weeks and weeks of dealing with the IT department. Which is final and undeniable truth of Karl Marx's theory "The production of too many useful things results in too many useless people. "

At first they insisted I used a VPN. This VPN uses Microsoft MFA. So it times out every 4 hours. Right in the middle of any upload.
Then they insisted they need to build me a new machine and install a tunnel in it. So I re-organised my office to make space for it. Bought £500 of kit so I could actually use it as the machine they sent was useless. Started uploading and got SSL timeouts every 6 hours.
So I split my single changelist into 40 changelists and started uploading them. One by one.  :(
One changelist failed to upload. Looked at it.

The muppet in Stockholm had put the perforce repo in "E:\Program Files\Perforce\Repositories"

That brought up yells of WTF from the two experienced games coders in the company.



Indeed I cannot upload my final change list as the path to the file now exceeds MAXPATH.

Today it got worse as the guy in Stockholm I had been dealing with has moved on to something else and I now have to educate another IT muppet. This one reminds me of the cookie monster. Sigh.

Anyway it gave me some time to work on my game.

Which brought in a whole new set of muppets.

The terrain system is based on latitude and longitude so I need routines to convert from latitude longitude to an earth centric coordinate system. Luckily there is a free library I can use. So I plugged it in and roughed out a terrain manager.

Didn't work. Found the coordinate transformation didn't work. A longitude of 1.1 produced the same coordinate as 1.0. So all my terrain patches were packed into the same space. Sigh

So instead I did the mathematically correct conversion using the WGS84 defined ellipsoid.  Too slow. Frame rate dropped to nothing. Sigh.

So I hacked something in based on a crude approximation and it works.

So I quickly added a deep ocean shader a friend gave to me , and ..... it's crap

(https://i.postimg.cc/K840DcVd/Desktop-Screenshot-2018-12-04-08-56-07-96.png) (https://postimg.cc/18h09SyH)

As usual, I have to do everything myself.

Whimper.

Title: Re: Weekly progress report
Post by: Pursuivant on December 04, 2018, 04:11:12 PM
I have had a week of dealing with muppets.

Although you're probably sick of Swedes by now, Uff-dah.

As a former low-level IT muppet, I'm all too aware of the tendency for high-level "tech support" people to try to cram new problems into existing IT infrastructures, often creating all sorts of stupidity and delays as a result, rather than trying to figure how to most easily and logically resolve the problem with minimal fuss to the user.

At a mass level, low levels users might need that sort of control and management, and the organization's IT systems might benefit as a result, but for power users the only logical solution is to sit down, shut up, listen closely, give them what they need, and get the hell out of the way.

Given all the BS you've had to deal with, it seems simpler, faster, cheaper, and easier for everyone, to ship a carefully-packed portable hard via overnight courier.
Title: Re: Weekly progress report
Post by: Stainless on December 05, 2018, 01:19:21 AM
Quote
Given all the BS you've had to deal with, it seems simpler, faster, cheaper, and easier for everyone, to ship a carefully-packed portable hard via overnight courier.

Oh I have done that. The drive had to be encrypted, which took a day to do. Then specially packaged. The postage cost me £70, but it arrived the next day.

The key for the encryption,,,,,  had to be sent by email...... :-X

Now I am told they have a problem with getting some kit ready for CES and won't be able to fix the problem for the foreseeable future.

The worst thing is one of the coders in Stockholm could solve the problem in 10 minutes, but they won't give him access to the server.

"Always look on the bright side of life ...."
Title: Re: Weekly progress report
Post by: Stainless on December 06, 2018, 04:40:13 AM
I really am having a bad week.

Wrote my own deep ocean shader.... looks ok...

(https://i.postimg.cc/qRFQrLjx/Desktop-Screenshot-2018-12-06-11-31-08-71.png) (https://postimg.cc/S2Wc7W0n)

Not quite what I want but close enough for now..... but look at the prop on the Spit..... WTF is going on now!!!!
Title: Re: Weekly progress report
Post by: DarkBlueBoy on December 06, 2018, 05:37:03 AM
And breathe....

I can't offer much technical assistance - but how about a "you're doing an amazing job!"?? :) :)
Title: Re: Weekly progress report
Post by: Pursuivant on December 06, 2018, 05:14:42 PM
Wrote my own deep ocean shader.... looks ok...

Actually, it looks pretty good, so very good work as a start. Not quite photoreal, but subtly "impressionist".

The main problem is the lack of sufficient parallax with the sun glare on water effect which spoils the illusion of distance and depth of field. That and the fact that the width of the glare pattern is based on the width of sun's core + corona rather than just the core. You only get the broader core + corona glare pattern when the sun has gone low enough that you get a greater level of diffusion from the atmosphere (and/or haze/dust/smoke/whatever, if you plan to model it).
Title: Re: Weekly progress report
Post by: Pursuivant on December 06, 2018, 05:24:13 PM
"Always look on the bright side of life ...."

"And pray that there's intelligent life somewhere up in space, 'Cause there's bugger-all down here on planet Earth." :)
Title: Re: Weekly progress report
Post by: Stainless on December 07, 2018, 05:16:31 AM
Quote
The main problem is the lack of sufficient parallax with the sun glare on water effect which spoils the illusion of distance and depth of field. That and the fact that the width of the glare pattern is based on the width of sun's core + corona rather than just the core. You only get the broader core + corona glare pattern when the sun has gone low enough that you get a greater level of diffusion from the atmosphere (and/or haze/dust/smoke/whatever, if you plan to model it).

Yes it needs more work, at the moment it's just specular and reflection. I have much bigger problems to solve at the moment.

I have solved the propeller issue..

(https://i.postimg.cc/pVnH9nB1/Desktop-Screenshot-2018-12-07-11-47-47-92.png) (https://postimg.cc/23mJMyM4)

The damn thing was getting renderered on the wrong render pass

But I have a big problem with my environment mapping. One view direction constantly glitches. It goes from this nice view ....

(https://i.postimg.cc/LXQ8HK2Y/Desktop-Screenshot-2018-12-07-11-48-57-80.png) (https://postimg.cc/Hc5g2NJd)

To this fecked up one...

(https://i.postimg.cc/8PMfbcTZ/Desktop-Screenshot-2018-12-07-11-49-04-04.png) (https://postimg.cc/Tp2PdRLb)

Totally randomly. About 15 times a second.

It's doing my head in.

I have tried everything I can think of, but if I run the game in RenderDoc.... the problem goes away. I have looked through the code with a fine tooth comb, nothing.

Every time I put debug code in to try and track it down... it goes away.

Whimper

Title: Re: Weekly progress report
Post by: Stainless on December 11, 2018, 03:58:21 AM
Fixed the environment map issue, damn thread ordering issue.

Now I have another problem I have to fix.

I calculate the sun position based on time , date, latitude, longitude..... what did I forget?

When the sun is below the horizon you shouldn't get diffuse lighting.


(https://i.postimg.cc/yNTfhKJN/Desktop-Screenshot-2018-12-11-10-48-02-18.png) (https://postimg.cc/LqnBRr3d)

Sigh..

1 step forward ... two steps back...

Title: Re: Weekly progress report
Post by: Stainless on December 13, 2018, 02:18:34 AM
Okay that problem sorted.


(https://i.postimg.cc/mrFz1bc0/Desktop-Screenshot-2018-12-13-09-10-29-19.png) (https://postimg.cc/R34VjxLR)

Now moon and stars
Title: Re: Weekly progress report
Post by: Pursuivant on December 13, 2018, 02:49:55 AM
When the sun is below the horizon you shouldn't get diffuse lighting.

Actually, it depends.

The picture doesn't look too unrealistic if you assume that the sun has just set "behind" the observer's point of view while still illuminating objects at altitude, and if you assume that there is some massive source of light pollution and haze is creating airglow effects just over the horizon. (e.g., Sunset while the formation is flying just off the coast of modern Los Angeles).

You can also get diffuse light from airglow, haze, etc. when the sun is just below the horizon after sunset or sunrise. At extreme latitudes, you can still have twilight throughout the night near the summer/winter solstice due to the "white night" phenomena. (https://en.wikipedia.org/wiki/Sky_brightness)

If you want to model airglow effects, they will be more visible to observers at high altitudes, since they are able to get a better viewing angle to see long distances through the earth's atmosphere, creating spectacular "corona" type effects which show the atmosphere's limits (e.g., any video of sunrise over earth from the ISS or similar spacecraft). The higher the altitude, the more obvious the airglow effect and the greater the "red to blue" shift from the sun's position on the horizon to the edge of the Earth's atmospheres, but they only really become really obvious above ~10k m ASL. (e.g., https://www.youtube.com/watch?v=WHJ04uuWjLY).

If you wanted to be really fancy with the airglow effects, you could have actual Rayleigh Scattering effects from any large and intense source of light and/or haze, including light pollution from modern metro areas or massive fires like the recent California wildfires or a 1945 Dresden- or Tokyo-style firestorm. Among other things, that would automatically give you big "blood moons" in environments where the moon is close to the Earth's horizon and there are high levels of particulates in the upper atmosphere, give a brownish or reddish cast to the skies over smoggy or extremely dusty areas, and would reduce visible starlight in areas with high levels of light pollution and haze.
Title: Re: Weekly progress report
Post by: slibenli on December 13, 2018, 03:32:08 AM
Concerning atmospheric light scattering you might want to take a look at:
https://hal.inria.fr/inria-00288758
https://ebruneton.github.io/precomputed_atmospheric_scattering
https://www.youtube.com/watch?v=0I7Af2Ev5iQ.
I'm using some of the methods in il2ge (to compute the atmosphere thickness between viewer and object).
Title: Re: Weekly progress report
Post by: Stainless on December 13, 2018, 04:21:45 AM
I calculate the scattering in my shader.

Here it is if it is useful

Code: [Select]

#include "ShaderVariables.inc"



struct appdata {
float3 Position : POSITION;
float4 Normal : NORMAL;
float2 UV0 : TEXCOORD0;
  half4 Tangent : TANGENT0;
  half4 Binormal : BINORMAL0;
};

struct vertexOutput {
float4 HPosition : POSITION;
float3 WorldLightVec : TEXCOORD0;
float3 WorldNormal     : TEXCOORD1;
float3 WorldEyeDirection : TEXCOORD2;
half3  WorldTangent : TEXCOORD3;
half3  WorldBinorm : TEXCOORD4;
  float2 UV : TEXCOORD5;
  half Fog : TEXCOORD6;
  half2 Altitudes : TEXCOORD7;
};

float4 LightDirection = {100.0f, 100.0f, 100.0f, 1.0f};
float4 LightColor = {1.0f, 1.0f, 1.0f, 1.0f};
float4 LightColorAmbient = {0.0f, 0.0f, 0.0f, 1.0f};

float4 FogColor = {1.0f, 1.0f, 1.0f, 1.0f};

float fDensity ;

bool isSkydome;

float SunLightness = 0.2;

float sunRadiusAttenuation = 256;

float largeSunLightness = 0.2;
float largeSunRadiusAttenuation = 3;
float dayToSunsetSharpness = 1.5;
float hazeTopAltitude = 20;

texture DiffuseTexture;

sampler SurfSamplerDiffuse = sampler_state
{
Texture = <DiffuseTexture>;
MinFilter = Linear;
MipFilter = Linear;
MagFilter = Linear;
};

texture SkyTextureNight;

sampler SurfSamplerSkyTextureNight = sampler_state
{
Texture = <SkyTextureNight>;
MinFilter = Linear;
MipFilter = Linear;
MagFilter = Linear;
AddressU = mirror;
AddressV = mirror;
};

texture SkyTextureSunset;

sampler SurfSamplerSkyTextureSunset = sampler_state
{
Texture = <SkyTextureSunset>;
MinFilter = Linear;
MipFilter = Linear;
MagFilter = Linear;
AddressU = mirror;
AddressV = mirror;
};

texture SkyTextureDay;

sampler SurfSamplerSkyTextureDay = sampler_state
{
Texture = <SkyTextureDay>;
MinFilter = Linear;
MipFilter = Linear;
MagFilter = Linear;
AddressU = mirror;
AddressV = mirror;
};

vertexOutput mainVS (appdata IN)
{
vertexOutput OUT;
float4 Po = float4(IN.Position.xyz,1);
OUT.HPosition = mul( Po, WorldViewProjection);

OUT.WorldNormal = mul( IN.Normal, WorldInverseTranspose).xyz;
OUT.WorldTangent = mul(IN.Tangent, WorldInverseTranspose).xyz;
OUT.WorldBinorm = mul(IN.Binormal, WorldInverseTranspose).xyz;

OUT.WorldLightVec = -LightDirection.xyz;

float3 Pw = mul( Po, World).xyz;
OUT.WorldEyeDirection = ViewInverse[3].xyz - Pw;

OUT.Altitudes.x = ViewInverse[3].y;

  float4 pos = mul( IN.Position, World);
 
  float dist = length(OUT.WorldEyeDirection);
OUT.Fog = (1.f/exp(pow(dist * fDensity, 2)));

OUT.Altitudes.y = Pw.y;

OUT.UV = IN.UV0;
return OUT;
}

float4 mainPS(vertexOutput IN) : COLOR0
{
float4 colorOutput = float4(0,0,0,1);
float4 DiffuseColor = tex2D( SurfSamplerDiffuse, float2( IN.UV.x, 1-IN.UV.y));
float4 colorAmbient = DiffuseColor;

// Calculate light/eye/normal vectors
float eyeAlt = IN.Altitudes.x;
float3 eyeVec = normalize(IN.WorldEyeDirection);
float3 normal = normalize(IN.WorldNormal);
float3 lightVec = normalize(IN.WorldLightVec);

// Calculate the amount of direct light
float NdotL = max( dot( normal, -lightVec), 0);

float4 colorDiffuse  = DiffuseColor * (NdotL * LightColor) + LightColorAmbient * DiffuseColor;
colorOutput += colorDiffuse;
colorOutput.a = 1.0f;

// Calculate sun highlight...
float sunHighlight = pow(max(0, dot(lightVec, -eyeVec)), sunRadiusAttenuation) * SunLightness;
// Calculate a wider sun highlight
float largeSunHighlight = pow(max(0, dot(lightVec, -eyeVec)), largeSunRadiusAttenuation) * largeSunLightness;

// Calculate 2D angle between pixel to eye and sun to eye
float3 flatLightVec = normalize(float3(lightVec.x, 0, lightVec.z));
float3 flatEyeVec = normalize(float3(eyeVec.x, 0, eyeVec.z));
float diff = dot(flatLightVec, -flatEyeVec);

// Based on camera altitude, the haze will look different and will be lower on the horizon.
// This is simulated by raising YAngle to a certain power based on the difference between the
// haze top and camera altitude.
// This modification of the angle will show more blue sky above the haze with a sharper separation.
// Lerp between 0.25 and 1.25
float val = lerp(0.25, 1.25, min(1, hazeTopAltitude / max(0.0001, eyeAlt)));
// Apply the power to sharpen the edge between haze and blue sky
float YAngle = pow(max(0, -eyeVec.y), val);

// Fetch the 3 colors we need based on YAngle and angle from eye vector to the sun
float4 fogColorDay = tex2D( SurfSamplerSkyTextureDay, float2( 1 - (diff + 1) * 0.5, 1-YAngle));
float4 fogColorSunset = tex2D( SurfSamplerSkyTextureSunset, float2( 1 - (diff + 1) * 0.5, 1-YAngle));
float4 fogColorNight = tex2D( SurfSamplerSkyTextureNight, float2( 1 - (diff + 1) * 0.5, 1-YAngle));

float4 fogColor;

// If the light is above the horizon, then interpolate between day and sunset
// Otherwise between sunset and night
if (lightVec.y > 0)
{
// Transition is sharpened with dayToSunsetSharpness to make a more realistic cut
// between day and sunset instead of a linear transition
fogColor = lerp(fogColorDay, fogColorSunset, min(1, pow(abs(1 - lightVec.y), dayToSunsetSharpness)));
}
else
{
// Slightly different scheme for sunset/night.
fogColor = lerp(fogColorSunset, fogColorNight, min(1, -lightVec.y * 4));
}

// Add sun highlights
fogColor += sunHighlight + largeSunHighlight;
   
// Apply fog on output color
colorOutput = lerp(fogColor, colorOutput, IN.Fog);

// Make sun brighter for the skybox...
//if (isSkydome)
colorOutput = fogColor + sunHighlight;

return colorOutput;
}


technique SkyDome
{
pass p0
{
CullMode = None;
VertexShader = compile VS_SHADERMODEL mainVS();
PixelShader = compile PS_SHADERMODEL mainPS();
}
}
Title: Re: Weekly progress report
Post by: Stainless on December 14, 2018, 02:05:34 AM
Thinking about it, I should put in a modified lighting equation for altitude. It is easy to do and will make a difference.

Currently I am using the horizontal plane as a filter, all I need to do is use the aircraft's altitude to rotate the plane till it is a tangent to the Earths surface at a point were the altitude intersects the Earth.

This image shows what I mean.


(https://i.postimg.cc/2jwK73GJ/ligthing-mod.png) (https://postimages.org/)

In the case described here, currently the aircraft would have no diffuse lighting. With the mod it would as the purple line would be the filter instead of the red.

It's only a rotation of a vector, but it would make a big difference.
Title: Re: Weekly progress report
Post by: slibenli on December 16, 2018, 06:53:49 AM
I calculate the scattering in my shader.

Here it is if it is useful

Thanks, I'll look into it at some point.
Title: Re: Weekly progress report
Post by: Stainless on December 17, 2018, 05:13:42 AM
Okay back to normal one step forward two steps back....

I dropped in the moon. I use the latitude and longitude as well as the date and time to calculate the position of the moon in the sky, and that seems correct. Needs more testing , but generally looks ok.

Then I calculate the Earths position in heliocentric coordinates and use that as the light direction so I get the correct moon phase. Except it's wrong.

Moon rise.


(https://i.postimg.cc/52tMYz05/Desktop-Screenshot-2018-12-17-11-57-12-05.png) (https://postimg.cc/nCNWNCqM)

A few hours later

(https://i.postimg.cc/FFgtTpkg/Desktop-Screenshot-2018-12-17-11-58-35-77.png) (https://postimg.cc/RqFbFcRN)

WTF!

Has the Earth moved massiveley around it's orbit in a few hours????

Any ideas?

What is wrong with this?

Code: [Select]
        public static Vector3 GetSunDirection(DateTime when)
        {
            //1. Days elapsed since J2000 (1st january 2000 at 12:00)
            DateTime epoch = new DateTime(2000, 1, 1, 12, 0, 0);
            TimeSpan j2000TS = when.ToUniversalTime() - epoch;
            double j2000 = j2000TS.TotalDays;

            //2. Centuries since J2000
            double cJ2000 = j2000 / 36525.0f;

            double inclinationE = (0.00005f - 46.94f * cJ2000 / 3600.0f) * rad;
            double longNodeE = (-11.26064f - 18228.25f * cJ2000 / 3600.0f) *rad;
            double longPeriE = (102.94719f + 1198.28f * cJ2000 / 3600.0f) * rad;
            double meanDistE = 1.00000011f - 0.00000005f * cJ2000;
            double eccenctricityE = 0.01671022f - 0.00003804f * cJ2000;
            double meanLongE = Mod2Pi((100.46435f + 129597740.63f * cJ2000 / 3600.0f) * rad);

            //Position of Earth in its orbit
            double me = Mod2Pi(meanLongE - longPeriE);
            double ve = TrueAnomaly(me, eccenctricityE);
            double pEarthOrbit = meanDistE * (1 - eccenctricityE * eccenctricityE) / (1 + eccenctricityE * Math.Cos(ve));

            //Heliocentric rectangular coordinates of Earth
            double xe = pEarthOrbit * Math.Cos(ve + longPeriE);
            double ye = pEarthOrbit * Math.Sin(ve + longPeriE);
            double ze = 0.0f;

            return new Vector3((float)xe, (float) ze, (float)ye);
        }



Or am I just stupid and missing something obvious.

Title: Re: Weekly progress report
Post by: Pursuivant on December 18, 2018, 02:30:12 PM
Assuming that the moon hasn't suddenly jumped to a new position in the sky (hard to tell because shifted PoV between the two pics), my guess is that you've got the shading effects on the "far side" of the moon a bit too dark, and you're not taking into account the fact that the portions of the moon which are illuminated by the sun are actually "emitting" (actually reflecting) light which better penetrates the Earth's atmosphere.

The fix might be just as simple as making the "moon by daylight" "texture" a bit lighter so that the brightest portions are visible against the morning sky, but the darker portions aren't so visible or shading the texture from white/yellow light on the illuminated portions to "sky color" on the unilluminated portions.
Title: Re: Weekly progress report
Post by: Stainless on December 19, 2018, 04:01:24 AM
No , sadly it's far more serious than that.

It's the parallax problem.

I am trying to mimic a very large object a very long way away by drawing a much smaller object much closer.

However when I do that I can see around the back of the object as it moves around the sky.

The only solution I can see is to render the moon to a texture then draw a quad in the main game scene at the correct point in the sky. One step forward....
Title: Re: Weekly progress report
Post by: Stainless on December 20, 2018, 04:51:37 AM
Anybody else noticed wobbly props on the He111?

https://youtu.be/hjyzAvhj86g
Title: Re: Weekly progress report
Post by: Pursuivant on December 20, 2018, 01:18:01 PM
The only solution I can see is to render the moon to a texture then draw a quad in the main game scene at the correct point in the sky. One step forward....

Or somehow rewrite the algorithm to "bend" light appropriately for a very large, distant object, but just for the moon.

But, no reason for the moon to be an actual physical object as opposed to just being a light source, and since you need a better texture anyway your solution is probably better.

The only sacrifice to realism is that the moon's surface will always be static relative to the Earth, which would only really make a difference if you were writing a space flight simulator!
Title: Re: Weekly progress report
Post by: Pursuivant on December 20, 2018, 01:24:50 PM
Anybody else noticed wobbly props on the He111?

Yes, but I'd want to see it at a different angle and prop pitch/speed before I'm certain.

It might be a weirdness in the way your simulator renders models imported from IL2, but more likely, its some bug created many years ago by 1c and never noticed or fixed until now. The He-111 models are old to ancient.
Title: Re: Weekly progress report
Post by: Stainless on December 21, 2018, 02:15:34 AM
What I am thinking of doing is keeping my current bump mapped moon, but render it to a texture using a calculated moon phase and angle based on latitude, longitude , and date.

This would then be added to the sky as a 2D axis aligned quad.

I would then render a second axis aligned quad over the top for moon glow based on a calculated "moonlight" value to give a glow and the same value could be used as a light source at night lighting objects in the world.

Well that is what I am planning anyway.  :-X
Title: Re: Weekly progress report
Post by: Stainless on January 23, 2019, 08:25:50 AM
So now I render the moon into a texture using a  moon phase angle calculated from the current game date and time.

Then I calculate the moons position based on date, time, latitude, longitude and render the texture at the correct point in space.

I use a variable to position the moon in world space which I need to calculate based on date time, currently it is fixed but when I figure out the equation it will allow me to change the visible size of the moon so we can have super moons.

I also render with a colour which is currently white, when I figure out how to calculate partial lunar eclipses I can modify this colour to give us blood moons.

So far so good, now I just need to add a moon glow effect to the sky....  then add the stars ... sigh.

My TODO list is not a list , it's a fecking encyclopedia.

(https://i.postimg.cc/02xv2Ldx/Desktop-Screenshot-2019-01-23-15-10-25-91.png) (https://postimg.cc/3WLVtfcb)
Title: Re: Weekly progress report
Post by: Stainless on January 24, 2019, 02:26:33 AM
Got the glow in, forgot I need to rotate the moon so looking into that. Happy that you can see the moons reflection in the water.

BUT not happy with the moon phase. Should have changed since yesterday......

One step forward....


(https://i.postimg.cc/N0KdPD39/Desktop-Screenshot-2019-01-24-09-15-16-41.png) (https://postimg.cc/XZ0Krf74)
Title: Re: Weekly progress report
Post by: Stainless on January 25, 2019, 01:07:54 AM
Well the stars went in.


(https://i.postimg.cc/9QCmXKcT/Desktop-Screenshot-2019-01-25-07-57-58-93.png) (https://postimg.cc/fJqnBHtT)

Guess what?

Don't like them.  ::(

I think one of the problems is that the current cheap sky shader doesn't go to black, so time to write a new sky shader then look at it again.

Title: Re: Weekly progress report
Post by: Stainless on January 25, 2019, 01:23:34 AM
I am an idiot.

I realised I wasn't handling star magnitude properly.

I was just using it to calculate an alpha value to draw the star with, now I use it to change the size and alpha.

Starting to look better.


(https://i.postimg.cc/YSb243d9/Desktop-Screenshot-2019-01-25-08-13-49-95.png) (https://postimg.cc/yJ3CtF44)

Now to sort out the sky

Title: Re: Weekly progress report
Post by: Stainless on January 25, 2019, 04:29:09 AM
So added a new sky shader which you can swap to in the render settings, and it looks much nicer.


(https://i.postimg.cc/15d3LjZP/Desktop-Screenshot-2019-01-25-11-18-45-76.png) (https://postimg.cc/56wJzp0k)


EXCEPT .... it has shown up major issues with my ocean shader, which I now have to fix.

Whimper
Title: Re: Weekly progress report
Post by: BT~wasted on January 25, 2019, 04:40:09 AM
Looks just amazing!

I have now words to describe how I admire your work!

I hope that one day I will be able to fly in your virtual skies!
Title: Re: Weekly progress report
Post by: vonOben on January 31, 2019, 03:35:08 AM
Hi Stainless

It's always interesting to come here and check your progress reports!  :)

Impressive for one person to create a completely new flight simulator, I really hope you'll pull it through!  :)

Best of luck!

Best regards

vonOben
Title: Re: Weekly progress report
Post by: Michkov on February 03, 2019, 12:51:14 AM
Looks great.

I also render with a colour which is currently white, when I figure out how to calculate partial lunar eclipses I can modify this colour to give us blood moons.

This maybe a typo here, but just to be sure. Partial lunar eclipses dont cause a blood moon. Only full eclipses will do that, partial only takes a circular chunk out of the full disk. The red of the blood moon comes from light bend through the Earths atmosphere and is really only visible during a full eclipse. In a partial one the faint red light gets drowned out by the still lit part of the moon.
Title: Re: Weekly progress report
Post by: Stainless on February 03, 2019, 01:59:26 AM
yes, I was caught up with the TV reports and got the terminology wrong.

if you know how to calculate lunar eclipses let me know so I can add it to the code
Title: Re: Weekly progress report
Post by: Michkov on February 03, 2019, 03:01:16 AM
Would a catalogue of eclipses do? Because NASA has one online for eclipses both solar and lunar for 2000BC to 3000AD

Solar eclipse catalogue   https://eclipse.gsfc.nasa.gov/SEcat5/SEcatalog.html
Lunar eclipse catalogue   https://eclipse.gsfc.nasa.gov/LEcat5/LEcatalog.html

Also a way to approximately calculate them but there isn't one equation for the whole 5000 years

Solar  https://eclipse.gsfc.nasa.gov/SEcat5/deltatpoly.html
Lunar https://eclipse.gsfc.nasa.gov/LEcat5/deltatpoly.html
Title: Re: Weekly progress report
Post by: Stainless on February 04, 2019, 12:57:27 PM
5000 years.

Shit .

What sort of flight simulator do you think I am building  ;)
Title: Re: Weekly progress report
Post by: Pursuivant on February 04, 2019, 03:37:32 PM
Would a catalogue of eclipses do? Because NASA has one online for eclipses both solar and lunar for 2000BC to 3000AD

Cool site. It also has data on planetary transits for the inner planets and 12 years of ephemeris data for all the planets, if one wanted a completely accurate sky.

With that sort of data, even if Stainless builds a crummy flight simulator, he's still got a great astronomy sim!
Title: Re: Weekly progress report
Post by: Pursuivant on February 04, 2019, 03:45:07 PM
5000 years.

Shit .

What sort of flight simulator do you think I am building  ;)

One that can handle missions like this? :)

https://en.wikipedia.org/wiki/The_Odyssey_of_Flight_33

https://www.youtube.com/watch?v=lYIgEJnddAk
Title: Re: Weekly progress report
Post by: Michkov on February 09, 2019, 03:31:22 PM
5000 years.

Shit .

What sort of flight simulator do you think I am building  ;)

For the inevitable ancient alien mod :)


Which reminds me to you need planet locations too?
Title: Re: Weekly progress report
Post by: Stainless on February 10, 2019, 01:39:58 AM
I have the code for the planets

I know I need to add Venus, it is so visible. However I am not sure which others I have to add.
Title: Re: Weekly progress report
Post by: Arkbird1000 on February 10, 2019, 02:39:27 PM
I have the code for the planets

I know I need to add Venus, it is so visible. However I am not sure which others I have to add.

Mars, Jupiter, and Saturn are bright in the sky. Perhaps Mercury too, as it is also quite visible from the ground, just not as easy to spot.
Title: Re: Weekly progress report
Post by: Jimbo947 on February 11, 2019, 02:32:44 AM
Sirius would be in that league
Title: Re: Weekly progress report
Post by: Stainless on February 11, 2019, 06:05:27 AM
Sirius is already in  :)
Title: Re: Weekly progress report
Post by: Jimbo947 on February 12, 2019, 02:46:47 AM
Another Senior Moment   :( :( :(
Title: Re: Weekly progress report
Post by: Pursuivant on February 12, 2019, 03:07:30 PM
I know I need to add Venus, it is so visible. However I am not sure which others I have to add.

Venus, Mercury, Mars, Jupiter, and Saturn are the planets visible from Earth with the naked eye, but Mercury isn't that important for celestial navigation.

I guess if you want to get really fancy and add some more eye candy to the night sky, you could add in the Periodic Comets (e.g., Halley's Comet) and the periodic meteor showers (e.g., Perseid and Leonid meteor showers). If you wanted to get really really fancy, you could include the brighter artificial satellites. It would probably make more sense to allow such things to be added to the game and let someone else fill in the details.
Title: Re: Weekly progress report
Post by: Stainless on February 14, 2019, 07:49:27 AM
Planets are in.

At the moment I have them on all the time (stars turn off when the sun drops close to the horizon) as I know Venus is often visible during the day.

However this is very crude. I would like a way of computing the correct luminance so I can turn them on and off properly.

Currently Saturn, Mars, and Jupiter are much too visible.

If anyone comes across a good equation, please let me know.


(https://i.postimg.cc/HkDVPF3W/Desktop-Screenshot-2019-02-14-14-42-05-24.png) (https://postimg.cc/Mv56nPhg)
Title: Re: Weekly progress report
Post by: Michkov on February 16, 2019, 07:46:58 PM
Not a formula but at least a starting point, Twilight and it's 3 different definitions. (https://en.wikipedia.org/wiki/Twilight) Which are all based on the declination of the sun below the horizon. Which I assume you have in the code or at least can extract, since you have it move across the sky. In effect you from Nautical twilight (47mins past sunset) onwards you should be able to navigate using the stars. By Astronomical Twilight (70mins past sunset) you should be able to see at least down to the least visible stars, that is dependent on environmental conditions though.

I'd implement it via a function that turns up the global luminance value depending on where the sun is below the horizon. Hitting the two conditions outlined above. I'm not quite sure what the usual magnitude of the navigational stars is but that should be easy to find out.


On another note, your moon phase looks very odd. Ignore the following paragraph if it's still WIP, but the lunar phases look like this

(https://cdn.shopify.com/s/files/1/1212/0982/articles/World-Record-Striper-Moon-Phases_91406367-4d4f-4816-8572-2657d1e4635f_1024x1024.jpg?v=1460489951])

Essentially what you got is a circle which is the fully lit moon and superimposed on it a dark ellipse with its long axis running perpendicular to the moon sun vector. As the moon goes from new to the first quarter, your ellipses short axis goes from the full lunar radius to zero at the first quarter.
In the next quarter you to the same in reverse, you have to switch to an ellipse that doesn't darken the moon but reveals the other quarters as the moon moves towards full.
Waning would be the process in reverse.

In the end the size of the small axis of the ellipse is a function of the angle between Sun and Moon as seen from the Earth.
Title: Re: Weekly progress report
Post by: Stainless on February 17, 2019, 01:26:53 AM
I realised my moon phase calculation is rubbish when I was in Stockholm. Sadly I haven't had chance to change it. (yet)

I render a sphere for the moon and change the lighting position to get the desired moon phase.

I calculate the moon phase using the epoch 1990 day (days since 1st of January 1990) and currently return this as a value in the range 0 - 1

Sadly in the display code I just multiply this by Pi, which is rubbish.

When it comes to the stars I use the angle between the sun position and the horizon to control display, this will be correct no matter the latitude.


Title: Re: Weekly progress report
Post by: Pursuivant on February 18, 2019, 02:43:07 PM
However this is very crude. I would like a way of computing the correct luminance so I can turn them on and off properly.

How much detail do you need?

The nitty-gritty of calculating Apparent Magnitude for planetary objects is fairly complex, and requires calculating planetary orbits, distance of a given body from both the Earth and the Sun, etc. then converting everything from AM to Lux.

If you wanted to handwave it, you could just assume a fixed AM for any given planetary object and have it "fade out" as luminance from competing light sources increases. Otherwise, you go down the rabbit hole into some fairly complex math. (The good news is that if you go that direction, you have the rudiments of a space flight simulator!)

I believe that this is one good entrance to the rabbit hole:

https://stjarnhimlen.se/comp/tutorial.html

This paper also gets into the fiddly bits about calculating AM for planetary objects (KBO in this case):

comethunter.lamost.org/scwrk/THECAL/opam.pdf

For the hand-wavy option:

Planet Min AM Mean AM Max AM (Remembering that when measuring AM negative numbers = brighter)
Venus (-2.98, -4.14, -4.92)
Jupiter (-1.66,-2.20,-2.94)
Mars (+1.86,+0.71,-2.94)
Mercury (+7.25,+0.23,-2.48)
Saturn (+1.17,+0.46,-0.55)

Faintest objects visible with naked eye when sun less than 10* above the horizon: -2.5
Faintest objects observable during day when sun is high: -4.0
Faintest stars visible in urban neighborhood with naked eye: +3 to +4
Naked eye limit: ~+6.0

Apologies if this is TMI or repeats stuff you already know.
Title: Re: Weekly progress report
Post by: Stainless on February 19, 2019, 01:42:12 AM
I have apparent magnitudes for all the stars and planets.

The table of when objects become visible is very useful, but it assumes ground level.

When you are at 45,000 feet the equation is very different  :D

It's a good start though, and has kicked off the little grey cells.

It occurs to me that the angle between the sun and the eye is a key factor, and at 45,000 feet you will be able to see over the curvature of the earth making the apparent horizon lower.... could be something there
Title: Re: Weekly progress report
Post by: Pursuivant on February 19, 2019, 06:13:48 PM
Glad that I could be of use.

Remember that AM assumes perfectly dark skies, with minimal light scattering due to atmosphere (i.e., for practical purposes you can pretend that there is no atmosphere assuming no competing light sources).

Once you get into the stratosphere and above, not only is curvature of the earth more obvious, but the skies above will be a bit darker with even less atmospheric scattering while the skies below will have a bit of extra luminance due to the angle of sunlight/moonlight striking the thicker air in the troposphere.

IIRC, atmospheric density, hence Rayleigh Scattering, is a more-or-less linear function of altitude. Create an invisible sphere for the atmosphere which extends to approximately the altitude of the ionosphere. Then base luminance/illuminance of the atmosphere on altitude plus a chord defined by the points where light strikes the atmosphere vs. where it "exits."

Not only will that give you the cool "sky glow" effects due to light passing through the atmosphere as seen from very high flight/LEO, but it will set up accurate sunrise/sunset and AM of celestial objects effects as seen from altitude. It would also lay the basis for aurora effects which originate at the ionospheric level and get a certain amount of their cool glowing effects from Rayleigh Scattering.
Title: Re: Weekly progress report
Post by: Stainless on February 24, 2019, 04:14:36 AM
Added support for ships


(https://i.postimg.cc/Nj6JjR6F/ship1.png) (https://postimg.cc/QFMk69nZ)
Title: Re: Weekly progress report
Post by: Stainless on March 15, 2019, 02:43:06 AM
Added field of fire components for weapons

Each weapon can have multiple fields of fire so we can make sure you don't shoot off the tail of your aircraft or put holes in the funnel of your pristine war ship.


(https://i.postimg.cc/26s558mk/Desktop-Screenshot-2019-03-15-08-28-40-67.png) (https://postimg.cc/N9xtJt5S)


At the moment I am using the debug camera as the guns target, and when you move into a valid field of fire the gun rotates


(https://i.postimg.cc/44vGc1Qb/Desktop-Screenshot-2019-03-15-08-29-05-38.png) (https://postimg.cc/BtvR9HyX)

Which is working but shows up a bug.

I need to use the hook for the start of the field of fire rather than the guns position.

Anyway some progress at last.

Title: Re: Weekly progress report
Post by: Chaoic16 on March 15, 2019, 07:19:55 AM
That is mind-blown progress!  I have serious respect for huge projects you have been working on for a vastly long time. I have been watching your progress here. I have a question. I am sincerely hoping that we will be able to get to command any ships like game called War Thunder or World of Warships?  I am confident that many of us would love to be able to command any warships and submarines, along with the add-on mods.
Title: Re: Weekly progress report
Post by: Pursuivant on March 17, 2019, 10:27:06 AM
That is mind-blown progress!  I have serious respect for huge projects you have been working on for a vastly long time. I have been watching your progress here. I have a question. I am sincerely hoping that we will be able to get to command any ships like game called War Thunder or World of Warships?  I am confident that many of us would love to be able to command any warships and submarines, along with the add-on mods.

While the ability to import models and objects from games like Warthunder or "World of X" would be welcome, they'd need serious physics updates if they were to have anything like realistic damage modeling or movement, never mind tactics. That seems like a major project for Somebody Else to work on in the future, while Stainless creates a kickass flight simulator.

That said, keeping the sim open enough that reasonably accurate water and ground movement physics could be added in the future seems like a good idea.
Title: Re: Weekly progress report
Post by: Pursuivant on March 17, 2019, 10:35:14 AM
Each weapon can have multiple fields of fire so we can make sure you don't shoot off the tail of your aircraft or put holes in the funnel of your pristine war ship.

Impressive progress, but make sure that this is one of the features that can be turned off by vehicle designers and players.

Realistically, early flexible guns didn't have electronic "cut outs" to prevent them from shooting their own vehicle. Even after simple electromechanical firing cut-out mechanisms were introduced (after WW1, prior to WW2) they could still fail and some AC or gun positions didn't have them at all (e.g., the flexible waist-mounted MG on US heavy and medium bombers). Overexcited or careless crew could shoot up their own airplanes!
Title: Re: Weekly progress report
Post by: Stainless on March 17, 2019, 10:39:08 AM
Then you just add a single field of fire and see what happens  :D
Title: Re: Weekly progress report
Post by: Stainless on March 19, 2019, 05:00:45 AM
Added support for hooks

And there sure are a lot of them on the Illy.


(https://i.postimg.cc/W1Mf8Q38/Desktop-Screenshot-2019-03-19-10-49-59-27.png) (https://postimg.cc/zyGjX2TH)
Title: Re: Weekly progress report
Post by: Stainless on March 27, 2019, 09:34:36 AM
Inspired by the book I just bought, I decided to add 2D graphics support to the engine and start the player record code

This is a book on a desk in your quarters.

Activating it brings up this scene

(https://i.postimg.cc/qvJ8SCwv/Desktop-Screenshot-2019-03-27-15-21-29-16.png) (https://postimg.cc/fJPt0y1G)

These pages are defined by code so we can do different nations, time periods etc.

(https://i.postimg.cc/c4m3RLWy/Desktop-Screenshot-2019-03-27-15-21-06-05.png) (https://postimg.cc/N5KLYYLp)

The fonts are signed distance fields, so you only need a single font file and then display it at (almost) any size

Title: Re: Weekly progress report
Post by: DarkBlueBoy on March 27, 2019, 10:00:06 AM
That's a really neat touch Stainless. The font you've chosen looks good. Does it just use a standard TTF?
Title: Re: Weekly progress report
Post by: Stainless on March 27, 2019, 12:54:07 PM
I have a tool you run that takes a ttf file and outputs a bitmap and a csv (text file)

My code reads this and allows you to render text strings at any size.
Title: Re: Weekly progress report
Post by: BT~wasted on March 27, 2019, 02:26:14 PM
I like the design! Looks very authentic because of lots of details.

Looking forward to write my name in one of them  :D
Title: Re: Weekly progress report
Post by: Pursuivant on March 30, 2019, 08:04:05 PM
That empty space on the desk just begs to be populated with period- & nation-specific stuff: personal equipment, uniforms with insignia & decorations, maps, manuals, paybooks, personal belongings, etc.
Title: Re: Weekly progress report
Post by: Stainless on April 02, 2019, 06:55:15 AM

(https://i.postimg.cc/GtYxFjwP/Desktop-Screenshot-2019-04-02-13-44-17-09.png) (https://postimg.cc/wRqNHLB3)

Started putting in the basic stuff from flight training school
Title: Re: Weekly progress report
Post by: max_thehitman on April 25, 2019, 11:00:58 AM


Very very cool  8)
Thank you !
Title: Re: Weekly progress report
Post by: tomoose on April 25, 2019, 02:20:21 PM
Finally, the personal "customizable" log book.  Nice touch and excellent idea.
Title: Re: Weekly progress report
Post by: LuseKofte on May 15, 2019, 03:19:57 AM
When you said you would attempt this endeavor years back I really did not believe you would  get this far.
Not that I did not think you could not do it, but simply the fact of the tremendous workload.
I thought this would be abandoned.
I am very impressed
Title: Re: Weekly progress report
Post by: Stainless on May 16, 2019, 11:11:51 AM
Sorry I haven't been posting recently, my contract with Tobii got cancelled early so I had to run around and got a new one, I had some time off, and now I am working on a big code block.

I am writing my own flight dynamic model, it's almost at the test stage and treats all mesh parts as individual aerodynamic elements.

So each wing section has it's own aerodynamic entry, each fuselage, fuel tank, weapon, blah blah

This means if you drop a bomb you will feel the difference in the flight characteristics, if you lose your rudder I don't have to write code to figure out what happens. I just let the model do it's thing.
Title: Re: Weekly progress report
Post by: Chaoic16 on May 16, 2019, 07:32:04 PM
That is truly a great idea!  With that, we can even have both historical and alternative historical "what if" with the secret project aircraft from Germany, USA, UK, Soviet, Japan, and other countries flying as realistic as possible.
Title: Re: Weekly progress report
Post by: slibenli on May 17, 2019, 04:15:59 AM
Sounds exciting!
Title: Re: Weekly progress report
Post by: Stainless on May 18, 2019, 12:33:49 AM
First view of the FDM designer


(https://i.postimg.cc/9MkqmcBZ/Desktop-Screenshot-2019-05-18-07-27-48-54.png) (https://postimg.cc/mzQrVfJg)

The grey bricks are point masses, you can see wings, horizontal + vertical stabilisers, fuselage, gear, point masses, thrusters, etc.

The two thrusters are so hard to see, but they are tied into weapon fire. So you fire the guns and the physics system feels it.

Now to do the test code


Title: Re: Weekly progress report
Post by: Pursuivant on May 19, 2019, 05:13:35 AM
That is truly a great idea!  With that, we can even have both historical and alternative historical "what if" with the secret project aircraft from Germany, USA, UK, Soviet, Japan, and other countries flying as realistic as possible.

As long as you have Reynolds Numbers or equivalent for wing airfoils. Some of the necessary data isn't available for poorly documented or "paper" aircraft.

More practically, if the game engine allows you to modify flight model info on the fly, is the potential to add and subtract equipment, alter mass or CoG based on damage or consumption of stores (or even movement of passengers), and to change flight performance based on damage.

For example, let's say you're flying a B-17 and the nose compartment gets a big nasty flak hit. The blast kills the navigator and bombardier, blowing their bodies out of the plane, and also blows away much of the nose ahead of the cockpit. This creates massive amounts of drag and changes the plane's CoG to make it tail heavy, but also reduces the plane's total mass by a good bit. Let's also say that the blast forces part of remaining nose bits downward, creating a sort of an airfoil which makes the plane want to fly upwards in addition to its other problems.

If the FM allowed for dynamic changes to mass, drag, lift, etc. then you could realistically handle the crisis by ordering equipment to be jettisoned and crew to be repositioned to fix CoG problems, dropping bombs to reduce overall mass, setting trim tabs and applying constant pressure on the stabilizers to keep the plane from climbing, etc.

On a more benign level, you could easily add gun pods, equipment, etc. by modeling them as different bits of the aircraft with their own FM & DM. For example, you could add or remove RDF loops, radios, radar equipment, etc. or modify baseline aircraft with chemical or water tanks, MADD "stingers" or AWACS saucers.

It could also allow better modeling of composite aircraft.
Title: Re: Weekly progress report
Post by: Stainless on May 19, 2019, 07:10:42 AM
So started testing.

I need someone to sanity check this for me.

I have loaded a model of a Spitfire IIa and ran the simulation at a fixed altitude and speed just changing the attitude of the aircraft from -15 degrees (15 degrees nose down ) to 90 degrees nose up.

I have then plotted the drag and lift. Does it look right? I think I have drawn the wrong label on the wrong graph.



(https://i.postimg.cc/7hdvVzFK/Desktop-Screenshot-2019-05-19-14-02-14-23.png) (https://postimg.cc/N26PGKfX)
Title: Re: Weekly progress report
Post by: sniperton on May 19, 2019, 08:15:21 AM
Just a blind guess, but why would drag (labeled as lift) drastically decrease in the region between ca. 15 and 45 degrees? Or why would lift (labeled as lift) drastically increase in the region between 45 and 90 degrees if 15 degrees represents the critical AoA for stalling?

It would be great to know which chart is which and whether your model counts with boundary-layer separation at a critical AoA or it simply calculates component forces?  ;)
Anyway, wait off the opinion of someone more knowledgable, and  ]cheers[



Title: Re: Weekly progress report
Post by: ildifa on May 19, 2019, 10:11:45 AM
I agree with Sniperton, the plots you posted raise a few questions... It doesn't seem to me that they are just mislabeled.

In very general terms, the lift should start with a negative value at -15 AoA, and reach zero at a slightly negative AoA (as the wings have a built-in angle of incidence); increasing more or less linearly until the max lift AoA (which is the stall angle of attack, let's say 20°), after which lift goes down abruptly.

The drag plot should start slightly positive, reach a minimum around the AoA where lift is zero, then increase in a less steep curve than lift; at the stall AoA drag starts to rise sharply.

Here is attached an example plot:

(https://i.postimg.cc/mg8fVYS7/Screenshot-75-edit.png)

I took it from a videogame, so it's not super accurate, but I think it explains well what I was trying to describe!

Sorry if I've been too wordy, or explained stuff you already know   ]read2[

Cheers
Title: Re: Weekly progress report
Post by: Stainless on May 20, 2019, 04:13:17 AM
Yes, I think something is very wrong.

I will have to look at it tonight.

What I think is happening is that the code is rotating the resultant forces into the world frame when I want them to be in the local frame.

So the graphs would be upside down to start with , and also transformed by the pitch of the aircraft

Then it starts to make a bit more sense. You can see the wing stall in the lift graph , and the drag would be the right general shape, maybe with an offset I am missing.

Anyone know roughly what aoa the spitfires wing stalls at?



 
Title: Re: Weekly progress report
Post by: sniperton on May 20, 2019, 04:39:01 AM
The Spitfire wing is somewhat special, but for your preliminary test you can take a number between 15 and 18 degrees.
Title: Re: Weekly progress report
Post by: Stainless on May 20, 2019, 12:33:22 PM
Well this looks a bit better.

The forces were in the wrong coordinate set.


(https://i.postimg.cc/tgYXfR7w/Desktop-Screenshot-2019-05-20-19-30-50-95.png) (https://postimg.cc/Y4BKLH6z)
Title: Re: Weekly progress report
Post by: sniperton on May 20, 2019, 01:53:48 PM
Lift is a matter of opinion and judgement (and I leave it to the savants), but I personally doubt that stalling the wings makes just a small bump down.
On the other hand, drag is definitely not what I would expect. It's hard to believe that drag at -10 could be way off the value at +10 degrees of AoA. The values should be largely the same with a small margin (the differences being due to wing incidence and airfoil shape).
Just my uneducated guess  ;)
Title: Re: Weekly progress report
Post by: Stainless on July 16, 2019, 05:14:40 AM
Experiments with my new deferred renderer and FFT water

https://www.youtube.com/watch?v=1Vg7tcC7UlE


(https://i.postimg.cc/c1wY3nsD/Desktop-Screenshot-2019-07-16-12-05-19-03.png) (https://postimg.cc/SjQJFjY8)
Title: Re: Weekly progress report
Post by: hello on July 18, 2019, 12:27:18 AM
Perfect storm brewing...   ;D
Title: Re: Weekly progress report
Post by: slibenli on July 18, 2019, 03:08:01 AM
In case you haven't seen it:

https://www.youtube.com/watch?v=2AVh1x-Uqjs

I will probably integrate this into il2ge at one point.

Demo with code: http://www-evasion.imag.fr/Membres/Eric.Bruneton/OceanLightingFFT.zip
Paper: http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Article@125fe8a8322_1ac3379/article.pdf

Another one - looks a bit more natural I think
https://www.youtube.com/watch?v=CeJCNmI-B7s

Title: Re: Weekly progress report
Post by: Pursuivant on July 21, 2019, 11:43:53 AM
Is there any way to easily get white combers and wind spray on the top of the waves? Curling waves that "break" at the top?

From altitude, it's far easier to to determine sea state by the white wave crests than from viewing wave motion. If you're trying to land on or near water, the white crests also give you a sense of wind direction and speed, as well as dangerously shallow areas and wind-sheltered areas.
Title: Re: Weekly progress report
Post by: Stainless on July 21, 2019, 11:38:59 PM
I am working on that, at the moment I am using the steepness of the surface normal, which is just wrong.

I need to work out the derivative of the surface normal, so where the normal rapidly changes direction is where the foam will form.

Of course this need to be at the top of the wave, so I need to use the sign of the derivative as well.
Title: Re: Weekly progress report
Post by: Pursuivant on July 24, 2019, 04:22:35 AM
I am working on that, at the moment I am using the steepness of the surface normal, which is just wrong.

Any possibility of just using the elevation of the wave? It's very rare that you have low waves with combers on them, unless it's something unusual like downdraft from a helicopter's blades or very high winds across a narrow body of water.

I need to work out the derivative of the surface normal, so where the normal rapidly changes direction is where the foam will form.

Couldn't you just use wind direction? Unless the waves are getting pushed up by a beach or reef, the combers will be on the downwind side of the wave.

Arguably, that would be better physics modeling, since the foam/comb at the top of the wave is formed by more or less straight-line air currents pushing the wave top.

Of course this need to be at the top of the wave, so I need to use the sign of the derivative as well.

Not necessarily. If you look at videos of really agitated seas, like in a Beaufort Force 10+ Storm/Hurricane, the entire sea surface appears to be white. The main thing is the degree to which the water's surface is whipped by wind, creating froth.

Of course, the real trick is getting a decent looking effect while still being thrifty with graphics processing power required.
Title: Re: Weekly progress report
Post by: Stainless on July 24, 2019, 10:15:22 AM
So I get the derivative of the normal to find the potential points to add foam.

Then get the dot product of the normal and the wind direction to filter those potential points to points that are down wind.

And vary the decision variable of the last stage based on the strength of the wind.

so in pseudo code

Code: [Select]
  float foam = 0;
  if (delta_normal > constant1)
 {
      float dw = dot(worldspacenormal,winddirection);
      if ((dw > 0)&&(dw > constant2))
      {
           foam = dw;
      }
 }
Title: Re: Weekly progress report
Post by: Stainless on September 03, 2019, 02:02:49 AM
I haven't done an update for a while, but I am working !

I have merged a lot of code into a single library which I am calling GuruEngine

This has my existing forward renderer in it and I have added the deferred renderer so you can swap between them.

At the moment I am fighting with transparency. It is a hard thing to get right in a deferred renderer, and we have a lot of transparent plane parts to deal with.

Once I have sorted that out I will post some screenies, then my plan is to get all the various lights on the aircraft in and operational.

Title: Re: Weekly progress report
Post by: Stainless on September 17, 2019, 12:53:19 AM
Something to show you at last

Moonlight

https://www.youtube.com/watch?v=kF30rViiAhw&feature=youtu.be

Title: Re: Weekly progress report
Post by: slibenli on September 17, 2019, 03:39:13 AM
Nice.
Regarding transparency - I find this an interesting method: http://casual-effects.blogspot.com/2014/03/weighted-blended-order-independent.html
Title: Re: Weekly progress report
Post by: ianp on October 12, 2019, 05:52:35 PM
Flat Earth - Euclids Elements Geo(Earth) metrein (Measure)- earth is demonstrably a plane

https://www.youtube.com/watch?v=XzHgJK09vjk
Title: Re: Weekly progress report
Post by: Stainless on October 23, 2019, 06:54:35 AM
Done some more work on the game object animator.

Very frustrating.

When you load an object it looks like this.


(https://i.postimg.cc/qqKwc4Ft/Desktop-Screenshot-2019-10-23-13-50-03-73.png) (https://postimg.cc/Wq20TLTj)


Not very helpful.

So I added a simple layout system, which results in this.

(https://i.postimg.cc/wB3hc9y6/Desktop-Screenshot-2019-10-23-13-50-48-92.png) (https://postimg.cc/wt8y98QP)

Still not very helpful.

You can see that the heart is here...


(https://i.postimg.cc/63Jy2KCb/Desktop-Screenshot-2019-10-23-13-51-14-01.png) (https://postimg.cc/LqDHwrCj)

But what is it?  so many lines.....


I am going to have to do more work here


Title: Re: Weekly progress report
Post by: SAS~Storebror on October 23, 2019, 07:22:10 AM
Looks a bit like the IL-2 Great Battles Mission Editor :D

(https://i.ibb.co/zm9xgN7/editor.png)

]cheers[
Mike
Title: Re: Weekly progress report
Post by: Stainless on December 29, 2019, 04:13:17 AM
So I need a static object editor so I can add details elements to the terrain.

Since I don't have an army of graphic artists, I have to use public domain objects, which are often in wavefront obj format.

So I need a tool to convert them and a simple way to animate them.

The tool allows you to simply add animators and create a structure instead of just a polygon soup.

https://www.youtube.com/watch?v=t6arMdLz7pA&feature=youtu.be

Hmmm   .... would this be useful for IL2?

Title: Re: Weekly progress report
Post by: SAS~Ghost129er on December 29, 2019, 05:13:27 AM
You have me here...

Jk jk but now, serious stuff. I had provided the aircraft for trial purposes. If you can send me a PM telling me what you need and stuff I'll do my best to help out but the problem is I'm slightly (quite actually) busy/occupied with things but want to help out.

Again, shoot a PM if you can and then you'll be able to tell if I can be of help or not.  8)
Title: Re: Weekly progress report
Post by: Pursuivant on December 30, 2019, 06:37:19 PM
Hmmm   .... would this be useful for IL2?

Quite likely, as long as the hit on frame rates due to animations isn't too heavy.

IL2 could benefit from static objects with moving parts - waterfalls and spillways with moving water, windmills, windsocks, flags, and trees which are blown by the wind, objects floating on water which rock with the waves, buildings which visibly collapse due to damage, etc.

While it might be too much work, the ability to have an object respond to some aspect of the environment - such as wind, waves, gravity, or bomb blasts - would be incredibly cool. For example, imagine that windmill in your example being able to change direction and blade rotation speed based on wind direction and speed.

The same concept could be used for fires or floods that spread to engulf and effect terrain objects, although the programming required to implement it might be excessive. (Imagine a Dambuster mission where your bombs could actually breach the dam, allowing you to watch the dam collapse, the reservoir behind it drain, the structures downstream getting swept away, and the landscape flood!)

A similar idea might allow for fully-animated vehicles, such as tanks with treads that move and turrets that turn.
Title: Re: Weekly progress report
Post by: Stainless on December 31, 2019, 02:25:40 AM
Generating a Live.Him from this is trivial.

I can add that today.

Animation means delving into java, HeirMesh::chunkSetAngles seems to be the logical place to do the animation and the object would have to be a AnimatedActor I guess.

Any of the java experts want to point me in the correct location?




Title: Re: Weekly progress report
Post by: Stainless on December 31, 2019, 06:52:03 AM
wind direction animator, just realised I need a link to wind speed. No wind no change in direction.

https://www.youtube.com/watch?v=zD-BvEa5VI4&feature=youtu.be
Title: Re: Weekly progress report
Post by: Pursuivant on December 31, 2019, 04:43:42 PM
Wow!

That was fast and very cool!

You've just opened up IL2 to smoke, fire, and dust which change direction and shape with wind speed, kite and barrage balloons which change direction and tether angle based on wind direction and speed, sailing ships which have sails which move based on wind speed and direction, windsocks, flags, etc. which accurately indicate wind speed and direction, and all manner of other cool stuff.

This is a huge step towards realistic water landings (assume that wave speed/direction, height and reach are also somehow factored in) and is a massive aid to pilots of small, light planes which fly at lower altitudes (e.g., WWI or FAC/FO light aircraft).
Title: Re: Weekly progress report
Post by: Stainless on January 01, 2020, 01:21:44 AM
Yes, the main reason I wanted to add this code was so you had visual cues for wind speed and direction.

I need guidance on the java side to make it easy to add the animation, then I will publish this tool and all of you can play with it.

Title: Re: Weekly progress report
Post by: Pursuivant on January 01, 2020, 04:52:33 AM
Would it be easily possible to link to other physical elements in the game, like water movement, gravity, or "X sort of object at Y location"? Also, if If the animator supports animated textures that brings an entirely new dimension to ground objects: things that change color, pattern, or light intensity. Lighthouses, stoplights, blinking lights, outdoor movie screens, neon billboards, airfield runway control lights and glide angle landing aids.

The combinations allow players to easily program:

* Buoys or floating docks which rock on the waves or which follow river currents.

* Floating debris, dye, or oil patches which move with wind and waves.

* Objects that slowly sink into water.

* Waterfalls, dams, and spillways, landslides & avalanches, buildings which visibly collapse when destroyed.

* More realistic parachute/drogue behavior (e.g., the possibility that parachutes can tear, tangle, burn, or spill their air).

* Falling bundles of "Window."

* Radar dishes and similar devices which track a particular aircraft's movement.

* Visible waypoint or mission objective markers which appear or vanish when the player achieves some goal. (For example, Rise of Flight has training missions where you have to fly through giant artificial rings in the sky which change color once you've gone through them.)

More realistically, you could have flares or fires on the ground which are extinguished when a player achieves some objective or just rolls past them on a takeoff or landing run. (Great for covert SOE/OSS missions where temporary airfield lights only go on when the player's plane gets near and which are extinguished immediately after the plane passes them on landing.)

* Animated landing signal officers aboard aircraft carriers who give you correct paddle/light signals based on your behavior during the landing approach. Animated ground crew who do things like pull chocks away, ride on the aircraft's wing to guide it during taxi, start engines (either manually or with a Huck starter), or cheer you as you take off or land. Animated aircrew who physically move or perform some action on your command.

* Herds of animals which panic and run when an aircraft gets too close. Flocks of birds which respond to aircraft movement. People who run for cover when an aircraft gets too close!
Title: Re: Weekly progress report
Post by: Stainless on January 01, 2020, 05:34:21 AM
I can do most of them.

I can see places in the java code that expose a lot of the variables I would need to change. So as far as the engine goes, it can be done.

I am happy to right a load of animators that can be attached to objects, BUT I need a java expert to point me at the correct way of doing it.

To be more precise, how would these objects get into the game?

My best guess is that in the mission editor you would need to add these objects as AnimatedActors.

I could then change the AnimatedActor base class to support my animators, and write a bunch of them.

My tool would then output a java class that controls the animation as well as a live.him and a set of msh files. Oh and collision meshes.

If that is something you guys want, then let me know and I will have a look at it.

Title: Re: Weekly progress report
Post by: Stainless on January 02, 2020, 04:50:20 AM
Damn got another problem to solve.

To get multiple animations to work properly, I have centralised all the mesh parts.  I calculate the centre of the mesh part and subtract that from all positions then create a translation matrix to position it properly in the world.

This allows me to rotate a mesh part and attach other parts to it.

However the centre point may not be the centre of rotation I need as can be seen in the video below.

https://www.youtube.com/watch?v=13WByNk8Flo&feature=youtu.be
Title: Re: Weekly progress report
Post by: Stainless on January 03, 2020, 03:53:51 AM
Added option to centralise an object about an axis, fixed the problem in the previous video
Title: Re: Weekly progress report
Post by: Stainless on January 09, 2020, 03:53:11 AM
Decided I needed to really get stuck in, the first stage of this is to generate mission maps.

I don't have a team of graphic artists I can task with creating maps, so I decided to write an app that uses GIS data to generate maps of any region of the world at any scale.

The data is out there, so why not use it.

Went really well at first.

(https://i.postimg.cc/SNJ15D7v/Desktop-Screenshot-2020-01-09-10-50-04-60.png) (https://postimg.cc/7frNJ1R3)

Notice something ?

I don't think the M25 was around in 1940  :)

Title: Re: Weekly progress report
Post by: Pursuivant on January 09, 2020, 07:01:04 AM
"We shall fight in the caravan parks, we shall fight in the housing estates, we shall fight in the shopping centres and on the motorways, we shall fight in the industrial estates; we shall never surrender" :)

Seems like a relatively simple cleanup job in Photoshop or similar program, at least as long as the post-war motorways don't overlap prewar roads and they don't share a common color.

Of course, there's been a ridiculous amount of change to coastlines and other geographical features since the 1940s. It might be simpler to make it easy for players to import their own GIS data and to customize existing maps by adding or removing certain types of features. Sussing out historical roadways, coastlines, etc. from WW2 era maps and aerial photos is the sort of semi-skilled labor that fans do well.
Title: Re: Weekly progress report
Post by: Stainless on January 11, 2020, 05:11:18 AM
Well I started again using a lot of the code I had already written.

(https://i.postimg.cc/gjpBxNSr/Desktop-Screenshot-2020-01-11-11-59-00-87.png) (https://postimg.cc/2bHxJFff)

Once you have selected the region you want using the centre latitude and longitude and scale, set the output bitmap size, you can turn on the features you want to include.

(https://i.postimg.cc/xdYkFm4M/Desktop-Screenshot-2020-01-11-12-00-19-89.png) (https://postimg.cc/DSjySSFw)

Now I just need to add a load more shape files and databases.

The code allows you to specify your own colour scheme so the maps can be given your own style.

Adding data is pretty easy. First you convert the dbf file supplied in the GIS data to CSV.

The header includes a value "Featurecla" this is used to colour the lines/polygons. Each one has  an entry in the colour scheme.

Some databases require more detail, for these you look for "Type" and add the types to the colour scheme.

Then add code to load the database and shape file.

Attach it to a checkbox so it can be turned on and off and that's it.


Title: Re: Weekly progress report
Post by: Stainless on January 14, 2020, 05:19:13 AM
Well starting to get there

The image you see in the tool is distorted by the screen resolution.

An example output is here.

(https://i.postimg.cc/TPS8FRx2/test1.png) (https://postimg.cc/WDMfJctx)

Now I am going to add the option to include your own GIS data.

Title: Re: Weekly progress report
Post by: Stainless on January 14, 2020, 01:11:50 PM
Wow.

There sure were a lot of airfields in the UK in 1940


(https://i.postimg.cc/dt3sZJFq/test1.png) (https://postimg.cc/1fxhLh4T)
Title: Re: Weekly progress report
Post by: Stainless on February 04, 2020, 01:24:40 PM
https://youtu.be/FkUi9zAPxcY
Title: Re: Weekly progress report
Post by: Stainless on February 05, 2020, 02:10:24 PM
Finally sorted out the normals in AC3D

The files do not include normals, instead each sub-object has a crease value.

The documentation says "this is used to determine smoothing normals", which isn't very descriptive.

So I worked out smooth normals for every sub-object, then when I convert the AC3D file into a static mesh, I calculate a face normal for each triangle and calculate the angle between the face normal and the smoothed normal.

If this angle is greater than the crease value, I use the face normal.

It seems to work....


(https://i.postimg.cc/DZZqNGjw/Desktop-Screenshot-2020-02-05-21-05-11-26.png) (https://postimg.cc/rdB00D2B)
Title: Re: Weekly progress report
Post by: Stainless on February 06, 2020, 10:08:41 AM
Realised I was being stupid with the moon rendering.

Just needed a custom blend equation


(https://i.postimg.cc/HnpBxp1h/Desktop-Screenshot-2020-02-06-17-05-47-30.png) (https://postimages.org/)

(https://i.postimg.cc/FzDGk29s/Desktop-Screenshot-2020-02-06-17-05-52-54.png) (https://postimages.org/)

(https://i.postimg.cc/05fV4JpR/Desktop-Screenshot-2020-02-06-17-05-58-59.png) (https://postimages.org/)
Title: Re: Weekly progress report
Post by: Stainless on February 09, 2020, 04:04:03 AM
Having a problem calculation ambient occlusion maps.

I have tried several techniques, the closest I have so far is shown below.

I am taking each vertex and shooting 16 rays up from it within a 45 degree cone. If the ray intersects any part of the mesh, I increment a counter. So I get 16 levels of grey scale per vertex.

I then render the mesh into a texture using the AO value as the colour of each vertex.

(https://i.postimg.cc/fLjgLxQP/skin10-ao.png) (https://postimg.cc/r0s9ZRmG)

You can see it is almost correct.

Areas near the fuselage are darker than the wings. The top of the fuselage is brighter than the wing route.

But it is not correct.

The underside of the fuselage near the join with the wings should be bright. There are seems. it's just wrong.

Any ideas?
 
Title: Re: Weekly progress report
Post by: Stainless on February 16, 2020, 09:24:06 AM
In game particle editor, not quite finished

https://youtu.be/AVIMKxFQdKo
Title: Re: Weekly progress report
Post by: Stainless on February 22, 2020, 09:45:00 AM
Changed glass shader.

I now take three refracted rays and sample the environment map, mix it with one reflected ray, then add in a single specular term.

I think it looks better


(https://i.postimg.cc/yNNNzvyd/Desktop-Screenshot-2020-02-22-16-40-31-08.png) (https://postimg.cc/4YrG6vMk)

(https://i.postimg.cc/k46X2GZP/Desktop-Screenshot-2020-02-22-16-40-54-14.png) (https://postimg.cc/7G4ycHwK)
Title: Re: Weekly progress report
Post by: Stainless on February 23, 2020, 12:40:27 PM
Started turret AI code

https://youtu.be/-lU0BY2FpSQ
Title: Re: Weekly progress report
Post by: Stainless on February 29, 2020, 04:29:30 AM
Attempting to calculate lead angle for the nose turret on the HE111's

Not quite right I think but close.

Could do with example code from IL2 if anyone has some.

https://www.youtube.com/watch?v=RPt3ykvmztI&feature=youtu.be
Title: Re: Weekly progress report
Post by: Stainless on March 05, 2020, 08:13:51 AM
Getting very close now


https://www.youtube.com/watch?v=Yz3LCy9T3bM&feature=youtu.be
Title: Re: Weekly progress report
Post by: DarkBlueBoy on March 05, 2020, 08:58:41 AM
Like many, I have watched this since you began. It is an incredible technical effort and to start to see elements coming together in such manner is very impressive Stainless. Not that you need me to tell you that! :)

Title: Re: Weekly progress report
Post by: Stainless on March 06, 2020, 03:07:27 AM
Thank you.

I am working on a deal with a friend. He wants me to work with him on a very big project which I can't talk about, but the key thing is it will make me enough money to be able to spend more time on this.

I have also reconnected with a friend who has the hardware knowledge and kit I am missing that will allow the two of us to manufacture real world cockpit instruments.

At first I will get them to talk to my game, then I intend to get them to talk to IL2.

So you will be able to make a cockpit for your favourite aircraft at a much lower cost than is currently possible.

When it comes to anything in this game, members of this ... well I was going to call it a forum, but it's more like a family now ;D will get everything I can give for free, and the things I can't give away at a much reduced price.

The credits on this game will include all of you, so might need a cup of coffee or two to sit through them all...  ;)
Title: Re: Weekly progress report
Post by: Stainless on March 25, 2020, 12:52:13 PM

Physics problem anyone?

https://www.youtube.com/watch?v=BTx4N9GYKCE&feature=youtu.be

Title: Re: Weekly progress report
Post by: sniperton on March 25, 2020, 01:30:07 PM
It seems to me alright, provided
- the three wheels do not touch the ground simultaneously (hence the rolling movement through X and Y);
- the gears and the airframe are unbreakable;
- no dampening for the gears / no energy absorption through the airframe;
- therefore the gear springs (and the airframe) counteract too effectively and redirect the full energy of the impact (or even more?)
(Sorry for my English)
Title: Re: Weekly progress report
Post by: Stainless on March 26, 2020, 05:06:13 AM
I have solved the problem with the spring forces.

The damping coefficient was way out.

I still have problems with friction which I hope to fix today.

At the moment the aircraft settles nicely, then accelerates slowly backwards due to the angle of the front undercarriage.

The friction is not enough to stop the plane ????

The trials of tribology

Title: Re: Weekly progress report
Post by: Mission_bug on March 26, 2020, 05:17:58 AM
Like many, I have watched this since you began. It is an incredible technical effort and to start to see elements coming together in such manner is very impressive Stainless. Not that you need me to tell you that! :)

Likewise, the technical aspects are way over my head so unfortunately like many here not able to contribute to the thread in any meaningful way, however, to say what you have done so far is very impressive Stainless is I think a understatement, good luck with the rest of it. 8)

Take care and be safe.


Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: sniperton on March 26, 2020, 05:53:06 AM
The friction is not enough to stop the plane ????

Do you mean that the plane never comes to a full stop? That there's always a minimal movement left, even if it's smaller and smaller?

If yes, and if you don't want to create a complex mechanical model, the quick and dirty solution would be to specify a small threshold value below which momentum ceases to drive forth the plane.

BTW, what about gear break and break forces?

Title: Re: Weekly progress report
Post by: Stainless on March 26, 2020, 09:54:46 AM
Oh no, it's much worse than that  :)

The aircraft ACCELERATES backwards.....  :P

I know what the problem is , just need to find the time to fix it.

Then I can move onto the more interesting stuff, like lift.

Interestingly though I looked at JSBSim and YaSim and neither of them factors in additional drag when the landing gear is lowered.

Both just go "the wheels are not on the ground, early out"

I have factored in a drag force proportional to the landing gears extension.
Title: Re: Weekly progress report
Post by: sniperton on March 26, 2020, 10:40:50 AM
Sounds great. Forgive me if I'm trying to point out trivial things, it's only because sometimes I'm unclear about what your code is supposed to do in the given situation.  ;)
Title: Re: Weekly progress report
Post by: Stainless on March 27, 2020, 03:50:46 AM
No worries.

The game is based on an entity component system.

So you add a GearComponent to the game object. This gear component has a bunch of parameters like location, up vector, spring and damping , etc.

As well as that it has a list of mapped command strings like BrakeCommand String "LeftBrake". In the update loop the component looks at the state component for the variable "LeftBrake" and applies it.

That way we can do everything in the game object editor

So the spitfire I am working on has three gear components as you would expect. Two are identical apart from the location.

One of the good things about this structure is that you have damage values per component. So your left main undercarriage may not function but the right main works fine just as in real life.

When you map input devices, I have a input control system that is per aircraft. So some aircraft will have separate commands for each brake and some only one.

I am trying to make the code as flexible as possible and have most of the simulation stuff done in the game object editor so you can create new aircraft et al much easier than you can in IL2
 
Title: Re: Weekly progress report
Post by: Stainless on March 27, 2020, 12:10:12 PM
Still not there

https://www.youtube.com/watch?v=NUKW404M2tc&feature=youtu.be

Title: Re: Weekly progress report
Post by: Stainless on March 29, 2020, 01:03:10 PM
Taking a break from physics.

I have decided I need to change to a physically based material system, so I want to have a second texture per object.

This texture will store 4 values

RedAmbient occlusion value
GreenRoughness value
BlueReflectance value
AlphaEmission value

As a first stage of this, the object editor can now generate an ambient occlusion map

The result is subtler than I expected, and at the moment I am only calculating ambient occlusion values per vertex, which is obviously wrong. Look at the steps to see what I mean. The centre of the step should not be occluded.




(https://i.postimg.cc/9QBvqz4z/no-ao.png) (https://postimg.cc/VJd7xfWc)

(https://i.postimg.cc/zfX4w5W7/with-ao.png) (https://postimg.cc/VJp71xK0)
Title: Re: Weekly progress report
Post by: Stainless on April 02, 2020, 02:23:01 PM
Started physically based rendering

Bugs to fix, but getting there

https://www.youtube.com/watch?v=HNr3Fi5oTJE&feature=youtu.be
Title: Re: Weekly progress report
Post by: andoodle on April 03, 2020, 05:46:05 AM
I apologize for getting on anyone’s nerve, Mr. Stainless, but about that building in your latest video, I need to know. Did you create the model of that building by using a model-making software, and if not, did you import that model from either the original IL-2 Sturmovik game, IL-2 Sturmovik: Forgotten Battles (and/or its “Aces Expansion Pack”), Pacific Fighters (which can be used as an add-on for IL-2 Sturmovik: Forgotten Battles), IL-2 Sturmovik: 1946 or its B.A.T. super-mod/expansion-pack?

I apologize for making a long post, but I felt that I needed to get it off my chest. With that in mind, I wish to know. Thanks.
Title: Re: Weekly progress report
Post by: Stainless on April 03, 2020, 11:29:26 AM
I have a pack of freeware buildings designed and released for FSX many years ago.

My tool can convert them to modern formats and then add game specific stuff.

I generally have to completely re-texture them as ambient occlusion requires a very good texture map.

And I often tweak them in a 3D package

They are good as a base mesh though
Title: Re: Weekly progress report
Post by: Stainless on April 03, 2020, 12:06:58 PM
well I think PBR is worth it

Original (re-textured )

(https://i.postimg.cc/xT6g9vcK/Capture-1.png) (https://postimg.cc/TpWn9Wjw)




With PBR


(https://i.postimg.cc/TPGzBjSn/Capture.png) (https://postimg.cc/XrH1C5nv)


The PBR texture


(https://i.postimg.cc/L6Q7xKBK/Cinema-pbr.png) (https://postimg.cc/YhgbSPsb)


Red = roughness, Green = occlusion, Blue is metalness   

Alpha will be emissive

Title: Re: Weekly progress report
Post by: Stainless on April 05, 2020, 07:12:17 AM
So I have played with the lighting equation ,,,,,, a lot! ,,,,, but I think it's okay now.

https://www.youtube.com/watch?v=oWQ3-DYthu4&feature=youtu.be

You have to generate the PBR texture by hand , so do you guys think it is worthwhile?

Title: Re: Weekly progress report
Post by: Stainless on April 16, 2020, 12:29:29 PM
I have so many tools I have written as test apps, it's silly, so I have decided to pull most of them into a single editor.

This of course meant that I had to write a new GUI... I always write a new GUI. It's an addiction.

Normally I search all over the internet for nice textures and spend ages stitching them together into something that looks good, bollocks to that.

I wrote a shader that fakes specular shading for a 2D region and used that throughout. No textures.

Looks okay



(https://i.postimg.cc/9QyJnrsB/Desktop-Screenshot-2020-04-16-19-24-20-03.png) (https://postimg.cc/K1vPKvGK)
Title: Re: Weekly progress report
Post by: Stainless on April 19, 2020, 10:31:03 AM
Seems to be working out well, didn't take very long to generate a map

I found one horrible thing doing this. The shape files which are my source for all the maps are split into elements. Line lists, polygon lists, that sort of thing.

Polygons are just a list of points , so to draw a filled polygon is not a trivial thing.

So I found an open source library called MonoGame.Extended which said it had support for filled polygons, looked nice so I installed it changed my code to use it.

Didn't work. So I looked at the source and it called another open source library called Triangle.

So I got rid of MonoGame.Extended and grabbed Triangle and changed my code to use it. It had loads of different techniques for changing an array of points into a list of triangles.

None of them worked. The GIS data was just too complicated for it.

So I swore a lot. Had a cig. Quick beer.

Then I sat down and wrote  a simple scan line converter based on the first polygon renderer I wrote in assembler 40 years ago. Came out to less than 100 lines of code, and guess what ?

WORKS PERFECTLY!  ;D

Modern techniques are just that MODERN, not necessarily better.

https://youtu.be/jjPVbv5u8LE


(https://i.postimg.cc/SNdHNwyk/Europe.png) (https://postimg.cc/N5yddC9z)
Title: Re: Weekly progress report
Post by: Ibis on April 20, 2020, 05:36:03 AM
Amazing work
Title: Re: Weekly progress report
Post by: Stainless on May 16, 2020, 03:52:08 AM
After much thought I have added a scripting system, but as usual this is not a normal scripting system.

I have used C# as the scripting language which means that while developing scripts you can edit them outside the game, but when the script is complete, it can be added to the games source code and built into the game.

To test it is working, I have started the aircraft script for the Spitfire IXc

At the moment I have added the AI driven startup procedure, so it turns on the magnetos, pumps the primer then fires the starter cartridge.

For the debug build , you get a message display you can use from the script to check what is happening. So no need to debug the game, just print out the variables you want to monitor.

The script has access to the renderer, so you can draw debug graphics, and start particle system, etc.

Here you can see the script interface in use.


https://www.youtube.com/watch?v=maGN2ghfQwM&feature=youtu.be

Now I have to add the merlin engine to the game object and see what happens.



Title: Re: Weekly progress report
Post by: Stainless on May 30, 2020, 04:51:24 AM
A friend of mine saw the physics demo, ever since he has been taking the piss out of me for my ground plane.

Sigh.

This brought me back to airports. So I noticed I had some airports from FSX and decoded the data files used and started my own importer.

Most of the data is simple, runways, towers, objects, pavements, no problem.

But taxiways are a problem.

The storage used is awful.

You have an array of points , then an array of lines.

The array of lines is not organised into chains, just point 234 to point 1290

You can see the lines in the video below.

So I am going to have to write a big chunk of clever code to turn this into something useful.

Before I do this, has anyone seen any code anywhere that does this?

My problem is going to be the junctions. I want to add the correct markings, convert the lines into odd shaped polygons, all sorts of little bits of detail to make it look correct.

Anything anyone throws at me gratefully received.

https://www.youtube.com/watch?v=Ma0a3Q8yAYM&feature=youtu.be



Title: Re: Weekly progress report
Post by: edc1 on May 30, 2020, 08:01:28 AM
Hi Stainless,

Just to make matters worse the airfields
In IL2 have hidden spawn points (that you can show if selected)
the only programming I can do is with my satnav!!!
cheers edc1
Title: Re: Weekly progress report
Post by: Stainless on June 01, 2020, 12:40:50 PM
Boundary fence turned out okay.


(https://i.postimg.cc/1z01YsDQ/Desktop-Screenshot-2020-06-01-19-36-42-89.png) (https://postimg.cc/QBMzFL64)
Title: Re: Weekly progress report
Post by: Pursuivant on June 01, 2020, 08:30:31 PM
This brought me back to airports. So I noticed I had some airports from FSX and decoded the data files used and started my own importer.

This seems like fiddly work best left to fans at some point in the future.

If you're wanting to procedurally generate airfields,

ICAO standards are here:

https://www.pilot18.com/icao-annex-14-aerodromes/

USDOD standards for marking modern runways are here:

https://www.wbdg.org/FFC/DOD/UFC/ufc_3_260_04_2018.pdf

The US FAA standards for airfield design, construction and marking are here:

https://www.faa.gov/airports/engineering/design_standards/

The FAA also has some freeware software which might conceivably be useful:

https://www.faa.gov/airports/engineering/design_software/

Useful web page with color graphics which are easily swiped and modified:

https://mycfibook.com/book_pages/airport-signs-markings-and-lighting/

Historical standards for airport construction and marking meaning wading into a massive thicket of archival material. If you can get your hands on them, historical Jeppeson Charts might be the best concentrated source for airfield design and markings from the 1930s on.
Title: Re: Weekly progress report
Post by: Stainless on June 02, 2020, 01:03:17 AM
Thanks mate, that is really useful data.

I chose to work with FSX files because I already wrote code for importing apt.dat airport definitions, but this data has no buildings.

FSX data has buildings and other scene dressing items like stationary aircraft, fire trucks, etc.

I have got to the stage where I really need at least one good looking scene so I can finalise a lot of the renderer and an airport is the perfect stress test.

Title: Re: Weekly progress report
Post by: Pursuivant on June 02, 2020, 03:20:31 AM
I have got to the stage where I really need at least one good looking scene so I can finalise a lot of the renderer and an airport is the perfect stress test.

It also helps that a lot of FSX terrain objects are highly detailed, look gorgeous, and there are entire libraries of add-ons.

Of course, they lack that most essential element of flight simulator terrain objects - you can't blow them up! :)
Title: Re: Weekly progress report
Post by: Stainless on June 02, 2020, 04:52:24 AM
Oh I will work on that  :)
Title: Re: Weekly progress report
Post by: Stainless on June 04, 2020, 01:53:48 AM
So coming together


(https://i.postimg.cc/vT2BXyrv/Desktop-Screenshot-2020-06-04-08-49-28-60.png) (https://postimg.cc/bSbpNKFG)

(https://i.postimg.cc/Dymm0Whp/Desktop-Screenshot-2020-06-04-08-50-14-10.png) (https://postimg.cc/XpSnDYp9)

I still have to sort out taxi ways, they are doing my head in.

Looking at the data they are marked as invisible, so I am assuming they are used by AI.

But where the hell are they defined ?

Anyone got any expierience with FSX
Title: Re: Weekly progress report
Post by: Stainless on June 05, 2020, 08:16:38 AM
This is so frustrating

I added vegetation to the airport, and I am not happy with the result. It is obvious to me I am going to have to replace all the vegetation meshes with something much better.

So far I have been using freeware tools to extract data from the BGL files, but while doing the vegetation I found a load of flags that don't get extracted by the freeware tools.
Things like sampler state, and blend mode are defined in the BGL file but ignored by the freeware tools.

So I have no choice but to write my own.

When this tool is done, it will have to automatically look for replacement meshes for the ones in the BGL files, so all I will end up using is object name and transform. Damn, more work



(https://i.postimg.cc/dVFRdz0H/Desktop-Screenshot-2020-06-05-15-06-26-40.png) (https://postimg.cc/MvsjJ3VV)

(https://i.postimg.cc/hGP9ZTTV/Desktop-Screenshot-2020-06-05-15-06-47-35.png) (https://postimg.cc/5XTY6HPt)

(https://i.postimg.cc/t4z3z2ZX/Desktop-Screenshot-2020-06-05-15-06-59-01.png) (https://postimg.cc/yDk31hy5)
Title: Re: Weekly progress report
Post by: Stainless on June 11, 2020, 06:49:40 AM

Added a day night sequence and started adding lighting.

Just added calvert so far , so many different bloody types to work through. :o

Just using sprites for lights at the moment. This is only the editor, the game will use a baked lightmap so will look a lot better, but I need the lights in before I can bake a lightmap.

Still haven't figured out taxiways, anyone every looked at them in FSX ?

https://www.youtube.com/watch?v=NKbZ7k5qTm4&feature=youtu.be
Title: Re: Weekly progress report
Post by: Mission_bug on June 11, 2020, 12:56:35 PM
Awesome stuff, seems to be coming on in leaps and bounds, excellent. 8)


Take care and be safe.


Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: Pursuivant on June 14, 2020, 01:49:05 PM
I added vegetation to the airport, and I am not happy with the result. It is obvious to me I am going to have to replace all the vegetation meshes with something much better.

One trick might be to have the option of making certain objects slightly random in location and/or orientation along their various axes.

For example, if you put down a rectangular group of identical tree objects, the location randomizer offsets each tree's location by some random amount along the X and Y axes so the grid pattern becomes a bit less obvious. You could then rotate the tree object by some random amount from 0-180 degrees around its Z axis so that, at first glance, identical tree objects don't look so uniform. Then, slightly rotate each tree along its X and/or Y axes by 0.5-2 degrees so that they come out of the ground at very slight random angles. That gives you more realistic tree farms and cultivated woodlots.

You could also specify that certain objects follow a line defined by some other object being spaced at a certain distance, orientation, and interval from the defining object. A variation of the same trick could be used to define objects that appear on or near two different objects which intersect or parallel each other. That allows you to procedurally generate scenery items along roads, define barriers where two roads parallel each other, or define railroad crossings where a road crosses a railroad track.

As for MSFS taxiways, is it possible that they're just defined as polygons and curves defined by mathematical points and then "clipped" where they intersect so the textures don't overlap and suitable markings can be laid down near the intersection?
Title: Re: Weekly progress report
Post by: Stainless on June 15, 2020, 10:32:59 AM
The taxiways are really confusing me.

They don't mesh together as you would expect, so I have a whole bunch of points defined, that is obvious.

Then you get an array of paths which go from one point to another. That's it. The points are always close together.

So I thought like you that I could just connect them all together into chains, so point 1 -2, point 2 -3, point 3-4, and so on.

But that doesn't work and when I try to connect them all together that way I get a load of unconnected short paths.

Now I could possibly work with that , except the path structure includes these values

Code: [Select]
public class RunwayTaxiwayPath
    {
        public String Type;
        public int Start;
        public int End;
        public float Width;
        public float WeightLimit;
        public bool DrawSurface;
        public bool DrawDetail;
        public String Surface;
        public String Name;
        public bool CenterLine;
        public bool CenterLineLighted;


The two booleans DrawSurface and DrawDetail are always false.

It makes no sense
Title: Re: Weekly progress report
Post by: Stainless on June 16, 2020, 06:53:33 AM
https://github.com/PaulBlythe/Fox1/blob/master/README.md
Title: Re: Weekly progress report
Post by: Pursuivant on June 22, 2020, 05:56:24 PM
The taxiways are really confusing me.

It appears that runways and taxiways in FSX are more complex than I thought. There are many features you can define, such as runway surface texture and aprons along the edges of the runway or taxiway. You can also define taxi paths for AI aircraft. It's also possible that there are additional parameters which define load-bearing areas for a taxiway/runway although they don't appear to be used in FSX.

I have no idea how these various parameters are defined, but it's possible that if you get them mixed up you get textures like you've described.

One possibility is that rather than defining just one rectangle or curve the numbers actually define three or more areas - the taxiway area and the areas bordering the taxiway. That gives you the option of, say, concrete taxiway but earth aprons, or plowed taxiways but snow-covered aprons. Aprons of different textures could also have effects on dust being kicked up by engines or problems with lack of load-bearing capacity should you go off the taxiway.

As for the FSX DrawSurface and DrawDetail booleans, it appears that those are null values which are just applied to aprons and taxiway values. They were included in FSX but never implemented in the stock game. They have been implemented in derivatives of FSX like Lockheed Martin's Prepared3D and in payware add-ons to FSX. In those cases if their value is set to 0/False then they don't appear in the game.

If you haven't yet seen this page, you might find it helpful:

https://www.fsdeveloper.com/wiki/index.php?title=BGL_File_Format
Title: Re: Weekly progress report
Post by: Stainless on June 24, 2020, 03:29:29 AM
Hi Pursuivant,

Yes it is looking a mess.

I agree the taxiways records in the file seem to be used only by AI, but that gives me the problem of finding how the taxiways are defined for the renderer.

They have to be drawn by something, so where is the data used to draw them?

At the moment I am trying graphing code to connect all the various taxiway paths into something sensible, but they just don't connect as I would expect.

To be honest I would not be suprised to see aircraft piled up in a traffic jam at certain points of the airfield  :)


I started writing an importer based on the doc you pointed out, but when I tested it, it was wrong  :(

I have a couple of tools I am using now. One converts the BGL file to XML.

Another just shows a view of what is in the file, but it shows raw data and interpreted data which is bloody useful.

Using these tools I can write my own code to extract and convert lot's of the features. Objects, lighting, runways, etc are all there waiting for rendering code to be written.

It's just taxiways that are doing my head in.

Thanks for looking at it man.




Title: Re: Weekly progress report
Post by: Stainless on July 03, 2020, 02:48:52 PM
Started putting together the items I need for a useable airport

This windsock is very simple, but functional for now.

I still need to generate a few bits of the mesh , and handle wind direction, but as you can see it will help you land an aircraft in a cross wind

https://www.youtube.com/watch?v=1ijmJM5zkNc&feature=youtu.be
Title: Re: Weekly progress report
Post by: Stainless on July 04, 2020, 09:50:22 AM
Added spacer and connection bar so it looks good enough for the low res version


(https://i.postimg.cc/0Qt697bg/Annotation-2020-07-04-164907.png) (https://postimg.cc/wymxVyXF)


Now to do the lit version

Title: Re: Weekly progress report
Post by: Stainless on July 04, 2020, 01:52:10 PM
Lit version


(https://i.postimg.cc/sgC0F7rn/Annotation-2020-07-04-205126.png) (https://postimg.cc/gn4K8wrR)
Title: Re: Weekly progress report
Post by: Stainless on July 07, 2020, 05:08:37 AM
Seems to work okay at night


(https://i.postimg.cc/3NNrnBDb/Desktop-Screenshot-2020-07-07-12-07-08-66.png) (https://postimg.cc/H8GCLbzQ)
Title: Re: Weekly progress report
Post by: Stainless on July 14, 2020, 01:54:12 PM
Added SSAO

Not happy with it yet

https://www.youtube.com/watch?v=G4PJ0r3v8ls&feature=youtu.be

Title: Re: Weekly progress report
Post by: SAS~Ghost129er on July 14, 2020, 05:34:49 PM
It's a start but it'll get there - Just don't do what happened in BoX with their shader/rendering engine..
Title: Re: Weekly progress report
Post by: Stainless on July 18, 2020, 12:54:12 AM
Added gamma adjustment


https://www.youtube.com/watch?v=YORiylSWYe8&feature=youtu.be
Title: Re: Weekly progress report
Post by: Stainless on July 18, 2020, 01:35:40 AM
Added transparency to deferred renderer


(https://i.postimg.cc/qqjrXkp3/Desktop-Screenshot-2020-07-18-08-33-23-08.png) (https://postimg.cc/y3g27Cg1)
Title: Re: Weekly progress report
Post by: Stainless on July 25, 2020, 01:08:03 AM
https://www.youtube.com/watch?v=lmHnRBwEeUQ&feature=youtu.be

Guns add point lights

Do you think the effect is too extreme?

Title: Re: Weekly progress report
Post by: Stainless on July 26, 2020, 03:53:42 AM
More work on SSAO

https://www.youtube.com/watch?v=g4-NTI0UjAM&feature=youtu.be

Still not correct

Title: Re: Weekly progress report
Post by: Pursuivant on July 27, 2020, 10:28:02 PM
Do you think the effect is too extreme?

Hard to tell since there's no way to determine how far away the guns are.

If anything, it's understated.

Close up, gun muzzle flash and tracer effects can be quite impressive.

Here's one example I found where you've got a line of machine gunners shooting a mix of ball and tracer at exploding targets. I'm not sure how much of the "streaky" tracer effect is an artifact of the camera used. At a distance, at least on old film, tracers look much more like floating balls of light when viewed from the side or at a distance. Old Pathe newsreels BoB antiaircraft fire get the effect better.

Here are a couple of videos showing 0.50 caliber MG in action:

A firing line with a number of different MG firing tracer or ball ammo with lights on and off:

https://www.youtube.com/watch?v=F7WrUEpJAFQ

Sperry ball turret firing tracer. At about 1:43 there a section where the turret is shown firing at night. The view from inside the turret shows just how extreme the muzzle effect flash can be on the gunner's night vision.

https://www.youtube.com/watch?v=7_TaK0WZj2k
Title: Re: Weekly progress report
Post by: Stainless on July 28, 2020, 01:49:57 AM
Yes I was looking at some footage of P51's strafing Japanese ships.

The tracer rounds look like big red baseballs floating through the air.

Really strange to watch

The code just uses a position, radius, and strength.

So I guess I can leave it as is for the moment and make it a settings you can play with later

Title: Re: Weekly progress report
Post by: Pursuivant on July 28, 2020, 09:51:10 PM
The tracer rounds look like big red baseballs floating through the air.

My apologies for getting it wrong. Camera film tended to make tracer trajectories into blobs, IRL and on digital the trajectory looks more like a series of streaks, a bit like a skyrocket in flight. And, yes, it is strange to watch, especially if the camera is jumping around between frames so that the tracers don't look like they're following a straight line.

If it's possible and easy, a nice touch might be to give users the ability to create the analogue film artifacts like camera vibration, lens flare, depth of field problems, and analogue film artifacts like blobby tracers or uneven propeller blur where you can sort of see the prop blades as they move. The screenshot and video guys would love you.

A simpler and more important feature is the ability to allow users to change color or intensity of light effects based on external triggers. For example, tracer color varied between countries and periods, engine manifolds might gradually glow red hot, and color of flames coming out of the manifold might vary based on fuel/oxygen mix.
Title: Re: Weekly progress report
Post by: Stainless on July 29, 2020, 01:16:51 AM
The nice thing about my design is that it uses an entity component system.

An entity is something in the world. Aircraft , tree, mountain, etc.

An entity contains components

The components are things like mesh parts, world transform, guns, animators, etc.

And I have an editor so you can edit the parameters of any component without doing any coding.

So I can add components for tracer rounds where you can define what they look like on a per entity basis.

Anything more global like your "vintage camera" idea are a little more complex, but do-able
Title: Re: Weekly progress report
Post by: Stainless on August 19, 2020, 01:01:16 PM
Had some problems.

Wife has a dust collector made out of ceramic on the top shelf of the bookcase just inside the lounge, which decided to attempt suicide by jumping onto my head.It broke into two pieces one of which hit my closed laptop hard enough to smash the screen through the lid of the case.

Now repaired, so I have got some progress

Started getting cockpit's in , but having problems. Looks like I have issues with the materials of the dials

(https://i.postimg.cc/8zqh236K/Desktop-Screenshot-2020-08-19-19-53-02-53.png) (https://postimg.cc/k2v68TwK)

So I needed to be able to edit materials , so I have added material editing to the editor.

(https://i.postimg.cc/FswdzSH1/Desktop-Screenshot-2020-08-19-19-52-10-91.png) (https://postimg.cc/vcLHSc9d)
Title: Re: Weekly progress report
Post by: Stainless on September 06, 2020, 02:52:52 AM
Well seems to be working ok, just some missing animations I will have to create myself

https://www.youtube.com/watch?v=dRSdJreMVoQ&feature=youtu.be

Title: Re: Weekly progress report
Post by: Stainless on September 06, 2020, 11:36:53 AM
Night mode aint too bad as well


(https://i.postimg.cc/ncQQJ7Ly/Desktop-Screenshot-2020-09-06-18-34-47-20.png) (https://postimg.cc/CzSKCRk7)
Title: Re: Weekly progress report
Post by: SAS~Storebror on September 06, 2020, 10:20:06 PM
Looks cool.
The night mode could almost have been an IL-2 screenshot ;)

]cheers[
Mike
Title: Re: Weekly progress report
Post by: DarkBlueBoy on September 07, 2020, 02:05:35 AM
Really looking good Stainless!
Title: Re: Weekly progress report
Post by: Stainless on September 19, 2020, 03:29:35 AM

Added hypoxia

This test run at 30000 feet with no oxygen

Needs some cleaning up, don't like the blur and the fade is too fast


https://www.youtube.com/watch?v=DeK_92zhqRA&feature=youtu.be
Title: Re: Weekly progress report
Post by: Stainless on September 19, 2020, 10:13:08 AM
New version

https://www.youtube.com/watch?v=4NLyQM5Pgeo&feature=youtu.be

Also added red out and black out due to high G over time, still need to work out tunnel vision

Title: Re: Weekly progress report
Post by: DarkBlueBoy on September 21, 2020, 02:53:24 AM
Very believable Stainless. Looks good.
Title: Re: Weekly progress report
Post by: Pursuivant on September 21, 2020, 03:39:28 AM
Also added red out and black out due to high G over time, still need to work out tunnel vision

Thank you! These are much needed additions to any flight sim. Most flight sims assume that airplanes are flown and crewed by robots, not humans. Hypoxia and similar human factors problems are much needed additions.

Don't forget relative loss of distance and night vision as hypoxia creeps up on aircrew. The human eyes are energy-hungry organs, so they begin to lose acuity as O2 starvation sets in ca.10k feet. (FWIW, smoking or other forms of mild oxyegen starvation make this problem worse.)

As for tunnel vision, it not only shows up as an early symptom of GLOC but also hypoxia and, effectively, combat stress (although the latter is actually reasonably well-modeled by inexperienced players getting target fixation and failing to check 6 or otherwise maintain SA).
 
There's also the related issue that it's far more difficult for even well-trained pilots to quickly do "shoulder checks" while pulling G because of the physical demands of turning the head and neck. That is, realistically, it should be harder to pan your POV around while pulling any serious Gs.

Stock IL2 actually does a good job of modeling tunnel vision due to GLOC. I think that it's just a simple function which applies an overlay texture to the screen which describes the area of the screen outside the bounds of a circle. The closer you get to GLOC, the smaller the radius of the circle and the more intense the red or black screen overlay is at its periphery.

It might be two algorithms, one to define the radius of the circle based on the player's POV and GLOC state, the other to fill in a progressively darker red/black screen overlay which has its origin at player POV and gets darker towards the screen perimeter as GLOC gets more severe. Both functions are actually conic/circular, but they normally appear to just affect the sides of the screen due to typical screen geometry.
Title: Re: Weekly progress report
Post by: Stainless on September 21, 2020, 06:01:54 AM
I know a lot about the function of the eye as I have spent the last few years working on eye tracking and foveated rendering, but I don't have the science of g-loc et al down yet.

If anyone has more data on this I would be very grateful

I like the idea of limiting head movement due to G forces
Title: Re: Weekly progress report
Post by: Pursuivant on September 21, 2020, 10:43:36 PM
NASA and the USAF have done a ridiculous amount of research on human factors in aviation. To a lesser extent the same can be said for the US Army and Navy and other countries' military researchers. Once you find the information the main problem is trying to sort through it all to find exactly what you want.

The following handbook is a good starting place for general human factors information:

  https://apps.dtic.mil/docs/citations/AD1020889

It should have just enough technical detail to give you an idea of what factors you need to take into account and to begin to model them. Since it's designed for non-specialists it doesn't get too bogged down with jargon.

If you have trouble downloading it from a non-US IP, PM me and I can send you a copy.
Title: Re: Weekly progress report
Post by: Stainless on September 24, 2020, 01:52:48 PM
More view modifiers added

And the fuselage

Kinda nice to look out the window and see the ailerons move

https://www.youtube.com/watch?v=3PI1jabLoHk&feature=youtu.be
 
Title: Re: Weekly progress report
Post by: Stainless on October 11, 2020, 05:03:39 AM
I have been working on indoor scenes for the last week or so.

The scene file format allows you to put rooms together from tiles, but I am having problems with the lighting.

I am trying to bake the lightmap so I can have nice lighting even on lower end machines.

still a lot of issues to solve. :(

https://youtu.be/hwvHfRCVjLQ
Title: Re: Weekly progress report
Post by: Stainless on October 22, 2020, 12:36:41 AM
Getting better, next is shadows

https://www.youtube.com/watch?v=C3oh6AF6mXU&feature=youtu.be
Title: Re: Weekly progress report
Post by: Stainless on November 08, 2020, 03:31:49 AM
getting better


(https://i.postimg.cc/JzDJh6Jy/editor2.png) (https://postimg.cc/Bj3tYCms)

I haven't been well recently, couple of trips to hospital, such is life.

It has made me think about what I should be working on. I have decided I am sick of working on other peoples projects and want to get this flight sim into full time development.

Just don't have the money to do it  :(

If anyone knows anyone with a couple of million to invest, give me a nudge  :)
Title: Re: Weekly progress report
Post by: DarkBlueBoy on November 18, 2020, 02:41:58 AM
I feel your pain Stainless. :D

Should my lottery numbers come in, I'd be more than happy to contribute!!
Title: Re: Weekly progress report
Post by: SGT68 on November 24, 2020, 11:01:06 AM
Been quietly following your progress over the years, and I very much look forward to one day flying your sim. That will be a happy day for us all here
Title: Re: Weekly progress report
Post by: Stainless on December 12, 2020, 02:25:04 AM
A lot going on, both in this project and in real life, but managed to make some progress.

Found a really strange speed up.

When you draw something, you have to pass parameters to the shaders. The standard way to do that is to do this

Code: [Select]
shader.Parameters["parameter_name"].SetValue(parameter_value);
Doesn't look like there is much you can do to speed that up does it?

Well the parameter array on the shader is an array of EffectParameter , so I changed the code to cache these objects myself.

Instead of using the default Effect class I created a RenderEffect class which held the shader and a dictionary of all the EffectParameter in it

The actual code looks identical, I didn't need to change any of it, I just changed shader from Effect to RenderEffect

The result.

Extra 20 FPS

20 FPS

This is mad

In the other part of the code, I am still not happy with the plotting room scene above. Doesn't look good enough.

So I decided to go OTT on it

I am currently finishing off photon mapping for the scene

Photon mapping constructs a ray from every pixel on every object to every light, works out how many photons will strike this pixel and stores it.

Then it creates a reflected ray from the pixel into the world, and works out where that ray will strike in the scene.

It adds the photons reflected to that pixel , then repeats the reflection pass until no photons remain.

Hopefully it will make the lighting more realistic



Title: Re: Weekly progress report
Post by: Stainless on January 01, 2021, 04:16:01 AM
Had a bit of time to work on it.

https://youtu.be/TNxXtuZbTqk

Flak gunner AI added

Now to add the particle systems
Title: Re: Weekly progress report
Post by: hello on January 01, 2021, 09:09:05 AM
Nice!
Title: Re: Weekly progress report
Post by: Stainless on January 02, 2021, 02:36:52 AM
https://www.youtube.com/watch?v=qGk-sMcvT3w&feature=youtu.be

Particle system added
Title: Re: Weekly progress report
Post by: Stainless on January 02, 2021, 02:40:22 AM
https://youtu.be/Wj7px_wncHY

150 mm howitzer

Not sure how they used at as an anti-aircraft gun, but history says they did.
Title: Re: Weekly progress report
Post by: Stainless on January 02, 2021, 08:38:15 AM
Tried to do some real work, but just ended up staring at the code.

Got a problem with templated class with multiple inheritance that will compile in Visual Studio but won't compile in g++, clang, or gcc.. sigh

So I decide to add artillery gunner AI

It two modes

AttackArea -- just shell a location
Visual --- shoot at anything you can see


https://youtu.be/agzedfmKLr4

Also added a weapon database and ammunition database
These are defined in the game object , so you can change them with just a text editor

The reason for that is you may want to use the same mesh for different weapons , or use different ammo with the same gun

Title: Re: Weekly progress report
Post by: Pursuivant on January 02, 2021, 04:34:58 PM
Not sure how they used at as an anti-aircraft gun, but history says they did.

It seems likely that the Germans remounted the gun barrels on an AA mount or just accepted the relatively low angle, long distance trajectory of guns. The Japanese had a very late war dedicated 15cm AA gun.

If you want to be a stickler for accuracy, consider adding particle emission points at the base of the mount to allow dust to be kicked up from recoil and below and in front of the gun to represent dust/snow blown around by the muzzle blast.
Title: Re: Weekly progress report
Post by: Stainless on January 03, 2021, 01:40:32 AM
I am in two minds at the moment.

I really want to improve this part of the code. Proper animated crew meshes. Ammunition and spent rounds. That sort of thing.

But if you are whizzing past at 550 knots with your arse on fire you are not going to see any of this.

Title: Re: Weekly progress report
Post by: Koty on January 03, 2021, 09:03:36 AM
On the topic of AA guns, maybe you should from the get go plan to have them use artillery directors.

(https://upload.wikimedia.org/wikipedia/commons/0/0e/Kommandogerat_40_director_helsinki_2.jpg)
Title: Re: Weekly progress report
Post by: Pursuivant on January 04, 2021, 08:54:14 PM
But if you are whizzing past at 550 knots with your arse on fire you are not going to see any of this.

More to the point, if you're whizzing along at 20,000 feet you're not going to see any of it.

Ground object animation and AI really only matters for movie makers and ground attack missions. If you're doing a BoB sim that aspect of the air war isn't so important. It's even less important if you're doing a 4th or 5th generation fighter sim.

Many fiddly bits I've proposed are nothing more than invitations to feature creep and should be ignored as serious suggestions. The real value of what you're doing is "making the tools to make the tools." Provide the mechanisms which eventually allow fans to easily "fill in the gaps" and trust that others will build on your framework.

Practically, that means making it easy to add little features to the game rather than adding them yourself.
Title: Re: Weekly progress report
Post by: vonOben on January 05, 2021, 12:16:26 AM

The real value of what you're doing is "making the tools to make the tools." Provide the mechanisms which eventually allow fans to easily "fill in the gaps" and trust that others will build on your framework.

Practically, that means making it easy to add little features to the game rather than adding them yourself.

Good point IMHO  ]thumbsup[, or else it would be too much work for one person to make everything himself for a new flight simulator.
Title: Re: Weekly progress report
Post by: Stainless on January 05, 2021, 11:19:04 AM
Yes I know I am a masochist.

This is a massive project, but I am making everything open source with all tools so hopefully something will come of it

 :P
Title: Re: Weekly progress report
Post by: vonOben on January 05, 2021, 11:29:00 AM
hopefully something will come of it

Let's hope so!
It would be a shame if all your work would be wasted.

 ]cheers[
Title: Re: Weekly progress report
Post by: Stainless on January 09, 2021, 02:49:40 AM
Added ground dust effect when gun fires as suggested

Think it needs a new particle system though

https://youtu.be/m89DVJGl3a4

Title: Re: Weekly progress report
Post by: Stainless on June 20, 2021, 01:40:57 PM
https://www.youtube.com/watch?v=HM96LC8KiCc

UE5 test

Title: Re: Weekly progress report
Post by: Chaoic16 on June 22, 2021, 04:39:15 AM
This is looking good!  If we could import IL-2 1946 assets into this, it would look amazing.
Title: Re: Weekly progress report
Post by: Stainless on June 22, 2021, 08:52:31 AM
This is the Spitfire IX c (Multi) him from IL2

The process is currently very slow and painful. I am doing it by hand until I understand it and can write code to automate the process.

Really need hires textures and normal maps.

Specular maps and since UE5 uses physical based rendering, it would be nice to have a map that combines metallic and roughness into the specular map.
Title: Re: Weekly progress report
Post by: Chaoic16 on June 23, 2021, 05:37:16 PM
AH I see! I didn't realize this is actually aircraft from IL-2 1946!  I am impressed!

When it comes to the first time for anything, it is always a pain in an ass.  You will eventually get this.
Title: Re: Weekly progress report
Post by: Stainless on June 23, 2021, 11:40:35 PM
https://www.youtube.com/watch?v=W9TUrJ20GRo

Title: Re: Weekly progress report
Post by: Chaoic16 on June 25, 2021, 07:33:54 PM
Looking good!  From what I understand, you are currently testing each features from IL-2 1946 in Unreal Engine, then make the automatic conversation software that would import IL-2 assets?

Title: Re: Weekly progress report
Post by: Stainless on June 26, 2021, 12:45:32 AM
That's the plan, but it is not trivial

To get the physics to work, you need a skeleton.

My design is for solid bones connected by rigid joints to hold all the aircraft parts in place. So when the aircraft gets destroyed you can just break the joint at the correct place and the aircraft falls apart as you would expect.

Then place physics elements for everything else

So the propellor is a thruster, each wheel has a matching physics wheel, each wing section is an aerofoil (which I will have to add to the physics system in UE5 as none exist), landing gear have springs, etc.

Then I will need to create a tool to do all of this

At the moment the ONLY way to do this work is with Maya, and I don't believe any of you have £3500 spare to buy yourself a copy

Title: Re: Weekly progress report
Post by: Pursuivant on June 26, 2021, 10:26:20 PM
My design is for solid bones connected by rigid joints to hold all the aircraft parts in place. So when the aircraft gets destroyed you can just break the joint at the correct place and the aircraft falls apart as you would expect.

There's a hidden benefit here which you might not have considered yourself - the ability to bend those joints with or without breaking.

That lets failing parts bend before they break.

E.g., at 1:08 on this video:

https://www.youtube.com/watch?v=t5LApha8AhM

If you wanted to get really fancy, you could have joints which deform under stress, so that vehicles crumple when they crash.
Title: Re: Weekly progress report
Post by: Stainless on June 27, 2021, 12:00:32 AM
yes , I need to look at how to do that.

One of the things I was thinking about was the testimony of a P51 pilot from world war two.

He dove in on a ME109 at low altitude and fired a 2 second burst from six o clock high

He says he saw the rounds hit either side of the cockpit by the wing root. Left guns hit left of the cockpit, right guns hit right of the cockpit.

The result was two small explosions then the wings folded upwards.

He flew alongside the doomed plane for a few seconds and could see the pilot look at him. Since the cockpit on the 109 folds out to the left, and the wing was blocking it, the pilot had no chance to bail out. He knew he was dead.

The P51 pilot says that one haunted him the rest of his life. Like most pilots he shoots down planes, not people.

I have talked to other people and they say it's impossible. The structure of the 109 means the wings would come off in that situation, not fold up.

I tend to believe the pilot more than the physics
Title: Re: Weekly progress report
Post by: Chaoic16 on June 27, 2021, 05:09:38 AM
Hello Stainless,

When I saw this video, I thought of you and the projects you are working on.  I thought these videos might have anything helpful:

Realistic Aircraft Physics for Games
https://www.youtube.com/watch?v=p3jDJ9FtTyM

Ocean waves simulation with Fast Fourier transform
https://www.youtube.com/watch?v=kGEqaX4Y4bQ
Title: Re: Weekly progress report
Post by: Pursuivant on June 28, 2021, 11:46:51 PM
I have talked to other people and they say it's impossible. The structure of the 109 means the wings would come off in that situation, not fold up.

The wings would have quickly come loose, but they could have hung on for a few seconds, attached by the skin and a partial spar, after they folded up. That would could have been long enough to keep the Bf-109 pilot from bailing out before his airplane went into an uncontrollable spin or got too low to allow a bail out.

I was also thinking of being able to fly a "bent" plane - like a Fw-200 with a "broken back" due to a hard landing, a plane with wings bent out of alignment due to serious abuse or severe weather, or a plane with bent propeller tips due to a flying too close to the ground.

Anyhow, it's another potentially very powerful tool once you get it working.
Title: Re: Weekly progress report
Post by: Stainless on July 10, 2021, 01:22:49 AM
So I have finally figured out how the taxiways work in FSX


(https://i.postimg.cc/R0Lbkmfz/Desktop-Screenshot-2021-07-10-07-24-52-62.png) (https://postimg.cc/06rfSLct)


You have an array of points , then an array of connections. A connection is just the indexes into the point array.

Which makes life hell.

This shows the problem

(https://i.postimg.cc/02dv8T7c/problem.png) (https://postimages.org/)

You can't just draw a thick line as you can see in the "simple" section above.

So what I have done is run through all the points all count the number of times they are referenced by paths. From this I can work out the basic shape of each intersection.


Now I have to add code for all of the combinations of the connection counts, so far I have done start - start and start - line which was complex enough

I had to form a ray along each edge of the start section, create a plane from the two points of the next section and get the intersection of the two to create a point. Then do the same for the other edge.

Next is two to two which is very similar, but the rest of the combinations need more thought.

I have also started getting the airport into UE5, which is going ok.



(https://i.postimg.cc/9FjpdSs3/Desktop-Screenshot-2021-07-10-07-50-07-18.png) (https://postimg.cc/w30LHW6F)

(https://i.postimg.cc/yNWX6z3R/Desktop-Screenshot-2021-07-10-07-50-59-51.png) (https://postimg.cc/3y5D9VBr)
Title: Re: Weekly progress report
Post by: Pursuivant on July 16, 2021, 07:39:50 PM
So I have finally figured out how the taxiways work in FSX

Wow. Whatever "intuitive" is, that's the opposite. I wonder why the FSX coders programmed it that way? (No need to reply: rhetorical question.)
Title: Re: Weekly progress report
Post by: Stainless on July 18, 2021, 02:02:29 AM
Realised the way Iwas doing this is inefficient.

SO working on a new technique. Again.

Now after I have read in all the points , I read in all the paths and store all the connections made to each point.

Then I iterate over the points generating new points based on the number of connections.

If a point only has one connection, it is trivial. You create a direction from this point to the connected point, cross it to generate a right vector, and multiply that by half the width. Then I use this to generate two points and store then in the point structure.

If it has two points, I start off the same. Generating a direction to the next point and the right vector, but this time I do the same for the other connection. so I end up with four points and two directions. I then use these points and directions to generate four lines and calculate the intersection points of these lines, and store those two intersections.

After that it gets more complex, but basically I generate directions from the current point to all connected points. I then sort these so they are counter clockwise. Then it's the same process of generating right vectors, generating lines, computing intersections, and storing the points.

This image attempts to explain the process

(https://i.postimg.cc/m2r1QbFD/problem2.png) (https://postimages.org/)

Then I iterate over the paths using the generated points to build triangles.

So you end up with something like this


(https://i.postimg.cc/XqPjK6TG/problem3.png) (https://postimages.org/)

It can handle changes in width as you go along no problem, and in the fist pass doesn't look too bad.

However I am thinking that by storing the direction of each line and doing a bit more logic , I can make it better by using splines



(https://i.postimg.cc/c4N0STdN/problem4.png) (https://postimages.org/)
Title: Re: Weekly progress report
Post by: Stainless on October 16, 2021, 05:53:10 AM
Got dragged into input handlers

https://www.youtube.com/watch?v=GttPmVqPgGM

The system uses a blueprint class that contains a list of inputs needed for a particular aircraft

It can connect to anything HID compliant, so all of your custom made switch boxes will work with it

The stuff at the bottom is just debug display, once I have finished the default display it will go

Title: Re: Weekly progress report
Post by: SAS~Storebror on October 16, 2021, 11:49:17 AM
Nice!
I love it when things are that shiny behind the scenes.

]cheers[
Mike
Title: Re: Weekly progress report
Post by: Stainless on October 24, 2021, 02:20:54 AM
This week I solved a problem that has bothered me for a while.

I need fully functioning sector control rooms. One of the key items in the control room is the squadron tally board. It displays the current state of all the squadrons.

I have tried a few techniques for this, none of them really worked. So I decided to mix 2D and 3D.

The display is actually a UMG widget with a blueprint behind it to control the status of all the lights, then I wrap it in a world object.

To add one to a room, you just drag one into the world and set the squadron number and the default state, then place it where you want it.


(https://i.postimg.cc/LsfHFx5f/Desktop-Screenshot-2021-10-24-09-13-30-99.png) (https://postimg.cc/7CHvgMgY)

Now I just need to model the rest of the room


Title: Re: Weekly progress report
Post by: Stainless on October 31, 2021, 05:02:11 AM
https://www.youtube.com/watch?v=HSgtkOIALdQ


Barrage balloon indicators
Title: Re: Weekly progress report
Post by: Stainless on November 14, 2021, 09:46:12 AM
Room coming together with my own player controller

https://www.youtube.com/watch?v=MuU0sFB3o-o

Still a lot ot do and I have to figure out UE5's bloody awful lighting
Title: Re: Weekly progress report
Post by: Stainless on November 14, 2021, 11:03:46 AM
https://www.youtube.com/watch?v=IRv-_8U28Co
Title: Re: Weekly progress report
Post by: Mission_bug on November 15, 2021, 04:10:41 AM
This has been a really interesting project to watch come to fruition, I do not understand most of the technicalities but
watching it progress has been awesome. 8)

There seems to be so much to do though I wonder if it is possible for any one individual to ever finish this alone. :o


Take care and be safe.

Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: Stainless on November 20, 2021, 03:41:28 AM
https://www.youtube.com/watch?v=rJNl2-YQYuU

Weather boards and pilot / aircraft availability
Title: Re: Weekly progress report
Post by: Stainless on November 20, 2021, 07:59:54 AM
Now added cloud cover indicator (in octas)


(https://i.postimg.cc/9FHKg7Qq/Desktop-Screenshot-2021-11-20-14-58-23-74.png) (https://postimg.cc/t7DBY7PX)
Title: Re: Weekly progress report
Post by: Stainless on January 16, 2022, 05:14:13 AM

https://www.youtube.com/watch?v=pXI5qThct8w


Not got a lot of time to work on it at the moment, but some progress
Title: Re: Weekly progress report
Post by: Stainless on January 22, 2022, 01:05:34 AM
Some big news this week.

As part of my day job, the chance came up to pitch this game to publishers, big publishers. The sort of people who can throw me a few million to get it off the ground.

And they are interested.

Will see what happens.
Title: Re: Weekly progress report
Post by: Mission_bug on January 22, 2022, 09:02:02 AM
Some big news this week.

As part of my day job, the chance came up to pitch this game to publishers, big publishers. The sort of people who can throw me a few million to get it off the ground.

And they are interested.

Will see what happens.



Hope all goes well with that, makes all your hard work and frustration worthwhile. 8)

Take care and be safe.

Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: SAS~tsisqua on January 22, 2022, 09:05:39 AM
Some big news this week.

As part of my day job, the chance came up to pitch this game to publishers, big publishers. The sort of people who can throw me a few million to get it off the ground.

And they are interested.

Will see what happens.

Good Day, Sir!!
  I have been lurking . . . er, uh . . . quietly FOLLOWING your work on this.
If this publisher can help you it would be so awesome! I'm sure you've considered how much being able to hire an actual team could speed up your work. We are all rooting for you!

Bird
Title: Re: Weekly progress report
Post by: Pursuivant on January 23, 2022, 02:55:17 AM
As part of my day job, the chance came up to pitch this game to publishers, big publishers. The sort of people who can throw me a few million to get it off the ground.

And they are interested.

Best of luck!

While it would be a nightmare from marketing/brand control point of view, a commercial "sandbox sim" where it's easy for fans to make and import mods or even official content from older sims would be a godsend for simmers of all types. Think of all the libraries of mods for MSFS, IL2, etc. and then imagine being able to run them all in a single environment. Infinitely expandable and moddable, with a franchise life measured in decades.
Title: Re: Weekly progress report
Post by: Stainless on January 23, 2022, 07:36:32 AM
That is the plan
 8)
Title: Re: Weekly progress report
Post by: slibenli on January 23, 2022, 08:25:33 AM
Now that sounds exciting!  8)
Title: Re: Weekly progress report
Post by: Stainless on January 23, 2022, 09:47:44 AM
https://www.youtube.com/watch?v=Jbekyr-di4Y
Title: Re: Weekly progress report
Post by: Chaoic16 on January 26, 2022, 03:04:41 AM
Hello Stainless, have you ever considered about patreon?  If you set up patreon, we can be more than happy to join and donate for tools and simulation development.

Your progress have been looking great, especailly with unreal engine.  A big respect to you for never giving up.

Cheers
Title: Re: Weekly progress report
Post by: Pursuivant on January 26, 2022, 03:03:59 PM
The destruction video with moving parts looks good.

I know it's early days, but will users be able to link secondary destruction effects to the main destruction effect? I.e., not just a fireball and destroyed object animation, but also things like shrapnel, lingering smoke and fire effects, and craters in the ground?
Title: Re: Weekly progress report
Post by: Stainless on January 28, 2022, 11:51:19 PM
The particle system is a asset created with a tool built into UE4

It is infinitely extendable, the only limit is the computer you are running the game on.

The effect is a collection of particle systems.

Each particle can use textures as done in IL2, or a mesh. So you can throw shrapnel around and have it bounce off the world around it

And each particle can have it's own shader, so you can use all the tools in UE4 to create something pretty.
Title: Re: Weekly progress report
Post by: Stainless on January 29, 2022, 10:01:33 AM
So you can do this

https://www.youtube.com/watch?v=4kYLvsTxxA0
Title: Re: Weekly progress report
Post by: Pursuivant on January 30, 2022, 02:58:38 PM
Very cool.
Title: Re: Weekly progress report
Post by: vonOben on February 01, 2022, 04:35:53 AM
Some big news this week.

As part of my day job, the chance came up to pitch this game to publishers, big publishers. The sort of people who can throw me a few million to get it off the ground.

And they are interested.

Will see what happens.

Let's hope for the best, good luck Stainless!  ]thumbsup[
Title: Re: Weekly progress report
Post by: Stainless on February 05, 2022, 12:44:48 AM
Well this week has been very strange.

My initial pitch for funding started well, then went weird.

They really want to do the game, but they don't want a historical game.

They want hamsters.

Hamsters.

The rest of the guys in the team are really keen on it, and while the concept art is excellent, I am a bit lost.

On one side having a million quid to do a flying game would be nice, and it would allow me to have all the help I need to get the hard parts done, it's not the game I want to make.

The concept art is brilliant, I would love to show you it, but of course it is all top secret. Having a hamster that looks like it is about to rip your heart out is quite a feat.

So I think if this goes ahead , it will just be a stepping stone to the real game.



Title: Re: Weekly progress report
Post by: Alfie Noakes on February 05, 2022, 01:15:57 AM
HAMPSTERS      o_O

Hahahahahahhahahaha

The world of computer game development is indeed very odd

Keep up the good work   ;D

Cheers

Alfie
Title: Re: Weekly progress report
Post by: slibenli on February 05, 2022, 02:06:33 AM
What  o_O ;D

Does that mean hamsters as pilots?
Title: Re: Weekly progress report
Post by: Stainless on February 07, 2022, 06:34:01 AM
Yes.

Don't Ask Me I Know Nothing, NOTHING
Title: Re: Weekly progress report
Post by: Pursuivant on February 08, 2022, 11:47:24 AM
If sounds like some marketing genius is trying to rip off Kerbal Space Simulator, possibly to make an aerospace sim more appealing to kids, seemingly less violent, or perhaps more marketable in repressive parts of the world.

It sounds like a potential train wreck, but I'm prepared to be pleasantly surprised.

If hamsters is what it takes to get the game finished then so be it. If anyone can make the concept work, it's Stainless.

Just make it easy as hell to mod the game so that we can swap in actual human pilots, real-world physics, accurate damage effects, and historically accurate equipment and scenarios.
Title: Re: Weekly progress report
Post by: Stainless on February 11, 2022, 06:11:13 AM
https://www.youtube.com/watch?v=jLGvbeP_JjY
Title: Re: Weekly progress report
Post by: Stainless on February 19, 2022, 12:50:26 AM
https://www.youtube.com/watch?v=sJiBCq7xYjs

Sopwith camel from here ported to UE5
Title: Re: Weekly progress report
Post by: Chaoic16 on February 19, 2022, 03:59:17 AM
Now that is awesome!!! Do you have "3D propeller" effects when viewing the propeller from side? 
Title: Re: Weekly progress report
Post by: Stainless on February 20, 2022, 11:39:10 AM
At low revs it is the normal mesh , at high revs it is two transparent meshes one slightly rotated
Title: Re: Weekly progress report
Post by: Mission_bug on February 21, 2022, 03:02:39 PM
Awesome, what else can I say. 8)

Take care and be safe.

Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: ChiefWH on March 27, 2022, 09:46:33 AM
This all looks really interesting. I hope it comes to a release.
Title: Re: Weekly progress report
Post by: Stainless on April 09, 2022, 05:37:57 AM
still in development, I have published some source code though
Title: Re: Weekly progress report
Post by: Stainless on May 30, 2022, 01:53:25 PM
So the news is that the pitch is nowin with 10 publishers.

No idea how it will go, but everyone is very positive that it will be funded.

I can't post anything at the moment, but I can tell you I have a fully functioning flight dynamics model in UE5 and I am currently working on some AI to demo it.

Well let you know how it goes.
Title: Re: Weekly progress report
Post by: Mission_bug on May 30, 2022, 02:35:06 PM
Congratulations, hope all goes well, you certainly worked long and hard on this, great stuff.

Take care and be safe.

Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: ChiefWH on July 01, 2022, 01:56:27 PM
Wow, good luck!
Title: Re: Weekly progress report
Post by: Chaoic16 on July 05, 2022, 05:53:00 PM
So the news is that the pitch is nowin with 10 publishers.

No idea how it will go, but everyone is very positive that it will be funded.

I can't post anything at the moment, but I can tell you I have a fully functioning flight dynamics model in UE5 and I am currently working on some AI to demo it.

Well let you know how it goes.

That is a great news!  Just to let you know, I sent you PM.  I would like an advice about the simulation development.


Cheers
Title: Re: Weekly progress report
Post by: Stainless on July 28, 2022, 12:58:09 PM
Keep your eyes open for "Pilots Of New Anarchy"
Title: Re: Weekly progress report
Post by: SAS~tsisqua on July 28, 2022, 07:41:53 PM
Keep your eyes open for "Pilots Of New Anarchy"

I hope that means what I think it does!!!
Bird :) ;)
Title: Re: Weekly progress report
Post by: Stainless on August 19, 2023, 01:12:00 AM
Sorry I haven't posted in a while, been dealing with shit.

The company I helped setup didn't manage to get a publisher interested in anything, and with financial pressure mounting, it was sold to Climax and is now "Climax Liverpool" or "Climax North"... not sure which.

This caused me a load of issues, and I am currently working with Climax on a game that will be released in a few days.

I haven't given up though.

My current plan is to write a much simpler game based on the artic convoys in world war two , and try and get that published. Then use the profits from that to fund the flight sim.

Only video I have put up so far

https://www.youtube.com/watch?v=r7drtJ5_WCU

Title: Re: Weekly progress report
Post by: Stainless on August 21, 2023, 12:15:27 AM
https://www.youtube.com/watch?v=sJiBCq7xYjs

https://www.youtube.com/watch?v=jLGvbeP_JjY

https://www.youtube.com/watch?v=uQl_JPpIC-8


Title: Re: Weekly progress report
Post by: SAS~Storebror on August 21, 2023, 12:41:28 AM
Wonderful!

]cheers[
Mike
Title: Re: Weekly progress report
Post by: Mission_bug on September 11, 2023, 05:37:01 AM
Truly amazing. 8)

Take care and be safe.

Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: Stainless on September 12, 2023, 09:59:00 AM
I hate this time of year, my birthday always brings up bad times.

Had a few days off and came back to work on last Friday, to find out my client I had been working with for the last two years said they had no more work for me.

Made a few calls, chatted to a few people, and got a new client 3 hours later.

Started today and it's a UE5 project so I can cross some work over from my own project.

"May you live in interesting times"
Title: Re: Weekly progress report
Post by: UberDemon on September 12, 2023, 10:24:32 AM
Eager to see how this turns out.  Thank you for posting your progress.

I am dealing with some personal stuff as well.  I understand (although... hey, we are all unique in our dealings...)
Title: Re: Weekly progress report
Post by: Stainless on November 03, 2023, 06:39:22 AM
Wanted to show how easy it is to create a new loadout in my new system.

https://www.youtube.com/watch?v=5zGI7xN7vxQ

Title: Re: Weekly progress report
Post by: UberDemon on November 03, 2023, 09:01:49 PM
Stainless,

This is very nice.  Will you eventually make this tool available for modders or will that will only be available to you and your development team?

Regardless, It looks nice.  Is it a GUI front to building/developing the object classes or does it build object files? (text and or 3D files)

Very nice and I wish I had that level of talent.
Title: Re: Weekly progress report
Post by: Stainless on November 04, 2023, 01:51:53 AM
This is Unreal Engine 5.3, free to download and use.

The whole project will eventually be available online, so you could install Unreal, download the game, and mod it yourself.
Title: Re: Weekly progress report
Post by: Mission_bug on November 04, 2023, 03:27:49 AM
Always great to see your progress Stainless, superb work as always. 8)

Take care and be safe.

Wishing you all the very best, Pete. ;D
Title: Re: Weekly progress report
Post by: UberDemon on November 04, 2023, 03:35:26 PM
This is Unreal Engine 5.3, free to download and use.

The whole project will eventually be available online, so you could install Unreal, download the game, and mod it yourself.

That is outstanding, and looking really nice.
Title: Re: Weekly progress report
Post by: Stainless on November 08, 2023, 11:43:53 AM
https://www.youtube.com/watch?v=dD7y05_j39U
Title: Re: Weekly progress report
Post by: WhiteSnake1976 on January 31, 2024, 10:55:50 AM
Not so "Weekly" anymore???
Title: Re: Weekly progress report
Post by: Stainless on February 05, 2024, 08:01:57 AM
Very true, very true.
Title: Re: Weekly progress report
Post by: Stainless on February 05, 2024, 08:14:26 AM
Just to let you all know what has been going on, the company I was working with to get the flight sim funded was bought out and the project dropped.

Just after that I was diagnosed with cancer in my nose. Just before xmas I went under the knife. I am now a member of the guinea pig club.

They chopped most of my nose off, then cut a slot out of my forehead and used that to make me a new nose.

I am fine now, though I am still in some pain because my forehead is tight as a drum. No botox for me.

I am currently working on an unannounced UE5 game for a company in Liverpool but will try and get back into it soon.

Cheers guys, sorry for the radio silence.
Title: Re: Weekly progress report
Post by: Frankiek on February 05, 2024, 08:31:53 AM
Sorry to hear about your health problems, the important is that you recover quickly we can wait. Take care and all the best 
Title: Re: Weekly progress report
Post by: shardana on February 05, 2024, 09:35:32 AM
Really sorry to hear that Stainless, hope you'll get better soon and that everything will be solved for good. Take care and look after yourself. Ciao.
Title: Re: Weekly progress report
Post by: Mission_bug on February 05, 2024, 11:50:18 AM
Sad to know of your ill health, hope all is good for you going forward.

Take care and be safe.

Wishing you all the very best, Pete.
Title: Re: Weekly progress report
Post by: Knochenlutscher on February 05, 2024, 12:21:33 PM
R/L comes first.
Hope you're OK.
Such surgery is very painfull, had a reconstruction at these parts too.
Watch yourself, take care. Get well soon.

Best wishes
Tobi
Title: Re: Weekly progress report
Post by: Kopfdorfer on February 06, 2024, 10:02:43 AM
Gee Stailnless ,

Terribly sorry to hear of your health issues.
I hope you are well on the mend.

Kopfdorfer
Title: Re: Weekly progress report
Post by: Stainless on February 07, 2024, 10:57:02 AM
Thanks guys
Title: Re: Weekly progress report
Post by: vonOben on February 18, 2024, 04:54:13 AM
Hi Stainless

Sorry to hear about your health issues, and I hope that you'll get well after the operation.

All the best.

Per
Title: Re: Weekly progress report
Post by: Chaoic16 on February 18, 2024, 07:46:20 PM
Hello Stainless,

We are relieved that you are dong well.  Sorry about the situation with health, and hang in there.  We wish you the best health recovery.  Take it easy and take your time.  As someone said here, real life comes first.  You have made the amazing progress with the simulation development.  We are in this together and take your time.


Cheers!
Title: Re: Weekly progress report
Post by: fatty_finn on February 25, 2024, 08:03:33 AM
Stainless,  You are a hero. To think of all that you've done - and in the face of much adversity.
Would that we all had your fortitude!
All the best,
Fatty Finn