If I were to guess, it's due to the alpha channel on these ones. But textures used for dynamic water will crash the tool when trying to export their texture files. Here are some examples:

ap.map

ps.map

... just as a few examples.

With the .maps I've tested so far, they've been importing into Maya by-and-large without issue (including retaining vertex color information). However, for ap34.map, I receive the following warning in Maya and the geometry imports as a single mesh with no vertex color information intact:

# Error: RuntimeError: file C:/Users/John/Documents/maya/2022/scripts\ObjVColorMaya.py line 216: Can't read vColor! # 

Through some additional tests, this is only happening when I import the Opaque Mesh master group from the tool. If I import any of the Transparent or Decal master groups then it imports correctly, with vertex color information and separate groupings intact.

I'm not sure what's causing the import error for this particular map, but it might very well be an issue with other maps I haven't come across yet.

For that RuntimeError mentioned above, here is the portion of code relating to it:

    def vColorApply(self, objName, vColor):
        mSel = om2.MSelectionList()
        mSel.add(objName)

        mDag = mSel.getDagPath(0)
        mfnMesh = om2.MFnMesh(mDag)
        vtxCount = mfnMesh.numVertices

        if len(vColor) == vtxCount:
            mfnMesh.setVertexColors(vColor, range(vtxCount))
        else:
            mc.error("Can't read vColor!")
            return
        mc.polyOptions(mDag, cs=1)

And attached is the Python script in its entirety.
ObjVColorMaya.zip

Hello, I'm having a problem when trying to open files that are larger than 30mb. I changed the textures of a file that exceeded 30mb, and now whenever I try to open it, the program crashes. The file works normally in the game. If you want, I can send you this file so you can test it. Thanks.

From your discussion over at Discord:

The behaviour of “Import OBJ” has now changed due to the grouping feature. The import currently does NOT look at which mesh category is highlighted in the tool. The reason you saw the OBJ model import into the category you had selected, was because the importer detected the annotations in the OBJ file specifying that exact group in the map.

Right now, the OBJ exporter and importer always identify and utilize grouping information. So, for example, if you export Geometry #3, Mesh #2, then that #3 and #2 will be engraved into the OBJ file (in the obj group names…) and when you re-import that OBJ file (or an edited re-exported version of the OBJ file from Blender or Maya with lightly touched obj group names) it will see “Geometry #3, Mesh #2” and intentionally re-insert that part of the model into geometry #3 mesh #2.

Before I realized this, when I was previously re-importing geometry with the same group naming convention, what would typically happen is the tool would simply duplicate the geometry within that master group. Basically there'd be two, exact instances of the same geometry, then.

However, I did find that with cb12.map, for example, if you export the geometry and re-import it the tool will crash to desktop, instead of "duplicating" the geometry within that same master group as mentioned prior.

Interestingly, at least with cb12.map, this crash only happens when trying to re-import an Opaque Mesh master group. It doesn't crash with Transparent or Decal. With Transparent and Decal, the tool imports them as "duplicated", as mentioned prior.

Seemingly being an issue with Opaque only, I wonder if there's any similarities with this? #8

Now, I can simply be mindful to try and not import like this, but I felt it's worth bringing to your attention, specially due to it sometimes crashing to desktop. I suppose a question to ask about this is: Would checks or fail safes be desired to help with such a predicament?

I encountered a problem when opening ph2ed_proto.exe. The file does not open after double-clicking. Or should it be launched in some other way?

I'm not a programmer, so I'm speaking out of my ass with that title. To replicate: Open various cc*.map files. After opening X amount, when you then try to open cc04.map, the tool will crash.

The tool can open cc04.map, but it seems to crash if you open X amount of other .maps prior to it. This might also affect opening other .maps, I'm unsure at this time.

You can change the ID of a texture to be the same as another texture's ID within the tool. When this happens, glitchy UI behavior happens where one of the textures can no longer be edited/adjusted by the tool.

Suggest adding a check to ensure whatever the texture ID is changed to isn't already assigned to another texture and warn the user of such.

Hi Phillip,

Thank you for everything you're doing. If you don't mind, I'd like to list some wishlist features for the tool. If any of the things below are not feasible or you just don't want to bother, feel free to tell me to hush. Really, the most important things in the list below are the import/export functions.

Display Modes

Have a feature in imgui to toggle between:

• #2
• #3

Have checkboxes for the following, which can be enabled in any combination with each other to work alongside the display modes mentioned above:

• #4
• #5

I'm ignorant to what type of workflow would be involved here, so apologies if this is outlandish to ask about.

File Directory/Changer

I know the tool is still in its early prototype stage, and you may have had something like this already planned, but perhaps have the ability to select a folder for the tool to search its directory for any cld/map files and then have a way to cycle between found cld/map files?

This isn't critical to have, but would be a nice convenience feature.

Import/Export Functionality

I'd like to know your thoughts on how best this could be done.

OBJs can hold mesh grouping information, but Maya, Unity, Blender, and 3ds Max may read and save out these groups in different ways. I'm not sure. If they do all read/save mesh groups differently, then it would be a pain to try and make this work across the many 3D editing software out there. You could make it work for one specific piece of 3D software, but that's also limiting for different reasons.

So how could you successfully import/export geometry data via geometry ID through a map file? Here's my idea:

In your tool, you've implemented checkboxes to show/hide mesh IDs. Have it to where only one mesh ID can be checked in order for an export/import button to become clickable. This way, the end user has to specifically choose what mesh group/ID they want to export/import for changes.

There is likely a more elegant way to handle this, and it's safe to say I'm probably overlooking several things here, which is why I wanted to discuss it out loud with you. But that's the initial idea I had. This would prevent worry of importing whole-level edited OBJs back into the tool; the worry here being whether or not the 3D editing software retained correct mesh ID information on OBJ export for your tool to read and understand when importing back in.

