It appears I've been suffering from the same problem today, so I'd like to add my voice to the suggestion of removing the image render from the timeout. As a related issue, it would also help to have a clearer error message that this is the reason for the failure. The error message I received simply said "The design could not be validated," which is not ideal for diagnosing where the problem lies.

I'm very happy with the service otherwise - and the great support I received through the forum!

Thanks for following this up. This happens for me when I try to upload certain models, especially VRML files with colour values assigned to nodes.

Although I believe the model is okay, after some time I receive an error message by email like the one attached.

The problem appears to be a combination of model complexity and colour/VRML, since the model uploads fine without colour as an STL file, or if I lower the polygon count.

It's notable that previously the Shapeways software has managed to calculate the cost correctly, but the image didn't get rendered, making it seem like the problem occurred during the render stage (which tallies with what Paul suggests in his email).

Thanks again for looking into this. It would be great if there's a fix, since I guess it would allow for better quality prints to be created.

The issue lays with the intersecting meshes, see image below. I chopped away all but the intersecting region where the tighter and less tight spirals cross. The tighter spiral is within the other mesh - the colour information pertains to the outer skins of the meshes and something along the way confuses Shapeways MeshMedic to the extent that the colour information gets disregarded when the meshes are merged - the only solution I've found to resolve this is to merge the meshes with NetFabb Cloud Service before colouring the model, but iirc this is not an option for you as the model is created and coloured 'on-the-fly'

That's impressive detective work! I can understand that the software could get confused where triangles cross, given that the colours are associated with nodes. However, it still seems odd to me that it works okay with a lower resolution version, but not with the high resolution mesh. They don't look that different to me (although my understanding is very limited unfortunately). What you say would seem to make sense though.

Unfortunately you're also right that the mesh is coloured at the same time the vertex positions are generated, and unfortunately decoupling and then reapplying the colour is way beyond my 3D modelling capabilities! I'd love to be as proficient as other people clearly are on these boards!

Given this, from my perspective it would (obviously!) be great if this is something that can be fixed at Shapeway's end, but I appreciate that this could be just a fundamentally difficult thing for the printing software to deal with. From your previous comments, my main concern was that this might be a problem with the rendering process rather than the printing process. If it's the former, it would seem a shame to reject models that are otherwise fine to print.

You say the lower res model uploads fine, yet the higher res one fails - in all probability this is down to the time out on the render side of things, are you able to get somewhere inbetween for resolution and try that?

Unfortunately I cannot attach my client's model files publically and they are too big to send in a PM, the models did eventually upload ok at an earlier time of (the next) day when it's probable that there was less load on on Shapeways systems. I'll PM you a link to the model page.