The FFED3DAJ Thread

[AndyJ]

I'd meant that you need to take into account the occlusion of the sun rather than the lens-flare image itself - bit of an over heavy, late-night edit sorry. It'd look bad if the sun was obscured by a planet, or terrain, a wall, a space-station etc. etc. and yet there was a lens-flare still poking you in the eye.
The culling issues aren't .x model related per-se but due to the game still drawing the original FFE models. It has no way of knowing if a triangle should be facing inwards or outwards in context of the model. If a model was a simple volume, perhaps a python or anaconda, then you could fix that - but many other ships, space-stations and objects are complex forms. The issue with the .x models blocking the view is that in spite of knowing how to cull its sides, there might be a new part of the model that now faces towards where the camera is positioned - so in that instance, you do have to move the camera elsewhere. (panther clipper turrets come to mind, blocked by raised surface details on the .x model)

I did a little testing for the sound issues at the weekend and looks like it probably isn't an overflow issue at the point I'd spotted in the assembly code. That only seems to happen when you're docked and another ship rams itself through the space-station. But saying that, I've struggled to find instances where the annoying sounds are intruding. If you do find you've entered a system and it's happening, please could you save the game - and if it's reproducible then after a re-load, share the file somewhere? Trying to make it happen to then catch the cause seems to be half the battle at the moment!

But it wasn't for naught as during my wanderings through the FFE assembly code, looking for those docking noises, I did happen upon an area that shouted out 'autopilot, landing at a space-port/pad'!
Part of the code calls a function that seems to make x/y/z directional changes and remembering the inherent auto-pilot landing issues, I thought to myself "I wonder what'll happen if I just get it to skip those updates at very low altitude?"
Well it was a quick hack to insert a new check at <200m ...but... it now looks like the autopilot doesn't decide to rotate the ship in the final moments when landing at x1 time... so it stays upright and doesn't destroy you!
I'm going to add that in with the obligatory .cfg wrapper around it so that the fix can be turned off ... just in-case wider testing reveals that it does anything worse than face-planting the ship into the landing pad!!!

 

[Zak Gordon]

But it wasn't for naught as during my wanderings through the FFE assembly code, looking for those docking noises, I did happen upon an area that shouted out 'autopilot, landing at a space-port/pad'!
Part of the code calls a function that seems to make x/y/z directional changes and remembering the inherent auto-pilot landing issues, I thought to myself "I wonder what'll happen if I just get it to skip those updates at very low altitude?"
Well it was a quick hack to insert a new check at <200m ...but... it now looks like the autopilot doesn't decide to rotate the ship in the final moments when landing at x1 time... so it stays upright and doesn't destroy you!
I'm going to add that in with the obligatory .cfg wrapper around it so that the fix can be turned off ... just in-case wider testing reveals that it does anything worse than face-planting the ship into the landing pad!!!

!!!

I knew it, i knew you'd get around to fixing the 'impossible' bug! Awesome, amazing even. Well done You do know this requires a completely different style of flying with the autopilot now, i'll have to relearn how to land!!

 

[Faramir]

Any news? When next build?

 

[Steve]

Any news? When next build?

Soon™

 

[alsakari]

Great work,man.I hope you to continue improving this great game!One question:the 1.11 patch will include the Hellmod?

 

[AndyJ]

Great work,man.I hope you to continue improving this great game!One question:the 1.11 patch will include the Hellmod?

Cheers alsakari!
Yes it will do - there's a beta1 build over at the elite-games.ru forum that I'm awaiting feedback on if you want to give it a test

 

[alsakari]

Cheers alsakari!
Yes it will do - there's a beta1 build over at the elite-games.ru forum that I'm awaiting feedback on if you want to give it a test

To tell you the truth,I haven't played your version yet .Time is so precious(I believe you have the same ...problem),but when I saw your screenshots and read this thread and what you have improve and fix,I promise myself I will find the time to play.I'm 48 and I grew up with this game(God,I'm really...old )
One last thing:is it possible to add new content to the game or the game engine forbit it?I mean,you and the other guys have already add so much staff,but I am refearring to adding stories,ships,newspaper articles(my best feature ),etc.Anyway,I know that everyone is playing elite:dangerous but I hope to continue what you are doing for this game,and stop only if there is nothing else to improve

 

[Donik]

Haven't played this in a few weeks. But being in the US, with a 3 day weekend starting right now. This is #1 on my to-do list, along with the beer I just picked up.

Mr. AndyJ - any news for us on future versions or anything? Thanks, as usual, for this masterpiece. Every time I load it up it brings a smile to my face!

 

[AndyJ]

Hi Donik!

I've been busy working away on it this past month but unfortunately seem to have missed your extended holiday with the latest build. There is a new v1.11-beta3 build just uploaded to the Russian forum which I hope adds their fan-created translations for the game-texts, where beta 1 added translations for the journal stories. (I hope - as I don't speak a word of Russian!)