I suppose having an "export entire map" feature may also be good? Perhaps it gives a warning that importing OBJs should only be done on a per-mesh ID basis? An Export All feature may also be nice because some people may just want to export the whole map to use elsewhere outside of the game.

Thanks for letting me think out loud here. Looking forward to your thoughts on some of these things; I always enjoy brainstorming!

The "elephant in the room" question: Is it possible to delete a specific mesh group within a master mesh container?

There are times/situations where what I need to delete (in order to remake) is conveniently contained in its own mesh group. If I could delete just that mesh group, then the time and workflow shortens noticeably. As currently, what I must do is export the entire master mesh container, delete the offending mesh group, then re-import all mesh groups back in, reconstructing their vertex format and re-assigning their material numbers in the process.

Now, it's certainly not the end of the world for me to have to do this as I currently am, but I figured I'd ask. 🤞

Hi Phillip,

I plan to make individual tickets for things unless you'd prefer I do one ticket with a list like before. Let me know and I'll accommodate moving forward, thank you.

In the tool, there's a "(?)" at the end of "Material" within the texture window. Is the "(?)" meant to be a tooltip similar to other parts that have a "?" you have hover your mouse over?

If the question mark is there because we don't know its purpose, then please disregard and close this ticket.

Thank you

Hi Phillip,

Please forgive me, but the anticipation proved too much and I wanted try out the tool and get my toes wet. To start: This... Is... Amazing!! I feel like a kid in a candy shop playing with this. I've had either a smile or grin on my face the past few hours using your tool. This is wonderful and it still feels like a dream to me. 😭

As I was playing around with it, I came across a few quirks I'd like to report your way, if that's okay.

Exporting

When exporting geometry or individual, specific textures, you must type in ".obj" or ".dds" as part of the filename, otherwise it'll save without the extension. This also makes the material file for the OBJ saved out as "*.obj.mtl" when you have to manually type in the extension for the OBJ filename.

Textures are not exporting correctly. Files are being created, but there's no data in them.

When exporting geometry, if you choose to flip it on the axis, it'll incorrectly reverse the normals as part of the export.

Export as-is (backface culling enabled)

Export with flipped axis (backface culling enabled)

I'm experimenting with another plug-in for Maya to import the OBJ and it kept freezing the software on import. Through experimentation I've found it's due to this line that's at the end of the .mtl file when exported through the tool:

  map_d -imfchan m E:\Silent Hill\PC SH2 Enhanced Edition WORK\Game File Adjustments\MAP Edits\scenes\bg\th\test3.tex_6116.dds

When searching for the map_d line, it looks like it might be a Blender-specific line for OBJs? Is it imperative to keep this line for export or would it be okay to have it removed?

I've found out why Maya wasn't importing materials upon OBJ import... and it's a remarkably dumb reason: The filepaths need to be relative. For example, this won't work for the OBJ:

mtllib E:\Silent Hill\PC SH2 Enhanced Edition WORK\Game File Adjustments\MAP Edits\scenes\bg\th\teeesssttt.mtl

...but this will:

mtllib teeesssttt.mtl

Same with the .mtl file. From this:

  map_Kd E:\Silent Hill\PC SH2 Enhanced Edition WORK\Game File Adjustments\MAP Edits\scenes\bg\th\teeesssttt.tex_6118.dds

...to this:

  map_Kd teeesssttt.tex_6118.dds

So can either the filepaths within the .obj and .mtl be made relative to each other, or could you make this a checkable option upon export?

That's all I found so far! If anything else comes up I'll leave it as a comment on this ticket.

I'm absolutely in love with this tool, Phillip. 😍 😍 😍

You know how the tool looks for the non-numbered .map to pull in additional texture files for any given map? A similar scenario happens with ru74. ru74 pulls its textures from ru73. I'm not sure if you can make a special exception to have ru74 look for ru73 in the same directory to grab and display its texture from it, similar to what you've done for use with the non-number .map files?

The reason for this is because it's the boss room and is special/different from mostly all the other interior rooms. This room actually "stitches" ru73 and ru74 together, similarly to how the outdoor town .maps are done... except all the textures used are stored in ru73 for some odd reasons. 😵

You'll see a new crash report from me from about 30-60 minutes ago. The reason the tool crashed to desktop is because of their group names. I was importing decals meshes back into the tool and I think their group names conflicted with existing group names already used in the tool (for opaque meshes).

This likely happened because I was exporting things separately, such as exporting only the opaque meshes first, then decal meshes, etc. I'm thinking that, since I was exporting things separately, they shared the same numerical ordering as the tool was unaware of me exporting separately, if that makes sense. So when it came time to re-import, group numberings conflicted as a result.

Anyway, I renamed all the decal group names to something random before exporting out of Maya and that prevented the crash in the tool and allowed the geometry to import without issues.

All this to say: As a safety/backup type of thing, can there be a checkbox on import to either allow/disallow merging mesh groups based upon their group names within the tool?

When you're getting down-and-dirty with meshes, there can be a lot of things opened. May I suggest adding an "Open All" and "Close All" button for this window?

Whenever you close/relaunch the tool, the BG color you set will reset. Likewise, when loading a new .map file, the BG color will also reset.

May I request a feature to save the BG color to the INI and have the tool launch with the last BG color used and also retain this color on various loaded .map files while using the tool?

And perhaps include a "Reset BG" button around it that'll change it back to the dark grey you have it auto-set to?

Currently, when you import an OBJ model, it moves the camera upon import. I believe it's moving and centering the camera to the new geometry that was imported, but I'm unsure.

May I ask if the camera can stay where it's at upon OBJ import? As currently, it can be a little disorienting to re-find your position once the camera jumps on its own.