Bug #19079
All parts z-fighting when other vessels load into range
10%
Description
Whenever you are trying to rendezvous with other craft in orbit or on the surface, as soon as any other craft loads into range (~2.2km) there is a lot of z-fighting among all parts of the craft, even with parts that never have before. Even command pod textures z-fight with the flag painted on the side.
This effect goes away during a scene switch. For example going to the Tracking Station and then back to the craft. But when other craft come into load range, it happens again.
History
#1
Updated by jclovis3 over 6 years ago
Updated by - Status changed from New to Need More Info
Would you be able to provide a copy of the vessels (craft files) you use and perhaps upload a video. I tried to reproduce and see no differences created by approaching a vessel. I started from about 3.5 km and watched as I approached. Then I reset back to launch pad to compare what I noticed with what the vessel displayed before I came within range.
The only Z-fighting I see are when some parts are close together, like the large batteries, and the folded ends of a large thermal control system.
Watch: https://youtu.be/2pmSxHPFKsI
Along with the craft and video, a description of your graphics settings (including anti-aliasing) or a copy of your settings.cfg file may help too.
#2
Updated by raptor9_ksp over 6 years ago
Updated by - File settings.cfg settings.cfg added
I've never tried it around the KSC, but I've noticed it on both the Mun and Duna, whenever I land multiple landers at the same site. It happens with any craft I've made. To be clear, I first noticed this in 1.4.1, but hadn't seen a lot of it until now because I hadn't started repeatedly putting a lot of craft in one area until recently. This happened when anti-aliasing was disabled, or on 2x, or 4x.
I made a short GIF of the effect here (with anti-aliasing off): http://i1356.photobucket.com/albums/q737/raptor_9000/GIFs/1.4.3%20z-fighting_zpsohcwpndw.gif
With the two landers, you can see z-fighting around parts and textures that normally shouldn't have any issues. Note that even though the grey "Rockomax Brand Adapter 02"s are not offset into the X200-32 tanks at all, they are z-fighting as if they are. Even Flags, or OX-STAT solar panels surface placed z-fight with their parent part even though they are not embedded in the collision mesh of them. Shadows shimmer as well, almost as if the collision meshes themselves are unstable.
#3
Updated by jclovis3 over 6 years ago
OK, here are some key differences between your graphic settings and mine.
Setting; Yours; Mine
Anti-Aliasing; 4x; 8x
Pixel light count; 30; 64
Frame limit; 120; 180
At 2x AA, I can see more disturbances in seems and edges but nothing like what you show. With AA turned off, I don't see quite so many disturbances as I do with 2x, so your graphic card capabilities might have part to do with it. I'm not seeing any heavy Z-fighting in either case. In your GIF, there is a shadow shake, which makes me wonder about the lighting calculations for your system. Are you running any mods to improve the scenery?
So just to run a test like your situation, I put two very massive ships on the moons surface. The video here shows me landing the second one starting just outside the 2.2 km range. I brought my graphic settings down to match yours, but I have a suspicion that your particular graphics card may be having problems. You can also try updating your drivers, including DirectX. To help the team with your hardware specifics, they'll need a copy of your KSP.log file as most of the data they need will be at the top of that. You'll have to close KSP first for this file to be closed out for access. I recommend keeping this file short so just have a quick save ready, restart KSP, open up your quick save to show the problem, then press Alt-F4 for a quick shut down and use the log file created from that. It will minimize the data they have to sift through.
Watch: https://youtu.be/itnS0Pk6e7c
The fuzzy video quality is because I had my capture set on low (about 14 Mbps). Either way, you still see pretty much what I saw in game.
#4
Updated by raptor9_ksp over 6 years ago
I did have SVE and Scatterer installed when I made that GIF, but I had already tried it in a vanilla install when I tested with the anti-aliasing off. I'll try updating my video drivers and matching your settings, see what happens there.
#5
Updated by diomedea over 6 years ago
Updated by While it is fine if different users compare their findings about this issue, please know it has first to be reproduced/analyzed to then be fixed. Beyond settings.cfg, please provide:
- .craft files (for vessels showing z-fighting parts);
- savegame with instructions about the next steps to achieve reproduction;
- output_log.txt file.
#6
Updated by raptor9_ksp over 6 years ago
- File EV-2C _Runabout_-Titan 3P (LV-2A).craft EV-2C _Runabout_-Titan 3P (LV-2A).craft added
- File KSP (z-fighting test output log).log KSP (z-fighting test output log).log added
- File persistent (z-fighting test).loadmeta persistent (z-fighting test).loadmeta added
- File persistent (z-fighting test).sfs persistent (z-fighting test).sfs added
- File settings (z-fighting test).cfg settings (z-fighting test).cfg added
Persistent/meta files provided, along with the settings and KSP output file after a test run. To replicate the test, a lander is in orbit around Minmus with a few landers on the surface already. Make an approach and land next to the surface assets. After loading into visual range (~2.2 km) z-fighting will start and get progressively worse as you get closer.
As I mentioned earlier, this happens with any and all craft files I've ever rendezvoused on the surface with each other. But as an example, I've included the craft file of the primary lander used in the test.
The most prevalent Z-fighting seems to occur with surface textures like flags, solar panels, and shadows. Again, here's a GIF showing an example after landing a couple other craft near each other on the Mun: http://i1356.photobucket.com/albums/q737/raptor_9000/GIFs/1.4.3%20z-fighting_zpsohcwpndw.gif
#7
Updated by diomedea over 6 years ago
- Status changed from Need More Info to Confirmed
- Severity changed from Low to Normal
- % Done changed from 0 to 10
Many thanks for those files. I could reproduce the z-fighting with your savegame and settings when just within the 2.2 Km distance. Your output_log also shows nothing unusual (at least to me). Craft file was needed to verify if parts had placement issues (it is often a cause for z-fighting), but found none. Therefore bug confirmed, is being proposed to the attention of developers for a fix (please be patient, there's plenty work already and this may require time).
#9
Updated by raptor9_ksp over 6 years ago
No worries. Only so many hours in the day, and priorities.
#10
Updated by jclovis3 over 6 years ago
In the output log, I noticed a lot of warnings that look similar to these:
[WRN 10:53:28.240] [Part]: PartModule ModuleColliderHelper at linearRcs, index 1: index exceeds module count as defined in cfg.
Looking for ModuleColliderHelper in other indices...
[WRN 10:53:28.240] ...no ModuleColliderHelper module found on part definition. Skipping...
[WRN 10:53:28.240] PartModule is null.
When I loaded your save game, I had them too, but with one of my own, no use of the word ModuleColliderHelper ever shows up in the log.
This error might suggest that HeatNaimatioEmissiveLiquidEngine3 was misspelled, leaving out the 'n' on 'Animation':
[LOG 10:54:59.991] FXModuleAnimateThrottle: Could not find animation HeatAnimatioEmissiveLiquidEngine3 in part's animation components. Check the animationName and model file
You said that the problem is resolved when you switch the the tracking station and return, but that didn't occur in this log so it's hard to see what changes upon loading the second time. There are a lot of references to struts being attached to the same rigid body at both ends in the grasshopper and Meerkat crafts. I'm not sure why that is unless it has to do with autostrut from the root part to the root part.
I'm not seeing a great deal of z-fighting but I did note you have some parts that overlap with surfaces close to one another. The little bit of flickering I did see was either on a flag or on some parts when observed from a few camera angles only but not everywhere. The flag was more noticeable when I zoomed away from it a bit. It seems distant parts don't warrant as much attention to detail.
Watch: https://youtu.be/Iju4hWpCJHQ
Hope these comparisons and observations help.
#11
Updated by Anonymous almost 6 years ago
Still present in version 1.6.0 (with an AMD Radeon R7 M360 (2039MB)).
The shimmering effect seemed (to me) to have gotten much better during 1.5.x, as I no longer see it when aircraft fly over my runway-end flags, so I thought to check here if it was reported fixed.
Loading the persistent(z-fighting test).sfs into a fresh 1.6.0 shows the bug as described. Quicksave/quickload resolves the problem.
#12
Updated by Yakuzi almost 6 years ago
Updated by 
- Language deleted (
English (US))
Still present in KSP 1.6.1.2401(Windows x64) using an NVidia Geforce GTX 960M.
#13
Updated by Yakuzi over 5 years ago
Still present in KSP 1.7.0.2483(Windows x64) using an NVidia Geforce GTX 960M.
#14
Updated by raptor9_ksp almost 4 years ago
This bug report can be closed/marked as resolved.