Black textures on nearly everything - Help!

JCitron

Trainzing since 12-2003
I've had a bit of bugger problem lately. Trainz crashed last week with a BSOD. I ran a database repair and in the middle it did the same thing. I figured it was something that got corrupted that caused it because the error message that Windows produced didn't elude to any hardware problems, although I did run system diagnostics, such as MemTest86, chkdsk, and motherboard diagnostics. These all came up clean. I even went as far as reinstalling the program.

Eventually, after reinstalling, patching, and reimporting content, I now have black textures on most objects and quite a few textures. I've run quite a few database repairs, which didn't bring up anything except for a few false warnings, which I cleared by opening and closing the content and viewing the error messages a few times.

The last thing I did was reinstall video drivers. At first I went to the latest NVidia drivers - 260.99, which didn't help, then reverted back to 258.96, which didn't do it either. I've also tried all different graphics settings for the drivers, figuring something got messed up as well as DirectX versus Open/GL in Trainz, turned off texture compression, and even reinstalled DirectX, thinking that was a problem.

Anyway, I'm at a loss now as to what the problem is. This must be some stupid thing I've missed that's causing this problem. I haven't had much luck with any web forums regarding graphics problems like this.

System Specs:

EVGA Classified 3-way P55 Motherboard
Intel i7 870 - Lynnfield @3.00 Ghz
8 Gig Corsair RAM
2 x 1TB Hard Drives, 1 x 2 TB Hard drive where Trainz lives
EVGA GTX 470
SB Xtreme Sound

All have the latest drivers except for video which I downgraded earlier today from the latest.

Any suggestions?

Thanks in advance,

John
 
I believe what you are supposed to do is disable hardware compression. You may have to recommit your assets. Do a search on "hardware compression" to get more info but there's a recent thread here:

http://forums.auran.com/trainz/showthread.php?t=66129&highlight=hardware+compression

Thank you, RRSignal!

I did just that after I posted this, and that answered my question. I should have checked here earlier :cool: hmmm.

That has fixed my problem. I am now recommitting my assets after opening up and testing a few.

Will be Trainzing tomorrow since I can't get into work because of the blizzard! :D

John
 
I've got the same problem.

I have a sneaking feeling the problem was precipitated by either the bad download of AVG profile or the usual MS security updates forced reboot during a night run, but I'm only guessing.

It didn't affect other Trainz instals only my largest which was in the middle of some repairs.

It's affecting locos, rolling stock, buildings and groundtexture, even newly downloaded assets that have no modifications.

As the other instals are OK it would appear that it is not Hardware Acceleration related or GTX 400 series GPUS or the latest nvidia graphics driver.

So it looks as if the Trainz core files are damaged.

Trouble is this is my largest instal with 300GB+ of assets and that takes a full day to do an EDR. Just coming up to 23 hours and still Checking for faulty assets. I'm not holding my breath that the EDR will resolve the problem, and it looks like a rebuild will be necessary. Swinging 300GB of data across is not for the chicken hearted, and you guessed auto database repair will run again and another day will be lost.

The current validation and updating method may be OK for small instals but for larger ones it leaves a lot to be desired. Surely there must be a more efficicient way that takes significantly less time to process.
 
My 87 GB install took all day and then some on my machine, I couldn't imagine 300GB of data!

I should say that my reinstall plus re-import of my assets, then the database repairs actually took me 5 days because I went to work in between and ran the repairs at night so I didn't have a chance to do anything during the day. I had Friday off because of the holiday and was hoping everything would be done. This was when I ended up where I am because I got stumped with the black textures.

I think it was a MS update too that caused this because I didn't have any problems up until now, including black textures even with the 400-series card.

Since the disabling of the compression and resaving the assets seems to work, I'm doing this band-aide until something better comes along.

I agree there's got to be some better way of doing this than doing the very slow database repair. Too bad there wasn't some kind of command line database refresh. I would think that a database compression might be good to when something is deleted or updated. This could speed up the process because there would be fewer entries to go through in the database scan and repair.

John
 
I've got the same problem.

I have a sneaking feeling the problem was precipitated by either the bad download of AVG profile or the usual MS security updates forced reboot during a night run, but I'm only guessing.

