VRML primitives and merging of adjacent shells

#1

Trying to test print in multicolor+ with a VRML2 file that was printed before by a well-known competitor, I was surprised to see it rejected as containing over 400 individual shells.
Now this model is composed of intersecting VRML “sphere” and “cylinder” primitives, each with its own object color assigned to it. The number of shells clearly corresponds to the number of spheres and cylinders, so it seems your site software does not merge adjacent or intersecting meshes automatically like at least some of the competitors do. Is this true in general, or is this a particular problem with my file ? (I tried converting it to X3D, DAE and OBJ and saw the same 406 shells reported on the analysis page, so this does not appear to be specific to WRL.)

Merging the shells myself would have the drawback that I would then need to texture (or vertex-paint) the model, which I would like to avoid as it could get quite tedious.

#2

Hello,
Thank you for contacting us. Could you please inform us about the order number. In that way, we can have a look at the problem and contact you again via mail.

#3

Sorry about lack of information. This is about order IMC129367 , modelId=06d69310-c523-4d3e-82e5-51908debf011

#4

Thank you. We will have a look at it and keep you informed via mail as soon as possible.
Have a nice day.

#5

Thank you. I see Olha has now replied to my initial reply, my fault for being impatient and cancelling the order instead of seeking a resolution right away. (Now I hope that the 406 shells
is just misleading raw data from your tool and the actual issue is that the model has two shells that may not be recognized as permanently interlocking. Actually demonstrating this feature of the structure is the purpose of this educational model)

#6

So tech support was kind enough to “fix” my two current test cases using their Materialise Magics software, and I am eagerly awaiting the multicolor+ prints.
(The fundamental issue with my formally correct but practically unusable VRML still remains to be solved, so far I am not entirely happy with the prospect of either buying a Magics license or having to bother CS each time I need to buy this type of model.)

#7

Prints arrived and do look great - this really looks like a big step up from the old zcorp gypsum prints.
Now I am looking into improving vrml support in meshlab to import my files for remeshing and texturing, as that seems to be an easier route than learning how to do the same in Blender (or rewriting my own software to output a single textured mesh).

#8

Hello,
We are very happy to read that the prints looked great. We are looking forward to receiving more orders from you in the near future.

#9

Hi mkroeker,

Not sure this can help, but you can try 3mf file format next time. More info about file format - https://3mf.io/
Also you can use tool to convert files to file format 3mf. - https://3mf.azurewebsites.net/

Maybe this works better for you than vrml.

#10

Thanks for the pointer. I do know about 3MF, but the format is sufficiently (as in completely) different from what my software is able to write as to require a major rewrite. And I suspect I would run afoul of the conditions of use of the azureweb service if I were to sell prints eventually. Adapting meshlab for my needs seems to be surprisingly simple (though getting a successful build of their current devel tree even without my changes is a different matter :slight_smile: ) And at least now I know that the multicolor+ is well worth the effort.