Beta 2? well that fixed some layout issues for contract and mission lists which I gave to Steve to test whilst I figured out how to get to beta 3!


This next v1.11 build is mostly a "dot the I's and cross the T's" for me, fixing those remaining issues such as the cockpit panel blanking during videos, info screens not repainting when switching between full-screen/windowed, but also I wanted to add support fan and original translations. JJFFE never did that, and I wanted to leave FFE (if perhaps I do soon) as 'complete' as it can be. Some of those are quite simple sounding updates I guess, but each one required some investigation & surgery under-the-covers to implement!

There will still be a few cosmetic     les with shaders to look at. Planet surfaces being too dark when flying at low levels and 'original FFE' buildings and grass areas remaining fully lit at night are obvious targets. More than one player has mistakenly thought that the dark surface meant there were missing textures. Perhaps in a future build though!
A GUI .cfg editor is also something that I had started to write for this build but decided to chop for the time being. With it currently being in VS2010 C++ and using .NET controls, it was proving quite unwieldy to code as that version of VS doesn't provide context-sensitive tips for methods etc. I'll probably move the .cfg editor over to the latest Visual Studio and rewrite it using MFC now that Microsoft have included it with the free 'Community' version of VS.


@alsakari: well do have a play and hopefully you'll enjoy the latest build!

Adding new content is difficult - but: If you can draw graphics for screens, buttons or textures then that is one open area that you can make your own mark upon, otherwise can you create .X (XNA) models? There are still quite a few ships, stations and buildings that draw with the original FFE models... and you could always add your own version of an existing model if you think you have a better vision of how it should look!

Brand new stories and missions are non-starters though I'm afraid... sorry! This is not a game that can be extended in those areas due to it being rooted to its original x86 assembly language. Mission creation is not understood, and I've no desire to spend time trying to figure it out, and the newspaper stories are tied to specific date ranges - often to tie in with one of FFE's hand-coded missions.

As you say, most people have moved on to Elite: Dangerous now, and most new-comers will be playing it too.
But FFE is a golden oldie that can hopefully be kept alive/preserved for prosperity

It can always benefit from new graphics/models but if missions/stories are really your calling - then probably the Frontier remake "Pioneer" would be a welcoming recipient of any contributions.

 

[Diziet Sma]

I think it's unlikely the Alioth Wiki is incorrect

Alioth wiki should be read with caution as it includes non-lore Oolite information...

Ahem.. the Alioth Wiki keeps FFE and Oolite information in entirely different sections. And we are very particular about keeping Oolite's own lore out of the sections devoted to the rest of the Elite stable of games. Your imputation that we might permit Oolite lore to corrupt information concerning Elite, FE:2 and FFE is not appreciated by those of us who maintain the Alioth Wiki.


On an entirely separate note, until now, I've never played FE:2 and FFE (frankly, so far as I'm concerned, they break Elite's lore/canon far more than Oolite does*, to the extent that I regard ED as Frontier 3, not Elite 4), but I came across FFED3DAJ just yesterday, and I've been impressed enough by yours and nanite2000's work that I'm starting to play around with it. Congratulations on a truly phenomenal piece of work, gentlemen!




* Actually, Oolite doesn't break Elite lore.. Unlike the Frontier games, it merely extends it.

 

[AndyJ]

Your imputation that we might permit Oolite lore to corrupt information concerning Elite, FE:2 and FFE is not appreciated by those of us who maintain the Alioth Wiki.

It was a quick, late night response to an active poster who'd already made several back-to-back posts. I was simply trying to avoid any potential for confusion between versions by directing them to an exclusively FFE site that I know very well - I was not suggesting that the wiki has incorrect information. A PM and I'd have happily rephrased/clarified the sentence, no offense was intended. My apologies if any was taken.

 

[Steve]

Is it still the case that medium gas giants use the same model as large gas giants? For example, this is how Saturn looks in FFED3DAJ

which looks suspiciously like Jupiter inside a load of rings!

ISTR reading somewhere that both types reference the same planet, unless I've missed an update somewhere? :S

 

[AndyJ]

Hi Steve!

