Fix reading OBJ meshes from UTF-8 paths on Windows

[Fstarnb]

Description

ReadTriangleMeshFromOBJ used tinyobj::LoadObj(filename, ...), which opens the path with narrow fopen/ifstream. On Windows that breaks when the path contains non-ASCII characters (e.g. Korean), while ASCII PLY paths work because other loaders use utility::filesystem::FOpen / FReadToBuffer (UTF-8 → wide open).

This change:

1. Loads the .obj bytes through FReadToBuffer
2. Parses via tinyobj::LoadObj stream overload
3. Resolves .mtl files with a small MaterialReader that also uses FReadToBuffer + MaterialStreamReader

Related Issue

Fixes #7336

Checklist

• Focused change
• No open competing PR for Bug report: Cannot load .obj file when path contains Korean characters #7336 at publish time

[update-docs]

Thanks for submitting this pull request! The maintainers of this repository would appreciate if you could update the CHANGELOG.md based on your changes.

[ssheorey]

Hi @Fstarnb, thanks for submitting this fix. Have you checked if the latest (main branch) of tinyobjloader fixes this? Its easier to update versions than have special workarounds in Open3D.

Alternately, will adding "/utf-8" to MSVC compile options fix this?

[Fstarnb]

@ssheorey Thanks for the review questions — I checked both options carefully.

1. Does latest tinyobjloader main already fix this?

Yes on main, no on the pin Open3D uses.

Open3D currently vendors tinyobjloader v2.0.0rc8 (3rdparty/tinyobjloader/tinyobjloader.cmake). That release opens paths with a narrow std::ifstream ifs(filename) / equivalent — no MultiByteToWideChar / wide path handling — so UTF-8 paths on Windows fail exactly as in #7336.

On tinyobjloader main (post-rc8), the filename LoadObj path was updated to open via LongPathW(UTF8ToWchar(filename)) (and the same for material file readers). So upstream has fixed the classic filename API.

I did not bump the third-party pin in this PR because:

• There is still no newer tagged release after v2.0.0rc8 (only that tag).
• Main has since grown a large pure-C11 loader and other surface area; pinning an untagged main commit is a wider dependency risk than this one IO path.
• Open3D already has the right primitive for this: utility::filesystem::FOpen / FReadToBuffer (UTF-8 → _wfopen on Windows), which other mesh loaders already use. Routing OBJ/MTL through that keeps path semantics consistent with the rest of Open3D IO even if tinyobj is upgraded later.

If you prefer a dedicated follow-up to bump tinyobjloader once there is a tagged release (or a pinned commit you trust), happy to do that separately. This PR stays a minimal, pin-safe fix for #7336.

2. Would MSVC /utf-8 fix it?

No. /utf-8 only sets the source/execution charset for the compiler (how string literals and source files are decoded). It does not change the CRT/MSVC behavior of narrow fopen / std::ifstream with a runtime path string: on a typical Windows ANSI/ACP code page those still go through the narrow API and break on characters outside that code page (e.g. Korean in the reporter’s path).

Open3D already learned this elsewhere: other loaders go through FOpen → MultiByteToWideChar(CP_UTF8, …) → _wfopen. That is the same mechanism this PR uses, just via FReadToBuffer + tinyobj’s stream overloads (LoadObj(istream*) + MaterialStreamReader), which exist on the current v2.0.0rc8 pin.

3. CHANGELOG

Also pushed a CHANGELOG.md entry for this fix (bot request).

Happy to adjust further if you’d rather see a tinyobj pin bump instead of the stream wrapper — just say which direction you prefer.

[Fstarnb]

Follow-up: rebased onto current main and resolved a CHANGELOG.md conflict with the recent SYCL/SPZ entries so the PR is mergeable again. Code change in FileOBJ.cpp is unchanged.