Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: fightermedic on September 03, 2016, 10:40:57 am
-
Oddgrims Anuket is completely finished, and PBR textured:
(http://i1293.photobucket.com/albums/b590/lolaldanee/Untitled_zpssgoeyw51.png~original)
(http://i1293.photobucket.com/albums/b590/lolaldanee/screen0004_zpswi4haz0k.png)
download:
http://www.mediafire.com/download/ch6ohvl39gzzdfl/anuket+1.1.zip
-
Well that was quick! , nicely done. c:
Hurm, I'm noticing quite a bit of artifacting on the textures when viewed in the lab. And looking at the dds. file I can see a lot of mashed pixels due to the compression.
Just to double check sure you included the right files in the release folder?
edit2:
yeah this looks like something mucked up the dds. conversion. :sadface
(http://i.imgur.com/lVWevaT.jpg)
-
Absolutely magnificent.
-
ah, oddgrim, are you talking about all those black spots? i can not see any compression artifacts out of the ordinary otherwise
just in case: those black spots are not errors, those are the parts of the ship where the metal comes through the painting
metal has a completely black diffuse in the PBR pipeline
you have a recent nightly build with PBR enabled, yes?
edit: i just double checked, in my lab everthing looks as it should be, i would say this ship is pleasingly artifact free, the apollo textures i recently did had some, but this one seems very good in that regard :confused:
-
Tried again with the lastest nightly build, same black spots. Looked at the other models as well to see if PBR was enabled, which worked without issue. Curious. :?
-
Hm, go to the material overide in the lab, and turn on the gloss override, and pull it all the way to 0, if the black spots turn more white/grey everything is fine
in a mission with very a colorfull skybox, those spots would not be black, they just receive very low ambient lighting, because they are really glossy
realistically metal parts on spaceships would appear almost completely black on the side not facing the sun, as far as i know
-
Well I tried but did not see any change whatsoever, even with post processing turned off. :c
-
just in case: those black spots are not errors, those are the parts of the ship where the metal comes through the painting
metal has a completely black diffuse in the PBR pipleine
No, this is so wrong it's painful. Metals should NEVER be (0,0,0), the diffuse value should be between (5,5,5) and (30,30,30) for 99% of all metals. This is the proper range based on PBR Scan Data.
-
@oddgrim
just for reference, this is how it looks in my lab:
(http://i1293.photobucket.com/albums/b590/lolaldanee/screen0007_zps8aznu7qi.png~original)
seems fine to me
-
I can't speak to textures, but the anuket-shp.tbm is wrong.
Firstly, you use the name "PVG Anuket" (this isn't an FS1-era ship, it should be "GVG Anuket"). Secondly, you don't provide enough data for a complete ship entry but don't have "+nocreate" (this, combined with the previous point, means it creates a new "PVG Anuket" entry as a Terran ship, and trying to actually select it in the F3 lab will crash FSO because it doesn't have a defined model file). Thirdly, you redefine all of the turrets when all you apparently wanted to do was include some extra information for the first turret, simply because you didn't want to name the turrets in the POF consistently with the retail model. This is, to say the least, a bad idea.
("But if I don't name them like 'turret01a', then it won't treat 'turret01b' as a lower-detail version of that submodel!" you might say. If you aren't saying that because you know what I'm about to say, then feel free to ignore this. Name the subsystem 'turret01', and then add "$lod0_name=turret01a" to the properties. This allows the model to remain compatible with the retail table entry while still having more than one LOD for those submodels.)
I've uploaded a fixed model and TBM here (http://deviance.duckish.net/downloads/anuket-fix.7z).
-
hm,
the part with $lod0 is actually news to me, the rust just a stupid oversight
-
i've updated the download with the changes mentioned by admiralralwood, and also with a new normal map, the old one had inverted Y values, aparently the software awesombump spits them out the wrong way by default
-
I think that archive might be corrupt. When I try to extract the files from it, I get "unspecified error" copy failures for the .dds files, which is something I've never seen before. Anyone else running into this or do I just need to redownload?
[Edit] Redownload, same deal - even with the space and extra period taken out of the filename. Looks like something got messed up when packing the files.
-
Did you use 7zip?
-
Apparently programs other than 7zip have problems uncompressing these files, even though it's ordenary .zip format, i have no idea why :/
-
Ah, that explains it. Was it packed with 7zip? Maybe something special about the compression method threw Windows' default archive reader for a loop. Decompressed fine with 7zip though. Thanks!