The FFED3DAJ Thread

[AndyJ]

Looking superb!

Isn't it! I do find myself stopping to watch the sun appearing around a planet at times - I think people will find the PetRocket atmosphere shader especially is a really, really nice addition in this next build, as well as the reworked rendering so that even within atmospheres you can glimpse hints of distant planets through a daytime sky

There's also a new 'glow' atmosphere shader that I've created to use around brown dwarfs & the irregular gas-giants (admittedly far less spectacular, but they can't use the PetRocket circular one) and also some surface effects to fog or boost colours to either obscure or make the terrain begin to glow relative to distance. You can see a nice example of this being used in nanite2000's 3rd picture of Jupiter seen through the haze of its volcanic moon, Io. The moon Europa is also just visible contrasted against the new backdrop of FFE's original nebula... (and btw, it is a shaded model of that distant moon - it's not a sprite!)

Between the new shader features and the enhanced texture pack, there's going to be some visual treats to be discovered in this next release!

As nanite2000 has posted, it looks like we're pretty much there with the next release and his texture pack!

I've just had a very productive testing/bug-fixing session and I think/hope I've been able to track down and squish the issues that had caused shutdown crashes when exiting the game. (annoyingly, they didn't happen or trigger anything in 'debug' builds!)

I've also decided to add a new display mode... couldn't help myself after reading a post in the Elite: Dangerous section of the forum yesterday!
The post described how a 3rd party tool (Borderless Gaming) allows games running within windows at fullscreen to lose their borders & caption to fill the screen - but still allow interaction with secondary monitors etc.
I thought this sounded like a neat idea and it was reasonably straight-forward to implement this feature internally as an alternative to the 'exclusive' full screen mode. The 'exclusive' full screen mode does have the advantage of being able to run at a specific resolution, and can restrict the mouse to the primary monitor, but it doesn't play well with any other windowed DirectX application running at the same time! The new mode will run full screen at the current resolution of the primary monitor - but other DirectX apps can run on other monitors, such as Windows Media Center, or the player can hop back and forth to applications such as BUFFET or a web browser without the game being disturbed.

I did decide however to 'park' the change that I was making to split up planetary rings for the time being. The idea was that it might help solve some rendition issues where the rings overdraw the planet, and unfortunately the new 'glow' surrounding them. Although the ring model does get broken up now into separate parts, in extended testing it seems that for as many scenes that this change fixes, there are perhaps as many new issues it creates
I could keep testing & tweaking this, but I think that I'll probably be fighting a fundamental "Cull" issue here; the ring models are currently drawn as a 'single sided' models and rely upon them not being culled at all at rendition time - this is so that you can see them from either direction, above or below. Normally you should only see a triangle that's drawn as facing towards you, switching off culling means that you can potentially see it from the opposite side as well - and rings require this...
And there are similar issues with the 'primitive' based FFE models where they draw 'mirrored' triangles and squares to save repeating mesh data. The sidewinder ship is a case in point - half of its body is a reflection of the other. When drawn, only half of these parts face the correct way, the other half doesn't... So these 'primitive' models currently require that culling is switched off when rendering them so that you can see the whole model! Meh!
Trivia: this is also why surface cities/stations can be seen through a planet's hills/ground, why the outer 'port' texture can be seen at the back of the docking bay when entering a 'claw' shaped space station (e.g. Mackenzie High@Beta Hydri) and why the rear view of some ships is obscured
This might yet be fixable, but I've already spent waaaaaay too much time tweaking triangles for this build - it'll have to wait for another day - it's time to play!


I just need a final "catch-up" on the admin side of things, documenting some of the latest functionality into the readme file (how to define surface fog, glows, atmospheres etc) as well as making sure that the standard installation's default settings without nanite2000's texture pack is still presentable - although installing that texture pack with v1.10 will obviously be the recommendation!

"Touch wood" though, this next release is incoming and preparing for final approach!

 

[Steve]

"Touch wood" though, this next release is incoming and preparing for final approach!

In time for the weekend would be nice

though my better half has a list of chores for me longer than a gorilla's arm

 

[polaris]

Will nanite2000's texture pack be resource demanding above what we have at the moment?

 

[nanite2000]

Will nanite2000's texture pack be resource demanding above what we have at the moment?

It will be more resource demanding.

I'm running the game with the new models and my texture pack, and it uses about 1.15GB of memory. Without my texture pack, the game uses about 850MB of memory.

Best thing is to try it and see how it goes (it's easy to enable/disable in the game CFG file). If becomes too slow, let me know and I'll try reducing the size of the textures. That way you'll still get the variety, just not the definition.

 

[Steve]

Those screenshots look amazing!

Can't wait for this update

 

[AndyJ]

Those screenshots look amazing!

Can't wait for this update

Stop gawping and do your chores! <whip crack!>


I've added explanations for the new tweakable texture settings into the readme file now, and realised that the 'base' texture.cfg file itself had actually expanded so much so, that it was easier just to write a function to generate it from now on, rather than try to transfer the settings by hand, and that part's done too!

I'd have loved to have gotten it out for this weekend, but ultimately things have to be documented and tested - there were new texturing features still being added even last week and so both myself & nanite2000 have needed some time to react & to make use of these features. (no surprise, I'm more behind having been mainly focussed on the coding until now!)

Will nanite2000's texture pack be resource demanding above what we have at the moment?

To answer this: yes, nanite2000's textures are currently quite a big hit on resources, but they're sized at a generous 512x512 - so there's still the option yet to downsize these and have a lower resolution pack.

Even if this still proves too much for those with lower spec'd machines, the base install doesn't require them to run, although obviously it'd be prettier! The new atmospheres will still work with just the base install and using them will actually drop 2 of the original 10MB sky textures, so it's a skinnier base to begin with...
(oh, and if the new atmosphere shaders are too taxing for some users' PCs then the original is still there as a fall-back and it can be chosen in the .cfg file!)


If you're running 64bit Windows with 4GB RAM then you've no worries anyway. It'll all still fit... nanite2000 also has some upgraded game textures to come and currently this hits around 2.3GB when all loaded.

I'm mindful though, not everyone has this much memory or might be running on 32bit Windows. So part of the testing is to make sure that it'll still work and tweak things if need be. This is why, when I add a new feature it'll typically have a .cfg setting to turn it on/off ... extra "bling" is all well and good, but I'm trying to make sure that any new build doesn't exclude anyone either!

A small gain on the 'tweak' front:
Steve had reported previously that the 'Hammer' space station doesn't always load it's central texture, I came across this too in testing so have taken a look and it's using a 2048x2048 image by default - and that sometimes fails to load. So I'm including a skins.ini in the next build that'll drop in the model 77 folder to switch it to default to the 1024x1024 skin instead. (the memory conscious can switch this to 512x512 if they want)
Also, this Station and it's "Hammer" arms have duplicated models for the into sequence, and there's a separate copy of the central section for both the 2-armed and 4-armed variants. So I'm now mapping these to use model 77. Similarly the ships that appear in the intro will use their in-game models and not the duplicate model/skins that exists. Doing this doesn't save a whole lot, but every little does help!

We're also not entirely painted into a corner resource wise either, although the haves vs the have-nots will benefit the most...
One resource that I've not looked at until now is the video card - mainly because mine were a bit rubbish until recently!
I've now got a 2GB card (previously an SLI set-up) and I'd commented on an Elite Dangerous thread about its low memory usage - speculating that perhaps textures were being cached on the video card... so with that little light blinking away all week in the back of my mind, I thought I'd have a quick experiment today with loading all of the main textures directly into the video memory rather than into system memory to see if it would work - and, oh! It did! This immediately saved a whole GB when using nanite2000's new terrain and forthcoming game textures!
Although the planet terrain & water textures "work", they do seem to 'sparkle' when drawn at a distance, almost like the static on an old TV. It's not terrible to look at, but not ideal or 'normal'. This might be a simple setting though on the texture load that describes how to select a pixel when scaling... we'll see...
But anyway, I'm not going to spend time exploring this right now and further delay this next build, I really do want to get it out there! But, we may have found a little more "wriggle-room" moving forward!
I'm not going to just ignore this potential gain for the next release either- so for now I'm going to add some "experimental" settings into the .cfg that can load groups of textures onto the video card. It'll either work or not, but it'll be up to the user to decide to turn it on or off for now - there'll be little/nothing to test if it works. It's a dead easy tweak to the texture load to implement this, and it'll be pretty straight-forward to update the 'lost-device' functionality to drop these textures from video memory & reload - so it'd be daft not to take an hour or two to include this, even if "YMMV" using it!

Anyway, unless something dreadful crops up - and I doubt that at this stage, I'd expect that v1.10 should be out within the next couple of days...

 

[Steve]

Stop gawping and do your chores! <whip crack!>

Chores all done!

I've added explanations for the new tweakable texture settings into the readme file now, and realised that the 'base' texture.cfg file itself had actually expanded so much so, that it was easier just to write a function to generate it from now on, rather than try to transfer the settings by hand, and that part's done too!

I'm kind of hoping some of those whopping great polygons on the planets have been banished. For example:-

Spoiler

I'd have loved to have gotten it out for this weekend, but ultimately things have to be documented and tested - there were new texturing features still being added even last week and so both myself & nanite2000 have needed some time to react & to make use of these features. (no surprise, I'm more behind having been mainly focussed on the coding until now!)

No worries, I'm just an impatient sort

Just out of curiosity, will London still be submerged under 50m of water with the new build and textures? I can fiddle with the terrain.cfg files of course, but that changes things for all the planets of that type

 

[AndyJ]

Chores all done!

I'm kind of hoping some of those whopping great polygons on the planets have been banished. For example:-

Spoiler

No worries, I'm just an impatient sort

Just out of curiosity, will London still be submerged under 50m of water with the new build and textures? I can fiddle with the terrain.cfg files of course, but that changes things for all the planets of that type

Pretty sure that the large polys are the engine simplifying the planet as you get further away from it. You could try adding 1 or 2 to max_divide_deep, or 1 to smart_optimizer_c in the .cfg file, but adding more detail will add more work for the CPU.

I suppose that the only way to really fix London would be to adjust the co-ordinates that the city is positioned at. The Sol system has hard-coded values for planets and city positions/types, so this is probably achievable.
I would expect that the locations get set when you hyperspace into the system - if you recall, altering the planet type doesn't affect a game already in the Sol system.

If you fancy experimenting with a hex editor search for these values:
"6A 54 6A 05 68 34 0B 00 00", There'll only be one match.
the value 54 is the city type, not sure about 05 - all of the earth cities have it, "34 0B 00 00" might be a co-ordinate (0x0B34 hex=2868)
(the 6A and 68 are code instructions, don't alter these)
There is then another value which also could be a co-ordinate: 68 90 CC FF FF which translates to 0xFFFFCC90, I think that this is negative.

London................: 6A 54 6A 05 68 34 0B 00 00 68 90 CC FF FF
Paris...................: 6A 53 6A 05 68 C1 07 00 00 68 B1 C7 FF FF
Tokyo..................: 6A 5A 6A 05 68 56 09 00 00 68 EF 84 FF FF
New York.............: 6A 54 6A 05 68 85 02 00 00 68 59 5E FF FF
New Moscow........: 6A 54 6A 05 68 CC 0F 00 00 68 38 B7 FF FF
New San Francisco: 6A 5A 6A 05 68 EC EF FF FF 68 24 61 FF FF
Sydney................: 6A 5A 6A 05 68 36 F6 FF FF 68 A5 94 FF FF

It looks like New San Francisco & Sydney have negative values for what could be the first co-ordinate. 0xFFFFEFEC = -4116 and 0xFFFFF636=-2506.

(To convert these hex values to decimal easily, use window's calculator in Programmer view with "Dword" selected.)

If you fancy having a go at relocating London, then be my guest! It's probably more efficient to experiment with the hex editor anyway due to the amount of time it takes to rebuild with a code change. I could look at exposing the co-ordinate values via the patch values in the .cfg file if you have any luck!

 

[Steve]

Thanks Andy, spot on as always!

Assigning London and Paris the same coordinates via your hex tables resulted in the game placing both cities on top of each other :smilie: so we're definitely in the right area.

Understanding how the coordinate system works in the program is an entirely different kettle of fish though. By referencing Jongware's analysis of the code, I thought the first value for each city could be the latitude in 1/100ths of a degree. So, for example, setting London to 5130 (0A14) might place it at around 51° but I'm not sure its doing that.

As for the longitude value, well to quote Jongware it's "the horizontal angle towards some arbritary vertical line. " Huh?

So for now, it's a bit of trial and error. I did have some lofty ideas of placing all the cities correctly geographically but then my head started to hurt.

Having great fun though. More soon!

 

[AndyJ]

Thanks Andy, spot on as always!
Assigning London and Paris the same coordinates via your hex tables resulted in the game placing both cities on top of each other :smilie: so we're definitely in the right area.

Hadn't checked the JongWare site, but sounds like the first co-ordinates much be latitude then. < 0 below the equator and > 0 above it. So... maybe try increasing the value a little to move London northwards and out of the sea?

if you are experimenting with London/Paris - perhaps by setting the same latitude value and varying the second co-ordinate +/- 10 or so, might give you an idea if it moves left or right?

 

[Steve]

Hadn't checked the JongWare site, but sounds like the first co-ordinates much be latitude then. < 0 below the equator and > 0 above it. So... maybe try increasing the value a little to move London northwards and out of the sea?

if you are experimenting with London/Paris - perhaps by setting the same latitude value and varying the second co-ordinate +/- 10 or so, might give you an idea if it moves left or right?

Yeah, been doing that but unfortunately it's turned out to not be as simple as increasing & descreasing the first setting to vary the latitude. There seems to be some sort of connection to the second value, but exactly what that is I don't know.

Anyway, I've managed to get London, Paris and New Moscow on dry land and in roughly the right places relative to each other. Tokyo seems to be in the right place already which just leaves New York, New San Francisco and Sydney to do tomorrow :smilie:

BTW a nice effect with the extended detail and draw distances in the latest build is that if you take off from London at night and go up to around 10,000m, Paris displays as more than just a dot but as lights, as it would on a plane flight at sufficient altitude

 

[Donik]

I have to say I'm just as excited for 1.10 as I am for ED beta 2. I've been helping people on reddit get the latest build set up perfectly for their machine whenever i see someone ask it. 1.10 is going to be awesome...

Anxiously waiting!

 

[AndyJ]

I have to say I'm just as excited for 1.10 as I am for ED beta 2. I've been helping people on reddit get the latest build set up perfectly for their machine whenever i see someone ask it. 1.10 is going to be awesome...

Anxiously waiting!

Ah that's cool to hear that your helping others elsewhere Donik, I wasn't aware of discussions on Reddit! (tbh I wasn't overly aware of Reddit full-stop!!)

Just got back from a holiday and haven't really had time to catch up yet with nanite2000 & to check out his finalised texture packs. Coding and the 'core' texture pack should be finalised too as of a fortnight ago, documentation is pretty much updated now bar a read through - so just a case of doing some final installation tests over base installations to check that all's good.
If all's well, nanite2000 & I then just have to synchronise a release of the new patch & the additional textures so that they're all available at the same time - the challenge being that we're on opposite sides of the world! Nearly there though!

 

[AndyJ]

Ah well, I had quietly hoped to test & perhaps we'd get the build out before or over the weekend but it seems that again, coming back with a fresh pair of eyes v1.0 is helpful!

I guess it's always true that when you're working so close to the code for a long time, you don't always spot the gremlins that sneak in! Seems that they bit the cables to the object lights in v1.08 and then engine flares and other lights/fires didn't effect sub-objects... oops! <cue blender, cue microwave!>
That issue's corrected now and also to account for depth-sorting. I've also tweaked it to give extra leeway for lights on space stations/bases so that they can all have an effect...

There was also another shut-down crash that happened <15% of the time that I've now tracked down to the game releasing memory for a specific sample. (I've been adding logging to narrow down where the app is at during start-up/shut-down).

Also the blue stars in the intro explosions have gone a bit crazy this release! There are one or two that spike all over the place in the runtime build when they fade away, but they are always fine in debug builds! I really don't know why this is! :S
I guess that they may have to be dropped or replaced in future, they seem to be broken in someway anyhow, but it seems that compilation optimizations are affecting them too... I've chased them around for a while and after dumping their vertex data out to files so to compare, it looks like it's perhaps either a glu tessellation issue -as in debug the stars always have 186 points but fewer in runtime- or possibly it's a precision, very-close-to-zero floating point issue
Looking back at previous builds, there's always one star that goes a bit screwy... so... to fix or to drop? there is the question! maybe a bill-board image to replace them instead will be an easier fix!
But... I seem to have hit upon an ok compilation setting right now, so although the issue is still lurking, and acceptably visible during one sequence, it's comparable to previous builds - so I think that I can park them to look at later...

I also noticed a couple of isolated areas of weird sea colour on the polluted planets and when 'softening' these, I then decided to revisit the fix I'd made to stop the sea-colour from bleeding into the land on 'green' living planets. A little tweak and the edge is now 'golden' to create a sandy shore area. This will benefit the 'basic' installation by adding a coast between land and sea, and for the moment it's just a hard-coded set of colours. But anyway - players that make use of nanite2000's new add-on terrain textures pack will get a much more detailed effect

testing continues now with the texture packs.... perhaps a release within the week?

 

[Donik]

Anxiously awaiting! It would figure however that I leave for holiday on Friday and am gone the entire next week. I'm looking forward to seeing a bunch of very nice screenshots in the near future from you and the players! Can't wait to give it a go. Keep up the great work - I love your updates.

 

[Steve]

I can't pretend I won't be giving Beta 2 a whirl, but I love FFED3DAJ updates as well!

 

[AndyJ]

I can't pretend I won't be giving Beta 2 a whirl, but I love FFED3DAJ updates as well!

Beta 2 is a good incentive for me to hurry it up too lol

 

[AndyJ]

Anxiously awaiting! It would figure however that I leave for holiday on Friday and am gone the entire next week.

Well Donik, have yourself a great holiday tomorrow, and all being well you'll have something to look forward to when you get back!

Testing is still on-going and I've a busy week-end ahead, so it'll probably be mid-week at best anyway before I'm happy to think about the release.

And I have to confess to indulging in a "little bit" of feature creep ...

Having stopped coding, and switching everything on again to test, the elephant in the room gave me a swift slap in the face!

There's one area that's really been swept under the carpet up until now - largely as I wasn't sure if it was easily fixable - and that area is ... docking!
I've spent most of the last 12months using the 'original' models (quicker to load) so it was a rude reminder to see just how bad the docking sequence is with the replacement models switched on... it's like one of those fairground ghost-rides where you smash through endless closed doors!
I felt this would just ruin any first impressions for someone just starting to play the game... and well, it was high time for that elephant to 'move on'!

The past few days I've looked at the .x models as well as the original mesh data to see how they matched up, and to see if there was a way forward.
Turns out there are actually 2 different docking 'entry bay' models in existence, one which fits the cylindrical station and the other fits the "hammer" station seen in the intro. Other stations can use the latter entry bay, but there's a bit of a gap between the outer walls and the bay itself. (I'm not a modeller, so I can't fix that right now... anyone who can extend the bay forwards with a little extension, well be my guest!!)

There were also a couple of .x models that were trying to replace complex FFE 'collections' of models which, depending upon game-variables would need to draw different shapes or draw sub-models (child models). Those replacements were clearly going to be incompatible moving forward.

So, first of all I've stopped the game from loading the incompatible models. Then, I've tweaked the 'tris.ini' files for the others to make sure that the replacements still load their required child objects. TV screens are suppressed in the docking bay entry areas as they don't fit, or can magically appear out of thin air! I've split the cylindrical station's docking area off to a new model folder and will display that instead as appropriate.
The entry bay .x models also have animated blast doors. I've now worked through the various docking/launch stages to make sure that the doors are either fixed as open/closed or are being animated in the correct direction.

All well and good. But the 'complex' objects meant that you would see the 'original' models for other docking bay gates and also the elevator room as you transitioned. So I've overridden the textures for these (when the .x entry bay model is in use) and have been able to re-skin them to blend in with the entry bay and the final docking bay room. I then had to figure out how to remove the yellow chevron symbols from the doors - but I've left them on the 'welcome mat' of the entry bay!!!
And one final "OCD" tweak I've made, was to stop the animated stars that you can see through the final room's windows when you're docked underground... bit unrealistic! and I even managed to find a blank, black frame for them to be set to!

It's took a fair amount of work but think it was well worth it! No more crashing through closed doors now and the docking/launching sequences are just as seamless (cough) as with the original 'primitive' models

 

[Donik]

Well Donik, have yourself a great holiday tomorrow, and all being well you'll have something to look forward to when you get back!

I'm back, and thanks! Is all well? I see no release or update! Watcha been up to over there?

 

[AndyJ]

I'm back, and thanks! Is all well? I see no release or update! Watcha been up to over there?

Well I've been very, very busy with fixing the docking bays - had to fix the .X models a little bit (thankfully figured out that I could do so with MeshView + notepad as I've no idea at all how to use Blender!) and there's now two separate models being used, one for the generic 'square' entry bays (scaled appropriately for each space-station type) and there's another for the slanted entrance of the Tube station that had been lost along the way it would seem. Both had an extra room where the lift is that needed chopping off, and the rear door needed resizing/moving to remove gaps that you could see through.
The lift room now draws the 'primitives' FFE model, but I'm changing the textures that both it and the doors use when using the .X model for the entry bay/final room - so that the docking/launch transitions all blend in to each other.
Additionally, if you dock in an underground station now, it'll use a different docking bay model - that's optional but even if you only use the same model as for orbital space stations, it's tweaked so that you won't see spinning stars through any windows when docked in a cave!
Few more bugs & CTDs squished throughout the week too... it's all good!

Some final, final testing now, whilst co-ordinating uploads of the texture packs first and then pretty soon after it'll be "Go!" for v1.10