meshing speed

Added by Jonah Barnett over 7 years ago

Hi. Two (possibly related) issues I would like to ask about, regarding the meshing speed for screen redraw and for stl output. I built a couple of quick tests using an array of vSpheres:

First test:
  • 24 x 24 x 10 vSpheres using vArray
  • total 5760 spheres
  • display mesh generated in about 20-30 seconds
  • array size approx 100mm x 100mm x 42mm
  • attempted to export stl with slice size approx .05 in each axis
    RESULT = Rhino using 2.4Gb RAM but hanging inifinitely. Eventually i shut it down.
Second Test
  • 10 x 10 x 8 vSpheres using vArray
  • total 800 spheres
  • added a vBend
  • display mesh generated in about 20-30 seconds
  • array size approx 60mm x 80mm x 60mm
  • attempting to export stl with slice size approx 0.2mm in each axis
    RESULT = Display mesh without bend took about 7-8 seconds to generate. Including bend, this multiplied up a few times (i don't recall the actual time). Currently trying to export the stl, but after 15 minutes, still the progress is only at 4% completed! Task Manager shows that Rhino is using 2.55Gb RAM but hanging inifinitely :(

Actually this resolution is MUCH worse quality than we actually need for production slicing. Is this speed issue just temporary? Is there internal progress to improve this? Or am i not using the export settings in an optimal way?

my system is Intel i7 @ 2.93GHz, running Win 7 64-bit


Replies (10)

RE: meshing speed - Added by Jonah Barnett over 7 years ago

Now trying to export a slice file to build on one of our printers. The object is 64 vSpheres (polar array of 8 spheres, arrayed again x 8). Object bounding size is approx 60mm x 30mm x 20mm. Our typical export resolution for this size object is .0254mm. Using vExportSLC, Rhino is completely frozen, again using 2.59Gb of RAM and I must shut down my session... I would post the model for your comparison. But of course, my Rhino session is frozen and I did not save the test model... So, I would really like to know what is going wrong here? :0


RE: meshing speed - Added by Turlif . over 7 years ago

What release version of Symvol are you using? Please post the test model here and we can take a look at it. I just ran a similar test of "Second Test" to an STL file and it took 50 min. I will post time on slicing tests next but better to use coordinate models.

It looks like you used the STL not mesh option which is correct. We should be more clear and let users know that they should always opt for saving the data to a file not providing it to Rhino. Rhino as a 32 bit application has limitations we are locked into (We will have a 64 bit version for Rhino 5). No such limitation exist for saving to disk. It is also faster if you save disk and will, no matter how long it takes, eventually complete (of course based on free disk space).

Here are a few suggestions:
1. when using vExportMesh choose STL not mesh for output
2. for Slices use vExportSLC for export not vExportPolylines
3. the less nodes in a object or tree the faster the system will be - use vTile in place of vArray when possible (for every object in vArray effectively there is one node - not true for vTile)
4. use a different machine for export/post possessing than your design system with as many cores as possible on board

I should say in the last case of sampling a 6cm object at 25 microns you should expect it to take quite a bit of time.

In regards to render time, we are a computationally heavy and this is our current limitation, however the near yearly doubling of the number of cores on systems should allow users to make more and more complex objects in the future with our tools. Also, keep in mind that all objects made with Symvol are watertight(including vArrays) - so in the case of Rhino this would mean making 5760 spheres and applying a Boolean union to all of them. Symvol may take time but it should complete the tasks you ask for.

In addition, we are working on a significant new acceleration method which will be released in the near future and a 64 bit version for Rhino which will help with in Rhino creation of meshes for example.

RE: meshing speed - Added by Jonah Barnett over 7 years ago

Hi Turlif. I'm using V1.1 (the most recent from a couple days ago). According to your suggestions, I am already doing everything in the same way. Also I just exported a text model (simple vSphere) and noticed that only 2 of my 8 (virtual) CPU cores are being used. This is obviously some problem. Is there a limitation on this? Or a setting i can adjust in SymVol or in my system?

For production work, we can not wait 50mins to slice a very small model as the one used on my test. As a point of reference, last week we exported a 30,000,000 facet stl from (brand-X voxel modeler) in the size of 80mm x 60mm x 50mm. The step size was .0508mm (double our normal size of .0254mm). I recall the exporter took just a minute or two to build the mesh. We also built a high-res stl @ .0254mm which took just a few extra minutes to complete. And this was a very dense model, built from over 2,000 Rhino elements merged/differenced into a single volume. So then we sliced this mesh in JewelCad without any problems in just a few minutes. Speed is critical for our daily workflow. Our maximum wait time must be minutes, not hours per piece.

I wonder is there some way to extract the display mesh directly form the volume?

Also - any news you could give me on 3 things would be great:
1) ETA for converting my own objects into volumes - These simple sphere tests really don't provide much reference. I need to start using SymVol on real models to know how best we can make use of it...
2) Ability to collapse nodes into single volumes...
3) 64-bit version...


