Here I have an OBJ file of size 330 MB with the following information in the header:
On import into Rhino, here are the properties:
On export from Rhino, the file size in now over 1 GB and causes other programs that I need this mesh in to crash. I tried mesh repair tool, weld, etc. Weld reduces vertices but messes up the mesh texture a lot. It also doesn’t bring it down to the original value of 1,739,728. It brings it down to about 3 million. What’s going on?
I took a look at your 318MB .obj file. Rhino 7 opens it just fine and saves it as a 147 MB .3dm file. Rhino compresses meshes which account for the size difference. You didn’t include your material/texture. I’m assuming this is what bloats the file to a gig.
You mentioned welded vs unwelded vertices, so I won’t explain that. But you might take note that Rhino store both single-precision vertices (for the GPU) and double-precision vertices (for computations). This, along with with other properties, such as vertex and face normals, texture coordinates, etc., add to the bloat.
You didn’t mention what you intention was, with the mesh. But if its just visualization, you might consider just importing a point cloud with vertex colors. Rhino imports .e57 files nicely.
I basically have two textured meshes like this, and I need to combine them into a single .wrl file for another program to accept it. I have done this in the past in Rhino without issue. This time, for some reason, I get over 7 million vertices on import in Rhino, versus the expected 1.3 million which you will see if you import the .obj into MeshLab. The number of faces stays correct between MeshLab and Rhino. These additional vertices carry over into the export, and the next program cannot handle it.
I specifically need a single .wrl file, and I have tried other avenues such as Blender and MeshLab to no avail. All I want to do at this point is figure out why it comes in at 7 million vertices so that I can fix the problem at its source, because I already know that the pipeline through Rhino is a feasible solution. The next program cannot handle point clouds.
The double-precision aspect may have something to do with it, but why would that affect the total vertex count readout?
OBJ allows for differences in vertex(v), normal(vn) and texture coordinate(vt) counts. It’s just a collection of faces, each with a number of corners that are indexes into a big list of v, vn and vt objects. Rhino doesn’t work that way. A mesh face has 3 or 4 indexes into the vertex array. It assumes that the vertex, normal and TC arrays are parallel (all have the same count and the same index into all of them gets you the appropriate value). So on import, a structure is made for each obj face corner and adds it to an array. After the read is complete it sorts that list and merges duplicates. Then those are added to the mesh and the face indexes set appropriately. So, unfortunately, I’m not aware of a way to work around this if you want to keep TCs and normals. Rhino exports OBJ files like a Rhino mesh.
One more thing Evan. I looked at the PLY format and it’s more like Rhino. You have a vertex and it might consist of three floats. But it could also be 6 floats, a vertex and a normal, for instance. Or 8 floats, vertex, normal, tc. You get the idea. The key is that they are in one unit. If you can get a PLY file then there should not be the blossoming of size making the parallel arrays.
Thank you for your response, it makes a lot of sense. I have tried the PLY workaround. It seems that it only likes vertex colors, no textures. On import with a face element property of the form “property list uchar float texcoord” such that a face element looks something like:
Rhino just turns up blank. No import error, just nothing appears. Oddly, it is selectable, you can assign textures, etc. When I look at the properties the vertex count seems right, the face count seems wrong, and it says “Invalid Mesh.” The one with only vertex colors has the right face count. I assume this is due to similar reasons as you stated above.
The next program that I need to go into cannot render using vertex colors. It only accepts texture coordinates. My only other option now is to bring in the mesh with vertex colors and see if Rhino can generate a texture parametrization and jpg file for me from the mesh vertex colors.
Although I cannot explain the problem in Rhino, I will suggest an alternative application to try since you mention neither Blender nor Meshlab work.
Accutrans3D … the developer has roughly 30 years of experience with this app, don’t let the website or the GUI fool you.
The cost is small (underpriced if you ask me) and you can try it for free. It does not have the bloat that modern apps have as it roughly the same interface as it was 30 yrs ago. It was updated regularly until 2021.
