Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Blue Creek Apt. Room 105 - Some geometry's normals reversed/non-conformed? #6
@Bigmanjapan if you're up to the task I'd like to keep giving you some challenges. There seems to be no stopping your momentum at this point!
In Room 105 of Blue Creek Apt. there seems to be, for all intents and purposes, normals reversed/non-conformed on a few pieces of geometry (the door to the coin puzzle furniture and the carpet off to the side):
Edit: Another video example of normals adjustments: https://youtu.be/G-K7WT9IIok?t=12m15s
This seems to only be an issue for the PC build (PC vs PS2 example):
I have no clue if this can possibly be resolved through hex editing but if anyone can determine this it is you. Also, I'm not 100% sure this is due to reversed geometry normals or something totally different... it just happens to look like reversed normals is all.
Here's a video confirming it's an issue with the polygon's normals:
However, it was not as I suspected: The normals are facing the correct direction but they are not conformed to an appropriate angle. If I set the normals to "Set to Face" in Maya the issue is fixed.
I am fairly certain this cannot be fixed on our end so I'll close this ticket in the near future; I'll leave it up a little longer in case anyone can think of a clever solution.
It doesn't import into Maya without opening it in another program and re-saving it. If you try to open it in Maya as-is you'll get the error message "Index Out of range for face creation." There are ways to fix this but it requires a lot of time and trial and error.
I opened the file in Photoshop (Photoshop can open 3D files!) and exported to Collada 3D (.dae). Then I was able to import the file in Maya.
In the past, I also had my friend open the OBJs in Rhino 3D and export for me as well.
I use Maya simply because that was the software I was trained/educated to use.
I nulled almost all of ap76.map and shading on carpet and cabinet is still preset:
There are still very small chunks of data that control those texture leftovers which I will inspect more.
I tried importing ap76.obj file alone (without .tga and ap76.mtl files) in Photoshop CS3 and it rendered the model without any shading.
If you open ap76.mtl in hex editor, you'll see strings of information like this:
http://paulbourke.net/dataformats/mtl/ discribes this format thoroughly.
The issue is that .obj / .tga / .mtl files are compressed (?) when they are stored in a single .map file and data between them is not in 1:1 format — there is no understanding what to hex edit in .map file yet.
Another issue is that (as far as I understand) visuals we actaully see in the game window are stored in VRAM and memory scanners like Cheat Engine can't access VRAM which leads to time consuming issue of always reloading a savefile to see any changes made to .map files. When changing stuff in .cam / .kg2 / .cld files via CE you can see changes right away on the screen.
It is possible to edit .map files on the fly in PCSX2 since the emulator allocates VRAM as a common RAM but, as we know, .map files are different between the platforms so it has no practical use.
Holy shit that's impressive what you've done so far.
Yeah, it seems to be that the vertex normal information is "baked in" to the geometry itself which is typical and standard for such things.
This will be the roadblock then. OBJs have their vertex normal information as
Although it does seem like, with 3D Model Researcher, it can guide you to the right hex regions for the models? I'll be honest: I watched some of the video examples for this software and it's all confusing to me... And, of course, there's also no guarantee it could even open a .map file to begin with.
I bolded the relevant part as this is what I did in Maya to fix the issue: I simply set the vertex normals to conform to the face.
I see, thanks for the info. That will take some time to research.
John_Modest's "Silent Hill Texture Explorer 2.1" program can import .tga files back into .map files, so it should be possible to do the same with .obj files. Judging from his program, tga files are compressed via DXT1 or DXT2 formats, so that's something.
referenced this issue
Nov 7, 2018
I wanted to share some good and exciting news with you all. I've been in contact with Stan @sbobovyc Bobovych, a multifaceted programmer/engineer, over the past month or so, and he has cracked open the secrets to the game's 3D data within the .map files.
This isn't his first time reverse engineering a game file as seen in one of his earlier blog posts here (and it was this same post that initially led me to him). With his expertise and knowledge in such work he graciously accepted my request to look into and solve the bad normals for this room.
To you programmers here, I'm sure this would be an interesting and fascinating read. And while we've been stumped with cracking this riddle since the beginning, if, after reading his post, any revelations come to you with how to see the solution through, please do chime in!
To any fans currently reading this: If you'd like to send Stan a "thank you" tip for his time and skills put towards this fix, please consider sending him a donation here. He's doing this on his spare/free time having never played the game before, so this is a pretty big deal for him to share his talents helping our fanbase out.
And to Stan: Thank you so much again for all that you are doing!
@FrozenFish24 that's the ticket! Everything looks fantastic! Thank you!
This is also great because now I can package up all the recent, new fix files and release them as v1.0.3 of the Enhanced Edition Essential Files for others to grab and enjoy.
I'll start work on making an update video covering all this as well. Thank you again!
Love your modesty. :) If you contribute, you're part of the team. Welcome to the team!
If I may ask, how deep/extensive is your background with this type of work? Elisha is working on removing the need for WineD3D for Nvidia cards but he's currently stuck on the last thing to fix: Preventing chunks of the wall from disappearing when the camera is too close to the geometry.
Are you familiar with such issues in games? Any clue on how to approach this fix? This particular task is a milestone for us because, once we remove the need for WineD3D for Nvidia cards, we can unify the installation process for everyone and then start looking in to making a bonafide installer for all the fixes (instead of making people download each fix, one-by-one). That, and WineD3D causes most problems for people when trying to play the game.
Here's Elisha's earlier notes on what he thinks the issue might be:
I've reversed a handful of binary formats here and there, mostly textures and archives. I have very little experience with graphics APIs though. This is the first 3D format I've attempted.
If he's thinking the problem lies in the actual vertex properties within the map files then I might be able to help. I can dump out the vertex buffers from the map files pretty easily and locate specific vertices using Blender. I'll have a look tomorrow.
Thank you kindly! Any research will surely help just the same as what was done here with the vertex normals.
Just a forewarning: There isn't necessarily a particular set of rooms (.map files) that experience this issue on Nvidia cards; it's more like any time, any where, when the camera gets too close to geometry it does this when not using WineD3D with Nvidia.
Another example: When you and Maria are being chased down the tight hospital corridor by Pyramid Head you will see chunks of the walls loading/unloading consistently as you keep running.