I'm finding that when I upload coloured models where the colour is a vertex attribute the model preview doesn't match what is upload. I've attached 3 images that show the issue. The ShapewaysPreview.jpg shows how it shows up here and the other 2 show how it should look. As you can see in Shapeways there are a large number of triangles with the wrong colours on them.
Could be wrong orientation of face normals (from triangle vertices listed in wrong winding order) affecting the lighting calculation, or even gaps in the original mesh that shapeways' site software filled in. If vrml/x3d you could try previewing the file with view3dscene.
What is view3dscene? There are no gaps, I think you can see that from the screen shots and I can confirm all the face normals are pointing the same way. As shown in this new screenshot with normals displayed. I've shared the file privately with Youknowwho4eva
View3dscene is a free, cross-platform vrml/x3d/dae/obj viewer - I find it useful for checking that the exported file really corresponds to what is shown within the originating design software. (Been using it for years to render 3d models before it became convenient to print actual physical copies)
Oh I see what's happening. I'm writing out vertex colours as x3d supports them, but Shapeways and view3dScene are changing them to polygon colours. So where the triangle has 2 white vertices and one red one it's just making the entire polygon white. Hmmm bit of a limitation there....
I can improve things my end by pre-converting to polygon colours which will be the average of the vertex colours rather than just picking one of them. Does the printer software do the same thing as the preview though, that's the question.
That should not be happening I think - if your file actually has ColorPerVertex TRUE, you should see the linear average of the vertex colors as you move across the face. Seeing that you mentioned Blender above, could this be related to a bug in 2.76b https://developer.blender.org/T47647 ? EDIT: The snippet you posted above definitely has colorPerVertex="false" (sorry for not getting around to looking at it earlier - busy day at work)
That could be it. I'm using 2.77 though so I would have thought it was fixed. Is there another way that you know of to convert .ply files to .x3d?
I do not see the T47647 issue mentioned on the release notes and bug fixes pages for either 2.77 or 2.77a, but it occurs to me that the link to the fix (under "Worked: see commit...") leads to a single python script file for the x3d export plugin. You could try pulling just that one file (by downloading the single .py file listed under "Changes(1)" on the repository page) and replacing the one in your current installation of 2.77.
Also, netfabb studio basic (netfabb.com, now a subsidiary of Autodesk) should read ply and write x3d (though I seem to remember seeing some bugs in their x3d export)
I managed to get meshlabserver (the commandline version of meshlab) to read and write a file that looks fine in Blender, a total disaster in view3dScene and has the same original error when uploaded to Shapeways I'll try Netfabb and see what happens there.
Netfabb much the same story, it looks fine when loaded in but when written out and uploaded Shapeways has the same issue with it. I'll have a look at that python patch for Blender
Get it from https://developer.blender.org/F329666 (did not realize downloading from the blender source system is that complicated, the link I originally suggested just leads down to the side-by-side diff further down on the page. Need to click on "View Options" there and select "show raw file (right)" to get that page where "download file" is finally offered...)
Ok so I patched Blender with the fixed Python file and now view3dScene loads it correctly, interestingly no mention of the colorPerVertex tag that I can see. However Shapeways still can't diplay it correctly. See screen grab attached. It see the gradients on the polys now, but on the wrong vertices, arrgghhhh