RE: meshing speed - Added by Turlif . over 7 years ago

Hello Jonah. Again, thanks for all the feedback. I should mention that meshing is not really multi-core in Maker yet - but that is around the corner (next Maker release if all QAs well). In terms of using any in scene mesh - this is not possible as we use a direct method for rendering. If you can provide even an example object in Symvol (even one of the test objects you made) or a command line dump so we can recreate the object it would be very helpful on our end for testing and optimization. We are quite responsive to requests - better when we have exact data to work with.

Also can you describe your tool chain process a bit more, you use Rhino and then export to a voxel tool? What is the purpose of going to voxels - additional modeling or ability to combine everything? This will help me better understand how we can support your process/objectives from a Symvol view point.

For the meshing/slicing of complex objects(objects with 100/1000s of nodes) at very fine resolutions this will likely always take more time than systems using voxels/meshes (naturally we aim to make that gap as small as possible and slices from meshes can produce bad results for complex objects). Of course the upside of Symvol is you have a real solid object defined at infinite resolution that can be easy and radically modified (this will be taken even further in the near future).

Answering your queries:
1) If mean conversion of for example meshes to Symvol, I can not give you an exact date. I can say it will be very soon and we are already modeling with legacy data in house (we also take Dicom/voxel data directly in our in development build).
2) We are still looking at the best way to do this f or fine detail objects such as the ones you describe, so ETA is unknown(for larger/simple objects we can already do this).
3) Our 64-bit is tied to the release of Rhino 5. Do you use Rhino 5 beta now?

RE: meshing speed - Added by Jonah Barnett over 7 years ago

Hi Turlif. Currently, I'm looking to SymVol as a means to combine volumes for printing/slicing at the prototyping stage. We try to keep our final models as Nurbs, because this makes things much easier on our manufacturing end. I imagine we will find ways to incorporate SymVol beyond this purpose, but it will take some experience to know this...

We use Rhino 5 beta only for limited functions, when 32-bit can not supply enough RAM for the task...


RE: meshing speed - Added by Jonah Barnett over 6 years ago

Hi Turlif. It's been nearly one year since this discussion. Still no news on Pro version, still no 64-bit version, still no importing "legacy" data, and unless i missed a major beta update there hasn't been any advancement toward improving the export and slicing times/results as I described earlier in this thread? Still interested in Symvol but waiting a year with almost no news would test anybody's patience. As you mentioned "legacy data" would be supported "very soon", but... where is it?


RE: meshing speed - Added by Turlif . over 6 years ago

Hello Jonah,

