Geometry
1:1
every triangle copied
Convert / OBJ → PLY
OBJ to PLY
OBJ in, PLY out, in this tab. OBJ and PLY both keep a vertex list, so this conversion is mostly a change of syntax: v lines become vertex properties, f lines become a face list.
→OBJ text (v + f lines) in · ASCII vertex + face lists out
Source
Result
.
PLY file · ASCII vertex + face lists
Same triangles, OBJ-style geometry rewritten as PLY. Convert, then download the . file.
—
- Triangles
- —
- Vertices
- —
- Time
- —
- Size
- —
Materials
in → none
geometry only
Units
none
OBJ stores no unit field
Engine
in-page JS
OBJ reader · PLY writer
First load
0 KB
no external script
Status
live
runs in this tab
OBJ → PLY · mesh to meshoutput ASCII vertex + face lists
What actually changes in the file
OBJ and PLY both keep a vertex list, so this conversion is mostly a change of syntax: v lines become vertex properties, f lines become a face list. Groups and material references do not survive, because the PLY writer emits geometry only.
| Field | OBJ (source) | PLY (target) | What happens |
|---|---|---|---|
| Triangles | stored | stored | copied 1:1, never remeshed |
| Vertices | shared list | shared list | coincident points merged on write |
| Normals | optional | not written | your importer recomputes them from the faces |
| UVs | optional | not written | nothing in OBJ to carry over |
| Objects | named groups | one element | every shell lands in the same object |
| Units | none | none | no scaling is applied |
| Materials | sidecar .mtl | none | geometry only, no sidecar file |
What this converter does, and what it does not
- Reads
- OBJ text (v + f lines)detected from the file contents, not the extension
- Writes
- ASCII vertex + face listsPLY output carries geometry only
- Merges vertices
- yescoincident points collapse before writing
- Scales units
- nocoordinates are copied as they are
- Repairs meshes
- noholes and non-manifold edges pass through unchanged
- Size limit
- memorybounded by the tab, not by a server quota
Convert, or convert to something else
OBJ → PLY is the right move when the next tool wants PLY. It is the wrong move when it does not.
Convert to PLY when
- Your pipeline expects PLY but the asset arrived as OBJ
- You want a text mesh with an explicit vertex count in the header
- You are preparing data for a scanner or research tool
Do not convert to PLY when
- You need the OBJ's groups or .mtl materials downstream
- Your OBJ is quad-based and you want to keep quads
- You need binary PLY for size
Waiting for a file
Frequently asked
Do OBJ groups become PLY elements?
No. The writer emits one vertex element and one face element, matching what most PLY consumers expect. Group boundaries are lost.
Are UVs carried over?
No. The reader ignores vt lines and the writer emits x/y/z only.
What about negative indices and polygons?
Both handled: negative indices are resolved against the vertex count, and polygons are fan-triangulated before writing.
Is the vertex order preserved?
Not exactly. Duplicate positions are merged, so indices shift; the surface is unchanged.
Can MeshLab open the result?
Yes. ASCII PLY with float vertices and a uchar-int face list is the most widely supported variant.
Related pairs
- STL to OBJreverse
- OBJ to STLsame family
- STL to PLYsame family
- PLY to STLsame family
- PLY to OBJreverse
- All 132 pairsmatrix