It didn't affect other Trainz instals only my largest which was in the middle of some repairs.

It's affecting locos, rolling stock, buildings and groundtexture, even newly downloaded assets that have no modifications.

As the other instals are OK it would appear that it is not Hardware Acceleration related or GTX 400 series GPUS or the latest nvidia graphics driver.

So it looks as if the Trainz core files are damaged.

Trouble is this is my largest instal with 300GB+ of assets and that takes a full day to do an EDR. Just coming up to 23 hours and still Checking for faulty assets. I'm not holding my breath that the EDR will resolve the problem, and it looks like a rebuild will be necessary. Swinging 300GB of data across is not for the chicken hearted, and you guessed auto database repair will run again and another day will be lost.

The current validation and updating method may be OK for small instals but for larger ones it leaves a lot to be desired. Surely there must be a more efficicient way that takes significantly less time to process.

Does look like an added problem in your case.

The hardware compression problem should only affect new assets added after upgrading the card or installing, if it was there to start with, it does not affect older versions of Trainz as they don't use hardware compression.
and it wont affect other installs of 2009 or 10 unless you add or download a new asset, existing items are not affected unless opened for edit and committed.

Time taken for the EDR? 47 GB here now, last one took about 40 minutes, which was about a third of the time it took on my previous setup. I presume that the EDR is using whatever multiple cores are available?

Possibly disabling AV, Indexing and Windows search on the drive where Trainz is would speed things up slightly, however if you disable indexing, it will take quite a while for Windows to change the file attributes on all the files. This is best done on a freshly installed OS before any additional programs are added which is what I did first before I built the PC.
 
Last edited:
Some of the black texture issues are due to kind 'Groundtexture' experiments I have been conducting.

In these I am updating tag trainz-build to 3.3 from legacy value to determine all errors and warnings at that level..

I have found that nearly all legacy ground textures can be made to work but not in accordance with the CCGTC or Wiki.

In the legacy situation tag 'asset-filename' is used for many things but at TB 2.9 and higher this tag red flags as obsolete and has to be removed.

However here it has to be replaced by tag 'texture'.

Setting it in accordance with CCGTC/Wiki it should have a value of *.texture with .texture.txt and .tga files.

In CM this gets rid of errors and warnings but it is a different kettle of fish in surveyor and driver.

In Surveyor:

No tag - Surveyor crashes
.texture - black textures when painting
.tga - damn good correct textures when painting.

I think this situation applies to kind 'texture' and texture-group' too.

But does not explain the locos,rolling stock and scenery,buildings,trees being black.

Hardware accel is unticked and OFE/Commit has reset compression to TS2010 requirements in the past, and has previously cured this problem after I upgraded to GTX460 GPUs.

I can only surmise that my database is out of whack due to a large number of changes being made and/or interruption caused by forced re-boot by MS security update last week during an auto database repair.

The EDR is still running with another 15 hours elapsed. The 'please wait message is useless in that the progress bar has not budged in a day and a half. If it wasn't for running WTM Resource Monitor where it can be seen that Transutil.exe has four instances hammering away at the local folder, an uninformed user could be forgiven for premature termination of EDR and then reporting CM/TADDAEMON/TS2010/patch etc don't work or TADDAEMON is running continuously when first launch Trainz.

If you display details in 'please wait' message you can see that TAD update and validation is running and from the messages I see it is reporting them correctly.

I shall be patient and let it complete.

BUT there's got to be a more user friendly way of doing the database repair and validation. As the database grows this problem exacerbates.

It seems to me that this could be partially alleviated by giving the User the choice whether auto updates should run just as we had in TRS2006.

One dangerous situation that occurs during a database repair is that the backing up of asset.tdx is suspended. See TADDAEMON log during EDR. This would not be of great significance in a small database as EDR would be completed relatively quickly. But when it takes a day or two to do an EDR I get anxious. Once again in TRS2006 and TC days we had Steve Forget's TADMON which heartbeated every step of the way. Asset.bku was always up to date and several backups available. TADDAEMON seems to not have advanced to that stage yet.

Edit - I shouldn't tempt fate. We've just had an hour's power cut after 170kph wind gusts. EDR was at 30 hours and counting.
You guessed it Auto-Database Update starts all over again.
 
Last edited:
Back
Top