Thanks for your patience and posting. Our small team has been very very busy. We have just publicly announced our company and the Symvol kernel at the 3D Printshow in London. Mesh In did take us longer than we anticipated. However, both the free and low cost versions of Symvol for Rhino do currently take in mesh data as first class objects that can be used as any other primitive in our system (see the slide at the front page of our website). This includes blending, shelling, adding blended micro-structures and as always watertight. In addition we have repair tools for meshes and can even produce volumes from "polygon soup". We have also release a number of other features and substantial bug fixes (e.g. Rhino layers are now fully respected) and have some more surprises for the import of data in the works.

We have also launched a Kickstarter campaign for a cross platform application for mixing, repairing and direct fabrication of meshes:

The 64-bit version for Rhino 5 is in the works right now and we hope to be able to ship by the end of year.

Best, .t

RE: meshing speed - Added by Jonah Barnett over 6 years ago

Hi Turlif.

Your product comparison chart still says (coming soon) for converting meshes to volumes... I see the Community version can import a maximum of 18000 polygons. Typically we are dealing with meshes of several million polygons. So i ran a quick test, reducing some meshes down to below the 18k limit. Then I ran VUnion on all the objects (about 12 objects) and the resulting volume was soooooooooooo slow to redraw. Keep in mind this is from converting meshes below the 18k limit. Will Symvol "Pro" be able to convert +1M polygon meshes? Will it see improvements in redraw and export/slicing speed? OR we need to wait for 64-bit version? I can tell you from experience that another voxel system can easily import multi-polygon meshes on 32-bit systems and maintain very high working speeds. and slicing/export times from that program are very fast. As many people complained to Rhino programmers, advising us to "use the 64-bit version" is not the solution. Another question then - Is the slow process time due to some Rhino limitation? Or the same problem will occur if using Meshup?

Sorry if i sound like a nag, BUT we have a very demanding workload (very complex jewelry projects, and with very short deadlines) and performance is the most critical factor if we adopt new software or not. So far, i don't see a fast & dependable solution for demanding work. Although I'm hopeful you will change my mind...


RE: meshing speed - Added by Turlif . over 6 years ago

Hi Jonah,

Our team is traveling at the moment so please excuse my delayed reply. Thanks for the notice we on the comparison chart. It was on our ToDo list unfortunately it seemed to have dropped off due to our rather insane schedule over the last 2 months. Should be corrected today.

Happy to have your feedback and this discussion. I would really like to know your case study and work flow. It would allow us to understand how we might be useful in your workflow and exactly what parts of our framework to focus on (there are many meanings to "faster" and even more ways to be "fast").

Maker (our free version) is limited to 18k polygons and community is open ended and can convert meshes up to the 32/64 bit Rhino memory limit. We have tested up to +8M polys. When working with many meshes and operations at once our system can be slow and we are working to make it faster. However when working with one large mesh, it is faster. Also, some meshes will be slower than others - poly count is not the only factor and meshes with "leaks" are dead slow (it is possible in some rare/currently unsolvable cases bad meshes can pass our mesh check). If there any sample model you can share with us?

In general Pro will include speed improvements - we are working on GPU acceleration for this release. 64-bit will not have a huge impact on speed, but it will let you convert larger meshes.

Voxel systems can be faster depending on the voxel resolution. We do not use voxels, our system uses continuous volumes, not discreet data. Regardless of the mesh you give us we will always convert 1 to 1 with no aliasing. Our approach is generally accuracy over speed (however speed is a development focus as accuracy using our approach is "built in"). Also note that modeling in our system is non-destructive (such as the video with the Teapot/Bunny). This means while display can take time (and yes is even a pain - see this model recently done with community: ) the overall modeling process for the designer is often faster (more so for iterative modification and design reuse).

Part of our speed issue is indeed interfacing with Rhino but we are looking at ways in Rhino 5 to overcome that. MeshUp will be faster as these issue will not exist - in fact we are looking forward to "freeing" our rendering engine. We also have a cloud solution in the works to offload the work.

It might be worth have a short webinar from us and for us to get some understanding of your exact needs such that we can consider how we might get Symvol's power working for you.