Hard Light Productions Forums
General FreeSpace => FreeSpace & FreeSpace Open Support => Topic started by: Trivial Psychic on December 13, 2017, 06:32:35 pm
-
This is an attempt to get some broader feedback and hopefully solve a lighting issue I've been having with recent Nightly builds. I've had frequent assistance from m!m in trying to resolve this, but we appear to be at a loss now.
Builds newer than October 31st have no ambient lighting for me. The glowmaps work, but all ambient lighting is gone. I've tried increasing the ambient factor in the launcher but there was no change. Oddly enough, Debug builds don't have this problem for me. m!m was unable to reproduce this, but he isn't using an ATI card like I am, and I was hoping that other ATI users might be able to confirm my findings. I've also found that jumpnodes render as black under these builds.
You see an example of my lighting issue in the Dec. 6th Nightly Build Thread (https://www.hard-light.net/forums/index.php?topic=94219.0).
My card is an ATI HD 5770 with 1GB RAM. I'm using Windows 7 Pro 64-bit. Because of this, I can't used the very latest drivers. In fact, the last driver set released for my configuration was in 2015.
Has anyone had this problem, or can shed some... light, on what might be causing this?
-
I've inconsistently had this problem as well. Usually never in game, but I've seen it in FRED and also in the little ship previews in the briefings.
-
I had this issue only in FRED2. the first visit in the technical database as well in the weapon loadout screen. But never in mission.
But i had this problem in Pre-3.8.0 Nightlies only that use the new lightning model. But after that, i did not have any issues. But also it made no difference if i used Debug or normal builds.
But during this time also some new graphic drivers were released... maybe they were responsible for my solution in the first place.
Well, i can not help you in this matter unfortunately, because the difference between debug and normal builds stumple me, too. Did you try to check some lightning flags? I am talking about Emissive Light or Deferred Lightning?
-
Emissive light and deferred lighting are both enabled.
-
Emissive light and deferred lighting are both enabled.
And the problem is the same if you play without it?
-
Disabling Emissive Lighting results in no change, but disabling Deferred Lighting brings things back to near normal. I say near normal because when comparing it on and off on the October 31st build, the last build before this problem began, having Deferred Lighting disabled makes it just a bit brighter than with it on. I don't have time right now to compare whether having DL turned off also restores my jumpnodes or not, but I'll likely try it tomorrow. I'll let you know what I find.
-
Please post your fs2_open.log file. Instructions on how to do this can be found in this post.
-
Log file using Dec. 12th fast Debug on Port3.5+MV2014 & FS2+MV2014 with Deferred Lighting disabled.
[attachment stolen by Russian hackers]
-
Does lighting work in that configuration? You said above that it works if you disable deferred lighting. If it works then a log of a run where it doesn't work would also be helpful.
-
Copy that. Same configuration. Just remember what I said earlier, that it renders with proper lighting under debug, even with deferred lighting enabled.
[attachment stolen by Russian hackers]
-
More data. Although lighting appears normal with deferred lighting disabled when viewing in the lab, but in mission lighting is often dark again. I say "often", because it sometimes flickers to proper lighting. I haven't tested it with a jumpnode yet.
-
Good news! Dec 17th build has proper lighting restored with no flickering. I even have my jumpnodes back! YAY!
Thanks to whoever figured it out!
-
This is really getting irritating. I don't have time to do some proper testing, and probably won't for at least another week. The Dec. 17th build working for me, appears to have been a one-off thing. Now it won't do lighting again. I loaded up the new Dec. 21st build and found no lighting. Then I switched back to the Dec. 17th build, no lighting. So I thought that perhaps one of the .dll files from the new build was responsible, so I re-extracted those with the Dec. 17th build and loaded it up, and still, no lighting. Back to the beginning... Oct. 31st build works, debug builds work. All release builds since Oct. 31st have no lighting.
-
Could you try disabling shader caching (should be in the Troubleshooting section in the launcher)?
-
Disabling shader caching leaves ships completely black, including glowmaps. Glowpoints are visible however. Unlike my previous and recurring issue however, this affects the techroom rendering. In fact, the techroom rendering in this build displays the same as the lab and in-game with shader caching on... model with glowmaps. With shader caching on, the dark texture problem I've been having is not manifest in the techroom. I forgot to mention that.
I should also mention that I tried the Dec. 21st build with deferred lighting disabling and didn't encounter the flickering issue... this time.
-
I'm gonna continue to use this thread because I'm convinced that the bugs I'm experiencing are the same as those I reported before. I'm gonna try to sort through these piece by piece. First, I'm gonna start with FRED builds.
I'm using the 2014 MVPs with the additions of the new Leviathan, Anket, Hippocrates, Ptah, Bes and its associated cargo.
I tested all models to make sure they rendered properly and found all models work properly up to and including the March 7th build. With the 10th however, I get render issues with the Hecate, Edjo, and Skyboxes.
As you can see, engine textures on the Hecate render as transparent on the newer build, and the Edjo doesn't render at all. It'll still show the wireframe if I select it, but no maps.
Be advised, the issue with that bit of damage texture by the engines doesn't show up in FSO builds unless I disable environment mapping or spec mapping in the lab.
BTW, you can't see it, but in the builds 2018-03-10 and newer, skyboxes won't render for me in FRED or FSO.
[attachment stolen by Russian hackers]
-
Here's the FRED debug file from having loaded these two models and a skybox (starfield.pof). I'd have included it in the above-post, but I can only include 4 attachments per post.
My next set that I'll readying involve a new build, the June 30th build. Most of the models won't render. That said, just the other night that same build was loading most models properly. Its the intermittent nature of most of my bugs in both FRED and FSO since 2017-10-31 that are the most irritating part. I might load up a build 6 or 7 times without issues, but on the 8th and successive runs it'll be buggy... but I digress. I've loaded the 30th build 3 times today, even after a reboot, and so far I'm getting the same result (although loading the Sath on my first load did lead to a crash). I'm putting together screenshots of some of the models with hopes that someone can spot a pattern.
Before going to posting screenshots, the following models have partial rendering, usually in the form of turrets or other detail submodels:
Ulysses (some front parts)
Hercules MK1 (piping on the engines)
Ares (some small bits on the back)
Artemis D.H. (the glass with the skull on it)
Medusa (Turret and engine paddles)
Ursa (Turret)
Fenris (Turrets & dishes)
Faustus (Sensor paddles)
Hecate (Turret & other details)
Hades (main hull renders but some bits around the head and pylons are transparent)
Deimos (Turrets & some details)
Aeolus (some turrets)
Iceni (Turrets)
Seth (paddles)
Horus (paddles)
Osiris (turrets & other details)
Nephthys (just the pilot)
Isis (Arms & Turrets)
Ankh (turret arms)
Anukhet (only two small pink circles)
Setekh (sensor panels, turrets, & a few other details)
Shivan Comm Node = Perfectly rendered
Waypoint = Perfect
Jumpnode = Perfect
BTW, I've downsized all of my screenshots to 1/2 original size, which seems to result in some disjointed grid-lines.
Screenshots for the above-renders will be loaded on a later post.
[attachment stolen by Russian hackers]
-
I can reproduce the damage texture bug so I'll take a look at that. I cannot reproduce your issue with the transparent engine textures though. Hopefully that is related to the damage texture bug...
-
Was the log file of any use?
-
Not to crash the party here, but by transparent engine textures, did you mean being able to see the engine glows thru the body of the model (like being able to see the glows from the front or sides thru the hull)? I began to notice this when 3.80 was released.
Just curious.
-
No. This refers to the fact that the textures on the engines of the Hecate are not rendered in the post-March-10th FRED (but not the latest) build, leading to it being see-through.
BTW, here are the screenshots for the June 30th FRED build. I'll attach 3 shots and the 4th attachment is a RAR with the whole June 30th set.
On a similar note, I recently loaded up the July 4th FSO build, trying both with just the 2014 MVPs and with the Upgraded Inferno R1 Classic, mentioned in THIS (https://www.hard-light.net/forums/index.php?topic=94101.0) thread. As I stated in that thread, I performed a number of model and graphical upgrades to my own install of that release, importing a number of models, many of which from the new Inferno development, which I used to be an active part of. Loading just the 2014 MVPs (+ newer models released since) and found that in the lab everything loaded properly. Then when I loaded the Inferno mod, I found that many of the classic R1 models were either not loading or were loading similar to the FRED builds, with mostly submodels rendering. Models I had replaced with upgraded ones were working almost flawlessly. It occurred to me that perhaps FSO was somehow choosing to ignore pcx files. The other possibility is that it is not rendering some textures that don't have normal maps or something.
As I am posting this, I decided to load up FSO again to see if I could find any more weirdness. What I found was that I could duplicate nearly exactly the FRED issues under 06/30 if I turned off the glowmaps in the lab. A few ships with modeled cockpits that weren't showing up in FRED, were showing up with glowmaps turned off in the lab. I then loaded up the upgraded Inferno R1, and found that with the few models from FSO that were being used from the 2014 MVPs, turning off glowmaps in the lab didn't produce the same result as with just the 2014 MVPs. The same result occurred however, if I disabled specular or environment mapping.
Again, I tested things again, and got different results since the above paragraph. Loading FSO with the 2014 MVPs this time gave more predictable results when disabling glowmaps in the lab. In fact, results are closer to the above-mentioned Inferno load, with the specular/environment thing. That said, this time when I loaded Inferno, the 2014 MVP models didn't display the same rendering issues when glowmaps, specular, or environment mapping is turned off in the lab. Results are more predictable now. The only weird difference from the earlier FSO 2014 MVP (no Inferno) load, is that some of my more recent pilots were missing. I chose an older pilot (which had been corrupted) and it worked, and I saw the glowmaps-off behaviour. This time the newer pilots returned, and the older pilot again resulted in a crash-on-load.
As you can see, this is getting quite irritating, as behavior changes from one load to another.
I did make some other observations, but I need to investigate further. I'll get back to you.
[attachment stolen by Russian hackers]
-
Well, I may be on the cusp of a solution for all of my graphical issues... yes, I'm upgrading. After a number of blue-screen fault messages, and for a time even having the computer shutting down during boot up just before the Windows login screen, I've decided that I can no longer trust this PC... also given that its about 7 yrs old. Fortunately, my mother has agreed to foot the bill for it. I've gotten to the point of contacting the store I want with a list of the components I want to include and inquiring about on-site assembly, but they haven't gotten back to me yet.
The last time I did a core upgrade, I bought an AMD Phenom-II X2 560, an ATI Radeon HD 5770 1GB, 4GB of system ram (DDR3 I think), a Gigabyte 790XT motherboard, and new power supply. I also replaced my OS with Windows 7 Pro-64-bit.
This time I'm looking to replace my entire tower. Here's what I'm looking at:
-New tower with hopefully 3 ventilation fans and front USB and media ports, and space for 2 5.25" bays
-New power supply capable of supporting all components.
-AMD Ryzen 5 2600 + Fan
-16GB DDR4-3000 (2X 8GB) for system ram
-An MSI, Gigabyte or ASUS motherboard with a B350 or X370 chipset in ATX form factor
-ATI-based video card. I was hoping for an RX560-4GB, but they're hard to find, so I may have to bump up to either an RX570 or RX580 with 8GB
-WDC 4TB 7200 rpm hard drive. Oddly enough, I may end up going for an Enterprise class Gold series, due to the fact that they are both available and reasonably affordable.
It seems though, that you can't get a motherboard with an AM4 socket that doesn't have on-board video. They do have the appropriate PCI-E slots for video card installation, so there muse be a way to disable the on-board video. Also, it seems that Parallel ATA is not longer supported, so I may have to drop the idea of retaining my DVD-RW drive, and just keep my Blu-Ray Burner drive as my only optical. Fortunately, it seems that I'll be able to get away with using the same OS, just reinstalling. Its still supported and drivers are still being released for it.
Anyway, since I have this week off as part of my 2-weeks of vacation, I should have ample time to get things set up and be back on my feet by the time I have to go back to... (shudders) WORK.
Wish me luck!
-
I'm pretty sure that the AM4 motherboards do not include an integrated GPU since that is included in the CPU. As far as I can tell, the CPU you mentioned does not have a GPU but even if it did you could still use a dedicated GPU.
FYI, the newer Ryzen CPUs require a BIOS upgrade to work with the old chipsets (B350 or X370) so it's probably a good idea to use a newer motherboard if possible (and affordable). Otherwise you will need an old Ryzen CPU to update the BIOS.
-
Well, I've already got the system assembled... that is, a computer store has assembled my desired components together and it is ready for me to pick up tomorrow. I will bring that up to them, (as I have selected a Gigabyte B350-based motherboard) and if it comes to it, I can download the update on a thumbdrive from my current computer and pop it in as I'm bringing the new PC online.
Thanks.
-
Your PC won't even POST without the update if you have a 2nd gen Ryzen with a gen-1 board. You'll need the shop to put in a gen 1 ryzen, install the update, and then put in your R5 2600. The thumbdrive solution won't work because you'll never even get to the UEFI BIOS without the update.
If you don't do this you'll end up with a very expensive brick.
-
Fortunately for me, the guys at the computer store installed the bios update for me, and I'm up and running. I did make a few changes though, it was communicated to me that the Enterprise class hard drive is both a power hog and not very quiet. Also I had to bus to one of their other outlets to get the video card, which is an RX570-8GB. While I was there however, I asked if they had the non-Gold series WDC hard drive in the same size and performance class, and they did... for the same price, so I picked it up there.
The system is not without it's faults however. Since I'm using Windows 7-64bit, there were problems initially installing the critical support drivers. I need to install the motherboard's chipset drivers in order to access the USB ports, which meant no usb mouse or keyboard functionality. By some fluke, I still had an old PS2-port keyboard kicking around, and was able to get partial functionality from that, using keyboard commands instead of mouse clicks. Unfortunately, the interface for the motherboard drivers didn't accept keyboard commands, and I couldn't seem to find the proper exe on the driver disk to install manually. I did however, manage to install the drivers for the on-board lan port, and get on the internet. However, Gigabyte's website again only had partial functionality with keyboard commands, and I couldn't select the file I wanted. I was almost pulling my hair out with how pathetic the situation was. Fortunately, (and again, by fluke) I had downloaded all of the drivers for the motherboard the night before on my old system, and the drive I stored them on was compatible with my new system, so I popped out the old drive and slipped it in, selected the file and ran it, and then literally shouted for joy when I saw it detecting the dongle for my Wireless keyboard. The mouse came soon after. Not all USB ports are working however... either that of the higher-end USB ports only detect very new items. This has led to my legacy ports getting a bit crowded.
The next problem again comes down to Windows 7... Microsoft can't force me to upgrade to 10, so they decided to neuter the PC of anyone who won't. Now, I already knew that Windows 7 wouldn't be able to take advantage of much of my new system's power, but I didn't expect that Microsoft would hold software updates for ransom until I either downgrade my processor or upgrade my Windows. I also couldn't download my previous email program, which was part of Windows Essentials, which is no longer available.
That said, Freespace just FLIES on this thing. Missions with complex models, which would take over a minute to load and turn into a slide show with too many models on the screen, now loads in a few seconds and gameplay is as smooth as silk.
So far so good on the graphical front.
-
You can still install updates by using an inofficial patch like this one: https://github.com/zeffy/wufuc
-
Thanks! I'll give it a whirl.
[Edit]Worked! Thanks Again![/Edit]