Yes, you are quite right - both the medium and large gas giants are represented by the same model in FFE (#134)

There wasn't any way to distinguish between them when I was adding the new texture options for v1.10 and by the time that build was drawing to a close, I was a bit too jaded to start digging through any more .asm code to try and figure out a way of doing so!

But, I did quietly revisit it earlier this year. I thought that the 2D system information views know which are medium or large gas giants, so how do they pick the description and graphic?

Before digging into the sysgen routine I had thought that I might have to work something out based on the radius or mass of the gas giant, as the 3D objects do retain that information. But there's a system generation function that's called to create a set of data for either the current system or the target system. This describes each of the suns, planets, moons and their stats, as well as any space stations or cities or star ports. This data is used directly for the 2D views and each object has an index value to choose the description/graphic for it. Each object also has a model# value as the data set can also used to populate a list of objects for the 3D planetary view, or for initialising the objects in a system when you hyperspace there.

When a 3D objects list was created, it didn't retain the description codes which could be used to split the medium/large gas giants..
However, I spotted that the planetary objects had a spare word at the end of their 3D data when compared to Ships, and I was able to able to tweak the .asm code and store the description index there. That was where I left it at the time though as other things were on-going...


Anyway I revisited this last night and it was quite straight forward to add a new check when drawing model#134 and it can now distinguish between the large and medium gas giant. I've also added support for a new section in the texture .cfg file ([134_Medium]) so that the medium gas giants can use a separate skin, atmosphere, shader variables etc. There is already an additional skin in the core textures pack waiting to be used, although when it is colourised the colours do look a bit "full on" so I'll need to tinker with the texture .cfg settings to soften it a bit.

A new "issue" was created though, because as I mentioned - the current system only gets populated into the 3D object list when you hyperspace there. So if you were to load an old save-game then the object data won't contain the extra description code and the medium gas giants would still render as before.
So I've added a patch-up routine tonight that gets called from FFE's load function. This checks for any gas giants that are missing the description value and if there are any, then I call FFE's sysgen function to build the 2D data list for the current system as this isn't in the save data. It was then quite straight forward then use that list to add in the missing values.


I also started looking at the texturing issues that the gas giants suffer from, they were really obvious in my test-saves.
It seems to be due to the "smart optimiser" code that FFED3D added to increase/decrease triangle subdivisions (detail) based upon the distance of the triangle. (I'm not entirely sure what this distance is actually measured from either...)

I'm experimenting with hard-coded values for the more simplistic objects (asteroids, gas-giants, moons and red-dwarfs) and decreasing them as the object gets further away from the camera. So far it seems to solve the issue and the texturing becomes uniform without any extra-large or oddly coloured triangles. It might even increase frame-rates a bit, although I need to test with a runtime build to really be sure.
I also noted along the way that I could fix a test-case where I'd landed on a moon (Gupta) and the ground no longer disappeared. I don't think this will fix all cases, as I do think that sometimes the ship is below ground, but it looks like a step forward in improving/fixing this problem... but need to test this on a few more scenarios than this one moon!


TLDR: medium & large gas giants will get separate skins. WIP improving texture issues on them, as well as asteroids & moons...

 

[Steve]

TLDR? Had to look that one up! But it doesn't apply to your "wall of text". I really enjoy reading through your account of what you've been up to, fixing the code

Sorry if I've caused you more work and late nights with the medium/large gas giant thing! It'll be nice to see Saturn rendered more accurately in the next build. Also, yeah the frame rate does suffer horribly around some of these planets so if you've found a way of improving that then that'd be cool

TBPH, the only "issues" I have with FFED3D these days (not just the AJ version, but also those that came before it) are the dodgy frame rate on and around planets and the disappearing ground/see-through planets. I fully understand that these are non-trivial to fix (though you may have partially fixed the latter!).

Just about to start another session on the game. Can't wait for the next build (once the Russians have sorted things out!)

 

[AndyJ]

Well I had a bit of an experiment, drawing lines to show the normals for the planet verticies (turning them into "pinheads" in the process) and found it was quite easy during the mesh-generation to identify which triangles would face the camera, and which were hidden in the 3D System views. So I was able to hard-code a detail level, dependant upon planet distance that generally increases the visible landscape by a step, whilst keeping those surfaces out of sight simplified.
I've also generally limited the detail for asteroids and moons which seems to be having a good impact upon frame-rates everywhere. Gas giants are much better now and have uniform texturing, also the splits such as the reversed "L" shape visible in Steve's screen shot seem to be resolved.

Steve is keen to see Saturn looking more realistic, so I had a little experiment tonight, adding some fog settings to help hide and colourise the texture:

Zut alors!


There are also a number of moons being drawn in that frame, and if you look really, REALLY closely (Mimas!) then you'll see that they're shaded 3D objects.
Now up until this evening, this was crashing the frame-rate down to about 8FPS on my slightly creaky Q6600 and it is CPU bound. I've just made a slight tweak to check distances and avoid FFED3D's smart_optimizer - and that frame rate is now hitting 28-29 FPS. Yay! A little bit better!

Low-level is currently a problem though. FFED3D added the smart_optimizer I think to try to increase detail level of triangles closest to the camera, so that the terrain would appear more detailed. Unfortunately, I'm not convinced that the distance measured at the time triangle-divisions are decided is valid in that sense. Also it doesn't prevent excess detail from being generated on the far side of the planet. Now I hold my hand up with all things 3D as still being a bit of newbie, but perhaps I can calculate where the triangle will be when viewed and the actual distance relative to the camera, then take the same approach as in the 3D Sytem view ... or perhaps I should look at whether it's possible to calculate & store the mesh at highest detail post-load or hyperspace and then have it drawn like any other replacement 3D model.

Anyway it seems that there are some reasonable gains already from quite a short investigation, but probably it's a bit too much to pursue right now to try to find the 'ultimate solution'!
I'm rather keen to draw a line under v1.11 sooner rather than later, as it's been on-going all year!

Hollow planets are still a 'thing' unfortunately. So if you do land below surface level or the camera dips below - then you'll see through to space beyond. This is a culling issue - triangles that aren't facing the camera aren't drawn.
I could set culling to 'none' but then you'd get a screen full of soil instead! Sot, it's a bit of a no-win situation, and GLFFE had the same issue it seems but you can see it less often as it drew FFE's solid 2D atmosphere below the surface of the moons as well as planets - and that would block out a lot of the transparent areas. It'll be a hard problem to fix I think, as obviously the idea is that the ship should land on the surface and not below it! (Filling in unexpected voids is something typically avoided in the first place!)
The only idea I have right now is perhaps to create a slightly smaller copy of the mesh when the player gets close to the planet, but then walking through the sides of the surface triangles to create pyramids down to the centre of the planet, and filled with a ground colour/texture. So a sort of Terry's Chocolate-Orange solid planet! I can't imagine this'll be very FPS friendly though! <shrug!>

[edited 28/08/2018 to update image URLs to postimg.cc]

 

[Steve]

Saturn looks beautiful there, Andy!

Good luck getting your head around the 3D issues.

If only planets in FFE were flat, like in real life

 

[Zak Gordon]

Wow, Saturn looks really good there! Excellent stuff Andy

This is going to sound dumb (for sure!), but on the issue of hollow planets and clipping through to see into that hollowness, is it not possible to not allow a lower than ground level landing? Like always hover it at a +1 whenever it is near to that 0 ground level? Or would that just look even worse in certain situations perhaps? I'm thinking that it would only look a bit odd in the 3D camera mode, but that can look odd already?

Is sea level the same as ground level in the game? Anyway i'm sure there are a bunch of us just really, really happy you are still doing this

 

[Steve]

This is going to sound dumb (for sure!), but on the issue of hollow planets and clipping through to see into that hollowness, is it not possible to not allow a lower than ground level landing?

Don't worry Zak, I was thinking the same thing! But there's the situation on some planets when you position the camera above your ship and zoom out and the ground disappears, so I'm guessing it's more complicated than that?

 

[AndyJ]

Ha! yes, flat planets would be a big help in FFE!!

Warning! wall of text incoming.... of course

Ok so I held off from replying straight away as to be quite honest I wasn't even sure how or where Altitude is calculated!
I also wasn't sure how aware FFE is of the planet's terrain - I thought that it must be as can fly into the slope of a hill and crash, but then we also have issues with star-port/base placement where they can float far above the ground level.

After a bit of a searching I eventually found something that looked like it must be the player-specific collision code, and perhaps bouncing the ship following an impact and also testing if near a star-port. What wasn't clear though is how it was deciding that a collision with the planet had happened. I also found that Altitude was being set via a memory location+offset nearby, but not how its value was being calculated. This was in some fairly large and impenetrable assembly code...

I was going to put it aside and perhaps take another look over the Christmas break, but I remembered some crib notes that probably came from John Jordan during JJFFE - and in these I found a brief analysis of the collision routines!

I now know that ship/missile collisions check a collision radius (bubble) around each object.
Ship to terrain collision checks for the bubble around the ship intersecting with the individual triangles that form the terrain mesh of the planet, and this can lead to either a crash or a landing. I'm not entirely sure of the calculation due to it being raw assembly code, but it looks to be using normals and the position of the ship to find the distance between a surface triangle and the ship - then checking if this is less than its collision radius. (I guess this is sphere-to-plane collision)
Altitude to the planet is derived from this distance calculation except when landing at a star port, and then it is the distance to the assigned landing pad.

So it appears that the ship is landing on the ground as far as FFE is concerned, despite what the 3D view seems to suggest. It's final position is adjusted by the radius of the collision sphere of the ship though, so perhaps if a ship is long, then it'll have a much taller sphere than it's model height. And if the triangle it collides with is sloped, then this might add to the impression that it is hovering far above the ground sometimes.

Placement of stations/bases on the planet calls the same collision functions as for ships to adjust their position to the surface.
However. Their position only appears to be calculated once when the system is generated - either at the start of the game or when you hyperspace in. I wasn't sure that it had a planet mesh to compare to, because it wasn't going through FFED3D's function, but digging deeper I found that the collision code calls the original FFE code to generate the planet surface mesh at a fixed detail level.
Their position also doesn't consider if the terrain is flat enough to place everything on or not, and this can be seen at the default start postion. If you take off and fly just to the left of the pad and land again, you'll see that the back edge of the star port intersects with the terrain slope, but everything forward of this including the town is on a flat plane that gets higher and higher from the ground below it, it's almost like a diving board jutting out from the terrain. This is why, when using replacement models, you can see sky through a gap between the star port and the grassy/road area just ahead and to the left.


Considering the complexity and obscurity of the assembly code, I don't think that there's a lot that I can do with it to fix the discrepancy in station/ship height when at altitude 0. But, it's also something that annoys me when landing on moons etc - so perhaps is there a plan B? How best to prevent being able to see below the surface of the planet?
And then I had a thought... if the ship is landing at altitude 0 and FFE is aware of the surface mesh... but the surface is drawing above the camera... well could it just be that the planet is scaled slightly too large? That almost seems too simple...

So I've experimented with a couple of moon/small planet landings as these seemed particularly affected by the ground disappearing when landing. I eventually found that at 99.9695% scale it's just enough to keep the terrain below the ship, and by turning off culling at low level there aren't any issues with hills disappearing either.
Earth-like planets have so-far required slightly less of a reduction, and the difference isn't noticeable to the player - especially as the perception of where the ground is compared to the altitude tend not to match up.
This tweak/fix hasn't exactly been extensively tested yet!!! The joys of procedural generation - so I'll add it in as an option that can be turned off if need be. I think that I might also expose the ratios per-planet type too - then if it's not quite right for one it can be adjusted and rolled into the next build.
As this seemed to work - I wondered if the same approach might help station placement - i.e. reduce it's 'height' by a similar percentage - and initial tests seem promising. Not perfect, but better anyway. I've also found the routine that rotates the camera when landed and tweaked it slightly so that it doesn't quite go "flat" to the surface, and this also helps preventing it from looking from beneath the ground.
It's not perfect- you can still zoom the camera out and then end up under a hill and able to see the inside of the planet, but this seems to need a deliberate effort to make happen so I guess it's probably not worth worrying about!

Other little tweaks too - I've forced the vector-fonts to draw at full detail so that they're consistent sizes on ships and TV adverts, also I've taken a look for where FFE decides to draw sub-models or not. It was always a bug-bear of mine from the days of Frontier on the Atari ST that you could land inside a dome, but rotate the turret and have the dome/buildings disappear at times - ruining the illusion - but this is now fixed! Removing the visibility check could impact a little on performance I guess, so just in case of issues this 'fix' can be switched off if necessary.
I'm not sure I've mentioned this either, but I also took the time to fix the aspect-ratio code so that it can now be displayed in a "square" 4:3 format within the native resolution that has been chosen, both windowed and full-screen. It's also a lot more stable than it used to be - since the last build I've added a lot of logging output to track where crashes were happening and then coded to safeguard against them. The major culprit appears to have been the introduction of LUA, primarily to display the loading screen "Tips" but it seems to have been causing stack corruption. I wanted to rewrite the loading screen to enable translations anyway, so I removed the LUA dependencies at the same time and it's been pretty solid since.

Have a couple of Russian translations to add in but will try to get another beta out tonight. I hope we're not far off the next build now though TBH - as much as it's been kinda nice to just chip away quietly at a new build with no external expectations, it's definitely way past the point of drawing a line for v1.11!

 

[Steve]

Warning! wall of text incoming.... of course

Happy with a wall of text when it's about FFED3DAJ!

Great to hear there's a possible solution to the see-through planets bug that doesn't involve wading through miles and miles of assembly code. Back in the day, I got quite proficient at BBC Basic and some other high-level languages, but assembler always made my brain hurt.

As long as the fps stays reasonably high on the populated planets I'll be one happy bunny trying any new betas you put out